On Wed, Aug 20, 2014 at 9:28 AM, Venkataramanan Kumar <venkataramanan.ku...@linaro.org> wrote: > 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.
Note that it works on trunk with --enable-checking=release for whatever reason. > 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.
