[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@gcc.gnu.org>]

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


-- 


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