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.
