I'm trying to build gcc with some nonstandard options and it fails. The error looks to be a bug in lto. I'm compiling the sources in gcc-4.6.0.tar.bz2 (the full bundle). My OS is Fedora 14 linux x86_64, with all packages updated to latest versions. Some libraries are not the right version, so I compiled the following: gmp-4.3.2 ppl-0.11.2 polylib-5.22.5 cloog-ppl-0.15.11 My configuration is: ../gcc/configure --enable-threads --with-arch=corei7 --with-tune=corei7 --with-fpmath=sse --enable-__cxa_atexit --enable-indirect-function --enable-languages=c,c++,java,lto,objc,obj-c++,fortran,ada,go --enable-libgcj-multifile --enable-java-home --with-arch-directory=x86_64 --enable-aot-compile-rpm --enable-browser-plugin --with-x --enable-java-awt=gtk,xlib --enable-gtk-cairo --with-gmp=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local I'm building with the following options: make BOOT_CFLAGS='-O3 -march=corei7 -flto' profiledbootstrap The error I get is the following: /usr/local/src/gccbuild/./prev-gcc/xgcc -B/usr/local/src/gccbuild/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -static-libgcc -static-libstdc++ -static-libgcc -o gnat1 ada/b_gnat1.o ada/adadecode.o ada/adaint.o ada/cstreams.o ada/cio.o ada/targtyps.o ada/decl.o ada/misc.o ada/utils.o ada/utils2.o ada/trans.o ada/cuintp.o ada/argv.o ada/raise.o ada/init.o ada/tracebak.o ada/initialize.o ada/env.o ada/a-charac.o ada/a-chlat1.o ada/a-elchha.o ada/a-except.o ada/a-ioexce.o ada/ada.o ada/ali.o ada/alloc.o ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o ada/comperr.o ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o ada/exp_aggr.o ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_util.o ada/exp_vfpt.o ada/expander.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o ada/frontend.o ada/g-byorma.o ada/g-hesora.o ada/g-htable.o ada/g-spchge.o ada/g-speche.o ada/g-u3spch.o ada/get_scos.o ada/get_targ.o ada/gnat.o ada/gnatvsn.o ada/hlo.o ada/hostparm.o ada/impunit.o ada/inline.o ada/interfac.o ada/itypes.o ada/krunch.o ada/layout.o ada/lib-load.o ada/lib-util.o ada/lib-writ.o ada/lib-xref.o ada/lib.o ada/live.o ada/namet-sp.o ada/namet.o ada/nlists.o ada/nmake.o ada/opt.o ada/osint-c.o ada/osint.o ada/output.o ada/par.o ada/par_sco.o ada/prep.o ada/prepcomp.o ada/put_scos.o ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o ada/s-addope.o ada/s-assert.o ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o ada/s-os_lib.o ada/s-parame.o ada/s-purexc.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strcom.o ada/s-strhas.o ada/s-string.o ada/s-strops.o ada/s-traceb.o ada/s-traent.o ada/s-unstyp.o ada/s-utf_32.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scans.o ada/scil_ll.o ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o ada/seh_init.o ada/sem.o ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o ada/sem_case.o ada/sem_cat.o ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o ada/sem_ch9.o ada/sem_disp.o ada/sem_dist.o ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o ada/sem_mech.o ada/sem_prag.o ada/sem_res.o ada/sem_scil.o ada/sem_smem.o ada/sem_type.o ada/sem_util.o ada/sem_vfpt.o ada/sem_warn.o ada/sinfo-cn.o ada/sinfo.o ada/sinput-d.o ada/sinput-l.o ada/sinput.o ada/snames.o ada/sprint.o ada/stand.o ada/stringt.o ada/style.o ada/styleg.o ada/stylesw.o ada/switch-c.o ada/switch.o ada/system.o ada/table.o ada/targext.o ada/targparm.o ada/tbuild.o ada/tree_gen.o ada/tree_in.o ada/tree_io.o ada/treepr.o ada/treeprs.o ada/ttypes.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o ada/usage.o ada/validsw.o ada/widechar.o ada/back_end.o ada/gnat1drv.o prefix.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a attribs.o ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/local/lib -lcloog -L/usr/local/lib -lppl_c -lppl -lpwl -lgmpxx -L/usr/local/lib -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz -O3 -march=corei7 -flto -fprofile-use lto1: internal compiler error: Violación de segmento Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: /usr/local/src/gccbuild/./prev-gcc/xgcc returned 1 exit status collect2: lto-wrapper returned 1 exit status make[3]: *** [gnat1] Error 1 make[3]: se sale del directorio `/usr/local/src/gccbuild/gcc' make[2]: *** [all-stagefeedback-gcc] Error 2 make[2]: se sale del directorio `/usr/local/src/gccbuild' make[1]: *** [stagefeedback-bubble] Error 2 make[1]: se sale del directorio `/usr/local/src/gccbuild' make: *** [profiledbootstrap] Error 2 And I send this bug report as suggested. By the way, "Violación de segmento" is the Spanish for "Segmentation fault". Thanks
You should not merely use -flto in BOOT_CFLAGS, that will fail anyway. Instead use --with-build-config=bootstrap-lto.
Ok. In the documentation it said that was equivalent to -flto in BOOT_CFLAGS, that's why I used it. Now I've checked bootstrap-lto.mk and looks like it disables lto when doing a profiled bootstrap. Is it right? I wonder what gives better performance: lto or profiled-driven optimizations...
(In reply to comment #2) > Ok. In the documentation it said that was equivalent to -flto in BOOT_CFLAGS, > that's why I used it. > Now I've checked bootstrap-lto.mk and looks like it disables lto when doing a > profiled bootstrap. Is it right? I wonder what gives better performance: lto or > profiled-driven optimizations... It disables LTO during the profile instrumented stage to speed up the compile of that. The final executables are still built with profile feedback and LTO.
Mmmm.... I'm afraid using --with-build-config=bootstrap-lto crashes at the same point with the same error. As a workaround, can I compile the ada frontend after installing the rest, without lto? How? I have one doubt about compiling the ada frontend (sorry if I shouldn't be asking this here). Documentation of --enable-threads config option looks to tell that the correct option for ada targets is --enable-threads=gnat, but this is equivalent to single for other targets. Should I compile everything except ada with default threading library (I guess posix) and separately the ada frontend with --enable-threads=gnat? Or am I misunderstanding? By the way, make doesn't look to honor --with-build-config=bootstrap-O3. I'm not an expert at all in Makefiles, but looking at the generated Makefile, the file is included after setting STAGE_CFLAGS to the value of BUILD_CFLAGS (and other variables from STAGE_CFLAGS). Of course, if BUILD_CFLAGS is altered after that, these variables are not correspondingly altered. More things I've found in my adventure of trying nonstandard options for building: - When using make -jn, when linking it claims to go back to -j1 because (something about jobserver, if I remember right) and says that '+' should be added to the top-level rule of the Makefile. Is this on purpose or '+' should have automatically been added? - Adding -mcmodel=large to BOOT_CFLAGS crashes (I think it's the assembler). -mcmodel=medium works. But I don't understand very well how these options work. Will the compiler have more available memory for data if I use medium model? Does this afect the heap or only static memory? And more important, will the compiler work correctly if it's compiled with these options? Thanks a lot, and sorry again if any of my comments should not be here, Juan
> Mmmm.... I'm afraid using --with-build-config=bootstrap-lto crashes at the > same point with the same error. Weird, LTO bootstrap for Ada is supposed to work (with default options). > I have one doubt about compiling the ada frontend (sorry if I shouldn't be > asking this here). Documentation of --enable-threads config option looks to > tell that the correct option for ada targets is --enable-threads=gnat, but > this is equivalent to single for other targets. Should I compile everything > except ada with default threading library (I guess posix) and separately the > ada frontend with --enable-threads=gnat? Or am I misunderstanding? Yes, you are, there is nothing special about Ada here.
(In reply to comment #5) > > Mmmm.... I'm afraid using --with-build-config=bootstrap-lto crashes at the > > same point with the same error. > > Weird, LTO bootstrap for Ada is supposed to work (with default options). > Well, I don't think it's difficult to reproduce, if you just compile with the options I described initially. I believe that it happens when I use profiledbootstrap together with lto, and for the Ada frontend. But I'm not 100% sure, as the long time it takes to test it every time prevents me from trying many combinations of options. I also don't know if things like -O3 or -march=corei7 have something to do with it or it would fail anyway. If I bound the minimal conditions that trigger this problem better, I'll let you know.
Investigating.
Author: ebotcazou Date: Sun Apr 17 14:57:14 2011 New Revision: 172611 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172611 Log: PR lto/48538 * lto-cgraph.c (merge_profile_summaries): Check that lto_file_data is non-null before accessing it. (input_cgraph): Remove trailing spaces. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c
Author: ebotcazou Date: Sun Apr 17 14:58:03 2011 New Revision: 172612 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172612 Log: PR lto/48538 * lto-cgraph.c (merge_profile_summaries): Check that lto_file_data is non-null before accessing it. (input_cgraph): Remove trailing spaces. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/lto-cgraph.c
The segfault should be eliminated now. As for the other issues: - you don't need to special-case the Ada compiler for anything, - the message issued with 'make -jn' is a known problem, - fiddling with -mcmodel isn't trivial because you need external support.
That was fast, thank you :)