[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 Dimitry Andric changed: What|Removed |Added Resolution|--- |Not A Bug Status|New

[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 Lorenzo Salvadore changed: What|Removed |Added CC||salvad...@freebsd.org ---

[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 --- Comment #1 from Dimitry Andric --- I can't reproduce this on freshly installed 14.1-RELEASE. The program compiles just fine. How have you installed your system? -- You are receiving this mail because: You are the assignee for the

[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 Yuri Victorovich changed: What|Removed |Added Assignee|b...@freebsd.org|toolchain@FreeBSD.org

Problem reports for toolchain@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 276170] LLVM bug prevents from enabling PGO optimization for Python 3.11+

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276170 --- Comment #22 from dmilith --- Well, the issue is still the case for 14.1-RELEASE. It crashes similarly for any software that uses PGO during the build on an aarch64/arm64 machine. -- You are receiving this mail because: You are the

Problem reports for toolchain@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #13 from Paul Floyd --- (In reply to Mark Millard from comment #9) (In reply to Mark Millard from comment #9) The original comment said > It should be possible to get an address of the end of the std::vector object, > even

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #12 from Yuri Victorovich --- (In reply to Yuri Victorovich from comment #11) And the port will be fixed soon. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #11 from Yuri Victorovich --- (In reply to Paul Floyd from comment #10) Asserts are already supposed to be turned off. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #10 from Paul Floyd --- (In reply to Yuri Victorovich from comment #8) I say that you should fix the UB and then optionally turn off asserts. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #9 from Mark Millard --- (In reply to Paul Floyd from comment #7) Yuri had specified that the code was analogous to upstream for devel/hpx, if I understood right. I kept to a fairly minimal style change compared to [cb] and

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #8 from Yuri Victorovich --- (In reply to Paul Floyd from comment #7) That's not the point. The point is that enabling asserts in the optimized production code reduces its performance, regardless whether the code is correct

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #7

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #6 from Mark Millard --- (In reply to Mark Millard from comment #5) Testing -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE for the code having: std::copy( [0], [cb], // !!!

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #5 from Mark Millard --- (In reply to Yuri Victorovich from comment #4) FYI: for NDEBUG vs. _LIBCPP_HARDENING_MODE # grep -r "NDEBUG" /usr/include/c++/v1/ | more /usr/include/c++/v1/module.modulemap: // 's use of NDEBUG

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #4 from Yuri Victorovich --- (In reply to Mark Millard from comment #3) [v.size()] should take the vector's base address, add the size to it, and return the result. This is technically an incorrect code, it would cause an

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #3 from Mark Millard --- cppreference.com reports the following for C only: 3) special case: & and * cancel each other, neither one is evaluated 4) special case: & and the * that is implied in [] cancel each other, only the

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 --- Comment #2 from Yuri Victorovich --- "[0] + cb" is certainly correct, but the problem is that the "gray area" case "[cb]" should also work in the optimized code. -- You are receiving this mail because: You are the assignee for the

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com ---

[Bug 279443] LIBCPP assertions are enabled in optimized builds when -DNDEBUG is given to clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279443 Yuri Victorovich changed: What|Removed |Added Assignee|b...@freebsd.org|toolchain@FreeBSD.org

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 --- Comment #8 from Dimitry Andric --- The fixes have been MFC'd now, but we're waiting on re@ to approve merging them to releng/14.1, to make sure it ends up in 14.1-RELEASE. Keeping this bug open until that is done. -- You are

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 --- Comment #7 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c56fde6514ee21ccb186267c304ad63f661c commit c56fde6514ee21ccb186267c304ad63f661c Author:

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 --- Comment #6 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a3e6eda7981319113d39caedf79b94b44773970f commit a3e6eda7981319113d39caedf79b94b44773970f

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ec38746722a15b4376bed274e96ff7b8c31804e1 commit ec38746722a15b4376bed274e96ff7b8c31804e1

Problem reports for toolchain@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 Dimitry Andric changed: What|Removed |Added Resolution|Overcome By Events |--- Status|Closed

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=cadd2ca21765ebcb95b77ec94977b4e74e1edc1b commit cadd2ca21765ebcb95b77ec94977b4e74e1edc1b Author:

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 --- Comment #8 from Yuri Victorovich --- (In reply to Matthias Andree from comment #7) Hi Matthias, I just made it build again, since I added BROKEN lines earlier. If you would like to commit further patches - you are welcome to do so.

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 --- Comment #7 from Matthias Andree --- Dimitry, Thank you. 14.0 will be around until end of September 2024 according to current schedules, see the table on https://www.freebsd.org/releng/ in context with

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 --- Comment #6 from commit-h...@freebsd.org --- A commit in branch 2024Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e5cd3589b262f0a530e2b201d923a69b9666adf9 commit e5cd3589b262f0a530e2b201d923a69b9666adf9 Author:

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d863e42c9258ad8673bfbaef2af27781cff3b42c commit d863e42c9258ad8673bfbaef2af27781cff3b42c Author:

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 --- Comment #4 from Yuri Victorovich --- It builds with llvm-17 from ports. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Dimitry Andric changed: What|Removed |Added Status|New |Open --- Comment #3 from Dimitry

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 --- Comment #2 from Matthias Andree --- Yuri: 138 resolves to 128 (core dump) + 10 = SIGBUS. Assertion errors usually end up in std::terminate() or abort(), hence SIGABRT, resulting in status codes 6 or 134. -- You are receiving this

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Matthias Andree changed: What|Removed |Added Severity|Affects Only Me |Affects Some People -- You are

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Matthias Andree changed: What|Removed |Added CC||mand...@freebsd.org --- Comment

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Matthias Andree changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu

Problem reports for toolchain@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3 on amd64, arm64

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Yuri Victorovich changed: What|Removed |Added Summary|clang-16 frontend command |clang-16 frontend command

[Bug 279136] clang-16 frontend command fails with exit code 138 w/out any assertion message on the port security/botan3

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Yuri Victorovich changed: What|Removed |Added CC||d...@freebsd.org

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 ni...@protonmail.com changed: What|Removed |Added Status|New |Closed

[Bug 278867] Linker is missing library: libclang_rt.asan_static-x86_64.a (and all others)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278867 --- Comment #7 from f...@fehcom.de --- Shall say: base.xyz from FreeBSD 13.3 (!) --eh. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 278867] Linker is missing library: libclang_rt.asan_static-x86_64.a (and all others)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278867 f...@fehcom.de changed: What|Removed |Added Status|New |Closed Resolution|---

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 Dimitry Andric changed: What|Removed |Added CC||d...@freebsd.org --- Comment #1

[Bug 278908] Upcoming 14.1-RELEASE LLVM -> Worse runtime performance on Zen CPU when optimizing for Zen

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278908 Tijl Coosemans changed: What|Removed |Added Assignee|b...@freebsd.org|toolchain@FreeBSD.org -- You

Problem reports for toolchain@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 278867] Linker is missing library: libclang_rt.asan_static-x86_64.a (and all others)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278867 --- Comment #5 from f...@fehcom.de --- Hi Dimitry, great idae; but I certainly don't take that option. I already spent too much time in trying to dig things out. I rather do a complete new install and see what is happening. All my

[Bug 278867] Linker is missing library: libclang_rt.asan_static-x86_64.a (and all others)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278867 Dimitry Andric changed: What|Removed |Added CC||d...@freebsd.org --- Comment #4

[Bug 278867] Linker is missing library: libclang_rt.asan_static-x86_64.a (and all others)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278867 --- Comment #3 from f...@fehcom.de --- Yes, I did several times. If I run freebsd-update IDS I get millions of errors: /usr/src/usr.bin/top/Makefile.depend has SHA256 hash 18f3d6215c6aef2e3c9a89eb6e27141051797070aad33d16a43d999173c823c6,

[Bug 278867] Linker is missing library: libclang_rt.asan_static-x86_64.a (and all others)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278867 SHENG-YI HUNG changed: What|Removed |Added CC||i19780219...@gmail.com ---

[Bug 278867] Linker is missing library: libclang_rt.asan_static-x86_64.a (and all others)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278867 SHENG-YI HUNG changed: What|Removed |Added CC||i19780219...@gmail.com ---

[Bug 278867] Linker is missing library: libclang_rt.asan_static-x86_64.a (and all others)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278867 Mark Linimon changed: What|Removed |Added Keywords||regression

[Bug 262706] Build on arm64 fails to find libclang_rt.asan-aarch64.a

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262706 --- Comment #20 from Dimitry Andric --- (In reply to feh from comment #19) It looks rather different: this bug was originally about aarch64 not supporting some (or all) of the sanitizers. Later, it became about some refactoring in the

[Bug 262706] Build on arm64 fails to find libclang_rt.asan-aarch64.a

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262706 --- Comment #19 from f...@fehcom.de --- Sorry: Should say: the same *kind* of error. --eh. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 262706] Build on arm64 fails to find libclang_rt.asan-aarch64.a

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262706 f...@fehcom.de changed: What|Removed |Added CC||f...@fehcom.de --- Comment #18

[Bug 278810] clang crashes: fatal error: error in backend: Cannot select: 0x27fbea00: v4f32 = fmaxnum 0x27178550, 0x26481eb0 (on the port misc/llama-cpp version 2619)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278810 --- Comment #4 from Dimitry Andric --- Specifically, this crash was fixed with https://github.com/llvm/llvm-project/commit/347b3f12090, for https://github.com/llvm/llvm-project/issues/65820 which is a similar test case, obtained from ggml.

[Bug 278810] clang crashes: fatal error: error in backend: Cannot select: 0x27fbea00: v4f32 = fmaxnum 0x27178550, 0x26481eb0 (on the port misc/llama-cpp version 2619)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278810 --- Comment #3 from John F. Carr --- Created attachment 250490 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250490=edit Test case dumped by llvm -- You are receiving this mail because: You are the assignee for the bug.

[Bug 278810] clang crashes: fatal error: error in backend: Cannot select: 0x27fbea00: v4f32 = fmaxnum 0x27178550, 0x26481eb0 (on the port misc/llama-cpp version 2619)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278810 John F. Carr changed: What|Removed |Added CC||j...@mit.edu --- Comment #2 from

[Bug 278810] clang crashes: fatal error: error in backend: Cannot select: 0x27fbea00: v4f32 = fmaxnum 0x27178550, 0x26481eb0 (on the port misc/llama-cpp version 2619)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278810 --- Comment #1 from Dimitry Andric --- Somebody with access to those jails needs to lift out the /tmp/ggml-555a7f.c and /tmp/ggml-555a7f.sh files. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 278810] clang crashes: fatal error: error in backend: Cannot select: 0x27fbea00: v4f32 = fmaxnum 0x27178550, 0x26481eb0 (on the port misc/llama-cpp version 2619)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278810 Yuri Victorovich changed: What|Removed |Added URL||https://pkg-status.freebsd.

[Bug 267751] lang/gcc*: Address sanitizer isn't properly enabled: ASan runtime does not come first in initial library list

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267751 --- Comment #31 from Gerald Pfeifer --- (In reply to Andreas Tobler from comment #25) > This is a possible fix for the bus error happening on gcc-13 and > up when running asan tests. (Or other binaries compiled with > -fsanitize=address).

Problem reports for toolchain@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 278711] math/sprng: BROKEN with recent clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278711 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d05586213892764617a96edec7151b464b1906ff commit d05586213892764617a96edec7151b464b1906ff Author:

[Bug 278711] math/sprng: BROKEN with recent clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278711 Thierry Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|New

[Bug 278711] math/sprng: BROKEN with recent clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278711 Dimitry Andric changed: What|Removed |Added CC||d...@freebsd.org --- Comment #1

[Bug 278711] math/sprng: BROKEN with recent clang

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278711 Thierry Thomas changed: What|Removed |Added Assignee|b...@freebsd.org|toolchain@FreeBSD.org -- You

[Bug 278649] lang/gcc13: build failed on 15.0-CURRENT armv7

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278649 John F. Carr changed: What|Removed |Added CC||j...@mit.edu --- Comment #2 from

[Bug 278630] math/kamis, misc/openn: GCC fails with an error on armv7: use of built-in trait '__remove_cvref(_InIter1)' in function signature; use library traits instead

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278630 --- Comment #5 from Dimitry Andric --- Can somebody verify on a armv7 system that older gcc ports build with the upstream patch for libc++? Because that is essential if I import that patch. -- You are receiving this mail because: You are

[Bug 278649] lang/gcc13: build failed on 15.0-CURRENT armv7

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278649 Lorenzo Salvadore changed: What|Removed |Added Hardware|Any |arm

Problem reports for toolchain@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #25 from Ed Maste --- (In reply to Mohammed Goder from comment #20) > So should this be reported upstream? I reported this upstream as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114839. You don't need to do anything further.

[Bug 278630] math/kamis, misc/openn: GCC fails with an error on armv7: use of built-in trait '__remove_cvref(_InIter1)' in function signature; use library traits instead

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278630 Yuri Victorovich changed: What|Removed |Added Severity|Affects Only Me |Affects Some People -- You

[Bug 278630] math/kamis, misc/openn: GCC fails with an error on armv7: use of built-in trait '__remove_cvref(_InIter1)' in function signature; use library traits instead

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278630 Yuri Victorovich changed: What|Removed |Added Assignee|y...@freebsd.org|toolchain@FreeBSD.org

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Lorenzo Salvadore changed: What|Removed |Added CC||stffn.mo...@freenet.de ---

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #23 from Mark Millard --- (In reply to Mark Millard from comment #21) Another combination that works uses libc++ instead (pthread example again): g++13 -static -pthread -stdlib=libc++

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #22 from Mark Millard --- (In reply to Mark Millard from comment #21) Probably not obvious for my prior note: The final -Wl,--eh-frame-hdr case does, in fact, also print the line: FreeBSD doesn't reach here. -- You are

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #21 from Mark Millard --- (In reply to Mohammed Goder from comment #20) Niether With proper command line options the trivial test case variant below works just fine on FreeBSD. // File: lang-gcc-g++-exception-handling.cpp

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #20 from Mohammed Goder --- So should this be reported upstream? If so, am I supposed to do that or will you guys be handling the rest of this? -- You are receiving this mail because: You are the assignee for the bug.

[Bug 278333] clang-18 crashes on the port audio/noise-suppression-for-voice-lv2: Assertion failed: (result && "no existing substitution for template name"), function mangleExistingSubstitution, file [

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278333 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c76a1cb07bec61ebda8c608af38fe449bfa188ee commit c76a1cb07bec61ebda8c608af38fe449bfa188ee Author:

[Bug 278333] clang-18 crashes on the port audio/noise-suppression-for-voice-lv2: Assertion failed: (result && "no existing substitution for template name"), function mangleExistingSubstitution, file [

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278333 --- Comment #3 from Dimitry Andric --- Created attachment 250214 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250214=edit audio/noise-suppression-for-voice-lv2: fix build with clang 18 -- You are receiving this mail because:

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #19 from Mark Millard --- (In reply to Mark Millard from comment #18) Whaat says that the two /wrkdirs/usr/ports/lang/gcc13/work/gcc-13.2.0/libgcc/* source files referenced are compatible with the otherwise-FreeBSD-specific

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #18 from Mark Millard --- FYI: I got more source code path information from a gdb based run. The context used g++13 but the system has symbols as well. I keep a main-src worktree that holds a copy of the main branch materials.

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #17 from Mohammed Goder --- (In reply to Ed Maste from comment #16) I did some further testing and I'm pretty sure that it's a clang issue. I remember using the flag on Windows, MacOS, and Linux but it seems as though either

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #16 from Ed Maste --- (In reply to Mohammed Goder from comment #14) > Should I make another bug report on FreeBSD's bug tracker or should this go > to the clang > devs? If you can get a minimized reproducer and exact

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #15 from Mohammed Goder --- (In reply to Mohammed Goder from comment #14) Actually slight correction. Clang's safe-stack does not work on OpenBSD. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #14 from Mohammed Goder --- Thank you guys for your hard work and dedication. I found the issue with clang++. The "-fsanitize=safe-stack" flag causes a segfault on FreeBSD. GCC's equivalent "-mshstk" works fine and Clang's

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #13 from Ed Maste --- I'm using the gcc13 package, and adding -v to my g++13 command line shows the link invocation as: /usr/local/libexec/gcc13/gcc/x86_64-portbld-freebsd14.0/13.2.0/collect2 -plugin

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #12 from Konstantin Belousov --- (In reply to Ed Maste from comment #11) Perhaps you do use libc++ from base indeed. I tried with the manual gcc build from sources, and got the destructor faulting. -- You are receiving this

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #11 from Ed Maste --- I did not reproduce a problem with g++13, with -Wl,--eh-frame-hdr: $ g++13 -Wl,--eh-frame-hdr -std=c++20 -static-libgcc -static-libstdc++ -static -pthread -O3 "main.cpp" -o "main_g++" && ./main_g++ kernel

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #10 from Mark Millard --- (In reply to Mohammed Goder from comment #0) If gcc is to be involved, a question may be if -Wl,-rpath=/usr/local/lib/gcc* for the appropriate * substitution is needed. -- You are receiving this

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Ed Maste changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #9 from Ed Maste --- from g++13 -dumpspecs it looks like --eh-frame-header is not included for statically linked binaries *link: %{!static|static-pie:--eh-frame-hdr} %{m32:-m elf_i386_fbsd}%{!m32:-m elf_x86_64_fbsd}

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #8 from Konstantin Belousov --- (In reply to Ed Maste from comment #6) -Wl,--eh-frame-hdr indeed help with the unwinder in thread_exit. There is one more bug meantime, (gdb) r Starting program:

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com ---

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #6 from Ed Maste --- If I link using Clang as the compiler driver (using either the ld.lld default, or ld.bfd) it works. The linker command line in the bfd case is: "/usr/local/bin/ld.bfd" --eh-frame-hdr -dynamic-linker

[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Ed Maste changed: What|Removed |Added Product|Base System |Ports & Packages

[Bug 278551] pthread_join() kills the process with a return code of 134

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #5 from Ed Maste --- I can reproduce this with GCC 10, 11, 12, and 13. I cannot reproduce this with Clang 16 or 17. $ clang++16 -std=c++20 -static-libgcc -static-libstdc++ -static -pthread -O3 "main.cpp" -o "main_clang++" &&

[Bug 278551] pthread_join() kills the process with a return code of 134

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Konstantin Belousov changed: What|Removed |Added CC||salvad...@freebsd.org

Problem reports for toolchain@FreeBSD.org that need special attention

To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and

  1   2   3   4   5   6   7   8   9   10   >