This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LTO bootstrap compare errors for ARM64


On Wed, Aug 20, 2014 at 6:12 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On Wed, Aug 20, 2014 at 9:28 AM, Venkataramanan Kumar
>> <venkataramanan.kumar@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.kumar@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 <hubicka@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]