Bug 829247 - Internal compiler error compiling C++ code
Internal compiler error compiling C++ code
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
17
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-06 06:09 EDT by Thiago Macieira
Modified: 2012-06-07 03:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-07 03:07:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Preprocessed C++ source code (1.69 MB, text/plain)
2012-06-06 06:10 EDT, Thiago Macieira
no flags Details
C++ source code compilede with regular C++98 (1.09 MB, text/plain)
2012-06-06 06:17 EDT, Thiago Macieira
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 53589 None None None Never

  None (edit)
Description Thiago Macieira 2012-06-06 06:09:33 EDT
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".
Comment 1 Thiago Macieira 2012-06-06 06:10:31 EDT
Created attachment 589811 [details]
Preprocessed C++ source code
Comment 2 Thiago Macieira 2012-06-06 06:17:16 EDT
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.
Comment 3 Jakub Jelinek 2012-06-07 03:07:38 EDT
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.
Comment 4 Thiago Macieira 2012-06-07 03:34:25 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.