From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11903 invoked by alias); 14 May 2007 16:42:39 -0000 Received: (qmail 11848 invoked by uid 48); 14 May 2007 16:42:23 -0000 Date: Mon, 14 May 2007 16:42:00 -0000 Message-ID: <20070514164223.11847.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: "ian at airs 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/msg00987.txt.bz2 ------- Comment #64 from ian at airs dot com 2007-05-14 17:42 ------- Re: comment #59: CHANGE_DYNAMIC_TYPE_EXPR does not have a result. I set it up so that it is essentially volatile, and represents an additional type aliasing at that point in the program. One of the earlier patches set it up as a cast. But it was hard to convince myself that it really did the right thing. A lot of code in the compiler strips casts for one reason or another. One would have to examine each of those places and make sure that it did not strip the cast inappropriately. Or, conversely, that it did strip the cast when it should. This would tend to introduce a bit of code in many different parts of the compiler, all to handle a very unusual case. Generating a statement with no result seemed more reliable to me. It's true that there is a downside: it may cause a placement new to be preserved inappropriately. But that seems like an unlikely case to me. I doubt that very much code does a placement new which changes types and then does not use the resulting memory. I think it's OK to misoptimize such code slightly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286