------- Comment #124 from rguenther at suse dot de 2007-05-23 09:35 ------- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
On Tue, 22 May 2007, dberlin at dberlin dot org wrote: > ------- Comment #116 from dberlin at gcc dot gnu dot org 2007-05-22 18:13 > ------- > 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 17:01:40 -0000, gdr at cs dot tamu dot edu > <[EMAIL PROTECTED]> wrote: > > > > > > ------- Comment #114 from gdr at cs dot tamu dot edu 2007-05-22 18:01 > > ------- > > 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: > > > > | 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? > > > > I just raised it, mainly because I do not believe your conclusions are > > right. > > > > The type information you can get from write and read are not just > > those appearing lexically in a scope. In fact, the semantics is defined > > in terms of the run time read and write access. > > That is what makes "C a strongly typed and weakly check language" (DMR). > > > > This whole issue does not mean you have to abandon TBAA. It means you > > have be careful in how you use the information gained from TBAA. In > > particular, many conclusions are OK when you have the definition of > > the objects at hand. > > Uh, you do more or less have to abandon TBAA for pointer arguments > unless you can account for every single caller of your function, and > ensure that none of them are passing you pointers external to what > your compiler can see. This case is *extremely rare* outside of the > user giving us a whole program guarantee. > > TBAA's main use is in fact, in disambiguating pointer arguments. If > you take that away, it becomes pretty much useless. > It's guarantees about local objects were never interesting. But you can still perform hoisting loads of incoming pointer arguments and sinking stores to incoming pointer arguments. Please read comment #105 and come up with a testcase where we wouldn't be allowed to do a useful transformation we do now. So I believe making placement new work with our current scheme will severely pessimize placement new users, but if we slightly change rules for everyone we'll be all happy. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
