From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27956 invoked by alias); 23 May 2007 20:16:06 -0000 Received: (qmail 27006 invoked by alias); 23 May 2007 20:15:08 -0000 Date: Wed, 23 May 2007 20:16:00 -0000 Message-ID: <20070523201508.26959.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/msg02067.txt.bz2 ------- Comment #142 from rguenther at suse dot de 2007-05-23 21:14 ------- 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, mark at codesourcery dot com wrote: > ------- Comment #140 from mark at codesourcery dot com 2007-05-23 21:07 ------- > Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement > new does not change the dynamic type as it should > > rguenth at gcc dot gnu dot org wrote: > > > > > Gaby's claim is that given an arbitrary > > pointer "p", saying: > > > > (int *)p = 3; > > > > is the same as saying: > > > > *(new (p) int) = 3; > > > > That makes life for the optimizers much, much harder. > > > > > > I say so as well (that those are the same), but I don't agree that this > > makes life for optimizers much harder. > > Placement new is rare; assignments to pointers are everywhere. > > Note that the first case does not need to use an explicit cast. In a > function: > > void f(int *p) { > *p = 3; > } > > under Gaby's interpretation, we cannot be sure that "p" points to an > "int" before this function, so we can't be sure the write to "*p" > doesn't clobber memory of other types. TBAA is one of the few ways to > disambiguate pointers in the absence of whole-program optimization, and > this model really undermines TBAA. In C inside the function f we can indeed be sure *p points to an "int". Now what matters is, that even in C for double g(int *p, double *d) { f(p); return *d; } we cannot be sure (in absence of whole-program optimization or the body of f available) that the call to f does not clobber *d through the value of the pointer p. As it can look like void f(int *p) { double *d = p; *d = 1.0; } > Frankly, I'm surprised that you are taking this position. This is a > change to the compiler that can only hurt high-performance C++ > applications, which is an area I know you care about. I know that > you're unhappy about how Ian's patches might hurt programs that use > placement-new in an inner loop, but this model will impose the same > penalties on programs that write to pointers in an inner loop. No it won't. Or at least - I belive so - unless I see a patch that manages to implement placement new with the same minor restrictions. If you discount scheduling on in-order machines, what would be an optimization that can be no longer done with Gabys and my scheme? I believe there are none. Also other compilers manage to not miscompile in the face of placement new but still optimize loops with them. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286