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 sames/valuated/evaluated/ ?
