From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15126 invoked by alias); 18 May 2007 18:01:59 -0000 Received: (qmail 15056 invoked by alias); 18 May 2007 18:01:38 -0000 Date: Fri, 18 May 2007 18:01:00 -0000 Message-ID: <20070518180138.15055.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/msg01439.txt.bz2 ------- Comment #93 from mark at codesourcery dot com 2007-05-18 19:01 ------- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should ian at airs dot com wrote: > void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; } > void g() { int i; f((double *)&i); } > > And the specific question is whether we are permitted to interchange the > assignments to *p and *l. I do not think we are. > void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; } > > Is that valid? Is the compiler permitted to interchange the assignments to *p > and *l? Consider that, as in comment #73, p might actually point to a union of > int and long. Does that fact that that union might exist somewhere else make > this test case valid? Presumably it does not. Presumably this is invalid. Agreed; this case is invalid. > So if that is not valid, and the placement new case is valid, then what is the > essential difference between the cases? The variable is being accessed via two > different types. Why is that OK? Because placement new changes the type of storage, in the same way that using ordinary ("delete") and then using (ordinary) "new" (but getting back the same memory pointer) does. The placement "new" operator is special. > You're right that don't have to abandon TBAA to make this work, that we can > make it work by turning placement new into a memory barrier. But then you have > to address comment #42. That approach will cause a performance regression for > natural valid code. The question then becomes whether we are willing to pay > that performance regression for normal code in order to support this sort of > weird code. I am willing to accept that performance regression. I don't consider that code "normal"; many C++ performance libraries now provide a way to produce an uninitialized container, precisely to avoid default construction. POOMA could use that technique. It would of course be better (though, in my opinion, not essential) to have a more gentle barrier. If we could tell the compiler to forget the type of anything that the argument to placement-new might point to, but not to assume that arbitrary weirdness has occurred, then the compiler could still eliminate the redundant stores. In other words, in Comment #42, the problem is that the volatile asm tells the compiler that not only must the stores/loads not be reordered across the barrier, but that stores before the barrier must actually occur because their may be some arbitrary action at the barrier that depends upon the values written. If we had a barrier that says just that the operations may not be reordered across the barrier -- but does not say that the operations before the barrier are side-effecting -- then we could still eliminate them as redundant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286