From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17987 invoked by alias); 22 May 2007 16:38:28 -0000 Received: (qmail 17865 invoked by alias); 22 May 2007 16:38:00 -0000 Date: Tue, 22 May 2007 16:38:00 -0000 Message-ID: <20070522163800.17864.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mark at codesourcery dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg01893.txt.bz2 ------- 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