[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.