This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: malloc attributes and realloc


> | Perhaps it would be worthwhile to define a realloc attribute.  That
> | would have the opportunity to optimize code like this:
> | 
> |     c1 = *p1;
> |     p2 = realloc(p1, n);
> |     c2 = *p2;
> | 
> | because we know that c1 == c2.
> 
> That makes sense.  
> 
> Do we have some kind of data whether such codes are widespread?

Adding such an attribute is worthwhile for the purpose of explicitly
differentiating realloc from malloc.  :-)  Were someone to write
code that let GCC notice such patterns, I'd be left wondering if
more compile time was spent on the analysis that was saved in the
aggregate world of computing.....

> "Joseph S. Myers" <jsm@polyomino.org.uk> writes:
> |  The @code{malloc} attribute .....
> | +Standard functions with this property include @code{malloc},
> | +@code{calloc} and @code{realloc}.
> 
> That is a clear improvement!
> 
> I think we'd better off not listing realloc for reasons exposed in
> this thread.  

Much better off.

Dan wrote:
> I'm dreading the __attribute__ (malloc) related bugs that will happen
> if I include this optimization in tree-ssa's

Perhaps cancel the attribute if the function name is "realloc"?  :-)

On Fri, 2 Jan 2004, Ian Lance Taylor wrote:
> Although I initially believed otherwise, I now think that it is
> possible to write a reasonable program which may be miscompiled if gcc
> thinks that realloc has the malloc attribute.  Whether such a program
> actually exists in practice, I don't know.  Whether such a program
> strictly conforms to the C standard, I don't know.

I've written many such.  I've written them based on the (_very_ reasonable)
assumption that if the realloc man page talks about "maybe returning
the same address" "possibly moved" or other such terms, then it is reasonable
to test for that condition and not reset my collection of scanning pointers
when the base address is unchanged.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]