Description of problem: Compiling anything (e.g. the classice hello.c) with "-O2 -g -Wall" fails Version-Release number of selected component (if applicable): clang-2.7-5.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1. clang -O2 -g -Wall hello.c 2. 3. Actual results: /tmp/cc-9CgPE8.s: Assembler messages: /tmp/cc-9CgPE8.s:408: Fatal error: duplicate .debug_line sections clang: error: assembler command failed with exit code 1 (use -v to see invocation) Expected results: a.out Additional info:
Sorry for the foulup. Bugzilla offered a menu for selecting the component, I selected clang, somehow it got 389-admintool when I submitted the report. "clang" isn't available for changing the component now. BTW, I also get: $ clang -O2 -g -Wall -v clang version 1.1 (branches/release_27) Target: x86_64-redhat-linux-gnu Thread model: posix clang: warning: argument unused during compilation: '-g' You have new mail in /var/spool/mail/vonbrand [vonbrand@laptop14 tmp]$ clang -O2 -g -Wall -v hello.c clang version 1.1 (branches/release_27) Target: x86_64-redhat-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-redhat-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name hello.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -g -resource-dir /usr/lib/clang/1.1 -O2 -Wall -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-8gLA3g.s -x c hello.c clang -cc1 version 1.1 based upon llvm 2.7 hosted on x86_64-redhat-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/lib/clang/1.1/include /usr/local/include /usr/include End of search list. "/usr/bin/gcc" -O2 -g -Wall -v -c -m64 -o /tmp/cc-SYFGnf.o -x assembler /tmp/cc-8gLA3g.s Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.4 20100611 (Red Hat 4.4.4-8) (GCC) COLLECT_GCC_OPTIONS='-O2' '-g' '-Wall' '-v' '-c' '-m64' '-o' '/tmp/cc-SYFGnf.o' '-mtune=generic' as --gdwarf2 -V -Qy --64 -o /tmp/cc-SYFGnf.o /tmp/cc-8gLA3g.s GNU assembler version 2.20.51.0.7 (x86_64-redhat-linux) using BFD version version 2.20.51.0.7-4.fc14 20100318 /tmp/cc-8gLA3g.s: Assembler messages: /tmp/cc-8gLA3g.s:408: Fatal error: duplicate .debug_line sections clang: error: assembler command failed with exit code 1 (use -v to see invocation)
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
T(In reply to comment #1) > Sorry for the foulup. Bugzilla offered a menu for selecting the component, I > selected clang, somehow it got 389-admintool when I submitted the report. > "clang" isn't available for changing the component now. > Sounds like a Bugzilla foul-up -- clang is not shipped as a separate SRPM, so it really should not have appeared as a component at all. I wonder if that's why the first package, when alphabetically sorted, gets a lot of bugs :) Will look into this, and check with upstream.
The correct package is llvm (as I set it now). Luser foulup, sorry.
Still the same with llvm-2.7-9.fc15.x86_64
Yap, -9 is a stop-gap update aimed at fixing a C++-only problem. The problem is really only with -g itself, not with the use of -O2 and -Wall (the latter two are fine even when combined). I've filed this upstream: http://llvm.org/bugs/show_bug.cgi?id=8210 and will try to reproduce this on F-14 i686 and F-13 {x86_64,i686}.
Upstream <http://llvm.org/bugs/show_bug.cgi?id=6218> claims this has been fixed, but as of llvm-2.7-10.fc15.x86_64 it still fails here.
The upstream commit supposed to fix this is <http://llvm.org/viewvc/llvm-project?view=rev&revision=110111>.
Thanks! This fix should be in 2.8-1.fc15 as it came out before llvm/clang 2.8 final. Looks like it should be cleanly appliable to clang 2.7 in F-13/14 too, so I'll mark this ON_DEV for now.
llvm-2.7-11.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/llvm-2.7-11.fc14
llvm-2.7-11.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/llvm-2.7-11.fc13
llvm-2.7-11.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update llvm'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/llvm-2.7-11.fc14
Fixed here (rawhide, llvm-2.8-3.fc15.x86_64)
llvm-2.7-11.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
llvm-2.7-11.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.