On Mon, Nov 18, 2019 at 5:45 PM Martin Sebor <mse...@gmail.com> wrote: > > On 11/18/19 1:36 AM, Richard Biener wrote: > > On Fri, Nov 15, 2019 at 10:28 PM Martin Sebor <mse...@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.
They at least sound like they do. I didn't look at the latest version of the patch but please amend the documentation of the attributes to then say that they will never be used in a way affecting code generation. Thanks, Richard. > > 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 >
