The following very short C program triggers a bug in /usr/bin/cc (Clang 3.4.1) on amd64 FreeBSD 10.2-RELEASE: extern int test2(); #pragma weak test2 = test1 int test1() {return 0;} int main() { return test2(); ; return 0; } This program is used as a configure test in the Schily utilities, it's supposed to test if the compiler correctly supports SysV #pragma weak, though it's not supposed to induce a compiler crash. The output of /usr/bin/cc is: Stack dump: 0. Program arguments: /usr/bin/cc -cc1 -triple x86_64-unknown-freebsd10.2 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name clang-bug.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -coverage-file /tmp/clang-bug.o -resource-dir /usr/bin/../lib/clang/3.4.1 -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gnustep -fdiagnostics-show-option -vectorize-slp -o clang-bug.o -x c clang-bug.c 1. clang-bug.c:5:14: current parser token ')' 2. clang-bug.c:4:12: parsing function body 'main' 3. clang-bug.c:4:12: in compound statement ('{}') cc: error: unable to execute command: Segmentation fault (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.2 Thread model: posix cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. cc: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: cc: note: diagnostic msg: /tmp/clang-bug-60a5bb.c cc: note: diagnostic msg: /tmp/clang-bug-60a5bb.sh cc: note: diagnostic msg: ********************
This is an extremely old LLVM bug, which I have reported upstream here: https://bugs.llvm.org/show_bug.cgi?id=36130.
*** Bug 237190 has been marked as a duplicate of this bug. ***
Hey Allan, Can you elaborate what happened to make this bug "overcome by events?"
(In reply to Robert Clausecker from comment #3) This means that Allan considered this bug obsolete, as FreeBSD 10.2-RELEASE is long out of support, and in the mean time clang was updated to 10.0 (in the supported FreeBSD 11.x and 12.x branches) and 11.0 (in the upcoming FreeBSD 13.0). That said, the upstream bug https://bugs.llvm.org/show_bug.cgi?id=36130 is still open, and even the most recent clang trunk still asserts on the example: % clang -v FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-rc2-0-g43ff75f2c3f) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin % clang -cc1 -triple x86_64 -S weak.c Assertion failed: (Proto && "Functions without a prototype cannot be overloaded"), function AddOverloadCandidate, file /usr/src/contrib/llvm-project/clang/lib/Sema/SemaOverload.cpp, line 6163. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: clang -cc1 -triple x86_64 -S weak.c 1. weak.c:4:27: current parser token ')' 2. weak.c:4:12: parsing function body 'main' 3. weak.c:4:12: in compound statement ('{}') #0 0x00000000041d56fe PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13 #1 0x00000000041d3955 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18 #2 0x00000000041d5df0 SignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 0x0000000805692e00 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 zsh: abort clang -cc1 -triple x86_64 -S weak.c But since upstream doesn't really seem to care much, there isn't much we can do either...
(In reply to Dimitry Andric from comment #4) Ah yes, that explains it. But certainly, the bug is still there and causes compiler crashes. What's the right way to proceed here? Open a new bug for CURRENT? Reopen this one with a note that it reproduces on CURRENT? Upstream does seem to care a little about the bug and there is some movement every once in a while.
Still applies to modern clang