Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge <thomas@codesourcery.com> wrote:
> Hi!
>
> I trimmed the CC list -- I'm looking for advice about debugging a lto1
> ICE.
>
> On Fri, 19 Aug 2016 11:05:59 +0000, Joseph Myers <joseph@codesourcery.com> wrote:
>> On Fri, 19 Aug 2016, Richard Biener wrote:
>> > Can you quickly verify if LTO works with the new types?  I don't see anything
>> > that would prevent it but having new global trees and backends initializing them
>> > might come up with surprises (see tree-streamer.c:preload_common_nodes)
>>
>> Well, the execution tests are in gcc.dg/torture, which is run with various
>> options including -flto (and I've checked the testsuite logs to confirm
>> these tests are indeed run with such options).  Is there something else
>> you think should be tested?
>
> As I noted in <https://gcc.gnu.org/PR77458>:
>
>     As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types", nvptx
>     offloading is broken, ICEs in LTO stream-in.  Probably some kind of data-type
>     mismatch that is not visible with Intel MIC offloading (using the same data
>     types) but explodes with nvptx.  I'm having a look.
>
> I know how to use "-save-temps -v" to re-run the ICEing lto1 in GDB; a
> backtrace of the ICE looks as follows:
>
>     #0  fancy_abort (file=file@entry=0x10d61d0 "[...]/source-gcc/gcc/vec.h", line=line@entry=727, function=function@entry=0x10d6e3a <_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") at [...]/source-gcc/gcc/diagnostic.c:1414
>     #1  0x000000000058c9ef in vec<tree_node*, va_heap, vl_embed>::operator[] (this=0x16919c0, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:727
>     #2  0x000000000058ca33 in vec<tree_node*, va_heap, vl_ptr>::operator[] (this=this@entry=0x1691998, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:1211

so it wants tree 185 which is (given the low number) likely one streamed by
preload_common_nodes.  This is carefully crafted to _not_ diverge by
frontend (!) it wasn't even designed to cope with global trees being present
or not dependent on target (well, because the target is always the
same! mind you!)

Now -- in theory it should deal with NULLs just fine (resulting in
error_mark_node), but it can diverge when there are additional
compount types (like vectors, complex
or array or record types) whose element types are not in the set of
global trees.
The complex _FloatN types would be such a case given they appear before their
components.  That mixes up the ordering at least.

So I suggest to add a print_tree to where it does the streamer_tree_cache_append
and compare cc1 and lto1 outcome.

The ICE above means the lto1 has fewer preloaded nodes I guess.

Richard.

>     #3  0x0000000000c73e54 in streamer_tree_cache_get_tree (cache=0x1691990, ix=ix@entry=185) at [...]/source-gcc/gcc/tree-streamer.h:98
>     #4  0x0000000000c73eb9 in streamer_get_pickled_tree (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930) at [...]/source-gcc/gcc/tree-streamer-in.c:1112
>     #5  0x00000000008f841b in lto_input_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, tag=tag@entry=LTO_tree_pickle_reference, hash=hash@entry=0) at [...]/source-gcc/gcc/lto-streamer-in.c:1404
>     #6  0x00000000008f8844 in lto_input_tree (ib=0x7fffffffceb0, data_in=0x1691930) at [...]/source-gcc/gcc/lto-streamer-in.c:1444
>     #7  0x0000000000c720d2 in lto_input_ts_list_tree_pointers (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/tree-streamer-in.c:861
>     #8  0x0000000000c7444e in streamer_read_tree_body (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/tree-streamer-in.c:1077
>     #9  0x00000000008f6428 in lto_read_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/lto-streamer-in.c:1285
>     #10 0x00000000008f651b in lto_read_tree (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, tag=tag@entry=4, hash=hash@entry=4086308758) at [...]/source-gcc/gcc/lto-streamer-in.c:1315
>     #11 0x00000000008f85db in lto_input_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, tag=tag@entry=4, hash=hash@entry=4086308758) at [...]/source-gcc/gcc/lto-streamer-in.c:1427
>     #12 0x00000000008f8673 in lto_input_scc (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x1691930, len=len@entry=0x7fffffffceac, entry_len=entry_len@entry=0x7fffffffcea8) at [...]/source-gcc/gcc/lto-streamer-in.c:1339
>     #13 0x00000000005890f7 in lto_read_decls (decl_data=decl_data@entry=0x7ffff7fc0000, data=data@entry=0x169d570, resolutions=...) at [...]/source-gcc/gcc/lto/lto.c:1693
>     #14 0x00000000005898c8 in lto_file_finalize (file_data=file_data@entry=0x7ffff7fc0000, file=file@entry=0x15eedb0) at [...]/source-gcc/gcc/lto/lto.c:2037
>     #15 0x0000000000589928 in lto_create_files_from_ids (file=file@entry=0x15eedb0, file_data=file_data@entry=0x7ffff7fc0000, count=count@entry=0x7fffffffd054) at [...]/source-gcc/gcc/lto/lto.c:2047
>     #16 0x0000000000589a7a in lto_file_read (file=0x15eedb0, resolution_file=resolution_file@entry=0x0, count=count@entry=0x7fffffffd054) at [...]/source-gcc/gcc/lto/lto.c:2088
>     #17 0x0000000000589e84 in read_cgraph_and_symbols (nfiles=1, fnames=0x160e990) at [...]/source-gcc/gcc/lto/lto.c:2798
>     #18 0x000000000058a572 in lto_main () at [...]/source-gcc/gcc/lto/lto.c:3299
>     #19 0x0000000000a48eff in compile_file () at [...]/source-gcc/gcc/toplev.c:466
>     #20 0x0000000000550943 in do_compile () at [...]/source-gcc/gcc/toplev.c:2010
>     #21 toplev::main (this=this@entry=0x7fffffffd180, argc=argc@entry=20, argv=0x15daf20, argv@entry=0x7fffffffd288) at [...]/source-gcc/gcc/toplev.c:2144
>     #22 0x0000000000552717 in main (argc=20, argv=0x7fffffffd288) at [...]/source-gcc/gcc/main.c:39
>
> (Comparing to yesterday's r240004, the line number are slightly off, as
> I've added some stuff to aid debugging.)
>
> Looking at frame 14, lto_file_finalize, the ICE happens inside
> lto_read_decls, after the mode table setup:
>
>     2025    #ifdef ACCEL_COMPILER
>     2026      lto_input_mode_table (file_data);
>     2027    #else
>     2028      file_data->mode_table = lto_mode_identity_table;
>     2029    #endif
>     2030      data = lto_get_section_data (file_data, LTO_section_decls, NULL, &len);
>     2031      if (data == NULL)
>     2032        {
>     2033          internal_error ("cannot read LTO decls from %s", file_data->file_name);
>     2034          return;
>     2035        }
>     2036      /* Frees resolutions */
>     2037      lto_read_decls (file_data, data, resolutions);
>
> I have some confidence that it's not the offloading-specific
> lto_write_mode_table/lto_input_mode_table mode table streaming; by manual
> inspection it seems as if there's no change in the streamed information.
>
> Looking at Joseph's gcc/tree.c:build_common_tree_nodes, I observe that
> the x86_64 GNU/Linux target compiler does but the nvptx-offloading lto1
> does not set up _Float128 and _Float64x types (expectedly, I'd day), but
> I'm not sure if that's really the reason for the breakage.
>
> From the backtrace I have difficulties to tell what exactly lto1 is
> choking on -- are there any good strategies aside from stepping
> before/after lto1s in GDB, and seeing where they diverge?  For example,
> can I pretty-print the LTO stream that the ICEing lto1 is reading in, and
> can I try to tell from that what it's choking on?
>
>
> Grüße
>  Thomas