Summary: | =sys-devel/gcc-4.6.3 on sparc - /work/gcc-4.6.3/libiberty/make-relative-prefix.c:199:1: internal compiler error: Segmentation fault | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | armin76, esigra, kripton, seraph, sparc |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | Sparc64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 418383 | ||
Attachments: |
build log
jmorgan_build_log |
Description
Agostino Sarubbo
2013-02-13 10:38:58 UTC
Can you build 4.5 with the 4.6 compiler? (In reply to comment #1) > Can you build 4.5 with the 4.6 compiler? For some reason now I have only 4.5.4 and with it, I can't build 4.6.3 The sparc team decided to move it back to ~arch. I see you're using a sun4v system. On my T2000, gcc will only build properly if I use "MAKEOPTS=-j1". I don't have that issue with any other packages. /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/libiberty/make-relative-prefix.c: In function ‘split_directories’: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/libiberty/make-relative-prefix.c:199:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. To get the preprocessed source, add -save-temps to the failing compiler line and attach the .i file it produces. (In reply to comment #4) > I see you're using a sun4v system. On my T2000, gcc will only build > properly if I use "MAKEOPTS=-j1". I don't have that issue with any other > packages. @dirtyepic: Jos is right, with makeopts = -j1 it works. It's strange that an ICE could be triggered by something like that though. In any case we still need the preprocessed code so we have a self-contained testcase to reliably reproduce this. Or are you saying that when you run the command on its own it works? I'm able to reproduce this bug when MAKEOPTS is greater than (see comment #4). For example, gcc-4.5.4 merges gcc-4.6.3. On another system, gcc-4.6.3 was able to merge gcc-4.6.3 with MAKEOPTS=j3. I'm also able to remerge world with gcc-4.6.3. I suggest closing this bug. I'm confused. You can or can't reproduce a build failure with higher than -j1? If you have gcc-4.5.4 (latest stable) and try to upgrade to gcc-4.6.3 with MAKEOPTS higher then -j1 it will fail. I was able to reproduce this defect. If you change MAKEOPTS=-j1, you can upgrade to gcc-4.6.3. In addition, I was able to remerge gcc-4.6.3 with gcc-4.6.3 with MAKEOPTS=-j3 as well as remerge world with gcc-4.6.3. In summary, this defect is only present in gcc-4.5.4 based on my testing. That's weird because I have seen reports of the opposite. It's probably a transient parallel build issue. Ago offered me access to a sparc machine but I just haven't had time to look into it. Maybe we should just force -j1 on sparc for 4.5/4.6 for now and see if it crops up again later. Btw, did it fail at the same point (libiberty/make-relative-prefix.c)? One report I saw failed somewhere else. no, it fails here... /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/gcc/c-family/c-ada-spec.c: In function 'print_ada_declaration': /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/gcc/c-family/c-ada-spec.c:3034:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.gentoo.org/> for instructions. make[3]: *** [c-family/c-ada-spec.o] Error 1 make[3]: *** Waiting for unfinished jobs.... /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/gcc/dbxout.c: In function 'dbxout_finish_complex_stabs': /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/gcc/dbxout.c:888:4: warning: ignoring return value of 'fwrite_unlocked', declared with attribute warn_unused_result [-Wunused-result] /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/gcc/dbxout.c:915:7: warning: ignoring return value of 'fwrite_unlocked', declared with attribute warn_unused_result [-Wunused-result] rm gcc.pod gfortran.pod attaching build log Created attachment 347694 [details]
jmorgan_build_log
I'd say this was a hardware issue if multiple people weren't hitting it. So I've made 4.6 and 4.7 build with -j1 for now. We can revisit for 4.8. http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/toolchain.eclass?r1=1.602&r2=1.603 |