Bug 814277

Summary: lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:10872
Product: [Fedora] Fedora Reporter: Peter Portante <pportant>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: jakub, knoel, law, pportant
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-14 01:19:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Set of sources and make file to reproduce problem none

Description Peter Portante 2012-04-19 14:17:38 UTC
Created attachment 578659 [details]
Set of sources and make file to reproduce problem

Description of problem:

I am toying around with gcc's LTO with the qemu-kvm source tree, and found an internal compiler error. I have narrowed it down to:

  * using -g2 or higher
  * -O1 or higher
  * three qemu-kvm source .i files

$ gcc -flto -O1 -r -nostdlib -g3 curses.i qemu-char.i
qemu-timer.i -o foo.o
lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:10872
Please submit a full bug report,
with preprocessed source if appropriate.


Version-Release number of selected component (if applicable):

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.3/lto-wrapper
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-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --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.6.3 20120306 (Red Hat 4.6.3-2) (GCC) 


How reproducible:

Every time.


Steps to Reproduce:
1. Unpack attached tar ball
2. type: "make"


Actual results:

Internal compiler bug report printed to console.


Expected results:

Would expect program to compile without internal bugs showing up.


Additional info:

Comment 1 Jakub Jelinek 2012-04-19 15:03:11 UTC
LTO is known not to work well together with -g, especially in 4.6 and earlier.
Either don't use -flto, or use it only without -g, unless you are using gcc 4.7+ (and even in that case there are many known issues).

Comment 2 Jeff Law 2012-05-08 04:09:27 UTC
Jakub, is there any chance you can help these guys out a bit more?

First, does it work properly with gcc-4.7?  Obviously gcc-4.7 is far more strategically important to Red Hat than gcc-4.6.  So it's in our best interest to verify the problem does or does not exist in gcc-4.7 so that we can take appropriate action.

Second, just because two components are known to not play terribly well together doesn't mean we should tolerate an ICE.   While I understand we don't officially support gcc-4.6; helping out Peter and the larger performance analysis group when they trip over this kind of thing is part of our job.  So if you could poke at it a little and come up with a workaround, or even a kludgy patch I think they'd appreciate it.  If you wanted to handoff to Alex, that'd be fine as well.

If it turns out to be horribly nasty to fix in a gcc-4.6 era compiler, fine, but we should provide that basic information so they at last know why we're closing without further investigation.  And we should seriously consider a warning/error if someone tries to use LTO + -g in a gcc-4.6 era compiler.



Peter, is it possible for y'all to retry this with gcc-4.7 (and more generally focus on gcc-4.7 rather than gcc-4.6)?   As I mentioned, gcc-4.7 is far more strategically important to Red Hat than gcc-4.6.

Thanks,
jeff

Comment 3 Peter Portante 2012-05-08 10:32:01 UTC
We can try gcc-4.7 with this bug. I was planning on installing it as a secondary compiler on my system by building gcc-4.7 directly with a --prefix switch.

Comment 4 Jakub Jelinek 2012-05-14 12:51:26 UTC
Please see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564#c8
which really matches my experience.  Cherry-picking randomly -g -flto ICE fixes is very risky for the branch, and isn't worth it when there are dozens of other known -g -flto ICEs.  Note, in 4.7 effort has been spent primarily on getting rid of -g -flto ICEs, not the quality of the generated debug info nor that it is valid DWARF.  So even with 4.7 and likely 4.8 -g -flto isn't something that should be recommended for actually being able to debug code.

Comment 5 Fedora End Of Life 2013-01-16 22:46:37 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Fedora End Of Life 2013-02-14 01:19:09 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.