C++ mangling/ABI mismatch vs GCC

[mstorsjo]

https://godbolt.org/z/TK7Yr8b6c shows a difference in C++ mangling, or what symbol reference gets generated, between GCC and and Clang.

#include <type_traits>
namespace rocket {

template<typename charT>
class basic_tinyfmt;

using tinyfmt = basic_tinyfmt<char>;
using ::std::enable_if;
using ::std::is_arithmetic;
using ::std::is_same;

template<typename charT, typename valueT,
typename enable_if<is_arithmetic<valueT>::value 
                   && !is_same<valueT, charT>::value
  >::type* = nullptr>
inline
basic_tinyfmt<charT>&
operator<<(basic_tinyfmt<charT>& fmt, valueT value);  //...

extern template tinyfmt& operator<<(tinyfmt&, signed char);
extern template tinyfmt& operator<<(tinyfmt&, signed short);
extern template tinyfmt& operator<<(tinyfmt&, signed int);
extern template tinyfmt& operator<<(tinyfmt&, signed long);
extern template tinyfmt& operator<<(tinyfmt&, signed long long);

}  // namespace rocket

void
do_format(::rocket::tinyfmt& fmt, int value)
  {
    fmt << value;
  }

$ g++ -S -o - cxx-mismatch.cpp -O2
[...]
_Z9do_formatRN6rocket13basic_tinyfmtIcEEi:
        jmp     _ZN6rocketlsIciLPv0EEERNS_13basic_tinyfmtIT_EES5_T0_@PLT

$ clang++ -S -o - cxx-mismatch.cpp -O2
_Z9do_formatRN6rocket13basic_tinyfmtIcEEi:
        jmp     _ZN6rocketlsIciTnPNSt9enable_ifIXaasr13is_arithmeticIT0_EE5valuentsr7is_sameIS2_T_EE5valueEvE4typeELPv0EEERNS_13basic_tinyfmtIS3_EESA_S2_@PLT

The generated function name is the same in both cases, _Z9do_formatRN6rocket13basic_tinyfmtIcEEi, but GCC references a function named _ZN6rocketlsIciLPv0EEERNS_13basic_tinyfmtIT_EES5_T0_ while Clang references a function named _ZN6rocketlsIciTnPNSt9enable_ifIXaasr13is_arithmeticIT0_EE5valuentsr7is_sameIS2_T_EE5valueEvE4typeELPv0EEERNS_13basic_tinyfmtIS3_EESA_S2_; this can end up causing undefined references. Both symbols demangle into the same, rocket::basic_tinyfmt<char>& rocket::operator<<<char, int, (void*)0>(rocket::basic_tinyfmt<char>&, int).

Issue originally encountered by @lhmouse.

[pinskia]

This might be gcc not implementing the full ABI here: enable_if . See #85656 also.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Martin Storsjö (mstorsjo)

https://godbolt.org/z/TK7Yr8b6c shows a difference in C++ mangling, or what symbol reference gets generated, between GCC and and Clang.

#include <type_traits>
namespace rocket {

template<typename charT>
class basic_tinyfmt;

using tinyfmt = basic_tinyfmt<char>;
using ::std::enable_if;
using ::std::is_arithmetic;
using ::std::is_same;

template<typename charT, typename valueT,
typename enable_if<is_arithmetic<valueT>::value 
                   && !is_same<valueT, charT>::value
  >::type* = nullptr>
inline
basic_tinyfmt<charT>&
operator<<(basic_tinyfmt<charT>& fmt, valueT value);  //...

extern template tinyfmt& operator<<(tinyfmt&, signed char);
extern template tinyfmt& operator<<(tinyfmt&, signed short);
extern template tinyfmt& operator<<(tinyfmt&, signed int);
extern template tinyfmt& operator<<(tinyfmt&, signed long);
extern template tinyfmt& operator<<(tinyfmt&, signed long long);

}  // namespace rocket

void
do_format(::rocket::tinyfmt& fmt, int value)
  {
    fmt << value;
  }

$ g++ -S -o - cxx-mismatch.cpp -O2
[...]
_Z9do_formatRN6rocket13basic_tinyfmtIcEEi:
        jmp     _ZN6rocketlsIciLPv0EEERNS_13basic_tinyfmtIT_EES5_T0_@<!-- -->PLT

$ clang++ -S -o - cxx-mismatch.cpp -O2
_Z9do_formatRN6rocket13basic_tinyfmtIcEEi:
        jmp     _ZN6rocketlsIciTnPNSt9enable_ifIXaasr13is_arithmeticIT0_EE5valuentsr7is_sameIS2_T_EE5valueEvE4typeELPv0EEERNS_13basic_tinyfmtIS3_EESA_S2_@<!-- -->PLT

The generated function name is the same in both cases, _Z9do_formatRN6rocket13basic_tinyfmtIcEEi, but GCC references a function named _ZN6rocketlsIciLPv0EEERNS_13basic_tinyfmtIT_EES5_T0_ while Clang references a function named _ZN6rocketlsIciTnPNSt9enable_ifIXaasr13is_arithmeticIT0_EE5valuentsr7is_sameIS2_T_EE5valueEvE4typeELPv0EEERNS_13basic_tinyfmtIS3_EESA_S2_; this can end up causing undefined references. Both symbols demangle into the same, rocket::basic_tinyfmt<char>& rocket::operator<<<char, int, (void*)0>(rocket::basic_tinyfmt<char>&, int).

Issue originally encountered by @lhmouse.

[lhmouse]

This might be gcc not implementing the full ABI here: enable_if . See #85656 also.

Is it likely that GCC will implement it in the future? I hope it won't happen, as it will be a serious ABI break, no matter how correct it seems.

And it's not only GCC that doesn't mangle the name, binutils (up to 2.44) is also not able to demangle the new symbol.

[philnik777]

This might be gcc not implementing the full ABI here: enable_if . See #85656 also.

Is it likely that GCC will implement it in the future? I hope it won't happen, as it will be a serious ABI break, no matter how correct it seems.

Is it though? There really aren't many uses of -fclang-abi-compat=17 in the wild: https://sourcegraph.com/search?q=context:global+-fclang-abi-compat%3D17+-file:mangle-concept.cpp+-file:ReleaseNotes.rst+-file:aarch64-mangle-sve-vectors.cpp+-file:ReleaseNotes.html&patternType=keyword&sm=0 (and in libc++ we've also changed the mangling of lots of builtins, which nobody has complained about so far)

[lhmouse]

Is it though? There really aren't many uses of -fclang-abi-compat=17 in the wild: https://sourcegraph.com/search?q=context:global+-fclang-abi-compat%3D17+-file:mangle-concept.cpp+-file:ReleaseNotes.rst+-file:aarch64-mangle-sve-vectors.cpp+-file:ReleaseNotes.html&patternType=keyword&sm=0 (and in libc++ we've also changed the mangling of lots of builtins, which nobody has complained about so far)

I suspect it's because an implicit template specialization of an inline function template always results in a COMDAT definition, so in user code there's always something to link with, even though there's another definition, mangled differently elsewhere.

I'm having this issue here because for some reason Clang chooses to not inline this template. Clang doesn't emit a COMDAT definition as it's specialized explicitly, and causes a linker error because the library that provides the definition is compiled by GCC.

---

The reason why I want to use Clang to compile this piece of code is because Meson generates compile_commands.json that includes pre-compiled headers. Configuring with GCC creates a GCC PCH that is unusable by Clang, and under such circumstance Clang attempts to include the real header which doesn't exist physically (meson source), making Clangd unusable.