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: "mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 May 2007 16:38:00 -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 #111 from mark at codesourcery dot com 2007-05-22 17:37 -------
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:
> | No, I do not. And GCC historically has not; you are only allowed to use
> | the union for type-punning if the accesses are through the union
> | directly.
>
> I am not talking of the GCC's historical behaviour here, but what the
> standard actually says. For the object "t", above the last write was
> to the double field, therefore the read is well-defined.
Suffice it to say that I disagree. I'm not debating that you can read
the standard that way. But, I don't think the standard contemplated
these issues in sufficient detail to make it useful in this respect.
Pragmatically, I don't think that we should change GCC, after years of
people using it with the current rules, to make it generate inferior
code -- without clear guidance from the standards committee. IMO, that
needs to go beyond a reading of the current standard; there needs to be
a clear expression from the committee that, indeed, the compiler cannot
use TBAA in the way that GCC has historically used it.
I'm all for bringing G++ into better conformance with the standard, and
agree that correctness is more important than optimization, but I don't
believe that the standard was written with these considerations in mind,
so I don't think it can be relied upon in this respect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286