public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/109887] New: Different mangled name for template specialization for clang and gcc
@ 2023-05-17  9:00 yedeng.yd at linux dot alibaba.com
  2023-05-17 10:13 ` [Bug c++/109887] " redi at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: yedeng.yd at linux dot alibaba.com @ 2023-05-17  9:00 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887

            Bug ID: 109887
           Summary: Different mangled name for template specialization for
                    clang and gcc
           Product: gcc
           Version: 12.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yedeng.yd at linux dot alibaba.com
  Target Milestone: ---

(This is a duplication of https://github.com/llvm/llvm-project/issues/62765
since I don't know which one is worse)

Reproducer:

```
#include <type_traits>

namespace llvm {
    class StringRef {
        public:
        StringRef(const char*);

    };
    template <typename T> class Optional {};
}

namespace n {
struct S {
    template <class T>
    std::enable_if_t<std::is_integral<T>::value, llvm::Optional<T>>
    get(llvm::StringRef) const {
        return {};
    }
};

template <>
llvm::Optional<bool>
S::get<bool>(llvm::StringRef) const;
}

void use() {
    n::S().get<bool>("hello");
}
```

For the specialization `S::get<bool>(llvm::StringRef)`, gcc will mangle it as:

```
_ZNK1n1S3getIbEENSt9enable_ifIXsrSt11is_integralIT_E5valueEN4llvm8OptionalIS4_EEE4typeENS6_9StringRefE
```

and clang will mangle it as:

```
_ZNK1n1S3getIbEENSt9enable_ifIXsr3std11is_integralIT_EE5valueEN4llvm8OptionalIS3_EEE4typeENS4_9StringRefE
```

Also the c++filt can only recognize the name mangled by gcc. And the
llvm-cxxfilt can only recognize the name mangled by clang.

So I am not sure if this is bug really or this is by design. But I think clang
and gcc are trying to make ABI compatible.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/109887] Different mangled name for template specialization for clang and gcc
  2023-05-17  9:00 [Bug c++/109887] New: Different mangled name for template specialization for clang and gcc yedeng.yd at linux dot alibaba.com
@ 2023-05-17 10:13 ` redi at gcc dot gnu.org
  2023-05-17 10:15 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-17 10:13 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Chuanqi Xu from comment #0)
> _ZNK1n1S3getIbEENSt9enable_ifIXsrSt11is_integralIT_E5valueEN4llvm8OptionalIS4
> _EEE4typeENS6_9StringRefE
> ```
> 
> and clang will mangle it as:
> 
> ```
> _ZNK1n1S3getIbEENSt9enable_ifIXsr3std11is_integralIT_EE5valueEN4llvm8Optional
> IS3_EEE4typeENS4_9StringRefE

The difference is that GCC mangles std::is_integral as St11is_integral and
Clang mangles it as 3std::is_integral. I think GCC is right.

Clang uses St9enable_if for std::enable_if so I don't knwo why it doesn't use
the St substitution for std::is_integral.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/109887] Different mangled name for template specialization for clang and gcc
  2023-05-17  9:00 [Bug c++/109887] New: Different mangled name for template specialization for clang and gcc yedeng.yd at linux dot alibaba.com
  2023-05-17 10:13 ` [Bug c++/109887] " redi at gcc dot gnu.org
@ 2023-05-17 10:15 ` redi at gcc dot gnu.org
  2023-05-17 10:19 ` jakub at gcc dot gnu.org
  2023-10-05 22:32 ` jason at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-17 10:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Clang mangles it as 3std::is_integral.

Oops, I mean 3std11is_integral of course.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/109887] Different mangled name for template specialization for clang and gcc
  2023-05-17  9:00 [Bug c++/109887] New: Different mangled name for template specialization for clang and gcc yedeng.yd at linux dot alibaba.com
  2023-05-17 10:13 ` [Bug c++/109887] " redi at gcc dot gnu.org
  2023-05-17 10:15 ` redi at gcc dot gnu.org
@ 2023-05-17 10:19 ` jakub at gcc dot gnu.org
  2023-10-05 22:32 ` jason at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-17 10:19 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, simpler testcase would be
#include <type_traits>

template <class T>
std::enable_if_t <std::is_integral <T>::value, int>
foo() { return 0; }

int a = foo<int> ();

GCC mangles this as
_Z3fooIiENSt9enable_ifIXsrSt11is_integralIT_E5valueEiE4typeEv
while clang as
_Z3fooIiENSt9enable_ifIXsr3std11is_integralIT_EE5valueEiE4typeEv
but c++filt is able to demangle both as
std::enable_if<std::is_integral<int>::value, int>::type foo<int>()
So, the difference between the two is that gcc uses substitution St for std::
while clang doesn't.
In https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling sr is
<unresolved-name> ::= [gs] <base-unresolved-name>                     # x or
(with "gs") ::x
                    ::= sr <unresolved-type> <base-unresolved-name>     # T::x
/ decltype(p)::x
...
and
<unresolved-type> ::= <template-param> [ <template-args> ]            # T:: or
T<X,Y>::
                    ::= <decltype>                                      #
decltype(p)::
                    ::= <substitution>
and
<substitution> ::= St # ::std::
among other things, so I think st is what should be used instead of 3std.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/109887] Different mangled name for template specialization for clang and gcc
  2023-05-17  9:00 [Bug c++/109887] New: Different mangled name for template specialization for clang and gcc yedeng.yd at linux dot alibaba.com
                   ` (2 preceding siblings ...)
  2023-05-17 10:19 ` jakub at gcc dot gnu.org
@ 2023-10-05 22:32 ` jason at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: jason at gcc dot gnu.org @ 2023-10-05 22:32 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
This is unresolved ABI issue 38.  I'm going to try to push it along again.

*** This bug has been marked as a duplicate of bug 67343 ***

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-10-05 22:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-17  9:00 [Bug c++/109887] New: Different mangled name for template specialization for clang and gcc yedeng.yd at linux dot alibaba.com
2023-05-17 10:13 ` [Bug c++/109887] " redi at gcc dot gnu.org
2023-05-17 10:15 ` redi at gcc dot gnu.org
2023-05-17 10:19 ` jakub at gcc dot gnu.org
2023-10-05 22:32 ` jason at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).