Hi Honza, After discussing with Richard Beiner via https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077, it look like it is an existing problem in trunk and is masked due the fact that stage1 and stage2 compilers in trunk are built with enable-checking and hence same garbage collection tuning parameters.
In release branches, stage 1 is built with some checks like "gc" but stage 2 is not. These gc parameters affect the LTO IR and it gets streamed differently. Currently for release branches we have workaround of setting same gc parameters for stage1 and stage2 builds (or) build stage1 with ---enable-checking=release. regards, Venkat On 11 August 2014 16:20, Venkataramanan Kumar <venkataramanan.ku...@linaro.org> wrote: > Hi Honza, > > I did not find any differences in tree level dumps. These are the dump > differences in IPA > > In gimple-fold.c.000i.cgraph > > (--Snip--) > < _Z25gimple_build_omp_continueP9tree_nodeS0_/761 > (gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff7ebda548 > --- >> _Z25gimple_build_omp_continueP9tree_nodeS0_/761 >> (gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff92b5a548 > 28865c28865 > < _Z26gimple_build_omp_taskgroupP21gimple_statement_base/760 > (gimple_build_omp_taskgroup(gimple_statement_base*)) @0x3ff7ebda400 > --- >> _Z26gimple_build_omp_taskgroupP21gimple_statement_base/760 >> (gimple_build_omp_taskgroup(gimple_statement_base*)) @0x3ff92b5a400 > 28875c28875 > < _Z23gimple_build_omp_masterP21gimple_statement_base/759 > (gimple_build_omp_master(gimple_statement_base*)) @0x3ff7ebda2b8 > --- >> _Z23gimple_build_omp_masterP21gimple_statement_base/759 >> (gimple_build_omp_master(gimple_statement_base*)) @0x3ff92b5a2b8 > 28885c28885 > < _Z24gimple_build_omp_sectionP21gimple_statement_base/758 > (gimple_build_omp_section(gimple_statement_base*)) @0x3ff7ebda170 > --- >> _Z24gimple_build_omp_sectionP21gimple_statement_base/758 >> (gimple_build_omp_section(gimple_statement_base*)) @0x3ff92b5a170 > (--Snip--) > > > In gimple.c.044i.profile_estimate > > (--Snip--) > > 1987c1987 > < vec<tree_node*, va_heap, vl_ptr>::qsort(int (*)(void const*, void > const*)) (struct vec * const this, int (*<T10f9>) (const void *, const > void *) cmp) > --- >> vec<tree_node*, va_heap, vl_ptr>::qsort(int (*)(void const*, void const*)) >> (struct vec * const this, int (*<T10fb>) (const void *, const void *) cmp) > (--Snip--) > > gimple.c.048i.inline > > (--Snip--) > > < min size: 6 > --- >> min size: 0 > 6590c6590 > < min size: 14 > --- >> min size: 0 > 6607c6607 > < min size: 28 > (--Snip--) > > On 7 August 2014 19:14, Jan Hubicka <hubi...@ucw.cz> wrote: >>> >>> As a First step I compared the "objump -D" dump between >>> "stage2-gcc/gimple.o" and "stage3-gcc/gimple.o". Differences are in >>> LTO sections .gnu.lto_.decls.0, .gnu.lto_.symtab. >>> Ref: http://paste.ubuntu.com/7949238/ >> >> If you see the differences already in .o files (i.e. at compile time), I >> think the next >> step is to produce -fdump-tree-all -fdump-ipa-all dumps of >> stage2-gcc/gimple.o >> and stage3-gcc/gimple.o and see how they differ. >> >> Debugging misoptimization of LTO stage2 compiler will be interesting - I >> guess we can >> first try to identify what is wrong rahter than usual bisecting method... >> >> Honza >>> >>> No differences when when using "objdump -d". >>> >>> Next I passed "-save-temps" to stage2 and stage3 builds and compared >>> the assembly files. The differences are in strings dumped via .ascii >>> and ,string directives. >>> >>> Next I checked the flags passed to the stage 2 and stage 3 builds. It >>> is same and below is the flag set being passed. >>> >>> -save-temps -O2 -g -flto -flto=jobserver -frandom-seed=1 >>> -ffat-lto-objects -DIN_GCC -fno-exceptions -fno-rtti >>> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings >>> -Wcast-qual -Wmissing-forma t-attribute -pedantic >>> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings >>> >>> Can you please suggest on how to fix/debug further these comparison >>> failures in GCC 4.9? >>> >>> regards, >>> Venkat.
