[MIPS][AArch64] Wrong code at O1 in trunk

[XChy]

C Testcase:

#include <stdint.h>
#include <stdio.h>
#define BS_VEC(type, num) type __attribute__((vector_size(num * sizeof(type))))
typedef int32_t int32;
typedef int64_t int64;
typedef uint64_t uint64;
uint64 BS_CHECKSUM;
int32_t g_25;
uint32_t func_55(uint8_t p_58) {
  BS_VEC(int64, 4) BS_VAR_2 = {};
  BS_VEC(int32, 32) BS_VAR_4;
  BS_VEC(int64, 8) BS_VAR_8;
  uint64 *LOCAL_CHECKSUM = &BS_CHECKSUM;
  for (; p_58 <= 7; ++p_58) {
    *LOCAL_CHECKSUM ^= BS_VAR_2[3] + *LOCAL_CHECKSUM;
    BS_VAR_2 = __builtin_shufflevector(
        __builtin_shufflevector(
            (BS_VEC(int64, 2)){},
            (BS_VEC(int64, 2)){0, BS_VAR_8[4]}, 1, 3, 0, 3, 3, 0, 2, 3),
        (BS_VEC(int64, 8)) __builtin_convertvector(
            __builtin_shufflevector(BS_VAR_4, BS_VAR_4, 8, 9, 1, 6, 0, 3, 8, 4),
            BS_VEC(uint64, 8)),
        5, 6, 4, 1);
  }
}
int main() {
  func_55(g_25);
  printf("0x%016llx\n", BS_CHECKSUM);
}

Compile with -O1 and run on qemu-mips64el:

0x000000000000007b

Compile with -O0/O2/O3 and run on qemu-mips64el:

0x0000000000000000

Maybe related to #157521

clang -v: clang version 22.0.0git (git@github.com:llvm/llvm-project.git 0c3cf200f5b918fb5c1114e9f1764c2d54d1779b)

Let me know if you need a reduced LLVM-IR testcase.

[llvmbot]

@llvm/issue-subscribers-backend-mips

Author: Hongyu Chen (XChy)

C Testcase: ```c #include <stdint.h> #include <stdio.h> #define BS_VEC(type, num) type __attribute__((vector_size(num * sizeof(type)))) typedef int32_t int32; typedef int64_t int64; typedef uint64_t uint64; uint64 BS_CHECKSUM; int32_t g_25; uint32_t func_55(uint8_t p_58) { BS_VEC(int64, 4) BS_VAR_2 = {}; BS_VEC(int32, 32) BS_VAR_4; BS_VEC(int64, 8) BS_VAR_8; uint64 *LOCAL_CHECKSUM = &BS_CHECKSUM; for (; p_58 <= 7; ++p_58) { *LOCAL_CHECKSUM ^= BS_VAR_2[3] + *LOCAL_CHECKSUM; BS_VAR_2 = __builtin_shufflevector( __builtin_shufflevector( (BS_VEC(int64, 2)){}, (BS_VEC(int64, 2)){0, BS_VAR_8[4]}, 1, 3, 0, 3, 3, 0, 2, 3), (BS_VEC(int64, 8)) __builtin_convertvector( __builtin_shufflevector(BS_VAR_4, BS_VAR_4, 8, 9, 1, 6, 0, 3, 8, 4), BS_VEC(uint64, 8)), 5, 6, 4, 1); } } int main() { func_55(g_25); printf("0x%016llx\n", BS_CHECKSUM); } ```

Compile with -O1 and run on qemu-mips64el:

0x000000000000007b

Compile with -O0/O2/O3 and run on qemu-mips64el:

0x0000000000000000

Maybe related to #157521

clang -v: clang version 22.0.0git (git@<!-- -->github.com:llvm/llvm-project.git 0c3cf200f5b918fb5c1114e9f1764c2d54d1779b)

Let me know if you need a reduced LLVM-IR testcase.

[xgupta]

Seems unrelated to mips, on macbook m4 which is aarch64, outout is also different -

$ clang test.c  -O0 -o test                                                                                                                                                                                                                        
test.c:25:1: warning: non-void function does not return a value [-Wreturn-type]
   25 | }
      | ^
1 warning generated.

$ ./test                                                                                                                                                                                                                                                                    
0x000000fffa4b2b50

$ clang test.c  -O1 -o test                                                                                                                                                                                                                        
test.c:25:1: warning: non-void function does not return a value [-Wreturn-type]
   25 | }
      | ^
1 warning generated.

$ ./test                                                                                                                                                                                                                                                                    
0x0000000000000000

[wzssyqa]

On aarch64-linux, I can produce similiar problem with -O0 vs -O1/2/3/s.
I don't think this is a bug, as g_25 is unitilized.

[XChy]

@wzssyqa. That's not an undefined behaviour. g_25 is assigned zero.

From section 3.5.7 of the C89 standard

If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant.

And this program is run with UBSan, ASan, and MSan.