This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/23383] builtin array operator new is not marked with malloc attribute
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 05 Jan 2012 08:39:57 +0000
- Subject: [Bug c++/23383] builtin array operator new is not marked with malloc attribute
- Auto-submitted: auto-generated
- References: <bug-23383-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> 2012-01-05 08:39:57 UTC ---
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.
> > We can explicitly handle REALLOC in the points-to code to honor the
> > fact that it is not (we do not at the moment).
>
> ok.
which needs to be fixed here.
Richard.