From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8885 invoked by alias); 23 May 2007 20:48:21 -0000 Received: (qmail 8843 invoked by alias); 23 May 2007 20:48:07 -0000 Date: Wed, 23 May 2007 20:48:00 -0000 Message-ID: <20070523204807.8842.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/msg02072.txt.bz2 ------- Comment #144 from rguenther at suse dot de 2007-05-23 21:48 ------- 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: > rguenther at suse dot de wrote: > > > >> 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". > > Not before the assignment to "p". In: > > void f(int *p, double *q) { > double d = *q; > *p = 3; > return d; > } > > your interpretation does not allow moving the load of "*q" after the > store to "*p". That's clearly limiting the freedom of the optimizer. Yes, it's limiting the freedom of optimizers. > Now, we can argue about how much that matters -- but it's inarguable > that it's a limitation. > > > 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. > > I'm lost. > > What does Gaby's model have to do with placement new? Only so much that we seem to agree on the semantics of placement new. Gaby extends this semantics to any store, so *p = X; is equivalent to *(new (p) __typeof__ *p) = X; to which semantics we thus can agree (not to whether those two should be the same, mandated by the standard or liked by some of us or not). > Gaby's model says that we know less about dynamic types than we > presently think we do, because there might be a union out there > somewhere. (Fortunately, as Joseph points out, C99 has already answered > this question. Surely we can agree that making C99 and C++ different in > this respect is a bad idea.) I don't think dragging in unions helps us here ;) Maybe Gaby can clarify if and how unions relate here, but I didn't percieve any previous comment as making implicit unions relevant here apart from what GCC and apperantly C99 agree to. > If "*p = 3" changes the dynamic type of "*p", that just means we know > even less. The less we know, the less optimization we can do. True. > Making "*p = 3" change the dynamic type of "*p" can't possibly help us > implement placement new more efficiently. I disagree here. Making "*p = 3" change the dynamic type of "*p" will make the placement new issue moot - the current library implementation is fine then and we don't need any new explicit or implicit side-effects of it. > Whatever conservative > assumptions we want to make about "*p = 3" we could make about "new (p) > int" instead. True. I say making them about "*p = 3" is way easier as we are changing semantics of memory operations and *p = 3 is one, but placement new is not. > If you have a patch that fixes the placement new problem, making us > generate correct code, and with minimal/no impact on optimization, > that's great! But, that can't possibly, in and of itself, be a reason > to change the rules we're using for TBAA. Well, it depends if you read it as changing TBAA rules. Does preserving store ordering in loop load/store motion change TBAA rules? Not in itself - but clearly changed TBAA rules would force us to. Same for limiting scheduling of memory operations. Btw, the necessary patch may be as simple as Index: alias.c =================================================================== --- alias.c (revision 124998) +++ alias.c (working copy) @@ -2284,7 +2284,8 @@ write_dependence_p (rtx mem, rtx x, int || MEM_ALIAS_SET (mem) == ALIAS_SET_MEMORY_BARRIER) return 1; - if (DIFFERENT_ALIAS_SETS_P (x, mem)) + /* We cannot rely on alias set differences for C++ aliasing semantics. */ + if (0 && DIFFERENT_ALIAS_SETS_P (x, mem)) return 0; /* A read from read-only memory can't conflict with read-write memory. */ but as I'm currently lacking a testcase that fails due to scheduling I'm not 100% sure. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286