[Bug c++/23383] builtin array operator new is not marked with malloc attribute

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383

--- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> 2012-01-09 08:39:37 UTC ---
On Thu, 5 Jan 2012, xinliangli at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> 
> --- Comment #20 from davidxl <xinliangli at gmail dot com> 2012-01-05 18:11:18 UTC ---
> (In reply to comment #19)
> > On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > > 
> > > --- Comment #18 from davidxl <xinliangli at gmail dot com> 2012-01-04 17:11:26 UTC ---
> > > (In reply to comment #17)
> > > > On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> > > > 
> > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > > > > 
> > > > > --- Comment #16 from davidxl <xinliangli at gmail dot com> 2012-01-04 00:28:55 UTC ---
> > > > > A related topic - aliasing property of realloc -- the malloc attribute is not
> > > > > applied in the glibc header and the comment is like
> > > > > 
> > > > > /* __attribute_malloc__ is not used, because if realloc returns
> > > > >    the same pointer that was passed to it, aliasing needs to be allowed
> > > > >    between objects pointed by the old and new pointers.  *
> > > > > 
> > > > > 
> > > > > It is true that the realloc can return an address is physically aliased with
> > > > > the pointer passed to it -- but assuming no-alias by the compiler should cause
> > > > > no harm -- as all code motions/CSEs across the realloc call will not be
> > > > > possible because realloc may modify/use the memory location.
> > > > > 
> > > > > 
> > > > > Any comment on this? 
> > > > 
> > > > The malloc attribute assumes that the contents of the memory pointed
> > > > to by the return value is undefined, so the comment is inaccurate
> > > > but the malloc attribute can indeed be not used.
> > > 
> > > Which part of the optimizer takes advantage of the 'undefinedness' of returned
> > > memory?
> > 
> > points-to analysis.  It assumes that the returned blob of memory
> > points to nothing (yet).  So for
> > 
> >  int i;
> >  int **p = malloc (8);
> >  *p = &i;
> >  int **q = realloc (p, 8);
> > 
> > you'd get that *q points to nothing insteda of i.
> 
> The malloc attribute documentation is confusing:
> 
> malloc
> The malloc attribute is used to tell the compiler that a function may be
> treated as if any non-NULL pointer it returns cannot alias any other pointer
> valid when the function returns. This will often improve optimization. Standard
> functions with this property include malloc and calloc. realloc-like functions
> have this property as long as the old pointer is never referred to (including
> comparing it to the new pointer) after the function returns a non-NULL value. 

Ugh, it should not mention realloc here.

> It does not mention the undefineness explicitly.
> 
> It might be better to fix the semantics of this attribute to only specify the
> aliasing property so that it can also be applied to realloc. Points-to needs to
> be fixed to special case realloc for the initialization.

It can't be "fixed" to not assume the undefinedness and still be useful.
For any non-builtin with the malloc attribute it would need to assume
the pointed to memory points to anything.  That will be pretty useless
once you put pointers in the allocated memory.

I'll fixup the documentation.