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

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

[sascha.scandella at dentsplysirona dot com]

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 <iostream>

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)

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-06-27
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ABI
                 CC|                            |ppalka at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Sascha Scandella from comment #0)
> This leads to a segmentation fault with a simple sample application when
> using clang-16 in combination with stdlibc++.

It's libstdc++

> 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++?

Still libstdc++ ;-)

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

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 <iostream> later.

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

[sascha.scandella at dentsplysirona dot com]

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

--- Comment #2 from Sascha Scandella <sascha.scandella at dentsplysirona dot com> ---
> 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 <iostream> 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] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
<aside>

interesting - Apple clang does seem to accept __attribute__((init_priority))
but it still does not actually work **between TUs** unless LTO is engaged. 

Actually GCC for Darwin could adopt a similar scheme (perhaps we should to be
*** compatible).

The issue is not whether GCC can do it - it is whether the linker (ld64)
honours the ordering information and can generate a new global initialiser
(which it seems still not to).

AFAIR upstream clang rejects the attribute for Darwin.

</aside>

@Jonathan is there a patch for that proposed solution?

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

[sascha.scandella at dentsplysirona dot com]

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

--- Comment #4 from Sascha Scandella <sascha.scandella at dentsplysirona dot com> ---
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

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sascha Scandella from comment #4)
> I found also this issue regarding init_priority:
> https://github.com/llvm/llvm-project/issues/15363

So that is the intentional behaviour (upstream clang definitely used to reject
it) - as noted it actually works fine with LTO too (or within one module if
not).

I was investigating whether we could do the work in collect2, but that gets
quite complex when considering the interactions between LTO and non-LTO
objects.

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.

in slower time, we might consider the option of following clang's behaviour for
Darwin (possibly with a warning about the does-not-work-between-tus).

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

[sascha.scandella at dentsplysirona dot com]

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

