This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
- From: "aph at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 04 May 2014 10:01:36 +0000
- Subject: [Bug ipa/60965] [4.10 Regression] IPA: Devirtualization versus placement new
- Auto-submitted: auto-generated
- References: <bug-60965-4 at http dot gcc dot gnu dot org/bugzilla/>
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.