Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])
Thomas Schwinge
thomas@codesourcery.com
Wed Sep 7 12:18:00 GMT 2016
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
#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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160907/123514d2/attachment.sig>
More information about the Gcc-patches
mailing list