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:
> 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/ ? Did the implementation change significantly requiring another review iteration? jeff