[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

2023-08-07 Thread sascha.scandella at dentsplysirona dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432

--- Comment #19 from Sascha Scandella  ---
(In reply to Jonathan Wakely from comment #17)
> The fix has been backported to gcc-13 now. There should be a release
> candidate for 13.2 in the next day or so, please try it out on macOS to make
> sure the fix works.

@Jonathan: I could have tested now at the earliest. It seems that 13.2 has
already been released. I could do a test as soon as the Homebrew version has
been released.

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

2023-07-01 Thread sascha.scandella at dentsplysirona dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432

--- Comment #15 from Sascha Scandella  ---
For Darwin and GCC 13.1 I've openend a PR with the band-aid fix as proposed by
Jonathan.

https://github.com/Homebrew/homebrew-core/pull/135530

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

2023-06-30 Thread sascha.scandella at dentsplysirona dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432

--- Comment #13 from Sascha Scandella  ---
Awesome. Thanks a lot for the provided solution! Nice!

Is already known when approximately GCC 13.2 will be released?

Have a great weekend!

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

2023-06-29 Thread sascha.scandella at dentsplysirona dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432

--- Comment #8 from Sascha Scandella  ---
I've tested the proposed solution ...

#if !__has_attribute(__init_priority__) || defined __APPLE__

... and it works as expected. I had also done something similar before, so I
wasn't that surprised.

Let me know if you need more information from my side.

Who will fix the bug?

Thank you for your help and support! I appreciate it very much.

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

2023-06-27 Thread sascha.scandella at dentsplysirona dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432

--- Comment #6 from Sascha Scandella  ---
(In reply to Iain Sandoe from comment #5)
> For now, IMO, we should adopt a fix of the nature Jonathan suggests and then
> it will "just work" if/when we get init prio on Darwin.

Agreed. Sounds reasonable to get a fix for one of the next versions.

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

2023-06-27 Thread sascha.scandella at dentsplysirona dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432

--- Comment #4 from Sascha Scandella  ---
I found also this issue regarding init_priority:
https://github.com/llvm/llvm-project/issues/15363

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

2023-06-27 Thread sascha.scandella at dentsplysirona dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432

--- Comment #2 from Sascha Scandella  ---
> Still libstdc++ ;-)

True that ;-)

> Patrick, we talked about this and IIRC your suggestion was to move the
> __has_attribute check into configure, so that it depends on GCC, not on
> whichever compiler happens to include  later.

I think this would also be a solution. Would this then be included in a future
GCC 13.2? Took quite a while until I figured out the reason for the segfault.

Just for completeness sake. I also posted it on one of the brew repositories
for GCC. Probably this could be patched on macOS also for GCC 13.1.
https://github.com/iains/gcc-13-branch/issues/6

[Bug libstdc++/110432] New: macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

2023-06-27 Thread sascha.scandella at dentsplysirona dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432

Bug ID: 110432
   Summary: macOS: Segmentation fault when using stdlibc++ from
gcc 13.1 in combination with clang-16
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sascha.scandella at dentsplysirona dot com
  Target Milestone: ---

As you certainly all know GCC has changed the way how the global iostream
objects are created since gcc 13.1. This can be found on the official page.

"For C++, construction of the global iostream objects std::cout, std::cin, etc.
is now done inside the standard library, instead of in every source file that
includes the header. This change improves the start-up performance of C++
programs, but it means that code compiled with GCC 13.1 will crash if the
correct version of libstdc++.so is not used at runtime. See the documentation
about using the right libstdc++.so at runtime. Future GCC releases will
mitigate the problem so that the program cannot be run at all with an older
libstdc++.so."

More details can also be found here:
https://developers.redhat.com/articles/2023/04/03/leaner-libstdc-gcc-13

On macOS SUPPORTS_INIT_PRIORITY within gcc is set to 0. This means that the
global iostream object is not initialized and the fallback will be taken (i.e.
static initialization of the iostream object).

The problem is that when the iostream include is used, the expression
__has_attribute(__init_priority__) is true, since clang-16 supports
__init_priority__ and the static initialization is not done. See here:

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/iostream#L78

This leads to a segmentation fault with a simple sample application when using
clang-16 in combination with stdlibc++.

Sample application:

#include 

int main()
{
  std::cout << "Hello" << std::endl;
}
$HOMEBREW_PREFIX/opt/llvm@16/bin/clang++ \
  -v \
  -stdlib=libstdc++ \
  -stdlib++-isystem $HOMEBREW_PREFIX/opt/gcc@13/include/c++/13 \
  -cxx-isystem $HOMEBREW_PREFIX/opt/gcc@13/include/c++/13/x86_64-apple-darwin22
\
  -L $HOMEBREW_PREFIX/opt/gcc@13/lib/gcc/13/ \
  -L $HOMEBREW_PREFIX/opt/llvm/lib \
  -o test main.cpp
Execute test -> segfault.

➜  ~ ./test
[1]7965 segmentation fault  ./test

Would it be possible to change the #if statement such that it would also work
on macOS when using clang in combination with the stdlibc++?

#if !__has_attribute(__init_priority__)
  static ios_base::Init __ioinit;
#elif defined(_GLIBCXX_SYMVER_GNU)
  __extension__ __asm (".globl _ZSt21ios_base_library_initv");
#endif

Remarks: When compiling with gcc everything works as expected since the
iostream object gets initialized properly with the fallback.

gcc -v

Using built-in specs.
COLLECT_GCC=gcc-13
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/13.1.0/bin/../libexec/gcc/x86_64-apple-darwin22/13/lto-wrapper
Target: x86_64-apple-darwin22
Configured with: ../configure --prefix=/usr/local/opt/gcc
--libdir=/usr/local/opt/gcc/lib/gcc/current --disable-nls
--enable-checking=release --with-gcc-major-version-only
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-13
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-zstd=/usr/local/opt/zstd --with-pkgversion='Homebrew GCC 13.1.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-system-zlib --build=x86_64-apple-darwin22
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Homebrew GCC 13.1.0) 

OS: macOS Ventura 13.4 (Intel)