https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #8 from Li Pan <pan2.li at intel dot com> --- For gcc.dg/torture/pr58955-2.c, we can simply reproduce it by options Pass when: -O3 Pass when: -O3 -ftracer -fno-schedule-insns -fno-schedule-insns2 Fail when: -O3 -ftracer -fno-schedule-insns2 10154: 4409 li s0,2 10156: 9c1d subw s0,s0,a5 10158: 1402 sll s0,s0,0x20 1015a: 9001 srl s0,s0,0x20 1015c: 97ca add a5,a5,s2 1015e: 078a sll a5,a5,0x2 10160: 7b018493 add s1,gp,1968 # 13400 <b> 10164: 97a6 add a5,a5,s1 10166: 00241613 sll a2,s0,0x2 1016a: 853e mv a0,a5 1016c: 4581 li a1,0 1016e: 158000ef jal 102c6 <memset> 10172: ffc50793 add a5,a0,-4 10176: 4689 li a3,2 10178: 0d047057 vsetvli zero,s0,e32,m1,ta,ma 1017c: 40d8 lw a4,4(s1) <== Load 1017e: 5e00b0d7 vmv.v.i v1,1 10182: 74d1a423 sw a3,1864(gp) # 13398 <a> 10186: 0207e0a7 vse32.v v1,(a5) <== Store 1018a: 03271163 bne a4,s2,101ac <main+0x6e> Looks like the tracer and the sch1 resulted in the failure, it is a typical Load Before Store issue AFAIK. The lw load should be after the vse32 store in semantics but the sch1 moves it before the store and of course, the value of a4 is unexpected here.
