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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[Bug 278649] lang/gcc13: build failed on 15.0-CURRENT armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278649 --- Comment #7 from Mark Millard --- Sorry, dumb c++ mistake: I forgot to also add -static-libstdc++ # g++13 -static-libgcc -static-libstdc++ main.c /usr/local/bin/ld: warning: libunwind.o: missing .note.GNU-stack section implies executable stack /usr/local/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 278649] lang/gcc13: build failed on 15.0-CURRENT armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278649 --- Comment #6 from Mark Millard --- Same source handled as c++ code: # g++13 -static-libgcc main.c /usr/local/bin/ld: warning: libunwind.o: missing .note.GNU-stack section implies executable stack /usr/local/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/local/bin/ld: /usr/local/lib/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/../../../libstdc++.so: undefined reference to `__aeabi_ldivmod@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/../../../libstdc++.so: undefined reference to `__aeabi_d2lz@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/../../../libstdc++.so: undefined reference to `__aeabi_uldivmod@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/../../../libstdc++.so: undefined reference to `__aeabi_l2d@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/../../../libstdc++.so: undefined reference to `__aeabi_idivmod@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/../../../libstdc++.so: undefined reference to `__aeabi_ul2f@GCC_3.5' /usr/local/bin/ld: /usr/local/lib/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/../../../libstdc++.so: undefined reference to `__aeabi_ul2d@GCC_3.5' collect2: error: ld returned 1 exit status -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 278649] lang/gcc13: build failed on 15.0-CURRENT armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278649
Mark Millard changed:
What|Removed |Added
CC||marklmi26-f...@yahoo.com
--- Comment #5 from Mark Millard ---
A trivial armv7 example based on pkgbase:
# ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' |
sort -r | uniq | head -1
FreeBSD-.snap20240626211138
# uname -apKU
FreeBSD OPiP2E-RPi2v1p1 15.0-CURRENT FreeBSD 15.0-CURRENT
main-n270963-609cdb12b962 GENERIC arm armv7 1500019 1500019
and packages from pkg update.
# more main.c
int main() {}
# gcc13 -static-libgcc main.c
/usr/local/bin/ld: warning: libunwind.o: missing .note.GNU-stack section
implies executable stack
/usr/local/bin/ld: NOTE: This behaviour is deprecated and will be removed in a
future version of the linker
/usr/local/bin/ld: a.out: hidden symbol `__aeabi_unwind_cpp_pr0' in
/usr/local/lib/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/libgcc_eh.a(unwind-arm.o)
is referenced by DSO
/usr/local/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
# gcc13 -v
Using built-in specs.
COLLECT_GCC=gcc13
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc13/gcc/armv7-portbld-freebsd15.0/13.2.0/lto-wrapper
Target: armv7-portbld-freebsd15.0
Configured with: /wrkdirs/usr/ports/lang/gcc13/work/gcc-13.2.0/configure
--disable-multilib --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --enable-host-shared --enable-plugin
--libdir=/usr/local/lib/gcc13 --libexecdir=/usr/local/libexec/gcc13
--program-suffix=13 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc13/include/c++/
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --without-zstd
--enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/share/man
--infodir=/usr/local/share/info/gcc13 --build=armv7-portbld-freebsd15.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (FreeBSD Ports Collection)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 278649] lang/gcc13: build failed on 15.0-CURRENT armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278649 Mark Linimon changed: What|Removed |Added CC||bro...@freebsd.org --- Comment #4 from Mark Linimon --- ^Triage: notify committer of https://cgit.freebsd.org/src/commit/?id=99ea67573164637d633e8051eb0a5d52f1f9488e . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 278649] lang/gcc13: build failed on 15.0-CURRENT armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278649 --- Comment #3 from qrox...@protonmail.com --- After running git bisect, it appears that gcc -static-libgcc conftest.c fails to link when libc is linking to libsys https://cgit.freebsd.org/src/commit/?id=99ea67573164637d633e8051eb0a5d52f1f9488e -- You are receiving this mail because: You are on the CC list for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[Bug 279800] Static assert in /usr/include/c++/v1/__algorithm/iterator_operations.h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279800 Dimitry Andric changed: What|Removed |Added Status|New |Closed Summary|Static assert in|Static assert in |/usr/include/c++/v1/__algor |/usr/include/c++/v1/__algor |ithm/iterator_operations.h |ithm/iterator_operations.h |(problem was encountered in | |the devel/benchmark | |testsuite) | Resolution|--- |DUPLICATE --- Comment #1 from Dimitry Andric --- This is due to a problem in our cdefs.h. This was already reported in bug 276738. *** This bug has been marked as a duplicate of bug 276738 *** -- You are receiving this mail because: You are the assignee for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[Bug 279800] Static assert in /usr/include/c++/v1/__algorithm/iterator_operations.h (problem was encountered in the devel/benchmark testsuite)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279800 Yuri Victorovich changed: What|Removed |Added Summary|Static assert in|Static assert in |/usr/include/c++/v1/__algor |/usr/include/c++/v1/__algor |ithm/iterator_operations.h |ithm/iterator_operations.h ||(problem was encountered in ||the devel/benchmark ||testsuite) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279800] Static assert in /usr/include/c++/v1/__algorithm/iterator_operations.h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279800 Yuri Victorovich changed: What|Removed |Added CC||d...@freebsd.org Assignee|b...@freebsd.org|toolchain@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug.
[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 Mark Linimon changed: What|Removed |Added Version|Unspecified |15.0-CURRENT -- You are receiving this mail because: You are the assignee for the bug.
[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 |Closed --- Comment #3 from Dimitry Andric --- (In reply to Lorenzo Salvadore from comment #2) Ah yes, this is because the old copy of /usr/include/c++/v1/setjmp.h must be deleted upon an upgrade. A fresh install will never have this issue. -- You are receiving this mail because: You are the assignee for the bug.
[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 --- Comment #2 from Lorenzo Salvadore --- I had a similar issue recently on CURRENT. In my case the cause was that I had built base from sources forgetting to run "make delete-old". After running it everything was fixed. -- You are receiving this mail because: You are the assignee for the bug.
[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.
[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 Blocks|279505 | CC||d...@freebsd.org Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279505 [Bug 279505] graphics/libheif fails to build with message about csetjmp error -- You are receiving this mail because: You are the assignee for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[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 assignee for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[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 though it doesn't point to an allocated byte. This is precisely the purpose of std::end() (or std::vector::end(), std::end() has the advantage that it will also work with raw arrays). > I kept to a fairly minimal > style change compared to [cb] and what it means in C and > some parts of C++ for my test example, using notation showing > specific distinctions that other C++ notations could hide and > so be less clear. As I see it you were using idiomatic C to show how to do the wrong thing rather than using idiomatic C++ to do the right thing. It looks like Yuri is getting things sorted out. -- 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 #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 what it means in C and some parts of C++ for my test example, using notation showing specific distinctions that other C++ notations could hide and so be less clear. I was making no claim that such was the best way to rewrite the related devel/hpx source: a limited purpose example. -- 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 #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 or incorrect. -- 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 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #7 from Paul Floyd --- (In reply to Mark Millard from comment #1) Why not write it in clean C++ style rather than taking pointers in crappy UB C style? std::copy( std::begin(buf), std::end(buf), std::back_inserter(r) ); That way you don’t need to cross your fingers and hope that the compiler does what you imagined it should do. -- 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 #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], // !!! ASSERTs HERE !!! //[0] + cb, std::back_inserter(r) ); # c++ -g -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE get_executable_filename.cpp # gdb a.out . . Reading symbols from a.out... (gdb) run Starting program: /usr/home/root/c_tests/a.out /usr/home/root/c_tests/a.out [Inferior 1 (process 66950) exited normally] In a more general context you might need both -DNDEBUG for the non-libc++ code and also the -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE for the libc++ code that is involved for one compile command. -- 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 #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 requires
textual inclusion.
Nothing in the standards say that the C++ standard library has to ever use
assert
from . NDEBUG is only defined relative to and its assert
use,
not for any other context. _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS does not trace
back
to a use of assert in the libc++ code.
# grep -r "cassert" /usr/include/c++/v1/ | more
/usr/include/c++/v1/cassert:cassert synopsis
/usr/include/c++/v1/__std_clang_module:#include
/usr/include/c++/v1/module.modulemap:module std_cassert [system] {
/usr/include/c++/v1/module.modulemap: // 's use of NDEBUG requires
textual inclusion.
/usr/include/c++/v1/module.modulemap: textual header "cassert"
libc++ does not use or its assert(. . .), which is completely
standard compliant.
There is a separate libc++ specific mechanism that does not involve assert or
NDEBUG : alternate values for _LIBCPP_HARDENING_MODE
/usr/include/c++/v1/__config indicates:
// The library provides the macro `_LIBCPP_HARDENING_MODE` which can be set to
one of the following values:
//
// - `_LIBCPP_HARDENING_MODE_NONE`;
// - `_LIBCPP_HARDENING_MODE_FAST`;
// - `_LIBCPP_HARDENING_MODE_EXTENSIVE`;
// - `_LIBCPP_HARDENING_MODE_DEBUG`.
//
// These values have the following effects:
//
// - `_LIBCPP_HARDENING_MODE_NONE` -- sets the hardening mode to "none" which
disables all runtime hardening checks;
//
// - `_LIBCPP_HARDENING_MODE_FAST` -- sets that hardening mode to "fast". The
fast mode enables security-critical checks
// that can be done with relatively little runtime overhead in constant time;
//
// - `_LIBCPP_HARDENING_MODE_EXTENSIVE` -- sets the hardening mode to
"extensive". The extensive mode is a superset of
// the fast mode that additionally enables checks that are relatively cheap
and prevent common types of logic errors
// but are not necessarily security-critical;
//
// - `_LIBCPP_HARDENING_MODE_DEBUG` -- sets the hardening mode to "debug". The
debug mode is a superset of the extensive
// mode and enables all checks available in the library, including internal
assertions. Checks that are part of the
// debug mode can be very expensive and thus the debug mode is intended to be
used for testing, not in production.
--
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 #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 assert, it it should produce the correct expected pointer. Standards aside, in the absence of asserts there should be nothing in the compiled program that is in the way of returning the correct pointer in this specific situation. -- 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 #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 addition implied in [] is evaluated. For C++ it reports: Note that, unlike C99 and later C versions, there's no special case for the unary operator& applied to the result of the unary operator*. But I've not tried to see what any fairly modern C++ standard says about such and cppreference.com is not explicit about the & and [] combination in contexts that could possibly use &*(a+i) as a valid translation. If cppreference.com is correct, modern C++ may well require avoiding the [i] notation for the non-dereferenceable case: only use such for dereferenceable accesses, even for for likes of std::contiguous_iterator contexts. Again, I'm not sure because I've not analyzed any relevant version of the standard for the issue. -- 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 #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.
[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 --- Comment #1 from Mark Millard --- I tried the code that is based on: std::copy( [0], [cb], // !!! ASSERTs HERE !!! std::back_inserter(r) ); via: # c++ -g get_executable_filename.cpp # gdb a.out . . Reading symbols from a.out... (gdb) run Starting program: /usr/home/root/c_tests/a.out Program received signal SIGILL, Illegal instruction. Privileged opcode. 0x00203faa in std::__1::vector >::operator[][abi:se180100](unsigned long) (this=0x7fffe940, __n=29) at /usr/include/c++/v1/vector:1393 1393 _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(__n < size(), "vector[] index out of bounds"); Then I tried that sequence based on: std::copy( [0], //[cb], // !!! ASSERTs HERE !!! [0] + cb, std::back_inserter(r) ); # c++ -g get_executable_filename.cpp # gdb a.out . . Reading symbols from a.out... (gdb) run Starting program: /usr/home/root/c_tests/a.out /usr/home/root/c_tests/a.out [Inferior 1 (process 66199) exited normally] I'm not so sure that C++ defines [cb] as equivalent to [0] + cb for std::contiguous_iterator contexts relative to all issues. cppreference.com reports for std::contiguous_iterator : QUOTE Semantic requirements Let a and b be dereferenceable iterators and c be a non-dereferenceable iterator of type I such that b is reachable from a and c is reachable from b. The type I models contiguous_iterator only if all the concepts it subsumes are modeled and: std::to_address(a) == std::addressof(*a), std::to_address(b) == std::to_address(a) + std::iter_difference_t(b - a), and std::to_address(c) == std::to_address(a) + std::iter_difference_t(c - a). END QUOTE [0] + cb notation does avoid any suggestion of dereferencing buf[cb] at any stage. -- 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 Yuri Victorovich changed: What|Removed |Added Assignee|b...@freebsd.org|toolchain@FreeBSD.org CC||d...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[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 receiving this mail because: You are the assignee for the bug.
[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: Brooks Davis AuthorDate: 2024-05-28 11:47:37 + Commit: Brooks Davis CommitDate: 2024-05-28 11:56:43 + devel/llvm18: misc improvements Fix worse runtime performance on Zen CPU when optimizing for Zen. [0] Install all standard heaaders with clang. Historically we've been unable to build FreeBSD with the full set due to conflicts and/or missing features between the compiler provided headers and FreeBSD's headers. I've verified that I can build world and kernel on the main, stable/14, and stable/13 branches for amd64 so let's give it another try in broader testing. [1] PR: 278908 [0], 274542 [1] devel/llvm18/Makefile | 2 +- .../patch-clang_lib_Headers_CMakeLists.txt (gone) | 37 -- .../llvm18/files/patch-freebsd-cadd2ca21765 (new) | 83 ++ devel/llvm18/pkg-plist | 25 +++ 4 files changed, 109 insertions(+), 38 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[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 Author: Dimitry Andric AuthorDate: 2024-05-25 17:52:15 + Commit: Dimitry Andric CommitDate: 2024-05-28 05:26:46 + Merge commit d0be944aa511 from llvm-project (by Simon Pilgrim): [X86] Add slow div64 tuning flag to Nehalem target (#91129) This appears to have been missed because later cpus don't inherit from Nehalem tuning much. Noticed while cleaning up for #90985 Merge commit 8b400de79eff from llvm-project (by Simon Pilgrim): [X86] Enable TuningSlowDivide64 on Barcelona/Bobcat/Bulldozer/Ryzen Families (#91277) Despite most AMD cpus having a lower latency for i64 divisions that converge early, we are still better off testing for values representable as i32 and performing a i32 division if possible. All AMD cpus appear to have been missed when we added the "idivq-to-divl" attribute - this patch now matches Intel cpu behaviour (and the x86-64/v2/3/4 levels). Unfortunately the difference in code scheduling means I've had to stop using the update_llc_test_checks script and just use old-fashioned CHECK-DAG checks for divl/divq pairs. Fixes #90985 This fixes possibly worse runtime performance on AMD Zen hardware, when using -march=znver4 (or any other znver), as opposed to -march=x86-64-v4 or the baseline -march=x86-64. A similar fix is applied for Nehalem. PR: 278908 MFC after: 3 days (cherry picked from commit cadd2ca21765ebcb95b77ec94977b4e74e1edc1b) contrib/llvm-project/llvm/lib/Target/X86/X86.td | 6 ++ 1 file changed, 6 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[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 Author: Dimitry Andric AuthorDate: 2024-05-25 17:52:15 + Commit: Dimitry Andric CommitDate: 2024-05-28 05:25:49 + Merge commit d0be944aa511 from llvm-project (by Simon Pilgrim): [X86] Add slow div64 tuning flag to Nehalem target (#91129) This appears to have been missed because later cpus don't inherit from Nehalem tuning much. Noticed while cleaning up for #90985 Merge commit 8b400de79eff from llvm-project (by Simon Pilgrim): [X86] Enable TuningSlowDivide64 on Barcelona/Bobcat/Bulldozer/Ryzen Families (#91277) Despite most AMD cpus having a lower latency for i64 divisions that converge early, we are still better off testing for values representable as i32 and performing a i32 division if possible. All AMD cpus appear to have been missed when we added the "idivq-to-divl" attribute - this patch now matches Intel cpu behaviour (and the x86-64/v2/3/4 levels). Unfortunately the difference in code scheduling means I've had to stop using the update_llc_test_checks script and just use old-fashioned CHECK-DAG checks for divl/divq pairs. Fixes #90985 This fixes possibly worse runtime performance on AMD Zen hardware, when using -march=znver4 (or any other znver), as opposed to -march=x86-64-v4 or the baseline -march=x86-64. A similar fix is applied for Nehalem. PR: 278908 MFC after: 3 days (cherry picked from commit cadd2ca21765ebcb95b77ec94977b4e74e1edc1b) contrib/llvm-project/llvm/lib/Target/X86/X86.td | 6 ++ 1 file changed, 6 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[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 |In Progress Flags||mfc-stable14+, ||mfc-stable13+ --- Comment #4 from Dimitry Andric --- Reopening to track MFCs. -- You are receiving this mail because: You are the assignee for the bug.
[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: Dimitry Andric AuthorDate: 2024-05-25 17:52:15 + Commit: Dimitry Andric CommitDate: 2024-05-25 19:12:29 + Merge commit d0be944aa511 from llvm-project (by Simon Pilgrim): [X86] Add slow div64 tuning flag to Nehalem target (#91129) This appears to have been missed because later cpus don't inherit from Nehalem tuning much. Noticed while cleaning up for #90985 Merge commit 8b400de79eff from llvm-project (by Simon Pilgrim): [X86] Enable TuningSlowDivide64 on Barcelona/Bobcat/Bulldozer/Ryzen Families (#91277) Despite most AMD cpus having a lower latency for i64 divisions that converge early, we are still better off testing for values representable as i32 and performing a i32 division if possible. All AMD cpus appear to have been missed when we added the "idivq-to-divl" attribute - this patch now matches Intel cpu behaviour (and the x86-64/v2/3/4 levels). Unfortunately the difference in code scheduling means I've had to stop using the update_llc_test_checks script and just use old-fashioned CHECK-DAG checks for divl/divq pairs. Fixes #90985 This fixes possibly worse runtime performance on AMD Zen hardware, when using -march=znver4 (or any other znver), as opposed to -march=x86-64-v4 or the baseline -march=x86-64. A similar fix is applied for Nehalem. PR: 278908 MFC after: 3 days contrib/llvm-project/llvm/lib/Target/X86/X86.td | 6 ++ 1 file changed, 6 insertions(+) -- 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 --- 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. I know very little about botan3 and have never used it. Thanks, Yuri -- 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 --- 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 https://www.freebsd.org/security/#sup Yuri, why are you rushing this and ignoring https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279173 with this? Basically we can build with "all LLVM from ports" if I understand Dimitry correctly, so that would be the right recourse, rather than forcing a version that nobody else has or uses. Note that 279173 also has other necessary changes working around the older libc++ in FreeBSD 13's base. -- 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 --- 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: Yuri Victorovich AuthorDate: 2024-05-22 01:59:38 + Commit: Yuri Victorovich CommitDate: 2024-05-22 02:02:28 + security/botan3: Unbreak on amd64 and arm64 by using llvm-17 PR: 279136 (cherry picked from commit d863e42c9258ad8673bfbaef2af27781cff3b42c) security/botan3/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 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 --- 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: Yuri Victorovich AuthorDate: 2024-05-22 01:59:38 + Commit: Yuri Victorovich CommitDate: 2024-05-22 01:59:38 + security/botan3: Unbreak on amd64 and arm64 by using llvm-17 PR: 279136 security/botan3/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 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 --- 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 Andric --- Yes, it's an assertion caused by the reversal of https://github.com/llvm/llvm-project/commit/08c8d5bc51c5, which I committed during the llvm-12 (!) import, here: https://github.com/DimitryAndric/freebsd-src/commit/9c6443e9491128ed78f069af0caa77f062929dd8 This is was originally to fix a problem with bootstrapping the gcc ports. However, I removed it during the llvm-17 import, so from llvm-17 onward it should compile botan just fine. Also, the llvm-16 port should compile it OK, since it does not have the above revert. How long does 14.0-RELEASE have to live, still? 14.1-R is coming up, which should fix this problem too. -- 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 --- 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 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 Matthias Andree changed: What|Removed |Added Severity|Affects Only Me |Affects Some People -- 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 Matthias Andree changed: What|Removed |Added CC||mand...@freebsd.org --- Comment #1 from Matthias Andree --- Note that in order to reproduce this, if https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279173 were to be committed, the LLVM version restriction would have to be dropped from botan3's port Makefile because the fixes in PR 279173 will pin the LLVM version to minimal 14, maximal 15, avoiding the base LLVM on systems that carry LLVM 16 there. -- 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 Matthias Andree changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2791 ||73 -- You are receiving this mail because: You are the assignee for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[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 |fails with exit code 138|fails with exit code 138 |w/out any assertion message |w/out any assertion message |on the port security/botan3 |on the port security/botan3 ||on amd64, arm64 -- 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279136 Yuri Victorovich changed: What|Removed |Added CC||d...@freebsd.org Assignee|b...@freebsd.org|toolchain@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug.
[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 Resolution|--- |Overcome By Events --- Comment #2 from ni...@protonmail.com --- (In reply to Dimitry Andric from comment #1) Thanks for the reply, i will then close the ticket, Have a nice Day -- 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 --- 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|--- |FIXED --- Comment #6 from f...@fehcom.de --- Hi, after re-installing /usr/lib/clang/17 from base.xzy (and FreeBSD 13.2), the compiler works like a charm. /usr/lib]$ ls -la clang/ total 32 drwxr-xr-x 4 root wheel512 May 14 19:26 . drwxr-xr-x 12 root wheel 18432 Apr 25 22:42 .. drwxr-xr-x 5 root wheel512 Aug 30 2023 14.0.5 drwxr-xr-x 5 root wheel512 Mar 2 03:50 17 Please close the ticket and just use it as reference for similar problems. --eh. -- You are receiving this mail because: You are the assignee for the bug.
[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 from Dimitry Andric --- We're already at 14.1-BETA2, and since this does not appear to be a regression, I would guess it is too late to get in. -- You are receiving this mail because: You are the assignee for the bug.
[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 are receiving this mail because: You are the assignee for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[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 'valuable' files sit on an external RAID1 ZFS; no need to worry. Just before, I did a portsnap in order to install gcc (13) from the sources. Well, the system was hanging with the last message 'try to find most recent ADA compiler' (or something like that) with a load > 500. Sorry. Something seems to be broken beyond repair. And of course: There is no way in install Clang from packages/ports (at least no the recent version). I'm using this machine since about 8 ys and did an incremental upgrade starting with FreeBSD 10. Recently (FreeBSD 13.2), even vim did not work because of incompatible libs (solved now). https://fehcom.de/news.html I'm familiar with FreeBSD since version 3.2 ;-) Here, my desktop machine is a FreeBSD 14. Time to move on. Regards. --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 Dimitry Andric changed: What|Removed |Added CC||d...@freebsd.org --- Comment #4 from Dimitry Andric --- (In reply to feh from comment #3) Go to http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/13.3-RELEASE/, download the tarballs you need (base.txz, kernel.txz and depending on how you installed, lib32.txz and others). Untar those (as root!) into a temporary directory. (DON'T extract them into your existing root, because files in /etc get overwritten!) Then you can compare the files by hand, if you like, and selectively restore the ones that are bad. -- 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 --- 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, but should have SHA256 hash f4bdd216be3cbfaea1b0bb0b66337dd02cc5878f807f3bd5d04fad9d26f2fa43. /usr/src/usr.bin/top/commands.c has SHA256 hash 1421826171182b06adbc0ce37ad7cea6c03ea654f0836fda04bfa36c497b1604, but should have SHA256 hash 15bbb02ec92c86c9accff76d9dea1ba6ed9585a081b88f49093a2ca36912360a. /usr/src/usr.bin/top/commands.h has SHA256 hash 02aaa4a0368994fc3ff03427c6e3b29c9a1837397de2d5c2c6ac677bcd96fd1b, but should have SHA256 hash 6f96e407ddd5f8a4f71ab9ac1b482bb5d7425f1de5771ba7fffa69933b66ffad. /usr/src/usr.bin/top/display.c has SHA256 hash 94368e148e48c05400d61c178555cc7bcb707cc3ce93994e163a67fe71798ba5, but should have SHA256 hash e3770ed61f0444bc61492dcf9e65c70773106aef8ec5b97ab36b59707d3adb29. /usr/src/usr.bin/top/display.h has SHA256 hash 3adbf99035cbe0dde43f8e1f412b41d6306d9d6688a6cfd2cdba4b2a163bf6c6, but should have SHA256 hash 40a1c7a80eb10caf293aed589a57f419466f520a4d262b41817eaa7c3733b5a8. (many other more). How to get a clean 13.3?? (Apart from reinstalling from scratch). Regards. --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 SHENG-YI HUNG changed: What|Removed |Added CC||i19780219...@gmail.com --- Comment #1 from SHENG-YI HUNG --- I update my 13.2 machine to 13.3 but I cannot reproduce this problem. I check the clang/17 directory and all of the file is put correctly. Do you use freebsd-update upgrade again after you reboot? -- 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 SHENG-YI HUNG changed: What|Removed |Added CC||i19780219...@gmail.com --- Comment #1 from SHENG-YI HUNG --- I update my 13.2 machine to 13.3 but I cannot reproduce this problem. I check the clang/17 directory and all of the file is put correctly. Do you use freebsd-update upgrade again after you reboot? --- Comment #2 from SHENG-YI HUNG --- I update my 13.2 machine to 13.3 but I cannot reproduce this problem. I check the clang/17 directory and all of the file is put correctly. Do you use freebsd-update upgrade again after you reboot? -- 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 Mark Linimon changed: What|Removed |Added Keywords||regression Assignee|b...@freebsd.org|toolchain@FreeBSD.org -- 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 --- 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 Makefiles causing libraries for some architectures to be erroneously skipped. In your case, it looks like you used freebsd-update? And maybe it was not aware that you had the /usr/lib/clang directory at all, so it did not update it? How did you upgrade, exactly? -- 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 --- 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 from f...@fehcom.de --- I get the same error here after upgrade from 13.2 => 13.3: ld: error: cannot open /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-x86_64.a: No such file or directory The machine IS a AMD64: FreeBSD bigchief.fehnet.de 13.3-RELEASE-p1 FreeBSD 13.3-RELEASE-p1 GENERIC amd64 All updates installed. regards. --eh. -- 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 --- 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. Note that this commit does not appear to have been merged to the upstream release/17.x branch. Since the pkg-status error indicates the default cc of 14.0-RELEASE is used, maybe we can roll the fix into an errata release, or make the port use devel/llvm18? -- 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 --- 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 John F. Carr --- This crash is fixed in llvm17. -- 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 --- 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. ||org/ampere1/data/140releng- ||armv7-quarterly/1658bffbb67 ||9/logs/llama-cpp-2619.log Assignee|b...@freebsd.org|toolchain@FreeBSD.org CC||d...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[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). I tested it with > gmake check-gcc RUNTESTFLAGS=asan.exp on current gcc-13 git branch. A belated Thank you! Is this patch upstream as well or are you planning to engage upstream? It would be nice to avoid a FreeBSD Ports-specific patch here... -- You are receiving this mail because: You are on the CC list for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[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: Thierry Thomas AuthorDate: 2024-05-04 13:21:44 + Commit: Thierry Thomas CommitDate: 2024-05-04 13:32:02 + math/sprng: fix build with clang 18 This is not a bug of clang. Patch suggested by dim@. PR: 278711 .../files/patch-TESTS_mpitests_wolff.cpp (new) | 37 ++ math/sprng/files/patch-TESTS_wolff.cpp (new) | 37 ++ math/sprng/files/patch-TESTS_wolfftest.cpp (new) | 37 ++ 3 files changed, 111 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[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 |Closed --- Comment #2 from Thierry Thomas --- Committed, thanks Dimitry! -- You are receiving this mail because: You are the assignee for the bug.
[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 from Dimitry Andric --- I would guess that the code in question has "using namespace std;" at the top? That is most likely the cause for this error: the local variable name 'stack' now conflicts with 'std::stack'. It would be more correct to remove the "using namespace std;" statement and fix up the instances of std types used in the source, but an easier fix is to rename the local 'stack' variable to something else, for instance 'stack_' or 'my_stack'. -- You are receiving this mail because: You are the assignee for the bug.
[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 are receiving this mail because: You are the assignee for the bug.
[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 John F. Carr --- I was able to build lang/gcc13 (gcc13-13.2.0_4) in an armv7 jail on an armv8 host: JAILNAME VERSION ARCH METHOD TIMESTAMP PATH armv715.0-CURRENT 1500018 arm.armv7 src=/usr/src 2024-04-22 10:15:45 /usr/local/poudriere/jails/armv7 # poudriere options -j armv7 -n -s lang/gcc13 [00:00:01] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS [00:00:01] Working on options directory: /usr/local/etc/poudriere.d/armv7-options [00:00:01] Using ports from: /usr/ports [00:00:01] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf ===> The following configuration options are available for gcc13-13.20_4: GRAPHITE=off: Support for Graphite loop optimizations > Options available for the radio BOOTSTRAP: you can only select none or one of them LTO_BOOTSTRAP=off: Build using a full LTO bootstrap STANDARD_BOOTSTRAP=on: Build using a full bootstrap without LTO ===> Use 'make config' to modify these settings [00:00:02] Re-run 'poudriere options' with the -c flag to modify the options. I have on my local system a fix for bug #271087 (missing __aeabi_ exports) but it does not affect visibility of __aeabi_unwind_cpp_pr0. -- You are receiving this mail because: You are on the CC list for the bug.
[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 the assignee for the bug.
[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 Flags|maintainer-feedback?(salvad |maintainer-feedback+ |o...@freebsd.org)| CC||toolchain@FreeBSD.org Status|New |Open --- Comment #1 from Lorenzo Salvadore --- Unfortunately armv7 is a tier 2 platform for FreeBSD, so there are many issues with higher priority than this one. https://www.freebsd.org/platforms/ However, here is a few suggestions that might help you fix the issue: - test more recent GCC versions, see lang/gcc13-devel, lang/gcc14-devel, lang/gcc15-devel. lang/gcc14 is also coming soon; - look at this recent issue about GCC, libc++ and armv7, which might be related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278630 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114878 https://github.com/llvm/llvm-project/commit/55357160d0e151c32f86e1d6683b4bddbb706aa1 -- You are receiving this mail because: You are on the CC list for the bug.
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 obsolete releases.
Status |Bug Id | Description
+---+---
Open|236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open|261341 | clang-13 runs out of memory on the port math/open
Open|263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open|271624 | emulators/qmc2: clang crashes during build on {12
Open|192686 | Segfaults using combinations of -pie -pthread -lm
5 problems total for which you should take action.
[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. Kostik may have found another issue (see comment #12) that we'll have to take care of. -- You are receiving this mail because: You are the assignee for the bug.
[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 are receiving this mail because: You are the assignee for the bug.
[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 Product|Ports & Packages|Base System Version|Latest |15.0-CURRENT CC||d...@freebsd.org Component|Individual Port(s) |misc -- 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 Lorenzo Salvadore changed: What|Removed |Added CC||stffn.mo...@freenet.de --- Comment #24 from Lorenzo Salvadore --- *** Bug 273398 has been marked as a duplicate of this bug. *** -- 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 #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++ lang-gcc-g++-exception-handling-with-threads.cpp -o lang-gcc-g++-exception-handling-with-threads && /lang-gcc-g++-exception-handling-with-threads -- 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 #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 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 #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
// On FreeBSD:
// Works: g++13 -static -Wl,--eh-frame-hdr lang-gcc-g++-exception-handling.cpp
-o lang-gcc-g++-exception-handling && ./lang-gcc-g++-exception-handling
// FAILS: g++13 -staticlang-gcc-g++-exception-handling.cpp
-o lang-gcc-g++-exception-handling && ./lang-gcc-g++-exception-handling
int main(int argc, char *argv[])
{
try {
throw (int)0;
} catch (int i) {
return 0;
}
return 1;
}
Such is also true with -static-libgcc -static-libstdc++ added
to the command lines.
I do not know if -Wl,--eh-frame-hdr should be implicit/automatic
for FreeBSD.
My test context was based on:
# uname -apKU
FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT #5
main-n269589-9dcf39575efb-dirty: Sun Apr 21 01:42:00 PDT 2024
root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76
arm64 aarch64 1500018 1500018
# ~/fbsd-based-on-what-commit.sh -C /usr/ports
62a76b7dc95a (HEAD -> main, freebsd/main, freebsd/HEAD) graphics/mahotas:
Update to 1.4.15
Author: Wen Heping
Commit: Wen Heping
CommitDate: 2024-04-22 00:04:50 +
branch: main
merge-base: 62a76b7dc95aa8c2a74b06f92b0a8b752e3b1848
merge-base: CommitDate: 2024-04-22 00:04:50 +
n661234 (--first-parent --count for merge-base)
I'll note that the same is true for:
// File: lang-gcc-g++-exception-handling-with-threads.cpp
// On FreeBSD:
// Works: g++13 -static -Wl,--eh-frame-hdr -pthread
lang-gcc-g++-exception-handling-with-threads.cpp -o
lang-gcc-g++-exception-handling-with-threads &&
/lang-gcc-g++-exception-handling-with-threads
// FAILS: g++13 -static-pthread
lang-gcc-g++-exception-handling-with-threads.cpp -o
lang-gcc-g++-exception-handling-with-threads &&
/lang-gcc-g++-exception-handling-with-threads
#include "iostream"
#include "cstdio"
#include "pthread.h"
#include "pthread_np.h"
void* kernel(void* par) {
printf("kernel\n");
return NULL;
}
int main(int argc, const char* const* args){
pthread_t thread;
pthread_create(
,
NULL,
kernel,
NULL
);
pthread_join(thread, NULL);
printf("FreeBSD doesn't reach here.\n");
return 0;
}
--
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 #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: Dimitry Andric AuthorDate: 2024-04-26 10:06:20 + Commit: Yuri Victorovich CommitDate: 2024-04-26 10:06:20 + audio/noise-suppression-for-voice-lv2: workaround for clang-18 crash on 15 PR: 278333 audio/noise-suppression-for-voice-lv2/Makefile | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- 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 #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: 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 #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 source code files referenced? -- 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 #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. Thus the /usr/main-src/ in my paths. (gdb) run Starting program: /usr/home/root/c_tests/g++-static-link-test [New LWP 249477 of process 56713] kernel Thread 2 received signal SIGABRT, Aborted. Sent by thr_kill() from pid 56713 and user 0. [Switching to LWP 249477 of process 56713] thr_kill () at thr_kill.S:4 4 RSYSCALL(thr_kill) (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x004c283f in __raise (s=s@entry=6) at /usr/main-src/lib/libc/gen/raise.c:48 #2 0x004df3d9 in abort () at /usr/main-src/lib/libc/stdlib/abort.c:61 #3 0x00402be5 in uw_init_context_1 (context=context@entry=0x7fffdfffdd50, outer_cfa=outer_cfa@entry=0x7fffdfffdf80, outer_ra=0x4b2fc6 ) at /wrkdirs/usr/ports/lang/gcc13/work/gcc-13.2.0/libgcc/unwind-dw2.c:1336 #4 0x004ae786 in _Unwind_ForcedUnwind (exc=0x800818940, stop=0x4b3170 , stop_argument=stop_argument@entry=0x0) at /wrkdirs/usr/ports/lang/gcc13/work/gcc-13.2.0/libgcc/unwind.inc:212 #5 0x004b2fc6 in thread_unwind () at /usr/main-src/lib/libthr/thread/thr_exit.c:172 #6 0x004b2f2c in _pthread_exit_mask (status=0x0, mask=mask@entry=0x0) at /usr/main-src/lib/libthr/thread/thr_exit.c:254 #7 0x004b2e9b in _Tthr_exit (status=0x3ce85) at /usr/main-src/lib/libthr/thread/thr_exit.c:206 #8 0x004b2b0d in thread_start (curthread=0x800818700) at /usr/main-src/lib/libthr/thread/thr_create.c:289 #9 0x in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 -- 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 #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 my memory is bad or they removed support for the flag on Windows and MacOS; and left it in an unstable state on Linux. My memory might be conflating using GCC's shadow stack with clang's safe-stack. Either way; Thanks a bunch. I'll leave you guys to solve the GCC problem. -- 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 #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 reproduction steps, please go ahead and submit a FreeBSD bug. Issues that affect 3rd party FreeBSD base system software could be clearly upstream issues, could be clearly FreeBSD issues, or (as is the case here) might not be obvious or might be somewhere in between, so it's most reasonable for FreeBSD folks to do an initial triage before sending upstream. -- 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 #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 safe-stack works on OpenBSD, Linux, Windows, and MacOS. Should I make another bug report on FreeBSD's bug tracker or should this go to the clang devs? -- You are receiving this mail because: You are the assignee for the bug.
