[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 #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
<gcc-bugzilla@gcc.gnu.org> 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
> > <gcc-bugzilla@gcc.gnu.org> 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" <gcc-bugzilla@gcc.gnu.org> 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" <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?
> > >
> > > 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