This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: malloc attributes and realloc
> From: Geoff Keating <geoffk@geoffk.org>
>
> "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.
Eh? What does that have to do with pointer ">" comparison?
Besides alloca.c has been used in many other GNU packages besides GCC
over the years.
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu