------- Comment #132 from dberlin at gcc dot gnu dot org 2007-05-23 19:03 ------- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
On 23 May 2007 08:35:12 -0000, rguenther at suse dot de <[EMAIL PROTECTED]> wrote: > > > ------- 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. > Have fun encoding this into the IL :) If TBAA can't say things about particular load/store pairs, without having to do a lot of work to see what is in between them, it's not going to be useful to us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
