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.
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).