On Thu, Sep 8, 2016 at 1:43 PM, Thomas Schwinge <tho...@codesourcery.com> wrote: > Hi! > > On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge <tho...@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 <jos...@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