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

["rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #105 from rguenth at gcc dot gnu dot org  2007-05-22 10:50 -------
Let me again do a step back and look at the problem from another view ;)

--

C++ aliasing imposes additional restrictions on transformations we
are allowed to do to memory references compared to C type-based
aliasing rules.  
Consider two memory references A and B which we need to know whether 
we can exchange them.

 - If we can prove that both memory references are
   to non-overlapping memory regions we always can exchange them (PTA
   can provide this knowledge).

 - We can always re-order two loads.

TBAA gives us another source of information to disambiguate the
two references.  So, if TBAA says the two references do not conflict then

 - we can hoist loads across stores.

     *double = 1.0;
     x = *int;

   if *int aliases *double the program is invalid.

 - we can sink stores across loads.  (this is just the opposite view
   of the above)

 - we _cannot_ re-order stores.

 - we _cannot_ sink loads across stores.

     x = *int;
     *double = 1.0;

   the store to double may change the dynamic type of what *int
   points to.

 - we _cannot_ hoist stores across loads.  (opposite view of the above)

Note that all the interesting stuff (hoisting loads and sinking stores)
is not affected by the stricter C++ aliasing rules.

The caveat is, that these rules do not map to our representation of
aliasing (VOPs) nor to type-based queries of the alias oracle.

--

So the proposal is to impose these additional restrictions ontop of
our alias representation and fixup passes that do not honour them.
One of them is loop load/store motion which messes up store ordering,
another is scheduling.

If anyone can come up with a clever way to encode the extra restrictions
into our IL be my guest (I wrapped my brain around this for some days now,
and only a may_reorder_accesses (A, B) style oracle can handle this, but
not VOPs in SSA form or something similar - we'd need a DU chain
and another set of VOPs but that looks way too costly)


-- 


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