------- 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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
