Richard Guenther wrote:
> A better one:
>
> int *p = new int;
> foo(p);
> int *q = new int;
>
> if foo deletes p then q may be equal to p. But alias analysis still
> (validly!) says they don't alias.
Yes, I agree that this is safe. (Either "p" is still valid and
therefore different from "q", or it has been deleted and you may no
longer talk about it.) That's the case I mentioned of assuming that
distinct calls to "operator new" result in different values. But,
that's not as strong as assuming that "p" is distinct from all other
pointers in the program, which is what the "malloc" attribute says.
And, even here there's a corner case:
char *pool;
void *operator new(size_t) { // return memory from pool }
bool f() {
char *p = new char;
pool = p;
char *q = new char;
return p == q;
}
Here, we have the situation that two subsequent calls to the same
"operator new" returned the same pointer.
Why isn't that valid? For a more real-world example, use array-new for
the first call.
I don't think the GCC lists are actually the place to fix these kinds of
problems. These are fundamental problems with the C++ standard. It
simply is not sufficiently clear about all of these memory model issues
to allow us (as compiler vendors) to reason about them in the ways that
we "know" make sense.
I think the optimization we want to do here (i.e., assume that pointers
returned by operator new are all distinct, and distinct from all other
pointers we can see) is only safe for particular implementations of
operator new. So, I don't think we can put any attribute to that affect
in our standard headers. You need a command-line switch, macro, etc.,
for the user to use to say that they are using an implementation that
meets the requirements.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
