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

["hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> ---
> 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?

Note that I do intend to disable it for all POD types for now (both at 4.9 and
4.10, at the proposed patch does).  We may revisit it for 4.10 later, but I do
not expect this is giong to cost too much of optimization; basically it will
only lose in paths where there is call of virtual pointer of one derived type
but we know that the instance is of incompatible derived type.  These cases are
harmful, since inliner & IPA code will agressively inline and optimize along
those provably impossible paths, but it is not _that_ serious.

What matters currently is that types with vtbl pointer are not changing
randomly.

Note that there is -fno-devirtualize as workaround in 4.9

Thank you!
Honza