This is the mail archive of the 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

On Jan 4, 2004, at 1:00 PM, Bruce Korb wrote:

| 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" <> 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.

I agree completely.

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"? :-)

This is my point, of course.
The attribute is worthless for detecting malloc-like functions if it's used on non-malloc like functions, so if we use it on realloc, i'll have to simply detect-by-name, which sucks.

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