Message ID | 20101204220248.GD11171@kam.mff.cuni.cz |
---|---|
State | New |
Headers | show |
On Sat, Dec 4, 2010 at 2:02 PM, Jan Hubicka <hubicka@ucw.cz> wrote: > >> Hmm, missing dependency causing race during parallel build. I will commit the obvious >> fix adding dependency to lto-streamer.h on gcov-io.h > > Hi, > this is what I committed. I also noticed thinko in count_materialization_scale > computation. We should be scaling based on runs not run_max. > I still got [hjl@gnu-18 gcc]$ /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc -B/export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/ -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/sys-include -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genchecksum build/genchecksum.o .././libiberty/libiberty.a In function \u2018md5_process_block\u2019: 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: *** [/tmp/cc1Nc0QJ.ltrans0.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status lto-wrapper failedcollect2: ld returned 1 exit status
> I still got > > [hjl@gnu-18 gcc]$ > /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc > -B/export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/ > -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ > -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ > -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/lib/ -isystem > /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/include -isystem > /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/sys-include -g -O2 > -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use > -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes > -Wmissing-prototypes -Wmissing-format-attribute -pedantic > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror > -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H > -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o > build/genchecksum build/genchecksum.o .././libiberty/libiberty.a > In function \u2018md5_process_block\u2019: > 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: *** [/tmp/cc1Nc0QJ.ltrans0.ltrans.o] Error 1 > lto-wrapper: make returned 2 exit status > lto-wrapper failedcollect2: ld returned 1 exit status Hmm, I used to get similar segfault in liblto-plugin build that got fixed incrementally since I comitted few fixes from last week last night. Now I got clean profiledbootstrap build (with few local patches, but those are just to enable plugin by default now) By quick measurement unoptimize build of combine2.i reduces from 2.836s to 2.544s, 9.4% (on checking enabled compiler) and size by 6% compared to LTO bootstrapped cc1, so things seems to work as expected now. -O2 build is about 6% faster. This is consistent with my earlier tests. I configure as --enable-stage1-languages=c,lto --with-ld=/abuild/jh/trunk-install/bin/ld --with-build-config=bootstrap-lto I will try checking disabled compiler to possibly reproduce your segfault. Honza > > -- > H.J.
On Sun, Dec 5, 2010 at 3:38 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> I still got >> >> [hjl@gnu-18 gcc]$ >> /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc >> -B/export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/ >> -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ >> -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ >> -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/lib/ -isystem >> /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/include -isystem >> /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/sys-include -g -O2 >> -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use >> -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes >> -Wmissing-prototypes -Wmissing-format-attribute -pedantic >> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror >> -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H >> -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o >> build/genchecksum build/genchecksum.o .././libiberty/libiberty.a >> In function \u2018md5_process_block\u2019: >> 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: *** [/tmp/cc1Nc0QJ.ltrans0.ltrans.o] Error 1 >> lto-wrapper: make returned 2 exit status >> lto-wrapper failedcollect2: ld returned 1 exit status > > Hmm, I used to get similar segfault in liblto-plugin build that got fixed > incrementally since I comitted few fixes from last week last night. Now I got > clean profiledbootstrap build (with few local patches, but those are just to > enable plugin by default now) > > By quick measurement unoptimize build of combine2.i reduces from 2.836s to > 2.544s, 9.4% (on checking enabled compiler) and size by 6% compared to LTO > bootstrapped cc1, so things seems to work as expected now. -O2 build is about > 6% faster. This is consistent with my earlier tests. > > I configure as --enable-stage1-languages=c,lto --with-ld=/abuild/jh/trunk-install/bin/ld --with-build-config=bootstrap-lto > > I will try checking disabled compiler to possibly reproduce your segfault. > Please make sure that plugin isn't disabled.
> On Sun, Dec 5, 2010 at 3:38 AM, Jan Hubicka <hubicka@ucw.cz> wrote: > >> I still got > >> > >> [hjl@gnu-18 gcc]$ > >> /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc > >> -B/export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/ > >> -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ > >> -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ > >> -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/lib/ -isystem > >> /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/include -isystem > >> /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/sys-include -g -O2 > >> -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use > >> -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes > >> -Wmissing-prototypes -Wmissing-format-attribute -pedantic > >> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror > >> -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H > >> -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o > >> build/genchecksum build/genchecksum.o .././libiberty/libiberty.a > >> In function \u2018md5_process_block\u2019: > >> 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: *** [/tmp/cc1Nc0QJ.ltrans0.ltrans.o] Error 1 > >> lto-wrapper: make returned 2 exit status > >> lto-wrapper failedcollect2: ld returned 1 exit status > > > > Hmm, I used to get similar segfault in liblto-plugin build that got fixed > > incrementally since I comitted few fixes from last week last night. Now I got > > clean profiledbootstrap build (with few local patches, but those are just to > > enable plugin by default now) > > > > By quick measurement unoptimize build of combine2.i reduces from 2.836s to > > 2.544s, 9.4% (on checking enabled compiler) and size by 6% compared to LTO > > bootstrapped cc1, so things seems to work as expected now. -O2 build is about > > 6% faster. This is consistent with my earlier tests. > > > > I configure as --enable-stage1-languages=c,lto --with-ld=/abuild/jh/trunk-install/bin/ld --with-build-config=bootstrap-lto > > > > I will try checking disabled compiler to possibly reproduce your segfault.. > > > > Please make sure that plugin isn't disabled. It is not, I am building it bz default now. Honya > > > > -- > H.J.
Index: ChangeLog =================================================================== --- ChangeLog (revision 167458) +++ ChangeLog (working copy) @@ -1,5 +1,10 @@ 2010-12-03 Jan Hubicka <jh@suse.cz> + * Makefile.in (LTO_STREAMER_H): Add GCOV_IO_H. + * lto-cgraph.c (merge_profile_summaries): Fix thinko. + +2010-12-03 Jan Hubicka <jh@suse.cz> + PR tree-optimization/46760 * cgraph.c (cgraph_create_node): Initialize count_materialization_scale. * cgraph.h (struct cgraph_node): Add count_materialization_scale. Index: Makefile.in =================================================================== --- Makefile.in (revision 167457) +++ Makefile.in (working copy) @@ -975,7 +975,8 @@ IRA_INT_H = ira.h ira-int.h $(CFGLOOP_H) DBGCNT_H = dbgcnt.h dbgcnt.def EBITMAP_H = ebitmap.h sbitmap.h LTO_STREAMER_H = lto-streamer.h $(LINKER_PLUGIN_API_H) $(TARGET_H) \ - $(CGRAPH_H) $(VEC_H) vecprim.h $(TREE_H) $(GIMPLE_H) + $(CGRAPH_H) $(VEC_H) vecprim.h $(TREE_H) $(GIMPLE_H) \ + $(GCOV_IO_H) TREE_VECTORIZER_H = tree-vectorizer.h $(TREE_DATA_REF_H) IPA_PROP_H = ipa-prop.h $(TREE_H) $(VEC_H) $(CGRAPH_H) $(GIMPLE_H) GSTAB_H = gstab.h stab.def Index: lto-cgraph.c =================================================================== --- lto-cgraph.c (revision 167458) +++ lto-cgraph.c (working copy) @@ -1504,16 +1504,14 @@ merge_profile_summaries (struct lto_file During LTRANS we already have values of count_materialization_scale computed, so just update them. */ for (node = cgraph_nodes; node; node = node->next) - if (node->local.lto_file_data->profile_info.run_max) + if (node->local.lto_file_data->profile_info.runs) { int scale; - if (node->local.lto_file_data->profile_info.runs) - scale = - ((node->count_materialization_scale * max_runs - + node->local.lto_file_data->profile_info.run_max / 2) - / node->local.lto_file_data->profile_info.run_max); - else - scale = node->count_materialization_scale; + + scale = + ((node->count_materialization_scale * max_runs + + node->local.lto_file_data->profile_info.runs / 2) + / node->local.lto_file_data->profile_info.runs); node->count_materialization_scale = scale; if (scale < 0) fatal_error ("Profile information in %s corrupted",