https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #7 from Gary Mills <gary_mills at fastmail dot fm> ---
I'm still waiting for information on how to use gdb to check the alignment of
the structures involved in this ICE.
I had to RTFM and experiment. Here's the result:
$ /usr/bin/sparcv7/gdb build/sparcv7/./gcc/cc1 core
...
(gdb) bt
...
#9 <signal handler called>
#10 et_splay (occ=occ@entry=0x0)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:311
#11 0x00361834 in et_set_father (t=0xeaf810, father=0xeaf808)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/et-forest.c:525
#12 0x00301e6c in calculate_dominance_info (dir=dir@entry=CDI_DOMINATORS)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/dominance.c:658
#13 0x006701cc in cleanup_tree_cfg_noloop ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:759
#14 cleanup_tree_cfg ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfgcleanup.c:818
#15 0x0066ab88 in execute_build_cfg ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:360
#16 (anonymous namespace)::pass_build_cfg::execute (this=<optimized out>)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/tree-cfg.c:389
#17 0x0056a7e0 in execute_one_pass (pass=pass@entry=0xe30408)
---Type <return> to continue, or q <return> to quit---
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2336
#18 0x0056ad80 in execute_pass_list_1 (pass=0xe30408, pass@entry=0xe2e938)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2420
#19 0x0056ae1c in execute_pass_list (fn=0xfb410068, pass=0xe2e938)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/passes.c:2431
#20 0x002c8e18 in cgraph_node::analyze (this=this@entry=0xfb4a6000)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:636
#21 0x002cc2b0 in analyze_functions (first_time=first_time@entry=true)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:1086
#22 0x002cc9d0 in symbol_table::finalize_compilation_unit (this=0xfb410000)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/cgraphunit.c:2554
#23 0x006321e4 in compile_file ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:488
#24 0x00633f28 in do_compile ()
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:2014
---Type <return> to continue, or q <return> to quit---
#25 toplev::main (this=this@entry=0xffbff91e, argc=<optimized out>,
argc@entry=19, argv=<optimized out>, argv@entry=0xffbff984)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/toplev.c:2123
#26 0x00adcc28 in main (argc=19, argv=0xffbff984)
at
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-6/gcc-6.5.0/gcc/main.c:39
(gdb) q
So, it wasn't an alignment error after all. It was the most common thing that
causes a bus error: dereferencing a null pointer. The backtrace shows that
et_splay() was called with a NULL operand, occ. That NULL pointer was
dereferenced by this line:
311 while (occ->parent)
In et_set_father(), the et_splay() function was called with the operand rmost,
which must also be NULL.
That's the immediate cause of the ICE. I haven't identified the root cause
yet. I'm wondering, though, why the compiler built and ran on x86 hardware,
but failed on SPARC hardware. One difference is that the configuration on
SPARC hardware uses the native assembler. On x86 hardware, it uses the GNU
assembler. That's the only configuration difference. The hardware is
different, of course.
