[PING 3][PATCH] improve validation of attribute arguments (PR c/78666)

[Martin Sebor]

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html

On 7/26/20 11:41 AM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
> 
> On 7/16/20 4:53 PM, Martin Sebor wrote:
>> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549686.html
>>
>> (Jeff, I forgot to mention this patch when we spoke earlier today.)
>>
>> On 7/8/20 6:01 PM, Martin Sebor wrote:
>>> GCC has gotten better at detecting conflicts between various
>>> attributes but it still doesn't do a perfect job of detecting
>>> similar problems due to mismatches between contradictory
>>> arguments to the same attribute.  For example,
>>>
>>>    __attribute ((alloc_size (1))) void* allocate (size_t, size_t);
>>>
>>> followed by
>>>
>>>    __attribute ((alloc_size (2))) void* allocate (size_t, size_t);
>>>
>>> is accepted with the former overriding the latter in calls to
>>> the function.  Similar problem exists with a few other attributes
>>> that take arguments.
>>>
>>> The attached change adds a new utility function that checks for
>>> such mismatches and issues warnings.  It also adds calls to it
>>> to detect the problem in attributes alloc_align, alloc_size, and
>>> section.  This isn't meant to be a comprehensive fix but rather
>>> a starting point for one.
>>>
>>> Tested on x86_64-linux.
>>>
>>> Martin
>>>
>>> PS I ran into this again while debugging some unrelated changes
>>> and wondering about the behavior in similar situations to mine.
>>> Since the behavior seemed clearly suboptimal I figured I might
>>> as well fix it.
>>>
>>> PPS The improved checking triggers warnings in a few calls to
>>> __builtin_has_attribute due to apparent conflicts.  I've xfailed
>>> those in the test since it's a known issue with some existing
>>> attributes that should be fixed at some point.  Valid uses of
>>> the built-in shouldn't trigger diagnostics except for completely
>>> nonsensical arguments.  Unfortunately, the line between valid
>>> and completely nonsensical is a blurry one (GCC either issues
>>> errors, or -Wattributes, or silently ignores some cases
>>> altogether, such as those that are the subject of this patch)
>>> and there is no internal mechanism to control the response.
>>
>