This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

    [...]
    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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]