> > For compatibility it also detects clang::musttail
>
> FWIW, it's not clear to me we should do this. I don't see a precedent.
It would make existing code just work (as long as they don't use ifdef)
>
> > One problem is that tree-tailcall usually fails when optimization
> > is disabled, which implies the attribute only really works with
> > optimization on. But that seems to be a reasonable limitation.
> >
> > Passes bootstrap and full test
>
> I don't see a ChangeLog entry.
I have them, but will add them to the next post.
> > static void cp_parser_declaration_statement
> > (cp_parser *);
> >
> > @@ -12719,9 +12719,27 @@ cp_parser_statement (cp_parser* parser, tree
> > in_statement_expr,
> > NULL_TREE, false);
> > break;
> >
> > + case RID_RETURN:
> > + {
> > + bool musttail_p = false;
> > + std_attrs = process_stmt_hotness_attribute (std_attrs, attrs_loc);
> > + if (lookup_attribute ("", "musttail", std_attrs))
> > + {
> > + musttail_p = true;
> > + std_attrs = remove_attribute ("", "musttail", std_attrs);
> > + }
> > + // support this for compatibility
> > + if (lookup_attribute ("clang", "musttail", std_attrs))
> > + {
> > + musttail_p = true;
> > + std_attrs = remove_attribute ("clang", "musttail", std_attrs);
> > + }
>
> Doing lookup_attribute unconditionally twice seems like a lot.
> You could do just lookup_attribute ("musttail", std_attrs) and then
> check get_attribute_namespace() == nullptr/gnu_identifier?
Actually the common case is 0 and very rarely 1 attribute, and in that it is
both
very cheap. If people ever write code with lots of attributes
per line we can worry about optimizations, but at this point it would
see premature.
>
> It's not pretty that you have to remove_attribute but I guess we emit
> warnings otherwise?
Yes.
-Andi
