wrong code at -Os and above on x86_64-linux-gnu

[zhendongsu]

It appears to be a recent regression from 14.0.0.

% clangtk -v
clang version 15.0.0 (https://github.com/llvm/llvm-project.git b9513a70e16a7b7141601e09d5b9fc1cdecb26ab)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /local/suz-local/opfuzz/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Candidate multilib: .;@m64
Selected multilib: .;@m64
% 
% clangtk -O1 -w small.c; ./a.out
% 
% clangtk -Os -w small.c
% ./a.out
Segmentation fault
% 
% cat small.c
int printf(const char *, ...);
int a, h, b, d, f, i, j = -1, *c, *e, *g;
int main() {
  char *k, *l;
  for (; h < 8; h++) {
    int m = i;
    for (; a < 8; a++)
      if (d)
        printf(k);
    i = 71;
    k = (char *)&m;
    c = (int *)&l;
  }
  while (1) {
    int o = b, n = 7 & a;
    if (b && f) {
      printf("0");
      g = &o;
      for (; *k; (*k)++)
        ;
    }
    if (n)
      continue;
    int q = ~o, p = a ^ o;
    unsigned char r = ~(~(j * p) * o * ~(q ^ a));
    if (r < 8)
      break;
    return 0;
  }
  *e = 0;
  return 0;
}

Compiler Explorer: https://godbolt.org/z/a4Y3M51qP

@fhahn

[llvmbot]

@llvm/issue-subscribers-backend-x86

[fhahn]

This also reproduces on ARM64. Bisecting now

[fhahn]

It looks like this is a mis-compile with opaque pointers and that's why it doesn't reproduce with 14.0

It also fails on 14.0 with clang -Os -w -mllvm -opaque-pointers https://godbolt.org/z/1v3frYjE6

[nikic]

This is the same issue as #51838 (and works fine with -mllvm -no-stack-coloring). Opaque pointers are relevant in that they make the problematic accesses promotable.