Description of problem: When compiling Qt Creator master (6defb83d0362be6b8910b81733c7f4d7895c6b2d), GCC 4.7 ran into an internal compiler error Version-Release number of selected component (if applicable): 4.7.0 20120507 (Red Hat 4.7.0-5) How reproducible: Always Steps to Reproduce: 1. Try to compile the attached preprocessed source code 2. The actual compiler flags were: -c -pipe -march=core2 -mtune=corei7-avx -std=c++0x -g -O3 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W Actual results: Compiler spits out the error message: ../../../../../../src/qt/creator/src/libs/languageutils/fakemetaobject.cpp:48:18: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2197 Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla> for instructions. Expected results: Compilation works fine. Additional info: The error can still be reproduced with the same sources with the following minimal flags: -c -std=c++0x -O2 Reducing the optimisation level or turning off C++11 support makes it succeed in compiling. Note how debugging doesn't need to be enabled for the compiler to produce an error in a file called "dwarf2cfi.c".
Created attachment 589811 [details] Preprocessed C++ source code
Created attachment 589813 [details] C++ source code compilede with regular C++98 Turns out that C++11 isn't necessary for this issue to happen. This new source code produces the error without the -std=c++0x option. E.g.: $ g++ -O2 -xc++ /tmp/ccu2bGoR.out ../../../../../../src/qt/creator/src/libs/languageutils/fakemetaobject.cpp: In member function ‘QString LanguageUtils::FakeMetaEnum::name() const’: ../../../../../../src/qt/creator/src/libs/languageutils/fakemetaobject.cpp:48:18: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2197 Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla> for instructions.
Tracking this upstream. Note that the Qt atomic code is broken, you really can't have the atomic insn in one asm stmt and the jz in another asm (asm goto) stmt, the compiler could schedule in between some other instruction that could modify flags. Either it should be a single asm goto that performs the atomic insn and jz afterwards (but then it can't have outputs), or much better you should just use GCC __sync_* intrinsics (or __atomic_* for 4.7+), as you are using asm goto you are requiring gcc much newer than what is guaranteed to have those.
Oh, thanks for the pointer. That asm goto was just my own testing, it's unreleased. I didn't realise this would be the problem. Using __atomic_* in GCC 4.7 is my intention.