[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 at gcc dot gnu dot org>]

------- Comment #89 from mark at codesourcery dot com  2007-05-18 17:44 -------
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:
> ------- Comment #86 from ian at airs dot com  2007-05-18 17:24 -------
> Re comment #80, comment #81, comment #82.  My patch handles the placement new
> in comment #73 to indicate an alias between double and long.  The mis-ordered
> code is actually aliasing int and long.  That aliasing is due to a cast to
> (int*).  There is no placement new in that cast.  There is no reason for the
> compiler to avoid exchanging the store via int* and the store via long*.  Why
> should it? 

I don't think the fact that "p" is a "double *" is relevant; it could
just as well be "void *".  This kind of code is unambiguously valid:

  void f(double *p) { (int*)p = 3; }
  void g() {
    int i;
    f((double *)&i);
  }

Pedantically, the alignment of "double" has to be no stricter than "int"
for this to be valid, but since we define pointer conversion as a no-op,
it's always valid in GNU C.

This is why I liked your earlier patch that made placement new a memory
barrier.  I think the right handling of placement new is basically to
say "everything we know about types is forgotten here".  One can limit
that to things to which the operand might point, but points-to analysis
(should not) tell you that "p" and "l" cannot point at the same place,
since we have no idea what "p" points at.

I don't think this is equivalent to totally disabling TBAA in C++.


-- 


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