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