clang++ incompatibility with libstdc++ gcc4-compatible ABI on Windows

[jeremyd2019]

This was first seen on Cygwin (x86_64-pc-windows-cygnus), where GCC is built with --with-default-libstdcxx-abi=gcc4-compatible, but I reproduced it on x86_64-pc-windows-gnu as well, so I decided to report here.

Start with a mingw-w64 gcc built without --enable-fully-dynamic-string configure argument, and possibly with --with-default-libstdcxx-abi=gcc4-compatible. It should be possible to switch to the gcc4-compatible ABI with -D_GLIBCXX_USE_CXX11_ABI=0 if not built with that option.

The following test program aborts when built with -O2, unless built with -std=c++20 or newer:

#include <stdio.h>
#include <string>

class foo
{
public:
  foo() { m_str.assign("hello"); }

  std::string m_str;

} bar;

int main()
{
  printf("%ld - %s\n", __cplusplus, bar.m_str.c_str());
  return 0;
}

Output of clang++ -O2 -S -o test.clang.s test.cpp
test.clang.s.txt

output of g++ -O2 -S -o test.gcc.s test.cpp
test.gcc.s.txt

relevant difference:

	leaq	_ZNSs4_Rep20_S_empty_rep_storageE(%rip), %rdx
	cmpq	%rdx, %rcx
...
	.section	.bss$_ZNSs4_Rep20_S_empty_rep_storageE,"bw",discard,_ZNSs4_Rep20_S_empty_rep_storageE
	.globl	_ZNSs4_Rep20_S_empty_rep_storageE # @_ZNSs4_Rep20_S_empty_rep_storageE
	.p2align	4, 0x0
_ZNSs4_Rep20_S_empty_rep_storageE:
	.zero	32

vs

	cmpq	.refptr._ZNSs4_Rep20_S_empty_rep_storageE(%rip), %rcx
...
	.section	.rdata$.refptr._ZNSs4_Rep20_S_empty_rep_storageE, "dr"
	.globl	.refptr._ZNSs4_Rep20_S_empty_rep_storageE
	.linkonce	discard
.refptr._ZNSs4_Rep20_S_empty_rep_storageE:
	.quad	_ZNSs4_Rep20_S_empty_rep_storageE

relevant bit of libstdc++ header:

  // Inhibit implicit instantiations for required instantiations,
  // which are defined via explicit instantiations elsewhere.
#if _GLIBCXX_EXTERN_TEMPLATE
  // The explicit instantiation definitions in src/c++11/string-inst.cc and
  // src/c++17/string-inst.cc only instantiate the members required for C++17
  // and earlier standards (so not C++20's starts_with and ends_with).
  // Suppress the explicit instantiation declarations for C++20, so C++20
  // code will implicitly instantiate std::string and std::wstring as needed.
# if __cplusplus <= 201703L && _GLIBCXX_EXTERN_TEMPLATE > 0
  extern template class basic_string<char>;
# elif ! _GLIBCXX_USE_CXX11_ABI
  // Still need to prevent implicit instantiation of the COW empty rep,
  // to ensure the definition in libstdc++.so is unique (PR 86138).
  extern template basic_string<char>::size_type
    basic_string<char>::_Rep::_S_empty_rep_storage[];
# elif _GLIBCXX_EXTERN_TEMPLATE > 0
  // Export _M_replace_cold even for C++20.
  extern template void
    basic_string<char>::_M_replace_cold(char *, size_type, const char*,
					const size_type, const size_type);
# endif

_GLIBCXX_EXTERN_TEMPLATE is 1, and the issue manifests when _GLIBCXX_USE_CXX11_ABI is 0 and __cplusplus is <= 201703.

see msys2/MSYS2-packages#5329 for history of the investigation.

/cc @mstorsjo

[jeremyd2019]

I don't have rights to set labels, assuming there are more relevant ones.

[jeremyd2019]

MSYS2's mingw-w64-*-gcc packages are built with --enable-fully-dynamic-string so I had to build a custom GCC with the options necessary to test this there: https://github.com/jeremyd2019/MINGW-packages/actions/runs/14479493510

[jeremyd2019]

I'm also seeing a crash with the following simple "hello world" program. I haven't been able to see a relevant difference in the -S output yet (I see something fishy around std::endl but it crashes before getting to that and still crashes with the endl removed).

#include <iostream>

int main() {
    std::cout << "Hello" << std::endl;
    return 0;
}

Thread 1 "hello" received signal SIGSEGV, Segmentation fault.
0x00000003fd9f9cd6 in cygstdc++-6!_ZNSo6sentryC1ERSo ()
   from /usr/bin/cygstdc++-6.dll
(gdb) bt
#0  0x00000003fd9f9cd6 in cygstdc++-6!_ZNSo6sentryC1ERSo ()
   from /usr/bin/cygstdc++-6.dll
#1  0x00000003fda7cc19 in cygstdc++-6!_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l () from /usr/bin/cygstdc++-6.dll
#2  0x00000003fda8baa7 in cygstdc++-6!_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc () from /usr/bin/cygstdc++-6.dll
#3  0x00000001004010a6 in main ()

This crashes on Cygwin but not on MSYS2, so it seems likely to be due to the C++11 ABI option.

[mstorsjo]

I haven't really studied the libstdc++ code closely here to understand what's going on... Is this a case where the Cygwin GCC build somehow sets different ABI defines somewhere, that we should try to match? From the fix attempts, it seems so? It's a bit annoying if this is based on a configure option, which sets custom hardcoded values for that GCC build, but which may change at some point in the future...

For reference, see 4e6c8f1, where I added a similar libstdc++ define for a different case. That one was attempting to fix a define that GCC itself sets in gcc/config/i386/cygming.h, where it always is enabled for such targets, which makes it a bit easier to deal with.

That particular commit adds it in clang/lib/Frontend/InitPreprocessor.cpp though; adding it in a toolchain specific file is probably neater. Adding code for checking whether an explicit define already is set feels a bit unusual though - I don't think much other cases does that? If we predefined one value in the compiler, the user specified one should probably apply later anyway - but it would possibly cause warnings about being redefined. I think Clang maintainers may have better input on that case though...

[jeremyd2019]

I haven't really studied the libstdc++ code closely here to understand what's going on... Is this a case where the Cygwin GCC build somehow sets different ABI defines somewhere, that we should try to match? From the fix attempts, it seems so?

No, the "fix attempts" are really more "workaround attempts" that actually switch to the other of the "dual abi" because that one is not broken. The default ABI on Cygwin (due to gcc configure option, kept to keep compatibility with old libaries) is broken with Clang. It apparently doesn't treat the static member of an extern explicit template class instantiation as extern, while GCC does.

[mstorsjo]

Thanks, I see! Ok that makes it clearer what to look for here. Is it possible to reduce a minimal testcase with the problematic code without any includes at all? Does Clang do the right thing for a mingw target, for such a testcase, or is this a case which we just haven't hit there either?

[jeremyd2019]

Clang does not do the "right thing" (doesn't do the same thing as GCC, up to someone else to decide which is "right") for mingw target either, which convinced me to open this issue. I might be able to put something simple together, I don't know if it requires a DLL in the mix or if it will reproduce with just two TUs linked together.