[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Sat Jul 6 10:41:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813

--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> ---
On July 6, 2019 12:18:47 AM GMT+02:00, "pthaugen at linux dot ibm.com"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
>
>Pat Haugen <pthaugen at linux dot ibm.com> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>         CC|                            |pthaugen at linux dot ibm.com,
>               |                            |rguenth at gcc dot gnu.org
>
>--- Comment #22 from Pat Haugen <pthaugen at linux dot ibm.com> ---
>So the problem appears to be alias.c:true_dependence() telling
>sched-deps.c:sched_analyze_2() that the following two instructions'
>memory
>references don't alias.
>
>Breakpoint 11, sched_analyze_2 (deps=0x7fffffffdbf8, x=0x7ffff59a1a40,
>insn=0x7ffff57f16c0)
>    at /home/pthaugen/src/gcc/temp/gcc/gcc/sched-deps.c:2671
>2671                    if (true_dependence (pending_mem->element (),
>VOIDmode,
>t)
>(gdb) pr pending->insn()
>(insn 37 36 38 4 (set (mem/f/c:DI (unspec:DI [
>                    (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>                    (reg:DI 2 2)
>                ] UNSPEC_TOCREL) [8 c_+0 S8 A64])
>        (reg/f:DI 141)) "proc_ptr_51.f90":28:0 609 {*movdi_internal64}
>     (expr_list:REG_DEAD (reg/f:DI 141)
>        (nil)))
>
>(gdb) pr insn
>(insn 39 38 40 4 (set (reg/f:DI 143 [ c_ ])
>(mem/f/c:DI (reg/f:DI 142) [8 c_+0 S8 A64])) "proc_ptr_51.f90":37:0 609
>{*movdi_internal64}
>     (expr_list:REG_DEAD (reg/f:DI 142)
>  (expr_list:REG_EQUAL (mem/f/c:DI (symbol_ref:DI ("__f_MOD_c_") [flags
>0xc0] <var_decl 0x7ffff7f70990 c_>) [8 c_+0 S8 A64])
>            (nil))))
>
>Which then lets the scheduler move the load above the store. Since they
>really
>are referring to the same location, we load up garbage (null) and
>branch to it.
>
>Including some additional detail from a couple various spots in the
>debug
>chain. Hoping someone with more alias.c knowledge can chime in.
>
>
>Breakpoint 13, true_dependence_1 (mem=0x7ffff59a4878,
>mem_mode=E_VOIDmode,
>mem_addr=0x0, x=0x7ffff59a8e08, 
>    x_addr=0x0, mem_canonicalized=false) at
>/home/pthaugen/src/gcc/temp/gcc/gcc/alias.c:2902
>2902    {
>(gdb) pr mem
>(mem/f/c:DI (unspec:DI [
>            (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>            (reg:DI 2 2)
>        ] UNSPEC_TOCREL) [8 c_+0 S8 A64])
>(gdb) pr x
>(mem/f/c:DI (symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] <var_decl
>0x7ffff7f70990
>c_>) [8 c_+0 S8 A64])
>
>...
>
>(gdb) pr x_addr
>(symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] <var_decl 0x7ffff7f70990
>c_>)
>(gdb) pr true_mem_addr
>(unspec:DI [
>        (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>        (reg:DI 2 2)
>    ] UNSPEC_TOCREL)
>(gdb) pr mem_base
>(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>
>2958      if (! base_alias_check (x_addr, base, true_mem_addr,
>mem_base,
>(gdb) p base_alias_check (x_addr, base, true_mem_addr, mem_base,
>GET_MODE (x),
>mem_mode)
>$18 = 0
>
>(gdb) s
>base_alias_check (x=0x7ffff5992990, x_base=0x7ffff5992990,
>y=0x7ffff59a4890,
>y_base=0x7ffff5990ac8, 
>    x_mode=E_DImode, y_mode=E_DImode) at
>/home/pthaugen/src/gcc/temp/gcc/gcc/alias.c:2174
>2174      if (x_base == 0)
>(gdb) pr x
>(symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] <var_decl 0x7ffff7f70990
>c_>)
>(gdb) pr x_base
>(symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] <var_decl 0x7ffff7f70990
>c_>)
>(gdb) pr y
>(unspec:DI [
>        (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>        (reg:DI 2 2)
>    ] UNSPEC_TOCREL)
>(gdb) pr y_base
>(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
>
>2221        return compare_base_symbol_refs (x_base, y_base) != 0;
>(gdb) p compare_base_symbol_refs (x_base, y_base)
>$19 = 0
>
>2136          if (!x_node->definition)
>(gdb) n
>2137            return 0;

We seem to access the same decl (see MEM_EXPR) once via section anchor and once
not. We seem to be confused about this in this very place?


More information about the Gcc-bugs mailing list