[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

["mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #93 from mark at codesourcery dot com  2007-05-18 19:01 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement
 new does not change the dynamic type as it should

ian at airs dot com wrote:

> void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
> void g() { int i; f((double *)&i); }
> 
> And the specific question is whether we are permitted to interchange the
> assignments to *p and *l.

I do not think we are.

> void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
> 
> Is that valid?  Is the compiler permitted to interchange the assignments to *p
> and *l?  Consider that, as in comment #73, p might actually point to a union of
> int and long.  Does that fact that that union might exist somewhere else make
> this test case valid?  Presumably it does not.  Presumably this is invalid.

Agreed; this case is invalid.

> So if that is not valid, and the placement new case is valid, then what is the
> essential difference between the cases?  The variable is being accessed via two
> different types.  Why is that OK?

Because placement new changes the type of storage, in the same way that
using ordinary ("delete") and then using (ordinary) "new" (but getting
back the same memory pointer) does.  The placement "new" operator is
special.

> You're right that don't have to abandon TBAA to make this work, that we can
> make it work by turning placement new into a memory barrier.  But then you have
> to address comment #42.  That approach will cause a performance regression for
> natural valid code.  The question then becomes whether we are willing to pay
> that performance regression for normal code in order to support this sort of
> weird code.

I am willing to accept that performance regression.  I don't consider
that code "normal"; many C++ performance libraries now provide a way to
produce an uninitialized container, precisely to avoid default
construction.  POOMA could use that technique.

It would of course be better (though, in my opinion, not essential) to
have a more gentle barrier.  If we could tell the compiler to forget the
type of anything that the argument to placement-new might point to, but
not to assume that arbitrary weirdness has occurred, then the compiler
could still eliminate the redundant stores.

In other words, in Comment #42, the problem is that the volatile asm
tells the compiler that not only must the stores/loads not be reordered
across the barrier, but that stores before the barrier must actually
occur because their may be some arbitrary action at the barrier that
depends upon the values written.  If we had a barrier that says just
that the operations may not be reordered across the barrier -- but does
not say that the operations before the barrier are side-effecting --
then we could still eliminate them as redundant.


-- 


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