[WIP PATCH] add object access attributes (PR 83859)

Martin Sebor msebor@gmail.com
Mon Nov 18 16:46:00 GMT 2019


On 11/18/19 1:36 AM, Richard Biener wrote:
> On Fri, Nov 15, 2019 at 10:28 PM Martin Sebor <msebor@gmail.com> wrote:
>>
>> Thanks for the suggestion.  I will do that for GCC 11.  I take
>> Richard's point that the attributes' semantics need to be clearly
>> and carefully specified before they're put to use for optimization.
> 
> Before they are exposed to users please.  It doesn't help if we
> specify the same attribute for optimization later when uses are out
> in the wild "guessing" at what the possible interpretation is.
> 
> Maybe we can name your attributes maybe_readonly and friends
> to clearly indicate that this is only a guess by the user so at most
> usable for diagnostics but never for optimization.
> 
> Since we have quite costly attribute lookup I also prefer something
> that translates to less attributes - how about
> __attribute__((diag_argspec(1, readonly), diag_argspec(2, writeonly)))
> to indicate argument 1 is maybe readonly, 2 is writeonly?  We can
> then merge this into a single diag_arspec attribute instance we can
> lookup.

I can look into making a change along these lines.

I'm not fond of the idea of introducing a "maybe" kind of attributes
now and another parallel "for-sure" set later.  My goal is to have
the attributes express the same access constraints as those on
the arguments to built-in string functions like memcpy or strcat
(i.e., read_only only reads a pointed-to object, write_only only
writes, and, for strcat, read_write both reads and writes it).

Those properties are sufficiently well understood.  The three
attributes aren't intended to express constraints on aliasing
or on the side-effects of the functions, like restrict or
the const and pure attributes.

To let users do more than that, some additional annotation will
probably be necessary.  In my WIP patch I have a no_side_effect
attribute that lets functions do more than const and pure but
that's still work in progress that I don't plan to submit for
GCC 10.

Martin

> 
>>>
>>> I don't see anything terribly concerning.  Looking forward to the final
>>> iteration here.
>>
>> Attached is a subset of the original patch that just adds the three
>> attributes and uses them to do buffer overflow checking.  I have
>> also enhanced the detection of invalid arguments (null pointers,
>> negative sizes).
>>
>> Retested on x86_64-linux.
>>
>> Martin



More information about the Gcc-patches mailing list