[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