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 2, 2004, at 11:58 AM, Joseph S. Myers wrote:

On Fri, 2 Jan 2004, Daniel Berlin wrote:

1. heap allocation functions  return pointers that don't point to
2. pointer destroying operations destroy pointers irreversibly.

If #1 does not hold for realloc, it should not be attribute malloc.
The fact that it has worked okay so far doesn't mean it will continue
to work in the future. If you change the definition of attribute
malloc so that #1 doesn't hold for them, it makes it useless for
points-to analysis use in determining heap allocation functions. Which
may or may not be okay by everyone, i don't know.

My current draft documentation change for attribute malloc (for this issue
and PR 3414) is

The @code{malloc} attribute is used to tell the compiler that a function
-may be treated as if it were the malloc function. The compiler assumes
-that calls to malloc result in pointers that cannot alias anything.
+may be treated as if any non-@code{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 @code{malloc},
+@code{calloc} and @code{realloc}.

Does this description (non-NULL pointers don't alias anything valid when
the allocation function returns) accurately describe what is appropriate
for the points-to analysis, or not?
Yes, it does.

 (And quite what does the malloc
attribute do at present, given the lack of points-to analysis in GCC?)

Absolutely nothing, AFAIK. :)
I'm dreading the __attribute__ (malloc) related bugs that will happen if I include this optimization in tree-ssa's PTA.

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