Bug 205934 - clang crashes in configure test with #pragma weak
Summary: clang crashes in configure test with #pragma weak
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.2-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Dimitry Andric
URL:
Keywords:
: 237190 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-01-05 20:12 UTC by Robert Clausecker
Modified: 2021-01-17 06:15 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Clausecker 2016-01-05 20:12:12 UTC
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: 
    
    ********************
Comment 1 Dimitry Andric freebsd_committer 2018-01-28 22:16:50 UTC
This is an extremely old LLVM bug, which I have reported upstream here: https://bugs.llvm.org/show_bug.cgi?id=36130.
Comment 2 Dimitry Andric freebsd_committer 2019-04-11 16:33:26 UTC
*** Bug 237190 has been marked as a duplicate of this bug. ***
Comment 3 Robert Clausecker 2021-01-16 22:35:24 UTC
Hey Allan,

Can you elaborate what happened to make this bug "overcome by events?"
Comment 4 Dimitry Andric freebsd_committer 2021-01-16 22:49:20 UTC
(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...
Comment 5 Robert Clausecker 2021-01-16 22:57:08 UTC
(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.
Comment 6 Allan Jude freebsd_committer 2021-01-17 06:15:13 UTC
Still applies to modern clang