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

["Daniel Berlin" <dberlin at dberlin dot org>]

On 1 Jan 2007 00:41:44 -0000, mark at codesourcery dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> ------- Comment #26 from mark at codesourcery dot com  2007-01-01 00:41 -------
> Subject: Re:  [4.0/4.1/4.2/4.3 Regression] placement
>  new does not change the dynamic type as it should
>
> dberlin at gcc dot gnu dot org wrote:
>
> > If we add a placement_new_expr, and not try to revisit our interpretation of
> > the standard, we can just DTRT and fix placement new. This would be best for
> > optimizations, and IMHO, for users.
>
> I agree that treating placement new specially makes sense.  The first
> argument to a placement new operator could be considered to have an
> unspecified dynamic type on entrance to the operator, while the return
> value has the dynamic type specified by the operator.  (So that the
> pointer returned by "new (x) int" has type "int *".)

Right.

> I'm not sure that placement_new_expr is the best way to accomplish this,
> but, maybe it is.  Another possibility would be to define an attribute
> or attributes to specify the dynamic type of arguments and return types,
> and then have the C++ front end annotate all placement new operators
> with those attributes.
It would be nice if we could transform those attributes on
gimplification to something like an
an "alias preserving cast" (or something of that nature) that states
that the  cast is type unioning for alias purposes (IE that the
possible types of the result for TBAA/etc purposes is the union of the
type of the cast and the type of the cast's operand)..
Not a fully fleshed out idea, just something that popped into my head.