------- Comment #143 from mark at codesourcery dot com 2007-05-23 21:27 -------
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
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.
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?
We're all agreed that (a) placement new can change the dynamic type of
memory, (b) therefore GCC currently has a bug, (c) we want the fix to
have as little optimization impact as possible.
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.)
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. Making
"*p = 3" change the dynamic type of "*p" can't possibly help us
implement placement new more efficiently. Whatever conservative
assumptions we want to make about "*p = 3" we could make about "new (p)
int" instead.
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
