This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
- From: "dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 2 Jan 2007 03:01:37 -0000
- Subject: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
- References: <bug-29286-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #27 from dberlin at gcc dot gnu dot org 2007-01-02 03:01 -------
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286