This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: malloc attributes and realloc
Geoff Keating <geoffk@geoffk.org> writes:
| "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
|
| > > From: "Joseph S. Myers" <jsm@polyomino.org.uk>
| > >
| > > On Fri, 2 Jan 2004, Kaveh R. Ghazi wrote:
| > >
| > > > Hum, that is surprising. If we can't rely on pointer ordering, then
| > > > libiberty/alloca.c wouldn't work since it uses exactly this ordering
| > > > to detect the stack growth direction and also to detect when storage
| > > > can be freed.
| > >
| > > We clearly ought to document exactly what extensions to pointers we
| > > support beyond what the C standard specifies.
| >
| > If by "we support" you mean "GCC supports", my gist goes beyond that.
| >
| > The pointer comparison code in alloca.c is the way we support the
| > alloca() function for NON-gcc compilers. Therefore pointer comparison
| > works on _every_ stage1 compiler used to bootstrap gcc going back to
| > the oldest traditional C compiler up until today's ISO C. That's a
| > lot of compilers supporting this so-called extension which is why
| > (other than for segmented arches) I find it surprising we cannot rely
| > on this behavior. ;-)
|
| Note that stage1 is done without optimisation. I seem to remember
| that at -O0, GCC doesn't do aliasing analysis at all.
Still, we do depend on it behaving as we expected.
Undefined beahaviour is not just about optimization :-)
-- Gaby