--- Comment #6 from Sascha Scandella <sascha.scandella at dentsplysirona dot com> ---
(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

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Sascha Scandella from comment #2)
> I think this would also be a solution. Would this then be included in a
> future GCC 13.2?

Yes

(In reply to Iain Sandoe from comment #3)
> @Jonathan is there a patch for that proposed solution?

No

Thinking further about this, maybe we should just do:

#if !__has_attribute(__init_priority__) || defined __APPLE__

Because checking in the configure script would still give the wrong answer if
libstdc++ is built on macOS using Clang (which is unsupported, but people do
the darndest things). So maybe keep it simple and just don't try to use the
feature on macOS at all, ever.

(In reply to Iain Sandoe from comment #5)
> in slower time, we might consider the option of following clang's behaviour
> for Darwin (possibly with a warning about the does-not-work-between-tus).

I don't understand why one would want to use the attribute only within a single
TU, that doesn't seem useful.

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

[sascha.scandella at dentsplysirona dot com]

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

--- Comment #8 from Sascha Scandella <sascha.scandella at dentsplysirona dot com> ---
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

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Target Milestone|---                         |13.2
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

--- Comment #9 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> 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 <iostream> later.

Yes, sorry for letting this issue slip through the cracks.  It makes sense to
fix this by simply disabling the <iostream> optimization on macOS as you
suggested, and perhaps worry about a configure-time check only if it turns out
another platform hits this issue.

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

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #9)
> (In reply to Jonathan Wakely from comment #1)
> > 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 <iostream> later.
> 
> Yes, sorry for letting this issue slip through the cracks.  It makes sense
> to fix this by simply disabling the <iostream> optimization on macOS as you
> suggested, and perhaps worry about a configure-time check only if it turns
> out another platform hits this issue.

do all the other (I guess non-embedded) platforms now have init priority
support?
(I think maybe something was added to AIX recently, and I suppose that Solaris
when using bfd ld, at least would).

the solution is a reasonable band-aid (given that a patch to make init priority
work on Darwin is some way in the future).

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

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #10)
> do all the other (I guess non-embedded) platforms now have init priority
> support?

It's OK if they don't, as long as (1) the attribute tells the truth, and (2)
clang doesn't support it where gcc doesn't.

It's fine to have no init_priority support, the library handles that OK.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:fe2651affa8c15624188bfd062fb894648743431

commit r14-2221-gfe2651affa8c15624188bfd062fb894648743431
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Jun 30 11:07:35 2023 +0100

    libstdc++: Fix iostream init for Clang on darwin [PR110432]

    The __has_attribute(init_priority) check in <iostream> is true for Clang
    on darwin, which means that user code including <iostream> thinks the
    library will initialize the global streams. However, when libstdc++ is
    built by GCC on darwin, the __has_attribute(init_priority) check is
    false, which means that the library thinks that user code will do the
    initialization when <iostream> is included. This means that the
    initialization is never done.

    Add an autoconf check so that the header and the library both make their
    decision based on the static properties of GCC at build time, with a
    consistent outcome.

    As a belt and braces check, also do the initialization in <iostream> if
    the compiler including that header doesn't support the attribute (even
    if the library also containers the initialization). This might result in
    redundant initialization done in <iostream>, but ensures the
    initialization happens somewhere if there's any doubt about the
    attribute working correctly due to missing linker support.

    libstdc++-v3/ChangeLog:

            PR libstdc++/110432
            * acinclude.m4 (GLIBCXX_CHECK_INIT_PRIORITY): New.
            * config.h.in: Regenerate.
            * configure: Regenerate.
            * configure.ac: Use GLIBCXX_CHECK_INIT_PRIORITY.
            * include/std/iostream: Use new autoconf macro as well as
            __has_attribute.
            * src/c++98/ios_base_init.h: Use new autoconf macro instead of
            __has_attribute.

    Reviewed-by: Patrick Palka <ppalka@redhat.com>

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

[sascha.scandella at dentsplysirona dot com]

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

--- Comment #13 from Sascha Scandella <sascha.scandella at dentsplysirona dot com> ---
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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The above change hasn't been backported to 13 branch yet.
13.2 release is tentatively planned for July 27th.

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

[sascha.scandella at dentsplysirona dot com]

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

--- Comment #15 from Sascha Scandella <sascha.scandella at dentsplysirona dot com> ---
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:61bf34d17473d611bb2695329808810dbd5af478

commit r13-7591-g61bf34d17473d611bb2695329808810dbd5af478
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Jun 30 11:07:35 2023 +0100

    libstdc++: Fix iostream init for Clang on darwin [PR110432]

    The __has_attribute(init_priority) check in <iostream> is true for Clang
    on darwin, which means that user code including <iostream> thinks the
    library will initialize the global streams. However, when libstdc++ is
    built by GCC on darwin, the __has_attribute(init_priority) check is
    false, which means that the library thinks that user code will do the
    initialization when <iostream> is included. This means that the
    initialization is never done.

    Add an autoconf check so that the header and the library both make their
    decision based on the static properties of GCC at build time, with a
    consistent outcome.

    As a belt and braces check, also do the initialization in <iostream> if
    the compiler including that header doesn't support the attribute (even
    if the library also containers the initialization). This might result in
    redundant initialization done in <iostream>, but ensures the
    initialization happens somewhere if there's any doubt about the
    attribute working correctly due to missing linker support.

    libstdc++-v3/ChangeLog:

            PR libstdc++/110432
            * acinclude.m4 (GLIBCXX_CHECK_INIT_PRIORITY): New.
            * config.h.in: Regenerate.
            * configure: Regenerate.
            * configure.ac: Use GLIBCXX_CHECK_INIT_PRIORITY.
            * include/std/iostream: Use new autoconf macro as well as
            __has_attribute.
            * src/c++98/ios_base_init.h: Use new autoconf macro instead of
            __has_attribute.

    Reviewed-by: Patrick Palka <ppalka@redhat.com>
    (cherry picked from commit fe2651affa8c15624188bfd062fb894648743431)

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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.

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

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
A release candidate arrived:
https://gcc.gnu.org/pipermail/gcc/2023-July/242116.html

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

[sascha.scandella at dentsplysirona dot com]

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

--- Comment #19 from Sascha Scandella <sascha.scandella at dentsplysirona dot com> ---
(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.