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

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

------- Comment #115 from dberlin at gcc dot gnu dot org  2007-05-22 18:10 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should

On 22 May 2007 16:54:24 -0000, mark at codesourcery dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #113 from mark at codesourcery dot com  2007-05-22 17:54 -------
> Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement
>  new does not change the dynamic type as it should
>
> gdr at cs dot tamu dot edu wrote:
> > ------- Comment #112 from gdr at cs dot tamu dot edu  2007-05-22 17:46 -------
> > Subject: Re:  [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> writes:
> >
> > |                         But, I don't think the standard contemplated
> > | these issues in sufficient detail to make it useful in this respect.
> >
> > The issues has been raised on the -core reflector.
>
> So that I understand, do you mean that they have been raised in the
> past, and settled, or that you've just raised them now?
>
And if you've raised them now, can you please try to ensure that the
discussion covers what to do if the union'ing happens outside the
current translation unit?

IE What to do about cases where
1. One union member is written
2. We are being passed the address of a union member at the same offset
3. It then it is casted to a pointer to the type of the union member from 1.
4. It is stored/loaded

It is literally impossible to know whether the pointers being passed
into a function are from unions or not, since the union'ing may occur
outside of our translation unit.
This is true unless it is a static function whose callers do not pass
in pointers that are ever acquired externally.

If you take a strict reading of the standard that union'ing makes
everything okay, even when you can't see their may have been a union,
then you simply cannot perform TBAA except for completely local
variables, or when you are dealing with static function arguments that
meet the parameters above, or when you can get a guarantee you have
the whole program.  The ideal resolution here would be that all
accesses through a union must be must be visibly accessing through a
union type.  This is one of the proposed resolutions to the similar
problem in C (there were also proposals that said something about TBAA
changing at  function boundaries, but these are ridiculous given the
fact that it does not specify what happens if you inline, etc, so that
the function boundaries aren't where they were originally).


-- 


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