From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13535 invoked by alias); 23 May 2007 15:55:05 -0000 Received: (qmail 13427 invoked by alias); 23 May 2007 15:54:50 -0000 Date: Wed, 23 May 2007 15:55:00 -0000 Message-ID: <20070523155450.13426.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: "rguenther at suse dot de" 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/msg02047.txt.bz2 ------- Comment #131 from rguenther at suse dot de 2007-05-23 16:54 ------- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, ian at airs dot com wrote: > ------- Comment #130 from ian at airs dot com 2007-05-23 16:43 ------- > In this example > > void foo(int *p) > { > float *f = (float *)p; > new (p) float; > *f = 1.0; > } > > the pointer is p. In fact the relevant pointer is always the argument to > placement new, and every pointer which PTA can associate with it. I don't read that into the semantics of placement new ;) Placement new doesn't care about the pointer used to refer to the memory it operates on. > We may simply have an impasse here. You have a set of rules which will change > the compiler to support placement new while giving better results for your > code. I believe that your change will penalize the code I used to work with. Ok, fair enough. I'll try to teach load-store-motion for loops to not re-order the inserted stores compared to the order on the loop exit path. This is the only transformation on the tree-level I came across that violates my proposed semantics. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286