On Wed, Aug 20, 2014 at 6:12 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> 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. > > Strange, do you know how the IR is affected by garbage collection?
Well, for at least one remaining case it seems that type (parts) are re-used differently, so the input at the LTO-out streaming has type (parts) duplicated (or not) dependent on GC. The PR tells about the case I didn't finish tracking down. The case fixed is somebody modifying sth in place we stored into hash tables for re-use. Not sure what the second case is. I still think we should try to understand why trunk is not affected? Richard. > Honza >> >> > 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.
