[PATCH] add simple attribute introspection

Martin Sebor msebor@gmail.com
Mon Oct 22 18:33:00 GMT 2018


Jason,

Do you have any suggestions for the C++ parts or are they good
enough to commit (with the expectation that I'll add template
handling later)?

The last patch is here:
   https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00811.html

Martin

On 10/16/2018 05:19 PM, Jeff Law wrote:
> On 10/13/18 6:19 PM, Martin Sebor wrote:
>> Attached is an updated/enhanced patch with many more tests
>> and the suggested documentation tweak.  It also restores
>> the handling of empty attributes that the first revision
>> inadvertently removed from the C parser.
>>
>> The tests are much more comprehensive now but still not
>> exhaustive.  I have added warning for the mode attribute
>> that cannot be supported.  Enumerator attributes aren't
>> detected in C because they are folded to constants before
>> they reach the built-in, and label attributes aren't handled
>> yet either in C or in C++.  Supporting those will take a minor
>> enhancement.  I haven only added handful of test cases for
>> x86_64 target attributes,  The built-in is not exercised
>> for any other target yet.  I don't expect any surprises
>> there.  Either it will work or (where the attributes aren't
>> hanging off a node) it will return false.  Supporting those
>> will have to wait until the later (I think the best way is
>> to add a callback to struct attribute_spec to let each back
>> end query a node for the properties unique to such attributes
>> analogously to attribute vector_size).
>>
>> I haven't done any work on supporting templates.  I would
>> like to but I don't expect to be able to get it done before
>> stage 1 is over (I have another feature I need to finish,
>> the one that prompted this work to begin with).  I think
>> the new built-in is quite useful even without template
>> support.
>>
>> I've kept the name __builtin_has_attribute: it is close to
>> the __has_attribute macro, and I think that's fine because
>> the built-in's purpose is very close to that of the macro.
>>
>> Martin
>>
>>
>>
>> gcc-builtin-has-attribute.diff
>>
>> gcc/c/ChangeLog:
>>
>> 	* c-parser.c (c_parser_has_attribute_expression): New function.
>> 	(c_parser_attribute): New function.
>> 	(c_parser_attributes): Move code into c_parser_attribute.
>> 	(c_parser_unary_expression): Handle RID_HAS_ATTRIBUTE_EXPRESSION.
>>
>> gcc/c-family/ChangeLog:
>>
>> 	* c-attribs.c (type_for_vector_size): New function.
>> 	(type_valid_for_vector_size): Same.
>> 	(handle_vector_size_attribute): Move code to the functions above
>> 	and call them.
>> 	(validate_attribute, has_attribute): New functions.
>> 	* c-common.h (has_attribute): Declare.
>> 	(rid): Add RID_HAS_ATTRIBUTE_EXPRESSION.
>> 	* c-common.c (c_common_resword): Same.
>>
>> gcc/cp/ChangeLog:
>>
>> 	* cp-tree.h (cp_check_const_attributes): Declare.
>> 	* decl2.c (cp_check_const_attributes): Declare extern.
>> 	* parser.c (cp_parser_has_attribute_expression): New function.
>> 	(cp_parser_unary_expression): Handle RID_HAS_ATTRIBUTE_EXPRESSION.
>> 	(cp_parser_gnu_attribute_list): Add argument.
>>
>> gcc/ChangeLog:
>>
>> 	* doc/extend.texi (Other Builtins): Add __builtin_has_attribute.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 	* c-c++-common/builtin-has-attribute-2.c: New test.
>> 	* c-c++-common/builtin-has-attribute-3.c: New test.
>> 	* c-c++-common/builtin-has-attribute-4.c: New test.
>> 	* c-c++-common/builtin-has-attribute.c: New test.
>> 	* gcc.dg/builtin-has-attribute.c: New test.
>> 	* gcc/testsuite/gcc.target/i386/builtin-has-attribute.c: New test.
>>
> Generally looks OK except for a nit mentioned below.  I don't mind
> iterating a bit on the details here over time.  Give Jason a few days to
> chime in on the C++ side.
>
>> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
>> index 8ffb0cd..dcf4747 100644
>> --- a/gcc/doc/extend.texi
>> +++ b/gcc/doc/extend.texi
>> @@ -2649,8 +2649,9 @@ explicit @code{externally_visible} attributes are still necessary.
>>  @cindex @code{flatten} function attribute
>>  Generally, inlining into a function is limited.  For a function marked with
>>  this attribute, every call inside this function is inlined, if possible.
>> -Whether the function itself is considered for inlining depends on its size and
>> -the current inlining parameters.
>> +Functions declared with attribute @code{noinline} and similar are not
>> +inlined.  Whether the function itself is considered for inlining depends
>> +on its size and the current inlining parameters.
> Guessing this was from another doc patch that I think has already been
> approved :-)
>
>
>> @@ -11726,6 +11728,33 @@ check its compatibility with @var{size}.
>>
>>  @end deftypefn
>>
>> +@deftypefn {Built-in Function} bool __builtin_has_attribute (@var{type-or-expression}, @var{attribute})
>> +The @code{__builtin_has_attribute} function evaluates to an integer constant
>> +expression equal to @code{true} if the symbol or type referenced by
>> +the @var{type-or-expression} argument has been declared with
>> +the @var{attribute} referenced by the second argument.  Neither argument
>> +is valuated.  The @var{type-or-expression} argument is subject to the same
> s/valuated/evaluated/ ?
>



More information about the Gcc-patches mailing list