This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] add simple attribute introspection
- From: Martin Sebor <msebor at gmail dot com>
- To: Jeff Law <law at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 9 Nov 2018 16:43:29 -0700
- Subject: Re: [PATCH] add simple attribute introspection
- References: <55577012-4f85-bc8a-5c13-a53d5e0987f6@gmail.com> <alpine.DEB.2.21.1810111200170.31696@digraph.polyomino.org.uk> <87ebf5d6-2cb1-794e-890a-385265c7a392@gmail.com> <47151a5b-89aa-9bb1-5c80-c6afe7eb32a5@gmail.com> <deaeda31-8884-8184-f655-724e3677ae73@redhat.com> <09e10f3c-a17c-ca45-cc64-b738530c13ce@gmail.com> <5373acce-f28b-e8eb-9b0b-3bd1ab40d121@gmail.com> <45d186e9-4e0f-1328-607c-bbbcb138d6d2@redhat.com>
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.
Thanks
Martin