This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to special_function_p
- To: gcc-patches at gcc dot gnu dot org, jason at cygnus dot com
- Subject: Re: Patch to special_function_p
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Fri, 3 Mar 2000 11:28:45 -0500 (EST)
> From: Jason Merrill <jason@cygnus.com>
>
> The C++ standard doesn't appear to provide any guarantees about
> whether or not operator new returns the pointer to a unique object; in
> practice the default operator new will do so (since it just calls
> malloc), but it can be overridden by the user to something that
> doesn't, and we can't optimize based on something that is probably,
> but not necessarily, true.
>
> Furthermore, operator new (size_t, void *) always returns its
> argument, which is almost certainly going to alias something else, so
> the blanket treatment of all op news as malloc-like is very wrong.
>
> Thoughts?
>
> Fixes g++.other/anon3.C when built with -O2.
>
> 2000-03-03 Jason Merrill <jason@casey.cygnus.com>
>
> * calls.c (special_function_p): operator new may not be malloc-like.
Is even malloc safe? What if I do:
> foo = malloc(10);
> [...]
> free(foo);
> [...]
> bar = malloc(10);
Isn't it possible that malloc returns the same address here?
(Or does the intervening call to free() block the aliasing
optimization?)
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions