If you compile gcc13 with CPUTYPE?=broadwell then the resulting libgcc will break some applications, which receive a SIGBUS. Known applications are octave and freecad. %% Reproduce: (You need X11 or X11 forwarding to see the problem) Take some FreeBSD-14 (we had this on multiple subversions of 14). `pkg install octave` Call `octave --gui`. It will come up with a window with some text in it. Save /usr/local/lib/gcc13/ somewhere. Put CPUTYPE?=broadwell in /etc/make.conf `make reinstall` in lang/gcc13 Call `octave --gui` again. It will create the window but SIGBUSes before rendering text in there. Put back the saved /usr/local/lib/gcc13. `octave --gui` will work again. The other known affected app is freecad. %% Hardware which SIGBUSes: Dual Broadwell VM in a KVM VM Desktop 1: AMD ThreadRipper 7960X Desktop 2: AMD Ryzen 9 9900X Desktop 3: Intel i7-1185 %% FreeCAD backtrace: (gdb) bt #0 0x0000000804ded1c6 in _Unwind_ForcedUnwind (exc=0x808bbba48, stop=0x8040da480 <thread_unwind_stop>, stop_argument=0x0) at /mnt/part2/usr/ports/lang/gcc13/work/gcc-13.3.0/libgcc/unwind.inc:215 #1 0x00000008040da2bc in _Unwind_ForcedUnwind (ex=0x808bbba48, stop_func=0x7fffdeff5e20, stop_arg=0x0) at /mnt/part2/usr/src/lib/libthr/thread/thr_exit.c:106 #2 thread_unwind () at /mnt/part2/usr/src/lib/libthr/thread/thr_exit.c:172 #3 0x00000008040da232 in _pthread_exit_mask (status=<optimized out>, mask=mask@entry=0x0) at /mnt/part2/usr/src/lib/libthr/thread/thr_exit.c:254 #4 0x00000008040da0db in _Tthr_exit (status=0x808bbba48) at /mnt/part2/usr/src/lib/libthr/thread/thr_exit.c:206 #5 0x00000008040d9bca in thread_start (curthread=0x808bbb808) at /mnt/part2/usr/src/lib/libthr/thread/thr_create.c:289 #6 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdeff6000 Looks funny, not sure whether that is really the problem path. I don't have an octave backtrace at this time since it catches the signal and exits. Will do tomorrow. %% Problem originally found by jbo@freebsd.org
Backtrace from Octave: Thread 4 received signal SIGBUS, Bus error. Object-specific hardware error. [Switching to LWP 116085 of process 91602] 0x0000000805fb21c6 in _Unwind_ForcedUnwind (exc=0x80b8ada48, stop=0x805f1e480 <thread_unwind_stop>, stop_argument=0x0) at /mnt/part2/usr/ports/lang/gcc13/work/gcc-13.3.0/libgcc/unwind.inc:215 215 exc->private_1 = (_Unwind_Ptr) stop; (gdb) bt #0 0x0000000805fb21c6 in _Unwind_ForcedUnwind (exc=0x80b8ada48, stop=0x805f1e480 <thread_unwind_stop>, stop_argument=0x0) at /mnt/part2/usr/ports/lang/gcc13/work/gcc-13.3.0/libgcc/unwind.inc:215 #1 0x0000000805f1e2bc in _Unwind_ForcedUnwind (ex=0x80b8ada48, stop_func=0x7fffdfbfbe20, stop_arg=0x0) at /mnt/part2/usr/src/lib/libthr/thread/thr_exit.c:106 #2 thread_unwind () at /mnt/part2/usr/src/lib/libthr/thread/thr_exit.c:172 #3 0x0000000805f1e232 in _pthread_exit_mask (status=<optimized out>, mask=mask@entry=0x0) at /mnt/part2/usr/src/lib/libthr/thread/thr_exit.c:254 #4 0x0000000805f1e0db in _Tthr_exit (status=0x80b8ada48) at /mnt/part2/usr/src/lib/libthr/thread/thr_exit.c:206 #5 0x0000000805f1dbca in thread_start (curthread=0x80b8ad808) at /mnt/part2/usr/src/lib/libthr/thread/thr_create.c:289 #6 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfbfc000
gcc14 have same issue? CPUTYPE?=haswell/skylake same error?
(In reply to Vladimir Druzenko from comment #2) Unknown. I know only of octave and freecad being affected and they specifically request gcc-13.
I am would like to simply add WITHOUT_CPU_CFLAGS to the GCC ports. These ports are already complex enough to maintain without having to also deal with CPU specific bugs... Indeed, we already have multiple bug reports related to CPU specific stuff... Could you please test if adding WITHOUT_CPU_CFLAGS=yes to lang/gcc13/Makefile fixes the issue? Thanks
I have confirmed that Octave starts working again with gcc13/Makefile having WITHOUT_CPU_CFLAGS=yes while still having CPUTYPE?=broadwell in /etc/make.conf From my perspective this is a fine fix. index fe54d1ef7c13..738fdbea3464 100644 --- a/lang/gcc13/Makefile +++ b/lang/gcc13/Makefile @@ -27,6 +27,8 @@ USES= compiler:c++11-lang cpe gmake iconv libtool makeinfo perl5 tar:xz USE_BINUTILS= yes USE_PERL5= build +WITHOUT_CPU_CFLAGS=yes + CONFLICTS= gcc13-devel CPE_VENDOR= gnu
The question is, however, whether it is gcc generally producing invalid code with CPUtype set. Then the problem would pop up elsewhere later elsewhere even with this change. Or maybe it is something specific to unwinding in libgcc that has a bogus CPUtype switch, i.e. in assembler code. Then this problem would not pop up elsewhere.
(In reply to Martin Cracauer from comment #6) I have been building all my production packages with CPUTYPE?=broadwell for a year now and I have not encountered any issues other than the libgcc issue discussed here.
What's the next step? As far as I can tell WITHOUT_CPU_CFLAGS=yes is the way to go, except it should probably be conditionalized on amd64.
Since it seems there are no objections to the WITHOUT_CPU_CFLAGS, I plan to merge the change with the usual strategies: - the change will be committed to the -devel ports first, contextually with the weekly snapshots; - then, assuming everything goes fine, the change will go into the production non-default ports; - finally, if no new bugs are reported, it lands in GCC_DEFAULT (lang/gcc13). I do not plan to make the change specific to amd64. The GCC ports are very complex to maintain, so I prefer to keep them as simple as possible. I might change my mind in the future, since we are managing to simplify those ports step by step (e.g. we are collaborating more with upstream so that less local patches are needed; at each GCC_DEFAULT the number of GCC dependent ports decreases).
I have a question: Is WITHOUT_CPU_CFLAGS inherited by ports that are built as a dependency when gcc13 is built? Example: libgmp is a dependency of gcc13. gcc13 has WITHOUT_CPU_CFLAGS. cd /usr/ports/*/libgmp && make install # WITHOUT_CPU_CFLAGS not in effect cd /usr/ports/*/gcc13 && make install # ==> libgpm would be built with WITHOUT_CPU_CFLAGS in effect Is that assumption correct?
I can imagine how immensely complex and time consuming it is to maintain the GCC ports and I appreciate every single minute you put into it. What I am concerned about is that adding WITHOUT_CPU_CFLAGS=yes will be a one-way road. Lets say upstream eventually fixes the underlying issue and some people (like myself) would want to build GCC with CPUTYPE again. This would then require manually maintaining a port patch on the user/consumer level as there is no way to override it via make.conf or similar. If the reasoning is that WITHOUT_CPU_CFLAGS=yes is being applied because the port is too complex to deal with these issues, I fear that even if it works again in the future maintaining efforts will prefer to just keep it as is. After all, this is (I think) a bug in upstream which will/should/might be resolved in future releases. Will WITHOUT_CPU_CFLAGS=yes be removed from the port Makefile then? The compiler itself is just one thing but this basically means that all libraries that this port provides (such as the C++ std lib etc) will not be built to leverage stuff like AVX, AVX2, AVX512 etc. Any port using GCC linking to those libraries will therefore experience the corresponding performance penalty too.
(In reply to Martin Cracauer from comment #10) No, WITHOUT_CPU_CFLAGS is not inherited by dependent ports. You can check it by running "make -V CFLAGS" in dependent ports after having patched lang/gcc13: you should read "-march=broadwell" in the output. However of course dependent ports are affected through linked libraries. (In reply to Joel Bodenmann from comment #11) You are right, we should try harder to avoid introducing workarounds that are difficult to remove later. In other related bugs it has been suggested that higher GCC versions are not affected by this bug. Can you please check at least lang/gcc15-devel? It should be easy enough: just add DEFAULT_VERSIONS+=gcc=15 to your /etc/make.conf; or if you prefer you can set USE_GCC=15 in the ports involved in your tests. If you confirm that lang/gcc15-devel works, then we can avoid patching it and then we would have WITHOUT_CPU_CFLAGS only for lower GCC versions. Thus we would not keep the workaround forever. It would be nice to test other GCC ports too, so that we can set WITHOUT_CPU_CFLAGS only for the ports that really need it. But do not waste time on lang/gcc11: GCC 11 is not supported upstream anymore and the port will be removed once the last port depending on it manages to work with a supported GCC version (or even better with llvm).
(In reply to Lorenzo Salvadore from comment #12) Thank you! I am more than happy to run these tests. However, I have to ask for one or two days of patience. I won't be able to do it tonight.
Alright... I did nine total test builds. Each time I built lang/gcc* and math/octave and checked whether I get the same SIGBUS upon launching `octave --gui`. All other dependencies of math/octave were left untouched (i.e. the ones coming from my poudriere repo which uses CPUTYPE?=broadwell). Each time I verified that octave is linking to the correct libgcc_s.so by using ldd. All builds were performed on a threadripper 7960X with ECC RAM running stable/14 (commit b429d50df97bc6f85373d4bd4ffca7e7078b3fe8): > FreeBSD hedt1 14.2-STABLE FreeBSD 14.2-STABLE stable/14-n270817-b429d50df97b GENERIC amd64 CPUTYPE?=broadwell lang/gcc13 (13.3.0_2): -> SIGBUS lang/gcc14 (14.2.0_3): -> SIGBUS lang/gcc15 (15.0.1.s20250330): -> SIGBUS CPUTYPE?=znver4 lang/gcc13 (13.3.0_2): -> SIGBUS lang/gcc14 (14.2.0_3): -> SIGBUS lang/gcc15 (15.0.1.s20250330): -> SIGBUS CPUTYPE?= lang/gcc13 (13.3.0_2): -> works lang/gcc14 (14.2.0_3): -> works lang/gcc15 (15.0.1.s20250330): -> works Therefore, it appears that gcc14 and gcc15 are also affected. These versions also failed to build the math/openblas dependency. All dependencies to either lang/gcc* or math/octave were taken from my production poudriere. I'm willing to help however I can to "fix this more appropriately". While I understand the complexity, I'd strongly prefer if we'd not set WITHOUT_CPU_CFLAGS=yes in the lang/gcc* ports as per the reasoning in comment #11. After all, the default behavior that any "normal" user will experience is that CPUTYPE is not set anyway. Until we actually tracked down and fixed the underlying issue, is there a way to set WITHOUT_CPU_FLAGS in make.conf but only for the lang/gcc* port(s)? If cracauer@ could reproduce the issue on Linux that would be helpful too.
To see whether this is a general gcc bug I tested this on Linux. The bug with -march=broadwell (when building gcc) does not appear in octave, neither with gcc-13 nor gcc-14.
(In reply to Joel Bodenmann from comment #14) > Until we actually tracked down and fixed the underlying issue, > is there a way to set WITHOUT_CPU_FLAGS in make.conf but only for the lang/gcc* port(s)? Try this: .if ${.CURDIR:M*/lang/gcc*} WITHOUT_CPU_FLAGS=yes .endif
In some other related bug, a fix had been proposed: https://bz-attachments.freebsd.org/attachment.cgi?id=258472 . Can you please test if the fix works? If it does, we should then consider sending it upstream.
(In reply to Lorenzo Salvadore from comment #17) This patch fixes the problem for me. I do not understand how this patch fixes a problem that only appears with CPUTYPE set, nor do I understand why the problem did not appear in Linux.
(In reply to Martin Cracauer from comment #18) Used AVX* optimizations for this operations and corrupt (do not restore) AVX* registers after? Just a guess.
(In reply to Martin Cracauer from comment #18) The problem is that GCC generates instructions that require variables to be aligned in memory on ceratin CPUs. Our libthr doesn't have the required alignment so these CPUs fail to execute these instructions. The instructions generation is driven by CPUTYPE. And there are CPUs that are OK to execute these instructions on unaligned data. This patch explicitly forbids GCC to generate instructions that require alignment of the data so it helps here. Linux doesn't have libthr, (I think libpthread has the required alignment of the data) so GCC works there.
The patch from comment #17 also seems to work for me. @salvadore Is that patch viable from your perspective as a maintainer? Also, would it be possible to get a link to the "related bug" so I know to whom I should send my thanks? Thank you all for your efforts. Special thanks to cracauer@ as he spent countless hours with me on IRC tracking this down over the past few weeks.
(In reply to Joel Bodenmann from comment #11) > I can imagine how immensely complex and time consuming it is to maintain > the GCC ports and I appreciate every single minute you put into it. You're welcome (from the guy who did this the two previous decades). :-) (In reply to Lorenzo Salvadore from comment #17) > In some other related bug, a fix had been proposed: > https://bz-attachments.freebsd.org/attachment.cgi?id=258472 > > If it does, we should then consider sending it upstream. It looks like this does indeed address the issue? Happy to help upstreaming it. Who and where did it come from? (In reply to Oleg Sidorkin from comment #20) > The problem is that GCC generates instructions that require variables > to be aligned in memory on ceratin CPUs. Our libthr doesn't have the > required alignment so these CPUs fail to execute these instructions. > The instructions generation is driven by CPUTYPE. Thank you for the analysis! In addition to trying to upstream the GCC patch, shouldn't we also get libthr improved to align these variables? Even on CPUs not *requiring* alignment, such misalignment will incur a performance penalty. Thanks jbo@ and cracauer@ for your efforts tracking this down!
(In reply to Joel Bodenmann from comment #21) Yes, I believe this patch is good from a maintenance point of view. And of course if we manage to upstream it or to improve libthr as suggested by Gerald, it will only be temporary. > Also, would it be possible to get a link to the "related bug" so I know to whom I should send my thanks? (In reply to Gerald Pfeifer from comment #22) > Who and where did it come from? First occurrence of the patch seems to be https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284425#c43 . So we have to thank Oleg. And I also thank him for the nice explanation in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285711#c20 . As for the merging of the patch into the ports tree, the plan is the same announced in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285711#c9 . This week snapshots tests are almost finished (without the patch), so the merging into the -devel ports is planned for the next snapshots (20250410-20250413).
And of course I also thank jbo@ and cracauer@ and anyone else involved, for testing and help understanding the issue.
(In reply to Lorenzo Salvadore from comment #23) > First occurrence of the patch seems to be https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284425#c43 . Sorry, was going to answer, but got to my laptop too late. Originally it was just a way to check that alignment is a problem and the only problem. If the entire program is compiled by LLVM or GCC, there is no problem (with GCC everything is aligned, with LLVM vmovdqa is not used to assign both variables at once). On Linux, I guess, everything is built with GCC, so nobody sees it. I'm not sure it will be considered as a bug by GCC people, but IMO it still worth submitting it upstream because there might be a better way to fix it.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=0c397ecd5df61ac9258943c9f465ba7f937b0a93 commit 0c397ecd5df61ac9258943c9f465ba7f937b0a93 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-15 12:27:38 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-04-16 13:20:40 +0000 lang/gcc15-devel: Fix SIGBUS depending on CPUTYPE Compiling GCC with some CPUTYPE values (e.g. broadwell) result in breaking some applications (e.g. math/octave, cad/freecad), sending a SIGBUS. The issue is due to GCC generating instructions that require variables to be aligned in memory on certain CPUs. Our libthr does not have the required alignment so these CPUs fail to execute these instructions. The patch disables the generation of such instructions. PR: 285711 Reported by: cracauer Tested by: cracauer, jbo lang/gcc15-devel/Makefile | 1 + .../files/patch-libgcc_unwind.inc (new) | 28 ++++++++++++++++++++++ 2 files changed, 29 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ce45e3c376f4bd72ef6e12e0a3d9964ea217987e commit ce45e3c376f4bd72ef6e12e0a3d9964ea217987e Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-13 14:45:54 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-04-16 13:20:39 +0000 lang/gcc14-devel: Fix SIGBUS depending on CPUTYPE Compiling GCC with some CPUTYPE values (e.g. broadwell) result in breaking some applications (e.g. math/octave, cad/freecad), sending a SIGBUS. The issue is due to GCC generating instructions that require variables to be aligned in memory on certain CPUs. Our libthr does not have the required alignment so these CPUs fail to execute these instructions. The patch disables the generation of such instructions. PR: 285711 Reported by: cracauer Tested by: cracauer, jbo lang/gcc14-devel/Makefile | 1 + .../files/patch-libgcc_unwind.inc (new) | 28 ++++++++++++++++++++++ 2 files changed, 29 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=56b828239c1ab655fbc779e1c353874a8d116fc4 commit 56b828239c1ab655fbc779e1c353874a8d116fc4 Author: Oleg Sidorkin <osidorkin@gmail.com> AuthorDate: 2025-04-12 09:26:32 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-04-16 13:20:36 +0000 lang/gcc12-devel: Fix SIGBUS depending on CPUTYPE Compiling GCC with some CPUTYPE values (e.g. broadwell) result in breaking some applications (e.g. math/octave, cad/freecad), sending a SIGBUS. The issue is due to GCC generating instructions that require variables to be aligned in memory on certain CPUs. Our libthr does not have the required alignment so these CPUs fail to execute these instructions. The patch disables the generation of such instructions. PR: 285711 Reported by: cracauer Tested by: cracauer, jbo lang/gcc12-devel/Makefile | 1 + .../files/patch-libgcc_unwind.inc (new) | 28 ++++++++++++++++++++++ 2 files changed, 29 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e9a2cc36b513e6789f0519846f4c4dec98da54aa commit e9a2cc36b513e6789f0519846f4c4dec98da54aa Author: Oleg Sidorkin <osidorkin@gmail.com> AuthorDate: 2025-04-12 14:49:03 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-04-16 13:20:37 +0000 lang/gcc13-devel: Fix SIGBUS depending on CPUTYPE Compiling GCC with some CPUTYPE values (e.g. broadwell) result in breaking some applications (e.g. math/octave, cad/freecad), sending a SIGBUS. The issue is due to GCC generating instructions that require variables to be aligned in memory on certain CPUs. Our libthr does not have the required alignment so these CPUs fail to execute these instructions. The patch disables the generation of such instructions. PR: 285711 Reported by: cracauer Tested by: cracauer, jbo lang/gcc13-devel/Makefile | 1 + .../files/patch-libgcc_unwind.inc (new) | 28 ++++++++++++++++++++++ 2 files changed, 29 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1c41fd97c78672391f5a73c2b15baee509e6a2e5 commit 1c41fd97c78672391f5a73c2b15baee509e6a2e5 Author: Oleg Sidorkin <osidorkin@gmail.com> AuthorDate: 2025-04-24 08:02:04 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-04-24 12:55:48 +0000 lang/gcc14: Fix SIGBUS depending on CPUTYPE Compiling GCC with some CPUTYPE values (e.g. broadwell) result in breaking some applications (e.g. math/octave, cad/freecad), sending a SIGBUS. The issue is due to GCC generating instructions that require variables to be aligned in memory on certain CPUs. Our libthr does not have the required alignment so these CPUs fail to execute these instructions. The patch disables the generation of such instructions. PR: 285711 Reported by: cracauer Tested by: cracauer, jbo lang/gcc14/Makefile | 2 +- lang/gcc14/files/patch-libgcc_unwind.inc (new) | 28 ++++++++++++++++++++++++++ 2 files changed, 29 insertions(+), 1 deletion(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=231018e228187099b8fac7e55b1a662cdc81c1f8 commit 231018e228187099b8fac7e55b1a662cdc81c1f8 Author: Oleg Sidorkin <osidorkin@gmail.com> AuthorDate: 2025-04-23 14:36:49 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-04-24 12:55:47 +0000 lang/gcc12: Fix SIGBUS depending on CPUTYPE Compiling GCC with some CPUTYPE values (e.g. broadwell) result in breaking some applications (e.g. math/octave, cad/freecad), sending a SIGBUS. The issue is due to GCC generating instructions that require variables to be aligned in memory on certain CPUs. Our libthr does not have the required alignment so these CPUs fail to execute these instructions. The patch disables the generation of such instructions. PR: 285711 Reported by: cracauer Tested by: cracauer, jbo lang/gcc12/Makefile | 2 +- lang/gcc12/files/patch-libgcc_unwind.inc (new) | 28 ++++++++++++++++++++++++++ 2 files changed, 29 insertions(+), 1 deletion(-)
(In reply to commit-hook from comment #31) Great thanks for committing it. BTW, I haven't seen this problem with unpatched gcc-12.
How do you know that the problem is with libthr? Or what is the problem at all? Start with disassembling the faulted instruction, together with dumping all involved registers and memory.
(In reply to Oleg Sidorkin from comment #32) Then probably I could have avoided patching GCC 12, but it is not a big deal: we are going to deprecate GCC 12 ports soon anyway, as the first release of GCC 15 is almost ready and development for GCC 16 has started. lang/gcc13 (GCC_DEFAULT) still needs to be patched. I plan to commit the patch there in about a week. By the way, sorry that I forgot to set the Author field properly in the commits #26 and #27. I have corrected it with a mail on the appropriate mailing list: https://lists.freebsd.org/archives/dev-commits-ports-all/2025-April/157165.html https://lists.freebsd.org/archives/dev-commits-ports-all/2025-April/157166.html
(In reply to Lorenzo Salvadore from comment #34) > lang/gcc13 (GCC_DEFAULT) still needs to be patched. I plan to commit the patch there in about a week. Of course, this is assuming that everything works fine. If the investigations suggested by Konstantin happen to understand more deeply the problem and find a better solution, the plan will change. Unfortunately, I lack some knowledge here and then I am quite inefficient following this issue. Sorry about that. I will try to learn what I am missing and be more helpful.
(In reply to Konstantin Belousov from comment #33) I tried to decompile it here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284425#c43 There are multiple parts (gcc, llvm and libthr) involved, and I'm not sure what part we should blame here. IMO, every single part works well on its own, but the "right" combination of them fails.
Created attachment 259840 [details] libthr: align struct pthread
(In reply to Oleg Sidorkin from comment #36) First wrong thing is that the backtrace ended up in gcc' libgcc_s.so.1 at all. FreeBSD ABI assumes that /lib/libgcc_s.so.1 is used. 1. Does running the crashing binaries like this helps? LD_PRELOAD=/lib/libgcc_s.so.1 /path/to/binary 2. Try the attached patch. The problem is likely due to gcc unwinder assumes struct _Unwind_Exception having specific alignment, but when libthr allocates struct pthread, which embeds struct _Unwind_Exception, the alignment is not honored.
(In reply to commit-hook from comment #29) gcc12, gcc14 and received that patch, as well as gcc1[2-5]-devel. Was gcc13 (non-devel) in intentionally skipped? It's affected too.
(In reply to Harald Schmalzbauer from comment #39) Yes, this is intentional. lang/gcc13 is the default GCC version on FreeBSD at the moment, so it always gets any patch last. This strategy allows for safer updates: any issue with new patches hopefully arises in the -devel ports first or later in the non-default production ports, but in any case before default GCC port gets touched. In this particular case, Konstantin proposed a different solution that affects libthr in base instead. In case this patch is tested successfully, then no patch to any GCC port should be needed: thus the patch will not land to lang/gcc13 at all and the already applied patches to the other GCC ports will be reverted. (In reply to Konstantin Belousov from comment #38) > First wrong thing is that the backtrace ended up in gcc' libgcc_s.so.1 at all. > FreeBSD ABI assumes that /lib/libgcc_s.so.1 is used. Gerald (as maintainer of bsd.gcc.mk), I think that this issue is due to the following lines in bsd.gcc.mk: _GCC_RUNTIME:=++++++${LOCALBASE}/lib/gcc${V}$ .__if ${PORTNAME} == gcc$ # When building GCC itself, we want the target libraries to be used$ # and not the host GCC libraries.$ .__else$ CFLAGS+=++++++++-Wl,-rpath=${_GCC_RUNTIME}$ CXXFLAGS+=++++++-Wl,-rpath=${_GCC_RUNTIME}$ LDFLAGS+=+++++++-Wl,-rpath=${_GCC_RUNTIME} -L${_GCC_RUNTIME}$ .__endif$ Do we need to make an exception for libgcc_s.so.1? Are these lines still needed for other libraries? Maybe we could replace gcc's libgcc_s.so.1 with a symlink to /lib/libgcc_s.so.1.
(In reply to Konstantin Belousov from comment #38) > 1. Does running the crashing binaries like this helps? > LD_PRELOAD=/lib/libgcc_s.so.1 /path/to/binary that helps, thanks
(In reply to Konstantin Belousov from comment #38) > 2. Try the attached patch. Also works (with gcc14 without memcpy patch and without LD_PRELOAD). Thanks again
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=22e564c74eb20e14bd93fd9fdde20e38a29cfcf1 commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2025-04-24 21:24:19 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2025-04-25 11:48:12 +0000 libthr: properly align struct pthreads For instance, the structure contains the struct _Unwind_Exception, and it seems that libgcc requires specific alignment for it. PR: 285711 Tested by: Oleg Sidorkin <osidorkin@gmail.com> Sponsored by: The FreeBSD Foundation MFC after: 1 week lib/libthr/thread/thr_list.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
salvadore@, is it possible that you forgot to push the patch for lang/gcc13?
(In reply to Joel Bodenmann from comment #44) I just learned how to scroll - never mind. Thank you!
I believe that after Konstantin's commit in comment #43 all other commits I have done on the GCC ports are now obsolete and I can safely revert them. Do you confirm?
(In reply to Lorenzo Salvadore from comment #46) Yes I think so. Note that I will merge that to stable/14 and might be stable/13, but not into the release branches. It should be in 14.3.
At the moments we have Oleg's patch in: -lang/gcc12-devel; -lang/gcc13-devel; -lang/gcc14-devel; -lang/gcc15-devel; -lang/gcc12; -lang/gcc14. It is missing from: - lang/gcc13; - lang/gcc15 (not in the ports tree yet: I am creating and testing it); - lang/gcc16-devel (not in the ports tree yet: I am creating and testing it). Since no supported FreeBSD release include Konstantin's patch for now, this is how I plan to proceed: - include Oleg's patch in all GCC ports; - add the following sentence in all patch files: "This patch will become obsolete once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1." - add a similar sentence to all commit messages adding Oleg's patch. This way we ensure that all GCC ports always work for everybody and that the patch will not be forgotten forever once it gets obsolete.
(In reply to Lorenzo Salvadore from comment #48) > Since no supported FreeBSD release include Konstantin's patch for now, > this is how I plan to proceed: > > - include Oleg's patch in all GCC ports; > - add the following sentence in all patch files: "This patch will become > obsolete once all supported FreeBSD releases include commit > 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1." > - add a similar sentence to all commit messages adding Oleg's patch. For the record, this is an excellent plan. (I was just going to make a proposal based on the previous comments, then this comment of yours came in. :-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5835d34761a0b905a987986632222aa7de7fb083 commit 5835d34761a0b905a987986632222aa7de7fb083 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2025-04-24 21:24:19 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2025-05-02 07:30:51 +0000 libthr: properly align struct pthreads PR: 285711 (cherry picked from commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1) lib/libthr/thread/thr_list.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
(In reply to Lorenzo Salvadore from comment #40) > Gerald (as maintainer of bsd.gcc.mk), I think that this issue is due > to the following lines in bsd.gcc.mk: > > _GCC_RUNTIME:=++++++${LOCALBASE}/lib/gcc${V}$ > .__if ${PORTNAME} == gcc$ > # When building GCC itself, we want the target libraries to be used$ > # and not the host GCC libraries.$ > .__else$ > CFLAGS+=++++++++-Wl,-rpath=${_GCC_RUNTIME}$ > CXXFLAGS+=++++++-Wl,-rpath=${_GCC_RUNTIME}$ > LDFLAGS+=+++++++-Wl,-rpath=${_GCC_RUNTIME} -L${_GCC_RUNTIME}$ > .__endif$ > > Do we need to make an exception for libgcc_s.so.1? Are these lines still > needed for other libraries? > Maybe we could replace gcc's libgcc_s.so.1 with a symlink to > /lib/libgcc_s.so.1. I was wondering - if the system libgcc_s.so.1 is complete for all platforms, maybe simply not install GCC's libgcc? kib@ ?
(In reply to Gerald Pfeifer from comment #51) I think there is a value in having the official gcc libgcc_s.so.1. First, this is a different development stream, where the new APIs appear earlier than in the llvm libgcc_s. Second, as the source of truth, it is very useful to be able to replace our implementation with the canonical, and see what is different. Note that for the specific case of this bug, the existence of the gcc' libgcc_s.so allowed to identify and fix the issue in the base system.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a38818665f79d0455c1b788ff2cfb18c2e19181c commit a38818665f79d0455c1b788ff2cfb18c2e19181c Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-30 14:51:24 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:25 +0000 lang/gcc12: Add comment to existing patch Add a comment to files/patch-libgcc_unwind.inc to remember when it will get obsolete, i.e. once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. PR: 285711 lang/gcc12/files/patch-libgcc_unwind.inc | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=bfcb6f38f0ef3d08db3421ef59fa7d349c28c305 commit bfcb6f38f0ef3d08db3421ef59fa7d349c28c305 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-29 15:50:39 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:26 +0000 lang/gcc15: Add port GCC, the GNU Compiler Collection, supports a number of languages. This port installs the C, C++, and Fortran front ends as gcc15, g++15, and gfortran15, respectively. This is the first release from the GCC 15 series. It largely is a copy of lang/gcc15-devel, with release-specific modifications from lang/gcc14. Common issues that could happen when porting code to GCC 15: https://gcc.gnu.org/gcc-15/porting_to.html Changes: https://gcc.gnu.org/gcc-15/changes.html Note: files/patch-libgcc_unwind.inc will get obsolete once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. [1] PR: 285711 [1] lang/Makefile | 1 + lang/gcc15/Makefile (new) | 189 +++++++++++++++++++++ lang/gcc15/distinfo (new) | 3 + .../gcc15/files/patch-arm-unwind-cxx-support (new) | 106 ++++++++++++ lang/gcc15/files/patch-gcc_Makefile.in (new) | 19 +++ lang/gcc15/files/patch-gcc_configure (new) | 22 +++ lang/gcc15/files/patch-gcc_jit_Make-lang.in (new) | 14 ++ lang/gcc15/files/patch-gfortran-libgcc (new) | 69 ++++++++ lang/gcc15/files/patch-libcxxrt (new) | 18 ++ ...ch-libgcc_enable-execute-stack-mprotect.c (new) | 15 ++ lang/gcc15/files/patch-libgcc_unwind.inc (new) | 31 ++++ .../patch-libsanitizer_asan_asan__linux.cpp (new) | 23 +++ .../patch-libsanitizer_asan_asan__thread.cpp (new) | 13 ++ lang/gcc15/files/pkg-message.in (new) | 13 ++ lang/gcc15/pkg-descr (new) | 3 + lang/gcc15/pkg-help (new) | 3 + lang/gcc15/pkg-plist (new) | 36 ++++ 17 files changed, 578 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ef502dd9562c894c1b0065f5f497dd3cd372fae0 commit ef502dd9562c894c1b0065f5f497dd3cd372fae0 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-30 15:03:27 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:26 +0000 lang/gcc14: Add comment to existing patch Add a comment to files/patch-libgcc_unwind.inc to remember when it will get obsolete, i.e. once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. PR: 285711 lang/gcc14/files/patch-libgcc_unwind.inc | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=6a4bfe6146890a6f28e794bf8c602ec8afd74fd0 commit 6a4bfe6146890a6f28e794bf8c602ec8afd74fd0 Author: Oleg Sidorkin <osidorkin@gmail.com> AuthorDate: 2025-04-23 08:13:01 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:25 +0000 lang/gcc13: Fix SIGBUS depending on CPUTYPE Compiling GCC with some CPUTYPE values (e.g. broadwell) result in breaking some applications (e.g. math/octave, cad/freecad), sending a SIGBUS. The issue is due to GCC generating instructions that require variables to be aligned in memory on certain CPUs. Our libthr does not have the required alignment so these CPUs fail to execute these instructions. The patch disables the generation of such instructions and will get obsolete once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. PR: 285711 Reported by: cracauer Tested by: cracauer, jbo lang/gcc13/Makefile | 2 +- lang/gcc13/files/patch-libgcc_unwind.inc (new) | 31 ++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e796abb5742f2713cdca6a3de8b8633176927990 commit e796abb5742f2713cdca6a3de8b8633176927990 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-29 08:13:43 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:24 +0000 lang/gcc14-devel: Update to 14.2.1.s20250425 Also add a comment to files/patch-libgcc_unwind.inc to remember when it will get obsolete, i.e. once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. PR: 285711 lang/gcc14-devel/Makefile | 2 +- lang/gcc14-devel/distinfo | 6 +++--- lang/gcc14-devel/files/patch-libgcc_unwind.inc | 3 +++ 3 files changed, 7 insertions(+), 4 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ba5dcc456206032aa5774ae52dd2159e9718c801 commit ba5dcc456206032aa5774ae52dd2159e9718c801 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-30 13:45:06 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:23 +0000 lang/gcc12-devel: Add comment to existing patch Add a comment to files/patch-libgcc_unwind.inc to remember when it will get obsolete, i.e. once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. PR: 285711 lang/gcc12-devel/files/patch-libgcc_unwind.inc | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=37fa81474afeb35a8df275f56c2d1363b95e74b3 commit 37fa81474afeb35a8df275f56c2d1363b95e74b3 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-29 08:12:50 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:24 +0000 lang/gcc13-devel: Update to 13.3.1.s20250424 Also add a comment to files/patch-libgcc_unwind.inc to remember when it will get obsolete, i.e. once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. PR: 285711 lang/gcc13-devel/Makefile | 2 +- lang/gcc13-devel/distinfo | 6 +++--- lang/gcc13-devel/files/patch-libgcc_unwind.inc | 3 +++ 3 files changed, 7 insertions(+), 4 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=35e0f453eb0367c1bab1d797f048556325752838 commit 35e0f453eb0367c1bab1d797f048556325752838 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-29 08:15:53 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:24 +0000 lang/gcc15-devel: Update to 15.1.1.s20250426 Also add a comment to files/patch-libgcc_unwind.inc to remember when it will get obsolete, i.e. once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. PR: 285711 lang/gcc15-devel/Makefile | 3 +-- lang/gcc15-devel/distinfo | 6 +++--- lang/gcc15-devel/files/patch-libgcc_unwind.inc | 3 +++ 3 files changed, 7 insertions(+), 5 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3e400b40c3c6dc7b0fc68476a433df383ea7bd55 commit 3e400b40c3c6dc7b0fc68476a433df383ea7bd55 Author: Lorenzo Salvadore <salvadore@FreeBSD.org> AuthorDate: 2025-04-29 13:31:51 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2025-05-03 09:46:27 +0000 lang/gcc16-devel: Add port GCC, the GNU Compiler Collection, supports a number of languages. This port installs the C, C++, and Fortran front ends as gcc16, g++16, and gfortran16, respectively. This is the first snapshot from trunk with the GCC 16 designation. It largely is a copy of lang/gcc15-devel. Note: files/patch-libgcc_unwind.inc will get obsolete once all supported FreeBSD releases include commit 22e564c74eb20e14bd93fd9fdde20e38a29cfcf1. [1] PR: 285711 [1] lang/Makefile | 1 + lang/gcc16-devel/Makefile (new) | 194 +++++++++++++++++++++ lang/gcc16-devel/distinfo (new) | 3 + .../files/patch-arm-unwind-cxx-support (new) | 106 +++++++++++ lang/gcc16-devel/files/patch-gcc_Makefile.in (new) | 19 ++ lang/gcc16-devel/files/patch-gcc_configure (new) | 22 +++ .../files/patch-gcc_jit_Make-lang.in (new) | 14 ++ lang/gcc16-devel/files/patch-gfortran-libgcc (new) | 69 ++++++++ lang/gcc16-devel/files/patch-libcxxrt (new) | 18 ++ ...ch-libgcc_enable-execute-stack-mprotect.c (new) | 15 ++ .../files/patch-libgcc_unwind.inc (new) | 31 ++++ .../patch-libsanitizer_asan_asan__linux.cpp (new) | 23 +++ .../patch-libsanitizer_asan_asan__thread.cpp (new) | 13 ++ lang/gcc16-devel/files/pkg-message.in (new) | 13 ++ lang/gcc16-devel/pkg-descr (new) | 3 + lang/gcc16-devel/pkg-help (new) | 3 + lang/gcc16-devel/pkg-plist (new) | 36 ++++ 17 files changed, 583 insertions(+)
Everything that needed to be done for new and existing ports has been done for now. We now wait for the patches to become obsolete and remove them.
(In reply to Lorenzo Salvadore from comment #62) While the src commit (846229d60b4f & 22e564c74eb2) isn't strictly bound to a __FreeBSD version bump, I guess it's close enough to 1500039 resp. 1403000 to consider something like this: for patch in $(find lang -path 'lang/gcc*/files/patch-libgcc_unwind.inc'); do command git mv "$patch" "${patch%/*}/extra-${patch##*/}"; done (in case 85192b37a3f1 & 5835d34761a0 get MFS'd to 14.3-RELEASE, '<= 1403000' becomes '< 1403000') diff --git a/lang/gcc12-devel/Makefile b/lang/gcc12-devel/Makefile index c7df2f37cb79..c903b736e287 100644 --- a/lang/gcc12-devel/Makefile +++ b/lang/gcc12-devel/Makefile @@ -76,6 +76,10 @@ GRAPHITE_CONFIGURE_WITH+= isl .include <bsd.port.pre.mk> +.if ${OPSYS} == FreeBSD && (${OSVERSION} <= 1403000 || (${OSVERSION} >= 1500000 && ${OSVERSION} < 1500039)) +EXTRA_PATCHES+= ${FILESDIR}/extra-patch-libgcc_unwind.inc +.endif + .if ${ARCH} == amd64 CONFIGURE_TARGET= x86_64-portbld-${OPSYS:tl}${OSREL} diff --git a/lang/gcc13-devel/Makefile b/lang/gcc13-devel/Makefile index 12715c5e60bc..0666eab5abdf 100644 --- a/lang/gcc13-devel/Makefile +++ b/lang/gcc13-devel/Makefile @@ -75,6 +75,10 @@ GRAPHITE_CONFIGURE_WITH+= isl .include <bsd.port.pre.mk> +.if ${OPSYS} == FreeBSD && (${OSVERSION} <= 1403000 || (${OSVERSION} >= 1500000 && ${OSVERSION} < 1500039)) +EXTRA_PATCHES+= ${FILESDIR}/extra-patch-libgcc_unwind.inc +.endif + .if ${ARCH} == amd64 CONFIGURE_TARGET= x86_64-portbld-${OPSYS:tl}${OSREL} diff --git a/lang/gcc13/Makefile b/lang/gcc13/Makefile index 87a94678dcd1..4bd50e508c96 100644 --- a/lang/gcc13/Makefile +++ b/lang/gcc13/Makefile @@ -70,6 +70,10 @@ GRAPHITE_CONFIGURE_WITH+= isl .include <bsd.port.pre.mk> +.if ${OPSYS} == FreeBSD && (${OSVERSION} <= 1403000 || (${OSVERSION} >= 1500000 && ${OSVERSION} < 1500039)) +EXTRA_PATCHES+= ${FILESDIR}/extra-patch-libgcc_unwind.inc +.endif + .if ${ARCH} == amd64 CONFIGURE_TARGET= x86_64-portbld-${OPSYS:tl}${OSREL} diff --git a/lang/gcc14-devel/Makefile b/lang/gcc14-devel/Makefile index 380cba0092b3..ec2ecd4921f7 100644 --- a/lang/gcc14-devel/Makefile +++ b/lang/gcc14-devel/Makefile @@ -77,6 +77,10 @@ GRAPHITE_CONFIGURE_WITH+= isl .include <bsd.port.pre.mk> +.if ${OPSYS} == FreeBSD && (${OSVERSION} <= 1403000 || (${OSVERSION} >= 1500000 && ${OSVERSION} < 1500039)) +EXTRA_PATCHES+= ${FILESDIR}/extra-patch-libgcc_unwind.inc +.endif + .if ${ARCH} == amd64 CONFIGURE_TARGET= x86_64-portbld-${OPSYS:tl}${OSREL} diff --git a/lang/gcc14/Makefile b/lang/gcc14/Makefile index 29e119905af3..1fff8ff81b93 100644 --- a/lang/gcc14/Makefile +++ b/lang/gcc14/Makefile @@ -73,6 +73,10 @@ GRAPHITE_CONFIGURE_WITH+= isl .include <bsd.port.pre.mk> +.if ${OPSYS} == FreeBSD && (${OSVERSION} <= 1403000 || (${OSVERSION} >= 1500000 && ${OSVERSION} < 1500039)) +EXTRA_PATCHES+= ${FILESDIR}/extra-patch-libgcc_unwind.inc +.endif + .if ${ARCH} == amd64 CONFIGURE_TARGET= x86_64-portbld-${OPSYS:tl}${OSREL} diff --git a/lang/gcc15-devel/Makefile b/lang/gcc15-devel/Makefile index 4eed868d47df..2ad1f4d97556 100644 --- a/lang/gcc15-devel/Makefile +++ b/lang/gcc15-devel/Makefile @@ -76,6 +76,10 @@ GRAPHITE_CONFIGURE_WITH+= isl .include <bsd.port.pre.mk> +.if ${OPSYS} == FreeBSD && (${OSVERSION} <= 1403000 || (${OSVERSION} >= 1500000 && ${OSVERSION} < 1500039)) +EXTRA_PATCHES+= ${FILESDIR}/extra-patch-libgcc_unwind.inc +.endif + .if ${ARCH} == amd64 CONFIGURE_TARGET= x86_64-portbld-${OPSYS:tl}${OSREL} diff --git a/lang/gcc15/Makefile b/lang/gcc15/Makefile index c9444e5e22e8..d01c53246b2b 100644 --- a/lang/gcc15/Makefile +++ b/lang/gcc15/Makefile @@ -72,6 +72,10 @@ GRAPHITE_CONFIGURE_WITH+= isl .include <bsd.port.pre.mk> +.if ${OPSYS} == FreeBSD && (${OSVERSION} <= 1403000 || (${OSVERSION} >= 1500000 && ${OSVERSION} < 1500039)) +EXTRA_PATCHES+= ${FILESDIR}/extra-patch-libgcc_unwind.inc +.endif + .if ${ARCH} == amd64 CONFIGURE_TARGET= x86_64-portbld-${OPSYS:tl}${OSREL} diff --git a/lang/gcc16-devel/Makefile b/lang/gcc16-devel/Makefile index a16af13a1f09..f76ff8d69ace 100644 --- a/lang/gcc16-devel/Makefile +++ b/lang/gcc16-devel/Makefile @@ -76,6 +76,10 @@ GRAPHITE_CONFIGURE_WITH+= isl .include <bsd.port.pre.mk> +.if ${OPSYS} == FreeBSD && (${OSVERSION} <= 1403000 || (${OSVERSION} >= 1500000 && ${OSVERSION} < 1500039)) +EXTRA_PATCHES+= ${FILESDIR}/extra-patch-libgcc_unwind.inc +.endif + .if ${ARCH} == amd64 CONFIGURE_TARGET= x86_64-portbld-${OPSYS:tl}${OSREL}
(In reply to Harald Schmalzbauer from comment #63) We do not 'support' any HEAD except latest. In other words, if compiling on HEAD (current-15) port can assume that the srtuct pthread alignment is already correct.
(In reply to Harald Schmalzbauer from comment #63) > While the src commit (846229d60b4f & 22e564c74eb2) isn't strictly bound > to a __FreeBSD version bump, I guess it's close enough to 1500039 resp. > 1403000 to consider something like this: I don't recommend this which complicates things without a sufficiently strong benefit in my mind. Technically the patch is a bug fix for GCC since it cannot assume alignment, and I don't expect performance to be wildly different?
(In reply to Gerald Pfeifer from comment #65) > I don't recommend this which complicates things without a sufficiently > strong benefit in my mind. > > Technically the patch is a bug fix for GCC since it cannot assume > alignment, and I don't expect performance to be wildly different? Lacking knowledge here, I can't estimate performance impact or other side effects and didn't do comparison, hence I'd ruled out the possibility of such, just because of not better knowing. I'm fine with discarding my no-benefit suggestion, while I don't really see it's complicating anything, but avoiding a pointless extra commit.
I am closing this bug as fully resolved. The root cause (libthr struct _Unwind_Exception alignment) was fixed in FreeBSD src by kib@ (commit 22e564c74eb2) and MFC'd to stable/14. salvadore@ additionally applied workaround patches to all GCC ports (gcc12-16). Both the src fix and ports workarounds are committed.