From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27819 invoked by alias); 2 May 2007 15:57:33 -0000 Received: (qmail 27779 invoked by uid 48); 2 May 2007 15:57:24 -0000 Date: Wed, 02 May 2007 15:57:00 -0000 Message-ID: <20070502155724.27778.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/msg00177.txt.bz2 ------- Comment #29 from ian at airs dot com 2007-05-02 16:57 ------- Created an attachment (id=13497) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13497&action=view) Patch Here is one approach which fixes the test case. This introduces a new tree code, ALIASING_CONVERT_EXPR. It is conveyed into RTL via a flag on REGS: REG_ALIAS_ALL. I didn't try to really union the alias sets, I just said that the result of placement new can alias anything. This patch is essentially untested. I'm not very happy with this approach because it doesn't fail safe: it's too easy to lose the special aliasing, and then the problem appears again, but only with a more complicated test case. A safer approach might be to change the type returned by placement new and mark it as TYPE_REF_CAN_ALIAS_ALL, but then I'm worried about type conversion and type comparison problems, since it isn't actually a different type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286