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 <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 #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
signature.asc
Description: PGP signature
