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). -- Joseph S. Myers jos...@codesourcery.com
