[PATCH] handle attribute positional arguments consistently (PR 87541, 87542)

[Martin Sebor]

On 10/08/2018 05:33 AM, Joseph Myers wrote:
> On Sun, 7 Oct 2018, Martin Sebor wrote:
>
>> While still testing an enhancement in the area of attributes
>> I ran across bugs and inconsistencies in how different handlers
>> deal with positional arguments.  The bugs are either an ICE due
>> to the handlers not consistently converting positional arguments
>> to constants (i.e., CONST_DEL to INTEGER_CST in C++) for which
>> downstream code is unprepared (PR 87541), or errors for valid
>> code (PR 87542), or failing to diagnose invalid arguments.
>> The other inconsistencies are simply in responding to the same
>> invalid condition differently for different attributes .
>
> Note there's also a common bug that, where an integer constant expression
> should be required, an INTEGER_CST of pointer type is wrongly accepted.
> There's an INTEGRAL_TYPE_P check for sentinel attributes, and for
> constructor / destructor (see gcc.dg/initpri2.c for that being tested),
> but not for others.

Right, thanks.

>
>> PS It would be nice to have a general policy for how to respond
>> to invalid attribute arguments (warning or error).  Even better,
>> it would be ideal to move the validation from the front-ends and
>> back-ends into the middle-end.  I.e., describe attribute arguments
>> in more detail in struct attribute_spec and have decl_attributes
>> validate nut just the number of arguments but also their types
>> and, when appropriate, expected values.
>
> I don't think the middle-end can handle the default_conversion part of
> things (although attribute_spec could have the information for generic
> code in the front ends, rather than every attribute handler, to do that).

I think it could be handled by each front-end passing the handler
a callback function (e.g., as a new argument to decl_attributes).
Built-ins wouldn't benefit from it but they can all be trusted
to specify integer literals as arguments.

Martin