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/ ?