[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #18 from Jonathan Wakely --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Jonathan Wakely --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #16 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:61bf34d17473d611bb2695329808810dbd5af478 commit r13-7591-g61bf34d17473d611bb2695329808810dbd5af478 Author: Jonathan Wakely 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 is true for Clang on darwin, which means that user code including 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 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 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 , 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 (cherry picked from commit fe2651affa8c15624188bfd062fb894648743431)
[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fe2651affa8c15624188bfd062fb894648743431 commit r14-2221-gfe2651affa8c15624188bfd062fb894648743431 Author: Jonathan Wakely 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 is true for Clang on darwin, which means that user code including 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 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 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 , 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
[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #11 from Jonathan Wakely --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #10 from Iain Sandoe --- (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 later. > > Yes, sorry for letting this issue slip through the cracks. It makes sense > to fix this by simply disabling the 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 Patrick Palka 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 --- (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 later. Yes, sorry for letting this issue slip through the cracks. It makes sense to fix this by simply disabling the 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #7 from Jonathan Wakely --- (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #5 from Iain Sandoe --- (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #3 from Iain Sandoe --- 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. @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
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] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432
Jonathan Wakely 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 ---
(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 later.
