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

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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.

Richard.


-- 


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