Hi!
On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener <[email protected]>
wrote:
> On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge <[email protected]>
> 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 <[email protected]>
> > 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.
[...]
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
