Re: PING [PATCH] add simple attribute introspection

[Jeff Law <law at redhat dot com>]

On 11/15/18 8:06 PM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html
> (Still looking for an approval.)
> 
> On 11/09/2018 04:43 PM, Martin Sebor wrote:
>> On 11/09/2018 12:59 PM, Jeff Law wrote:
>>> On 10/31/18 10:27 AM, Martin Sebor wrote:
>>>> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html
>>>>
>>>> With the C++ bits approved I'm still looking for a review/approval
>>>> of the remaining changes: the C front end and the shared c-family
>>>> handling of the new built-in.
>>> I thought I acked those with just a couple minor doc nits:
>>
>> I don't see a formal approval for the rest in my Inbox or in
>> the archive.
>>
>>>> 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
>>
>> Yes.  It shouldn't be in the latest patch at the link above.
>>
>>>> @@ -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/ ?
>>
>> This should also be fixed in the latest patch at the link above.
>>
>>> Did the implementation change significantly requiring another review
>>> iteration?
>>
>> I don't think it changed too significantly between the last two
>> revisions but I don't have a record of anyone having approved
>> the C FE and the middle-end bits.  (Sorry if I missed it.) Other
>> than this response from you all I see in the archive is this:
>>
>>   https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00606.html
>>
>> Please let me if the last revision is okay to commit.
Yes.  It's fine to commit.
jeff