This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965

--- Comment #11 from Andrew Haley <aph at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #9)
> (In reply to Andrew Haley from comment #8)
> > While it's true that we can play hardball on this one by insisting that only
> > char arrays should be used with placement new, it wouldn't really do any
> > good.  I don't think it would make any real-world code more efficient.
> 
> On the contrary, this bug is an example of making real code more efficient,
> just inappropriately because of the special status of char arrays.  We
> really don't want to have to assume that any random object can invisibly
> change type, as that would make type-based optimizations pretty useless.

In this case?  Really?  What real well-defined code would be pessimized by
disabling this transformation in the case of POD types?

> As far as I know people always use char arrays for placement new anyway; at
> least all the examples I've ever seen do.

I'm not really sure how, given that objects must be aligned.  We don't really
know how much code this transformation breaks, but I do know that it breaks in
ways that are hard to diagnose: in the Java example a function silently falls
through to whatever happens to follow it.

How about a compromise?  Make this optimization respect -fno-strict-aliasing. 
People already expect that option to disable type-based optimizations.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]