[Bug 248795] std::random_shuffle broken with LLVM11
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248795 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sat Aug 22 12:05:12 UTC 2020 New revision: 364482 URL: https://svnweb.freebsd.org/changeset/base/364482 Log: Add a few new source files to libc++, in particular the implementation part of std::random_shuffle. These were split off at some point by upstream, but I forgot to add them to our Makefile. This should allow some ports which use std::random_shuffle to correctly link again. Reported by: thierry PR: 248795 MFC after:6 weeks X-MFX-With: r364284 Changes: head/lib/libc++/Makefile -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 248795] std::random_shuffle broken with LLVM11
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248795 Thierry Thomas changed: What|Removed |Added CC||thie...@freebsd.org --- Comment #1 from Thierry Thomas --- Same error for the port math/hpcombi: [14/22] : && /usr/bin/c++ -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fstack-protector-strong -L/usr/local/lib benchmark/CMakeFiles/sort.dir/sort.cpp.o -o benchmark/sort -lbenchmark -lpthread && : FAILED: benchmark/sort : && /usr/bin/c++ -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fstack-protector-strong -L/usr/local/lib benchmark/CMakeFiles/sort.dir/sort.cpp.o -o benchmark/sort -lbenchmark -lpthread && : ld: error: undefined symbol: std::__1::__rs_default::~__rs_default() >>> referenced by algorithm:3112 (/usr/include/c++/v1/algorithm:3112) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(rand_perms(int)) >>> referenced by algorithm:3112 (/usr/include/c++/v1/algorithm:3112) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(rand_perms(int)) ld: error: undefined symbol: std::__1::__rs_get() >>> referenced by algorithm:3105 (/usr/include/c++/v1/algorithm:3105) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(rand_perms(int)) ld: error: undefined symbol: std::__1::__rs_default::operator()() >>> referenced by algorithm:2950 (/usr/include/c++/v1/algorithm:2950) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(long std::__1::uniform_int_distribution::operator()(s td::__1::__rs_default&, std::__1::uniform_int_distribution::param_type const&)) >>> referenced by algorithm:2950 (/usr/include/c++/v1/algorithm:2950) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(long std::__1::uniform_int_distribution::operator()(s td::__1::__rs_default&, std::__1::uniform_int_distribution::param_type const&)) >>> referenced by algorithm:2950 (/usr/include/c++/v1/algorithm:2950) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(long std::__1::uniform_int_distribution::operator()(s td::__1::__rs_default&, std::__1::uniform_int_distribution::param_type const&)) >>> referenced 1 more times c++: error: linker command failed with exit code 1 (use -v to see invocation) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 248745] /usr/bin/lldb dumps core when attempting to print variable with `p`, `fr v` works
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248745 --- Comment #1 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sat Aug 22 10:55:55 UTC 2020 New revision: 364480 URL: https://svnweb.freebsd.org/changeset/base/364480 Log: Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x002018d4 testcase`main(argc=1, argv=0x7fffea18) at testcase.c:3:5 1int main(int argc, char *argv[]) 2{ -> 3return 0; 4} (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x0008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x0451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x01bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x01bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x01f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x01fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x01fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x01974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x01a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x01ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x01ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x01a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x01a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x01a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x01a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x01a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x01d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x01918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x0191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 Changes: head/contrib/llvm-project/lldb/source/Target/Target.cpp -- You are receiving this mail because: You are the assignee for the bug. ___
Re: /usr/lib/libomp.so : is there a reason that aarch64 does not have such by default?
On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm wrote: >My context: head ( currently at -r363590 ) > >man src.conf is explicit that WITHOUT_OPENMP is the default for >aarch64 (for example). [...] >Nothing stands out for why WITH_OPENMP is in use by default only >for amd64, i386, and powerpc64. Because nobody has bothered to merge https://reviews.freebsd.org/D21167 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"