Quoting <https://gcc.gnu.org/ml/gcc/2015-11/msg00017.html> "Re: abi_tag questions" by Jonathan Wakely: > On 4 November 2015 at 14:37, Stephan Bergmann <sbergman@redhat.com> wrote: >> I have two questions regarding the abi_tag attribute (as documented at >> <https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html>): [...] >> 2 "The argument can be a list of strings of arbitrary length." >> >> Does that mean the list can be empty? >> >>> void f() __attribute__((__abi_tag__())); >> >> fails with "error: wrong number of arguments specified for ‘__abi_tag__’ >> attribute" while >> >>> inline namespace n __attribute__((__abi_tag__())) {} >> >> is accepted by recent trunk GCC (as well as older versions). > > That seems like a bug. That would apparently have flagged the code fixed with <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=226022> "Fix abi_tag in special modes."
On non-namespace there is a clear requirement that it has at least one argument. For namespace, the code has for the case of zero arguments to the attribute in gcc/cp/name-lookup.c (handle_namespace_attrs): if (!args) { tree dn = DECL_NAME (ns); args = build_string (IDENTIFIER_LENGTH (dn) + 1, IDENTIFIER_POINTER (dn)); TREE_TYPE (args) = char_array_type_node; args = fix_string_type (args); args = build_tree_list (NULL_TREE, args); } That code doesn't look like something one would wrote without thinking what the behavior should be for no arguments, so I believe that it intentionally uses the name of the namespace in that case. So, if there is a bug, I'd say just that this is not well documented.
Yes, I was mistaken in my post to the mailing list. It's by design that it uses the name of the inline namespace as the tag name if no arguments are given, although I thought the correct syntax in that case was: inline namespace n __attribute__((__abi_tag__)) {} i.e. no parentheses after __abi_tag__
(In reply to Jakub Jelinek from comment #1) > So, if there is a bug, I'd say just that this is not well documented. See the attached Fix-abi_tag-doc.patch. (In reply to Jonathan Wakely from comment #2) > although I thought the correct syntax in that case was: > > inline namespace n __attribute__((__abi_tag__)) {} > > i.e. no parentheses after __abi_tag__ Would that be considered something worthwhile to change, to only accept __attribute__((__abi_tag__)) but reject __attribute__((__abi_tag__())) ?
Created attachment 36973 [details] proposed documentation patch
(In reply to Stephan Bergmann from comment #4) > Created attachment 36973 [details] > proposed documentation patch is used as <ins>the</ins> ABI tag ?
Created attachment 36974 [details] updated documentation patch (In reply to Jonathan Wakely from comment #5) > is used as <ins>the</ins> ABI tag yeah, probably sounds better
(In reply to Stephan Bergmann from comment #3) > Would that be considered something worthwhile to change, to only accept > > __attribute__((__abi_tag__)) > > but reject > > __attribute__((__abi_tag__())) > > ? GCC generally treats both forms the same, try any other attribute that accepts zero arguments.
So if the documentation patch is acceptable and somebody with commit rights can push it, we can close this issue as NOTABUG then.
There does seems some inconsitency though: inline namespace n __attribute__((__abi_tag__(""))) {} is rejected but inline namespace n __attribute__((__abi_tag__())) {} Is not.
(In reply to Andrew Pinski from comment #9) > There does seems some inconsitency though: > inline namespace n __attribute__((__abi_tag__(""))) {} > is rejected but > inline namespace n __attribute__((__abi_tag__())) {} > > Is not. How is that inconsistent? When providing the empty string as argument, it is rejected with "arguments to the ‘abi_tag’ attribute must contain valid identifiers" (just like e.g. > inline namespace n __attribute__((__abi_tag__("+"))) {} would be, too). But when providing no argument, the behavior documented in attachment 36974 [details] "updated documentation patch" kicks in.