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-bugzi...@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?