[ARC64] gcc generating wider load in glibc testsuite string/test-strcmp

[vineetgarc]

Since we are on the topic of wider accesses generated by codegen, here's another issue that we have but got lost along the way.

When built with -munaligned-access -O2, a glibc testsuite test: string/test-strcmp is seemingly miscompiled by arc64 gcc . It is generating a wider load (LD vs. LDB) and since the test is specifically designed to test page boundary condition, the LD bleeds past end of page triggers segv. (problem doesn't happen with -mno-unaligned-access).

Snippet from faltering code

static void
do_test (size_t align1, size_t align2, size_t len, int max_char,
  int exp_result)
{
  size_t i;
  char *s1, *s2;
  if (len == 0)
    return;

  align1 &= 63;
  if (align1 + (len + 1) * 1 >= page_size)
    return;

  align2 &= 63;
  if (align2 + (len + 1) * 1 >= page_size)
    return;

  i = align1 + 1 * (len + 2);
  s1 = (char *) (buf1 + ((page_size - i) / 16 * 16) + align1);
  i = align2 + 1 * (len + 2);
  s2 = (char *) (buf2 + ((page_size - i) / 16 * 16) + align2);

  for (i = 0; i < len; i++)
    s1[i] = s2[i] = 1 + (23 << ((1 - 1) * 8)) * i % max_char;

  s1[len] = s2[len] = 0;
  s1[len + 1] = 23;
  s2[len + 1] = 24 + exp_result;
  s2[len - 1] -= exp_result;                   <---- issue here

-mno-unaligned-access (OK)

# test-strcmp.c:197:   s2[len - 1] -= exp_result;
    ldb_s   r1,[r2] #, *_42
    rsub    r0,r0,r1    # tmp225, _38, tmp315
    stb_s   r0,[r2] # tmp225, *_42

-munaligned-access (NOK)

# test-strcmp.c:197:   s2[len - 1] -= exp_result;
    ld_s    r1,[r2] #, *_42
    rsub    r0,r0,r1    # tmp225, _38, tmp314
    stb_s   r0,[r2] # tmp225, *_42

This problem was originally triaged by @cupertinomiranda but we never got around to formally created an issue for this. Given other things going on I decided to park it by disabled unaligned access as default in arc64 gcc driver ARC64 Revert back to aligned data accesses only for now 0c79612a6a5e14fda

Given we are hot on gcc generating wider load/stores best it table it now ARCv2 issue #372 although this doesn't seem related. The test case builds fine for ARCv2 (with default -munaligned-access) and also it is affected by alignment toggle whereas that is not.

# test-strcmp.c:197:   s2[len - 1] -= exp_result;
    mov_s   r12,r18
    ldb.a r2,[r12,r2]   <-- OK
.LVL64:
    sub_s r3,r2,r3  # tmp245, *_42, _38
    ld  r2,[@impl_count]
    cmp_s r2,-1 # impl_count.60_45,
    beq.d @.L37 #,
    stb_s r3,[r12]  # tmp245, *_42

[vineetgarc]

Here's actual log from running the failing case on Linux

# /test-strcmp 
                        strcmp  simple_strcmp   stupid_strcmp
potentially unexpected fatal signal 11.
Path: /test-strcmp
CPU: 0 PID: 92 Comm: test-strcmp Not tainted 5.6.0-00194-gf1cd1145e4e5 #42
Invalid Read @ 0x2013a000 by insn @ 0x12400
  @off 0x12400 in [/test-strcmp]  VMA: 0x00010000 to 0x00016000
ECR: 0x00050100 EFA: 0x2013a000 ERET: 0x00012400
STAT32: 0x80081882 [IE U     ]   BTA: 0x2008f298
 SP: 0x5ffff948  FP: 0x00000000 BLK: 0x123bc
r00: 0x00000000 r01: 0x00000018 r02: 0x00000000
r03: 0x00000000 r04: 0x00000001 r05: 0x0000000f
r06: 0xfefefefefefefeff r07: 0x20139ff8 r08: 0x00000008
r09: 0x20139ff9 r10: 0x20139ffa r11: 0x20139ffb
r12: 0x20139ffc r13: 0x20139ffd r14: 0x20139ffd
r15: 0x20139fff r16: 0x000000a1 r17: 0x20135ffd
r18: 0x00000007 r19: 0x0000007f r20: 0x00000000
r21: 0x20139ff7 r22: 0x20135ff7 r23: 0x00000017
r24: 0x20139ffd r25: 0x00014858
Didn't expect signal from child: got `Segmentation fault'

[vineetgarc]

strcmp-issue.tgz.log

[claziss]

I cannot see the issue with either gcc11 or gcc10. Please can u retry.

[pavelvkozlov]

I've checked the issue with latest arc-2022.09 and 2023.03 toolchains (with gcc12.2) and can also confirm that issue has gone. I think we can close it.