Bug 48683 - [4.7 Regression] 252.eon in SPEC CPU 2000 failed to build
Summary: [4.7 Regression] 252.eon in SPEC CPU 2000 failed to build
Status: RESOLVED DUPLICATE of bug 48585
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: 4.7.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-19 12:59 UTC by H.J. Lu
Modified: 2011-04-26 08:48 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-04-19 13:08:12

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2011-04-19 12:59:40 UTC 
On Linux/x86-64, revision 172698 gave:

g++     -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin ....
...
In member function '_ZN8ggStringaSERKS_.constprop.760':
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [/tmp/cc7AjsKg.ltrans23.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
specmake[3]: *** [eon] Error 1

Revision 172608 is OK.
Comment 1 H.J. Lu 2011-04-19 13:07:12 UTC 
It is caused by revision 172609:

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00804.html
Comment 2 Richard Biener 2011-04-19 13:08:12 UTC 
I see the same for 483.xalancbmk:

In member function '_ZN10xalanc_1_818XalanDOMStringPoolC2Emmm.constprop.17718':
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [/tmp/ccfhgYqS.ltrans10.ltrans.o] Error 1

but eon may be nicer to analyze indeed.
Comment 3 Martin Jambor 2011-04-21 09:37:36 UTC 
The function _ZN10xalanc_1_818XalanDOMStringPoolC2Emmm is the one
causing PR 48585 (caused by an earlier commit of mine).  So these
might actually be two different bugs (is is a segfault in the LTRANS
stage, I suppose) ...or it is a better manifestation of the same bug,
it is hard to tell.  I guess I should update my source anyway.
Comment 4 Martin Jambor 2011-04-26 08:48:25 UTC 
Looking at our periodic tester results, it seems that it builds now and it started building at the same time 483.xalancbmk did.  So I believe it indeed was a duplicate of PR 48585.

*** This bug has been marked as a duplicate of bug 48585 ***