From jason at redhat.com Thu Jun 2 21:33:50 2016 From: jason at redhat.com (Jason Merrill) Date: Thu, 2 Jun 2016 17:33:50 -0400 Subject: [cxx-abi-dev] abi_tag mangling Message-ID: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> I've finally written up a specification for abi_tag mangling for the ABI standard: https://github.com/jicama/cxx-abi/commit/69cea3c9caf76cb308e35c66f4516f54973b6412 Note that some of the subtleties with local scopes described in the clang ABI tag documentation (http://clang.llvm.org/docs/ItaniumMangleAbiTags.html) are due to bugs in GCC 5 that are fixed in GCC 6. Jason From richardsmith at google.com Thu Jun 2 22:01:36 2016 From: richardsmith at google.com (Richard Smith) Date: Thu, 2 Jun 2016 15:01:36 -0700 Subject: [cxx-abi-dev] abi_tag mangling In-Reply-To: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> References: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> Message-ID: Thank you for writing this up! If a type is not part of the regular mangling, and it contains an ABI tag in its mangling but not as part of its type (for instance, a dependent expression in a template argument references an entity with an ABI tag), does that appear in the resulting mangling? (That is, is an implementation required to effectively mangle the return type and throw it away, or is some walk over the top-level type required instead?) On 2 Jun 2016 2:33 p.m., "Jason Merrill" wrote: > I've finally written up a specification for abi_tag mangling for the ABI > standard: > > > https://github.com/jicama/cxx-abi/commit/69cea3c9caf76cb308e35c66f4516f54973b6412 > > Note that some of the subtleties with local scopes described in the clang > ABI tag documentation ( > http://clang.llvm.org/docs/ItaniumMangleAbiTags.html) are due to bugs in > GCC 5 that are fixed in GCC 6. > > Jason > _______________________________________________ > cxx-abi-dev mailing list > cxx-abi-dev at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjmccall at apple.com Thu Jun 2 23:22:15 2016 From: rjmccall at apple.com (John McCall) Date: Thu, 2 Jun 2016 16:22:15 -0700 Subject: [cxx-abi-dev] abi_tag mangling In-Reply-To: References: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> Message-ID: <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> > On Jun 2, 2016, at 3:01 PM, Richard Smith wrote: > Thank you for writing this up! > > If a type is not part of the regular mangling, and it contains an ABI tag in its mangling but not as part of its type (for instance, a dependent expression in a template argument references an entity with an ABI tag), does that appear in the resulting mangling? > > (That is, is an implementation required to effectively mangle the return type and throw it away, or is some walk over the top-level type required instead?) > Do templates have ABI tags, or are the tags only properties of template specializations? How does that play into mangling and/or substitutability? I assume ABI tags can apply to unions as well. (The standard's definition of "compound type" distinguishes classes and unions.) It's probably worth spelling out that tags do not apply to enumerators. Are ABI tags mangled in the , or just on the entity ? What happens if the same tag is applied to multiple places in the lexical hierarchy, e.g. to both a class and one of its member functions? I guess an inline friend function definition doesn't implicitly use the tags of its defining class, but presumably has them anyway because of their presence in the function signature. Can you clarify which things in the Clang description are no longer correct? I assume that a type used in the name of a conversion function should be mangled with its ABI tag. Also, I don't see anything in your proposed wording that talks about not mangling ABI tags on an entity that appear in its type. John. > > On 2 Jun 2016 2:33 p.m., "Jason Merrill" > wrote: > I've finally written up a specification for abi_tag mangling for the ABI standard: > > https://github.com/jicama/cxx-abi/commit/69cea3c9caf76cb308e35c66f4516f54973b6412 > > Note that some of the subtleties with local scopes described in the clang ABI tag documentation (http://clang.llvm.org/docs/ItaniumMangleAbiTags.html ) are due to bugs in GCC 5 that are fixed in GCC 6. > > Jason > _______________________________________________ > cxx-abi-dev mailing list > cxx-abi-dev at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev > _______________________________________________ > cxx-abi-dev mailing list > cxx-abi-dev at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjmccall at apple.com Fri Jun 3 17:38:27 2016 From: rjmccall at apple.com (John McCall) Date: Fri, 3 Jun 2016 10:38:27 -0700 Subject: [cxx-abi-dev] abi_tag mangling In-Reply-To: <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> References: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> Message-ID: > On Jun 2, 2016, at 4:22 PM, John McCall wrote: >> On Jun 2, 2016, at 3:01 PM, Richard Smith > wrote: >> Thank you for writing this up! >> >> If a type is not part of the regular mangling, and it contains an ABI tag in its mangling but not as part of its type (for instance, a dependent expression in a template argument references an entity with an ABI tag), does that appear in the resulting mangling? >> >> (That is, is an implementation required to effectively mangle the return type and throw it away, or is some walk over the top-level type required instead?) >> > > Do templates have ABI tags, or are the tags only properties of template specializations? How does that play into mangling and/or substitutability? To answer my own question here, tags must be associated with the class template, not with its specific specializations, because a template specialization can be used as an incomplete type without requiring explicit specializations etc. to have already been declared. So you cannot e.g. tag a specific explicit specialization (e.g. std::vector) or template "pattern" as having been ABI-updated; you have to tag the entire template. Uses of the template as e.g. a template template argument must include the tag as well. > I assume ABI tags can apply to unions as well. (The standard's definition of "compound type" distinguishes classes and unions.) > > It's probably worth spelling out that tags do not apply to enumerators. > > Are ABI tags mangled in the , or just on the entity ? What happens if the same tag is applied to multiple places in the lexical hierarchy, e.g. to both a class and one of its member functions? > > I guess an inline friend function definition doesn't implicitly use the tags of its defining class, but presumably has them anyway because of their presence in the function signature. > > Can you clarify which things in the Clang description are no longer correct? I assume that a type used in the name of a conversion function should be mangled with its ABI tag. Also, I don't see anything in your proposed wording that talks about not mangling ABI tags on an entity that appear in its type. I wonder if we should include a rationale for this feature. At a first glance, it's tempting to say that it's largely redundant with inline namespaces. The main differences are: - You can pile up multiple tags on an entity. It's possible to stack inline namespaces, but that seems unappealing, and it wouldn't be as easy for other language features to help with the tagging problem. Piling tags on an entity is useful when you've made several orthogonal revisions to it, e.g. when a member variable of a struct has a type that changes ABI. Now, that's a case that doesn't propagate out implicitly because of the incomplete-type problem, but it can still propagate out explicitly, e.g. using a compiler feature that warns about "public" types that don't declare all the tags of their member variables. You'd probably want some way to explicitly propagate the tags of a declaration, e.g. __attribute__((abi_tag(std::string))) to give an entity all the tags that std::string has. - You can tag a member function, member type, or static member variable independently of the enclosing type. - Tags are mangled even for component types that aren't mangled, like the types of variables and the return types of non-template functions. John. > John. > > > > > >> >> On 2 Jun 2016 2:33 p.m., "Jason Merrill" > wrote: >> I've finally written up a specification for abi_tag mangling for the ABI standard: >> >> https://github.com/jicama/cxx-abi/commit/69cea3c9caf76cb308e35c66f4516f54973b6412 >> >> Note that some of the subtleties with local scopes described in the clang ABI tag documentation (http://clang.llvm.org/docs/ItaniumMangleAbiTags.html ) are due to bugs in GCC 5 that are fixed in GCC 6. >> >> Jason >> _______________________________________________ >> cxx-abi-dev mailing list >> cxx-abi-dev at codesourcery.com >> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev >> _______________________________________________ >> cxx-abi-dev mailing list >> cxx-abi-dev at codesourcery.com >> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev > > _______________________________________________ > cxx-abi-dev mailing list > cxx-abi-dev at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at redhat.com Fri Jun 3 22:25:26 2016 From: jason at redhat.com (Jason Merrill) Date: Fri, 3 Jun 2016 18:25:26 -0400 Subject: [cxx-abi-dev] abi_tag mangling In-Reply-To: <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> References: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> Message-ID: On Jun 2, 2016, at 3:01 PM, Richard Smith wrote: > If a type is not part of the regular mangling, and it contains an ABI tag in > its mangling but not as part of its type (for instance, a dependent > expression in a template argument references an entity with an ABI tag), > does that appear in the resulting mangling? > (That is, is an implementation required to effectively mangle the return > type and throw it away, or is some walk over the top-level type required > instead?) Hmm, good question. The current G++ implementation scans dependent expressions in a (member function of a class) template, and considers those in both the signature and the return type of a non-template member function (which is not part of its signature), leading to a somewhat curious result for this example: struct [[gnu::abi_tag ("foo")]] A { template static T f(); }; template struct B { static decltype(A::f()) g(decltype(A::f())); static decltype(A::f()) h(); }; int main() { B::g(0); // _ZN1BIiE1gEi -- the tag does not appear in the mangled name B::h(); // _ZN1BIiE1hB3fooEv } Here G++ sees that A (and thus tag "foo") appears in the signature of B::g, so it doesn't tag B::g, even though the dependent expression isn't actually part of the eventual mangling of B::g because for non-template member functions we mangle the instantiated type rather than the temploid type. The tag doesn't appear in the signature of B::h, so h gets tagged. On Thu, Jun 2, 2016 at 7:22 PM, John McCall wrote: > Do templates have ABI tags, or are the tags only properties of template > specializations? How does that play into mangling and/or substitutability? Templates have tags. > I assume ABI tags can apply to unions as well. (The standard's definition > of "compound type" distinguishes classes and unions.) Of course, unions are classes. There are separate bullets for them in that paragraph, but the union bullet says that unions are classes. > It's probably worth spelling out that tags do not apply to enumerators. OK. > Are ABI tags mangled in the , or just on the entity ? They are mangled as part of the name of the entity, whenever that name appears. > What > happens if the same tag is applied to multiple places in the lexical > hierarchy, e.g. to both a class and one of its member functions? Then it appears multiple times. > I guess an inline friend function definition doesn't implicitly use the tags > of its defining class, but presumably has them anyway because of their > presence in the function signature. Right. > Can you clarify which things in the Clang description are no longer correct? These lines: "If a function is used as a local scope for another name, and is part of another function as local scope, it doesn?t have any required tags. If a function is used as a local scope for a guard variable name, it doesn?t have any required tags." > I assume that a type used in the name of a conversion function should be > mangled with its ABI tag. Yes, any time the name of the type appears, the tags appear as well. > Also, I don't see anything in your proposed > wording that talks about not mangling ABI tags on an entity that appear in > its type. "that are not otherwise represented in the mangling" was supposed to cover that, but as we see with my example above it should really talk about the type or signature rather than the mangling. Jason From richardsmith at google.com Mon Jun 6 21:29:14 2016 From: richardsmith at google.com (Richard Smith) Date: Mon, 6 Jun 2016 14:29:14 -0700 Subject: [cxx-abi-dev] abi_tag mangling In-Reply-To: References: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> Message-ID: On 3 June 2016 at 15:25, Jason Merrill wrote: > On Jun 2, 2016, at 3:01 PM, Richard Smith wrote: > > > If a type is not part of the regular mangling, and it contains an ABI > tag in > > its mangling but not as part of its type (for instance, a dependent > > expression in a template argument references an entity with an ABI tag), > > does that appear in the resulting mangling? > > > (That is, is an implementation required to effectively mangle the return > > type and throw it away, or is some walk over the top-level type required > > instead?) > > Hmm, good question. The current G++ implementation scans dependent > expressions in a (member function of a class) template, and considers > those in both the signature and the return type of a non-template > member function (which is not part of its signature), leading to a > somewhat curious result for this example: > > struct [[gnu::abi_tag ("foo")]] A > { > template static T f(); > }; > > template struct B > { > static decltype(A::f()) g(decltype(A::f())); > static decltype(A::f()) h(); > }; > > int main() > { > B::g(0); // _ZN1BIiE1gEi -- the tag does not appear in the mangled > name > B::h(); // _ZN1BIiE1hB3fooEv > } > > Here G++ sees that A (and thus tag "foo") appears in the signature of > B::g, so it doesn't tag B::g, even though the dependent > expression isn't actually part of the eventual mangling of B::g > because for non-template member functions we mangle the instantiated > type rather than the temploid type. The tag doesn't appear in the > signature of B::h, so h gets tagged. Is that how this is supposed to work, or is it a bug? It would seem more reasonable to say the tag set added after to the declaration's name is the tag set from scanning the original unsubstituted declaration, minus the tags produced by mangling (and I suspect that probably doesn't change the mangling for any cases in the wild). Is the declaration that you scan the one from which a definition would ultimately be instantiated, or do you look back further than that? In particular, do you stop at member specializations: template<> float B::h() {} // how is this mangled? ? On Thu, Jun 2, 2016 at 7:22 PM, John McCall wrote: > > > Do templates have ABI tags, or are the tags only properties of template > > specializations? How does that play into mangling and/or > substitutability? > > Templates have tags. > > > I assume ABI tags can apply to unions as well. (The standard's > definition > > of "compound type" distinguishes classes and unions.) > > Of course, unions are classes. There are separate bullets for them in > that paragraph, but the union bullet says that unions are classes. > > > It's probably worth spelling out that tags do not apply to enumerators. > > OK. > > > Are ABI tags mangled in the , or just on the entity ? > > They are mangled as part of the name of the entity, whenever that name > appears. > > > What > > happens if the same tag is applied to multiple places in the lexical > > hierarchy, e.g. to both a class and one of its member functions? > > Then it appears multiple times. > > > I guess an inline friend function definition doesn't implicitly use the > tags > > of its defining class, but presumably has them anyway because of their > > presence in the function signature. > > Right. > > > Can you clarify which things in the Clang description are no longer > correct? > > These lines: > > "If a function is used as a local scope for another name, and is part > of another function as local scope, it doesn?t have any required tags. > If a function is used as a local scope for a guard variable name, it > doesn?t have any required tags." > > > I assume that a type used in the name of a conversion function should be > > mangled with its ABI tag. > > Yes, any time the name of the type appears, the tags appear as well. Coupled with the behavior of attributes on the return type, this seems strange. Once a library has ABI tags added to it, you can't add the same ABI tag to more types in a later release: suppose v1 has an ABI tag on std::list and v2 adds the same ABI tag to std::string. Then "std::string f(std::list)" has the same mangling in v1 and v2. Since you can't ABI-tag more entities in a later version of the same library, it would seem sufficient to list the ABI tags only once, with the name of the complete entity, rather than alongside each ABI-tagged constituent of its mangled name. But I guess you've already shipped this, so it's too late to do much about it :( > Also, I don't see anything in your proposed > > wording that talks about not mangling ABI tags on an entity that appear > in > > its type. > > "that are not otherwise represented in the mangling" was supposed to > cover that, but as we see with my example above it should really talk > about the type or signature rather than the mangling. > > Jason > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at redhat.com Tue Jun 14 21:09:25 2016 From: jason at redhat.com (Jason Merrill) Date: Tue, 14 Jun 2016 17:09:25 -0400 Subject: [cxx-abi-dev] abi_tag mangling In-Reply-To: References: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> Message-ID: On Mon, Jun 6, 2016 at 5:29 PM, Richard Smith wrote: > On 3 June 2016 at 15:25, Jason Merrill wrote: >> >> On Jun 2, 2016, at 3:01 PM, Richard Smith wrote: >> >> > If a type is not part of the regular mangling, and it contains an ABI >> > tag in >> > its mangling but not as part of its type (for instance, a dependent >> > expression in a template argument references an entity with an ABI tag), >> > does that appear in the resulting mangling? >> >> > (That is, is an implementation required to effectively mangle the return >> > type and throw it away, or is some walk over the top-level type required >> > instead?) >> >> Hmm, good question. The current G++ implementation scans dependent >> expressions in a (member function of a class) template, and considers >> those in both the signature and the return type of a non-template >> member function (which is not part of its signature), leading to a >> somewhat curious result for this example: >> >> struct [[gnu::abi_tag ("foo")]] A >> { >> template static T f(); >> }; >> >> template struct B >> { >> static decltype(A::f()) g(decltype(A::f())); >> static decltype(A::f()) h(); >> }; >> >> int main() >> { >> B::g(0); // _ZN1BIiE1gEi -- the tag does not appear in the mangled >> name >> B::h(); // _ZN1BIiE1hB3fooEv >> } >> >> Here G++ sees that A (and thus tag "foo") appears in the signature of >> B::g, so it doesn't tag B::g, even though the dependent >> expression isn't actually part of the eventual mangling of B::g >> because for non-template member functions we mangle the instantiated >> type rather than the temploid type. The tag doesn't appear in the >> signature of B::h, so h gets tagged. > > Is that how this is supposed to work, or is it a bug? It would seem more > reasonable to say the tag set added after to the declaration's name is the > tag set from scanning the original unsubstituted declaration, minus the tags > produced by mangling (and I suspect that probably doesn't change the > mangling for any cases in the wild). It does seem like a bug. For non-template member functions, since the signature we mangle is the fully-instantiated signature, it probably also makes sense to use that signature in determining tags, so that neither of the above functions would mention a tag: struct [[gnu::abi_tag ("foo")]] A { template static T f(); template static A g(); }; template struct B { static decltype(A::f()) fa(decltype(A::f())); static decltype(A::f()) fv(); static decltype(A::g()) ga(decltype(A::g())); static decltype(A::g()) gv(); }; int main() { B::fa(0); // _ZN1BIiE2faEi B::fv(); // _ZN1BIiE2fvEv B::ga(A()); // _ZN1BIiE2gaE1AB3foo B::gv(); // _ZN1BIiE2gvB3fooEv } Thoughts? > Is the declaration that you scan the one from which a definition would > ultimately be instantiated, or do you look back further than that? In > particular, do you stop at member specializations: > > template<> float B::h() {} // how is this mangled? My proposal just above would have us not look any farther back than the fully-instantiated signature, but for member templates, you look at the primary template. > > ? > >> On Thu, Jun 2, 2016 at 7:22 PM, John McCall wrote: >> >> > Do templates have ABI tags, or are the tags only properties of template >> > specializations? How does that play into mangling and/or >> > substitutability? >> >> Templates have tags. >> >> > I assume ABI tags can apply to unions as well. (The standard's >> > definition >> > of "compound type" distinguishes classes and unions.) >> >> Of course, unions are classes. There are separate bullets for them in >> that paragraph, but the union bullet says that unions are classes. >> >> > It's probably worth spelling out that tags do not apply to enumerators. >> >> OK. >> >> > Are ABI tags mangled in the , or just on the entity ? >> >> They are mangled as part of the name of the entity, whenever that name >> appears. >> >> > What >> > happens if the same tag is applied to multiple places in the lexical >> > hierarchy, e.g. to both a class and one of its member functions? >> >> Then it appears multiple times. >> >> > I guess an inline friend function definition doesn't implicitly use the >> > tags >> > of its defining class, but presumably has them anyway because of their >> > presence in the function signature. >> >> Right. >> >> > Can you clarify which things in the Clang description are no longer >> > correct? >> >> These lines: >> >> "If a function is used as a local scope for another name, and is part >> of another function as local scope, it doesn?t have any required tags. >> If a function is used as a local scope for a guard variable name, it >> doesn?t have any required tags." >> >> > I assume that a type used in the name of a conversion function should be >> > mangled with its ABI tag. >> >> Yes, any time the name of the type appears, the tags appear as well. > > Coupled with the behavior of attributes on the return type, this seems > strange. > > Once a library has ABI tags added to it, you can't add the same ABI tag to > more types in a later release: suppose v1 has an ABI tag on std::list and v2 > adds the same ABI tag to std::string. Then "std::string f(std::list)" > has the same mangling in v1 and v2. Since you can't ABI-tag more entities in > a later version of the same library, it would seem sufficient to list the > ABI tags only once, with the name of the complete entity, rather than > alongside each ABI-tagged constituent of its mangled name. > > But I guess you've already shipped this, so it's too late to do much about > it :( That was my original concept, actually; I don't remember now why I shifted away from it. >> > Also, I don't see anything in your proposed >> > wording that talks about not mangling ABI tags on an entity that appear >> > in >> > its type. >> >> "that are not otherwise represented in the mangling" was supposed to >> cover that, but as we see with my example above it should really talk >> about the type or signature rather than the mangling. >> >> Jason From rnk at google.com Wed Jun 22 19:59:02 2016 From: rnk at google.com (Reid Kleckner) Date: Wed, 22 Jun 2016 12:59:02 -0700 Subject: [cxx-abi-dev] Non-trivial move constructor In-Reply-To: <225867D4-033A-4AA5-8BD7-0741E22743DF@apple.com> References: <56CDB628.8000302@redhat.com> <225867D4-033A-4AA5-8BD7-0741E22743DF@apple.com> Message-ID: This bug still isn't fixed in Clang. It's https://llvm.org/bugs/show_bug.cgi?id=19668. You should probably go ahead and update the document. On Wed, Feb 24, 2016 at 10:41 PM, John McCall wrote: > > On Feb 24, 2016, at 1:14 PM, Richard Smith > wrote: > > On 24 February 2016 at 12:56, John McCall wrote: > >>> On Feb 24, 2016, at 11:43 AM, Richard Smith > wrote: > >>> On 24 February 2016 at 05:54, Jason Merrill wrote: > >>>> On 02/24/2016 05:51 AM, Marc Glisse wrote: > >>>>> > >>>>> in 3.1.1, we use "In the special case where the parameter type has a > >>>>> non-trivial copy constructor or destructor" to force passing by > >>>>> reference. It seems that for C++11, this should also include move > >>>>> constructors, for the same reasons. > >>>> > >>>> > >>>> We talked about adding move constructors to that sentence years ago. > Did it > >>>> never make it into the spec? > >>> > >>> Looks like it didn't. The rule we ended up with was: > >>> > >>> "[Pass an object of class type by value if] every copy constructor and > >>> move constructor is deleted or trivial and at least one of them is not > >>> deleted, and the destructor is trivial.? > >>> > >>> > >>> However, this seems overly-cautious to me; it would seem sufficient > >>> for there to be at least one copy or move constructor that is trivial > >>> and not deleted, and a trivial destructor. It's not really > >>> particularly plausible for there to be a trivial copy and a > >>> non-trivial move or vice versa, but it *is* plausible for there to be > >>> two non-deleted copy constructors -- a trivial one, and one that takes > >>> a const volatile reference -- and in that case, passing through > >>> registers seems completely reasonable. How about changing the rule in > >>> 3.1.1 bullet 1 to: > >>> > >>> "In the special case where the parameter type does not have both a > >>> trivial destructor and at least one trivial copy or move constructor > >>> that is not deleted, the caller must allocate space for a temporary > >>> copy, and pass the resulting copy by reference (below). Specifically > >>> [?]" > >> > >> I agree with your proposal in theory, but I?m concerned about changing > >> the ABI at this point. We *are* talking about the language standard > that was > >> released six years ago, and an area of that standard that was > theoretically > >> fully implemented by compilers several years before that. > >> > >> Do we understand the scope of the ABI disagreement between GCC and > Clang here? > >> What do other compilers do? > > > > Clang's rule is the one in the ABI: a class is passed indirectly if it > > has a non-trivial destructor or a non-trivial copy constructor. This > > rule definitely needs some adjustment, because it's not meaningful to > > ask whether an implicitly-deleted function is trivial. > > That sounds like it?s on us to fix. Do GCC and other compilers correctly > implement the rule that we agreed on? If so, I?ll go ahead and apply > the change to the ABI document, and we should fix this in clang. > > John. > _______________________________________________ > cxx-abi-dev mailing list > cxx-abi-dev at codesourcery.com > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richardsmith at google.com Mon Jun 27 20:35:34 2016 From: richardsmith at google.com (Richard Smith) Date: Mon, 27 Jun 2016 13:35:34 -0700 Subject: [cxx-abi-dev] abi_tag mangling In-Reply-To: References: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> Message-ID: On 14 June 2016 at 14:09, Jason Merrill wrote: > On Mon, Jun 6, 2016 at 5:29 PM, Richard Smith > wrote: > > On 3 June 2016 at 15:25, Jason Merrill wrote: > >> > >> On Jun 2, 2016, at 3:01 PM, Richard Smith > wrote: > >> > >> > If a type is not part of the regular mangling, and it contains an ABI > >> > tag in > >> > its mangling but not as part of its type (for instance, a dependent > >> > expression in a template argument references an entity with an ABI > tag), > >> > does that appear in the resulting mangling? > >> > >> > (That is, is an implementation required to effectively mangle the > return > >> > type and throw it away, or is some walk over the top-level type > required > >> > instead?) > >> > >> Hmm, good question. The current G++ implementation scans dependent > >> expressions in a (member function of a class) template, and considers > >> those in both the signature and the return type of a non-template > >> member function (which is not part of its signature), leading to a > >> somewhat curious result for this example: > >> > >> struct [[gnu::abi_tag ("foo")]] A > >> { > >> template static T f(); > >> }; > >> > >> template struct B > >> { > >> static decltype(A::f()) g(decltype(A::f())); > >> static decltype(A::f()) h(); > >> }; > >> > >> int main() > >> { > >> B::g(0); // _ZN1BIiE1gEi -- the tag does not appear in the > mangled > >> name > >> B::h(); // _ZN1BIiE1hB3fooEv > >> } > >> > >> Here G++ sees that A (and thus tag "foo") appears in the signature of > >> B::g, so it doesn't tag B::g, even though the dependent > >> expression isn't actually part of the eventual mangling of B::g > >> because for non-template member functions we mangle the instantiated > >> type rather than the temploid type. The tag doesn't appear in the > >> signature of B::h, so h gets tagged. > > > > Is that how this is supposed to work, or is it a bug? It would seem more > > reasonable to say the tag set added after to the declaration's name is > the > > tag set from scanning the original unsubstituted declaration, minus the > tags > > produced by mangling (and I suspect that probably doesn't change the > > mangling for any cases in the wild). > > It does seem like a bug. For non-template member functions, since the > signature we mangle is the fully-instantiated signature, it probably > also makes sense to use that signature in determining tags, so that > neither of the above functions would mention a tag: > > struct [[gnu::abi_tag ("foo")]] A > { > template static T f(); > template static A g(); > }; > > template struct B > { > static decltype(A::f()) fa(decltype(A::f())); > static decltype(A::f()) fv(); > static decltype(A::g()) ga(decltype(A::g())); > static decltype(A::g()) gv(); > }; > > int main() > { > B::fa(0); // _ZN1BIiE2faEi > B::fv(); // _ZN1BIiE2fvEv > B::ga(A()); // _ZN1BIiE2gaE1AB3foo > B::gv(); // _ZN1BIiE2gvB3fooEv > } > > Thoughts? Seems reasonable to me. This runs the risk of the ABI variance existing only in the SFINAE condition, rather than in the signature, but that's probably not an issue in practice. Would the upshot then be that the tags are always determined as if by mangling the declared return type (after substitution) and checking which tags would appear? > Is the declaration that you scan the one from which a definition would > > ultimately be instantiated, or do you look back further than that? In > > particular, do you stop at member specializations: > > > > template<> float B::h() {} // how is this mangled? > > My proposal just above would have us not look any farther back than > the fully-instantiated signature, but for member templates, you look > at the primary template. > > > > > ? > > > >> On Thu, Jun 2, 2016 at 7:22 PM, John McCall wrote: > >> > >> > Do templates have ABI tags, or are the tags only properties of > template > >> > specializations? How does that play into mangling and/or > >> > substitutability? > >> > >> Templates have tags. > >> > >> > I assume ABI tags can apply to unions as well. (The standard's > >> > definition > >> > of "compound type" distinguishes classes and unions.) > >> > >> Of course, unions are classes. There are separate bullets for them in > >> that paragraph, but the union bullet says that unions are classes. > >> > >> > It's probably worth spelling out that tags do not apply to > enumerators. > >> > >> OK. > >> > >> > Are ABI tags mangled in the , or just on the entity ? > >> > >> They are mangled as part of the name of the entity, whenever that name > >> appears. > >> > >> > What > >> > happens if the same tag is applied to multiple places in the lexical > >> > hierarchy, e.g. to both a class and one of its member functions? > >> > >> Then it appears multiple times. > >> > >> > I guess an inline friend function definition doesn't implicitly use > the > >> > tags > >> > of its defining class, but presumably has them anyway because of their > >> > presence in the function signature. > >> > >> Right. > >> > >> > Can you clarify which things in the Clang description are no longer > >> > correct? > >> > >> These lines: > >> > >> "If a function is used as a local scope for another name, and is part > >> of another function as local scope, it doesn?t have any required tags. > >> If a function is used as a local scope for a guard variable name, it > >> doesn?t have any required tags." > >> > >> > I assume that a type used in the name of a conversion function should > be > >> > mangled with its ABI tag. > >> > >> Yes, any time the name of the type appears, the tags appear as well. > > > > Coupled with the behavior of attributes on the return type, this seems > > strange. > > > > Once a library has ABI tags added to it, you can't add the same ABI tag > to > > more types in a later release: suppose v1 has an ABI tag on std::list > and v2 > > adds the same ABI tag to std::string. Then "std::string > f(std::list)" > > has the same mangling in v1 and v2. Since you can't ABI-tag more > entities in > > a later version of the same library, it would seem sufficient to list the > > ABI tags only once, with the name of the complete entity, rather than > > alongside each ABI-tagged constituent of its mangled name. > > > > But I guess you've already shipped this, so it's too late to do much > about > > it :( > > That was my original concept, actually; I don't remember now why I > shifted away from it. > > >> > Also, I don't see anything in your proposed > >> > wording that talks about not mangling ABI tags on an entity that > appear > >> > in > >> > its type. > >> > >> "that are not otherwise represented in the mangling" was supposed to > >> cover that, but as we see with my example above it should really talk > >> about the type or signature rather than the mangling. > >> > >> Jason > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.polukhin at gmail.com Fri Jun 17 11:37:19 2016 From: dmitry.polukhin at gmail.com (Dmitry Polukhin) Date: Fri, 17 Jun 2016 11:37:19 -0000 Subject: [cxx-abi-dev] abi_tag mangling In-Reply-To: References: <3694a9ff-2963-e2b1-9bfc-1a760dcc9437@redhat.com> <05E639EF-ADE0-4AF7-B182-731C1895C47A@apple.com> Message-ID: On Wed, Jun 15, 2016 at 12:09 AM, Jason Merrill wrote: > It does seem like a bug. For non-template member functions, since the > signature we mangle is the fully-instantiated signature, it probably > also makes sense to use that signature in determining tags, so that > neither of the above functions would mention a tag: > > struct [[gnu::abi_tag ("foo")]] A > { > template static T f(); > template static A g(); > }; > > template struct B > { > static decltype(A::f()) fa(decltype(A::f())); > static decltype(A::f()) fv(); > static decltype(A::g()) ga(decltype(A::g())); > static decltype(A::g()) gv(); > }; > > int main() > { > B::fa(0); // _ZN1BIiE2faEi > B::fv(); // _ZN1BIiE2fvEv > B::ga(A()); // _ZN1BIiE2gaE1AB3foo > B::gv(); // _ZN1BIiE2gvB3fooEv > } > > Thoughts? > IMHO, from theoretical point of view current rules are not consistent and it would be better to don't have tag for all functions above. But it is change in ABI (again). Current Clang implementation under review does the same mangling as GCC so from practical stand point it would be better to don't change it. -------------- next part -------------- An HTML attachment was scrubbed... URL: