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

[Richard Biener <richard.guenther@gmail.com>]

On Thu, Sep 8, 2016 at 1:43 PM, Thomas Schwinge <thomas@codesourcery.com> wrote:
> Hi!
>
> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge <thomas@codesourcery.com> wrote:
>> > 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!)
>
> Scary.  ;-/
>
>> 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.
>
> ACK, but that's also an issue for "regular" float/complex float, which
> also is in "reverse" order.  But that's "fixed" by the recursion in
> gcc/tree-streamer.c:record_common_node for "TREE_CODE (node) ==
> COMPLEX_TYPE".  This likewise seems to work for the _FloatN types.  (I've
> put "fixed" in quotes -- doesn't that recursion mean that we're thus
> putting "complex float", "float", [...], "float" (again) into the cache?
> Anyway that's for later...)
>
>> So I suggest to add a print_tree to where it does the streamer_tree_cache_append
>> and compare cc1 and lto1 outcome.
>
> Thanks for all your suggestions!
>
> As far as I can tell, tree 185 is in fact among the first trees just
> after the preloaded ones...  (See record_common_node followed by
> streamer_tree_cache_append with "ix == hash" vs., from "ix=180" onwards,
> streamer_tree_cache_append called from elsewhere with "ix != hash".)
> (I'm also noticing that this cache first is built from "ix=0" through
> "ix=179", then apparently discarded, and rebuilt again, which seems
> surprising but which I've not yet looked into; hopefully unrelated
> issue.)  I'll continue to poke at this, but wanted to given an update
> here at least.

Ok - so the only other suggestion is to do lock-step debugging of the
cc1 / lto1 process
starting from the last known "equal" tree we put into the cache...

Richard.

>     [...]
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:272:record_common_node
>      <fixed_point_type 0x7ffff68e23f0 unsigned UDA
>         size <integer_cst 0x7ffff68cd378 type <integer_type 0x7ffff68d2150 bitsizetype> constant 64>
>         unit size <integer_cst 0x7ffff68cd390 type <integer_type 0x7ffff68d20a8 sizetype> constant 8>
>         align 64 symtab 0 alias set -1 canonical type 0x7ffff68e23f0 precision 64>
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
>       ix=178 hash=178 tree=0x7ffff68e23f0
>      <fixed_point_type 0x7ffff68e23f0 unsigned UDA
>         size <integer_cst 0x7ffff68cd378 type <integer_type 0x7ffff68d2150 bitsizetype> constant 64>
>         unit size <integer_cst 0x7ffff68cd390 type <integer_type 0x7ffff68d20a8 sizetype> constant 8>
>         align 64 symtab 0 alias set -1 canonical type 0x7ffff68e23f0 precision 64>
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:272:record_common_node
>      <fixed_point_type 0x7ffff68e2690 unsigned UTA
>         size <integer_cst 0x7ffff68cd6a8 type <integer_type 0x7ffff68d2150 bitsizetype> constant 128>
>         unit size <integer_cst 0x7ffff68cd6c0 type <integer_type 0x7ffff68d20a8 sizetype> constant 16>
>         align 64 symtab 0 alias set -1 canonical type 0x7ffff68e2690 precision 128>
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
>       ix=179 hash=179 tree=0x7ffff68e2690
>      <fixed_point_type 0x7ffff68e2690 unsigned UTA
>         size <integer_cst 0x7ffff68cd6a8 type <integer_type 0x7ffff68d2150 bitsizetype> constant 128>
>         unit size <integer_cst 0x7ffff68cd6c0 type <integer_type 0x7ffff68d20a8 sizetype> constant 16>
>         align 64 symtab 0 alias set -1 canonical type 0x7ffff68e2690 precision 128>
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
>       ix=180 hash=1889092561 tree=0x7ffff68cc930
>      <optimization_node 0x7ffff68cc930
>         flag_fp_contract_mode (0)
>         flag_ira_algorithm (0)
>         flag_ira_region (0)
>         flag_reorder_blocks_algorithm (0)
>         flag_simd_cost_model (0)
>         flag_stack_reuse (0)
>         flag_vect_cost_model (0)
>     >
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
>       ix=181 hash=2721827057 tree=0x7ffff6993708
>      <target_option_node 0x7ffff6993708
>     >
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
>       ix=182 hash=3212777296 tree=0x7ffff6993730
>      <identifier_node 0x7ffff6993730 _ZL5placev>
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
>       ix=183 hash=1511527171 tree=0x7ffff6993758
>      <identifier_node 0x7ffff6993758 noinline>
>     PID=12052 [...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
>       ix=184 hash=4086308758 tree=0x7ffff6993780
>      <tree_list 0x7ffff6993780>
>
>     Breakpoint 1, fancy_abort (file=file@entry=0x10df3d0 "[...]/source-gcc/gcc/vec.h", line=line@entry=727, function=function@entry=0x10e003a <_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") at [...]/source-gcc/gcc/diagnostic.c:1414
>     1414    {
>     (gdb) bt
>     #0  fancy_abort (file=file@entry=0x10df3d0 "[...]/source-gcc/gcc/vec.h", line=line@entry=727, function=function@entry=0x10e003a <_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") at [...]/source-gcc/gcc/diagnostic.c:1414
>     #1  0x000000000059103f in vec<tree_node*, va_heap, vl_embed>::operator[] (this=0x16aba30, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:727
>     #2  0x0000000000591083 in vec<tree_node*, va_heap, vl_ptr>::operator[] (this=this@entry=0x169c868, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:1211
>     #3  0x0000000000c7d464 in streamer_tree_cache_get_tree (cache=0x169c860, ix=ix@entry=185) at [...]/source-gcc/gcc/tree-streamer.h:98
>     #4  0x0000000000c7d4c9 in streamer_get_pickled_tree (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x169f880) at [...]/source-gcc/gcc/tree-streamer-in.c:1112
>     #5  0x00000000008fca6b in lto_input_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x169f880, tag=tag@entry=LTO_tree_pickle_reference, hash=hash@entry=0) at [...]/source-gcc/gcc/lto-streamer-in.c:1404
>     #6  0x00000000008fce94 in lto_input_tree (ib=0x7fffffffceb0, data_in=0x169f880) at [...]/source-gcc/gcc/lto-streamer-in.c:1444
>     #7  0x0000000000c7b6e2 in lto_input_ts_list_tree_pointers (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x169f880, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/tree-streamer-in.c:861
>     #8  0x0000000000c7da5e in streamer_read_tree_body (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x169f880, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/tree-streamer-in.c:1077
>     #9  0x00000000008faa78 in lto_read_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x169f880, expr=expr@entry=0x7ffff6993780) at [...]/source-gcc/gcc/lto-streamer-in.c:1285
>     #10 0x00000000008fab6b in lto_read_tree (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x169f880, tag=tag@entry=4, hash=hash@entry=4086308758) at [...]/source-gcc/gcc/lto-streamer-in.c:1315
>     #11 0x00000000008fcc2b in lto_input_tree_1 (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x169f880, tag=tag@entry=4, hash=hash@entry=4086308758) at [...]/source-gcc/gcc/lto-streamer-in.c:1427
>     #12 0x00000000008fccc3 in lto_input_scc (ib=ib@entry=0x7fffffffceb0, data_in=data_in@entry=0x169f880, len=len@entry=0x7fffffffceac, entry_len=entry_len@entry=0x7fffffffcea8) at [...]/source-gcc/gcc/lto-streamer-in.c:1339
>     #13 0x000000000058d747 in lto_read_decls (decl_data=decl_data@entry=0x7ffff7fc0000, data=data@entry=0x16b0750, resolutions=...) at [...]/source-gcc/gcc/lto/lto.c:1693
>     #14 0x000000000058df18 in lto_file_finalize (file_data=file_data@entry=0x7ffff7fc0000, file=file@entry=0x15f9db0) at [...]/source-gcc/gcc/lto/lto.c:2037
>     #15 0x000000000058df78 in lto_create_files_from_ids (file=file@entry=0x15f9db0, file_data=file_data@entry=0x7ffff7fc0000, count=count@entry=0x7fffffffd054) at [...]/source-gcc/gcc/lto/lto.c:2047
>     #16 0x000000000058e0ca in lto_file_read (file=0x15f9db0, resolution_file=resolution_file@entry=0x0, count=count@entry=0x7fffffffd054) at [...]/source-gcc/gcc/lto/lto.c:2088
>     #17 0x000000000058e4d4 in read_cgraph_and_symbols (nfiles=1, fnames=0x1619990) at [...]/source-gcc/gcc/lto/lto.c:2798
>     #18 0x000000000058ebc2 in lto_main () at [...]/source-gcc/gcc/lto/lto.c:3299
>     #19 0x0000000000a5208f in compile_file () at [...]/source-gcc/gcc/toplev.c:466
>     #20 0x0000000000554f93 in do_compile () at [...]/source-gcc/gcc/toplev.c:2010
>     #21 toplev::main (this=this@entry=0x7fffffffd180, argc=argc@entry=20, argv=0x15e5f20, argv@entry=0x7fffffffd288) at [...]/source-gcc/gcc/toplev.c:2144
>     #22 0x0000000000556d67 in main (argc=20, argv=0x7fffffffd288) at [...]/source-gcc/gcc/main.c:39
>
>
> Grüße
>  Thomas