https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111875
--- Comment #9 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Note we may be seeing the same core issue showing up outside the sanitizer
context. My tester flagged this on sh3eb-linux-gnu
Tests that now fail, but worked before (4 tests):
gcc: gcc.target/sh/cmpstr.c scan-assembler-times tst\t#3 2
gcc: gcc.target/sh/pr67675.c scan-assembler-times or\tr[0-9],r[0-9] 1
gcc: gcc.target/sh/pr67675.c scan-assembler-times tst\t#3,r0 6
gcc: gcc.target/sh/strlen.c scan-assembler-times tst\t#3 1
I didn't look at all 4, but I'm seeing what appears to be lost alignment
information as we go into the SH specific cmpstr expand code. Previously we
had A32 and now we have A8 on the MEM objects:
(gdb) p debug_rtx (operands[1])
(mem:BLK (reg/v/f:SI 163 [ s1 ]) [0 MEM <char[1:]> [(void *)s1_3(D)]+0 A8])
$8 = void
(gdb) p debug_rtx (operands[2])
(mem:BLK (reg/v/f:SI 164 [ s2 ]) [0 MEM <char[1:]> [(void *)s2_4(D)]+0 A8])
$9 = void
Which leads to getting into this conditional:
if (addr1_alignment < 4 && addr2_alignment < 4)
{
emit_insn (gen_iorsi3 (tmp1, s1_addr, s2_addr));
emit_insn (gen_tstsi_t (tmp1, GEN_INT (3)));
jump = emit_jump_insn (gen_branch_false (L_loop_byte));
add_int_reg_note (jump, REG_BR_PROB, prob_likely);
}
And we ultimately have unexpected assembly code and fail the scan test. I'm
not chasing this down further, but just noting this may be more than just a
sanitizer problem.
