[clang] Main Function Missing Due to Incorrect Infinite Loop Optimization

[gbdngb12]

We are submitting this report to bring to your attention an issue that I have encountered while using clang compiler, specifically related to compiler optimization. While working with clang compiler, I have observed an error that seems to be related to optimization levels O1, O2, and O3. Although I had expected an infinite loop to occur when applying these optimization options, I have instead encountered an unexpected termination of the main function.

I have conducted extensive research and testing to pinpoint the root cause of this problem, but unfortunately, my efforts have not yielded a conclusive solution. Given the complexity of LLVM and its extensive code base, I believe that your expertise and resources can shed light on this issue and help clarify its underlying causes.

Extended Description

Proof of Concept to trigger the bug

#include <stdint.h>

uint8_t uint8_sub(uint8_t ui1, uint8_t ui2) {
  return ui1 - ui2;
}

int main() {
    int32_t i;
    for(i = 0; i > (-22); i = uint8_sub(i, 1)) { }
    return 0;
}

While it was anticipated that an infinite loop would ensue when employing all optimization options, the principal function becomes non-existent, leading to anomalous termination across O1, O2, and O3 optimization levels.

Expected Result

# version
$ clang-18 --version
clang version 18.0.0 (https://github.com/llvm/llvm-project.git 4706251a3186c34da0ee8fd894f7e6b095da8fdc)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/dongFiles/compiler_trunk/llvm-project/build/bin

# compile with O0 optimization
$ clang-18 target.c -o clang_O0 -O0 

# correct result: infinite loop
$ ./clang_O0 # Infinite loop                                                                     
^C

Clang Result (incorrect)

• clang x64 (incorrect)

$ clang-18 --version
clang version 18.0.0 (https://github.com/llvm/llvm-project.git 4706251a3186c34da0ee8fd894f7e6b095da8fdc)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/dongFiles/compiler_trunk/llvm-project/build/bin

$ clang-18 target.c -o clang_O1 -O1
$ clang-18 target.c -o clang_O2 -O2
$ clang-18 target.c -o clang_O3 -O3

$ ./clang_O1 
$ echo $?   # Abnormal termination
64
$ ./clang_O2 
$ echo $?   # Abnormal termination
64
$ ./clang_O3 
$ echo $?   # Abnormal termination
64

• clang aarch64 (incorrect)

$ clang-18 --target=aarch64-linux-gnu target.c -o clang_O0_aarch64 -O0
$ clang-18 --target=aarch64-linux-gnu target.c -o clang_O1_aarch64 -O1
$ clang-18 --target=aarch64-linux-gnu target.c -o clang_O2_aarch64 -O2
$ clang-18 --target=aarch64-linux-gnu target.c -o clang_O3_aarch64 -O3

$ ./clang_O1_aarch64 
$ echo $?    # Abnormal termination
1
$ ./clang_O2_aarch64 
$ echo $?    # Abnormal termination
1
$ ./clang_O3_aarch64 
$ echo $?    # Abnormal termination
1

• clang x64 O0, O1, O2, O3 : https://godbolt.org/z/sKsh6Tdv1
• clang aarch64 O0, O1, O2, O3 : https://godbolt.org/z/PTG47q6v9

Comparison to GCC Result (correct)

$ gcc-trunk --version                                                    
gcc-trunk (GCC) 14.0.0 20230913 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-trunk target.c -o gcc_O0 -O0 
$ gcc-trunk target.c -o gcc_O1 -O1
$ gcc-trunk target.c -o gcc_O2 -O2
$ gcc-trunk target.c -o gcc_O3 -O3 
$ ./gcc_O0   # Infinite loop   
^C
$ ./gcc_O1   # Infinite loop   
^C
$ ./gcc_O2   # Infinite loop   
^C
$ ./gcc_O3   # Infinite loop
^C

• gcc x64 O0, O1, O2, O3 : https://godbolt.org/z/5YM9r56EM
• gcc aarch64 O0, O1, O2, O3 : https://godbolt.org/z/TGdvGP9Ws

[shafik]

I believe this is another case of: #48943

[llvmbot]

@llvm/issue-subscribers-clang-codegen

We are submitting this report to bring to your attention an issue that I have encountered while using clang compiler, specifically related to compiler optimization. While working with clang compiler, I have observed an error that seems to be related to optimization levels `O1`, `O2`, and `O3`. Although I had expected an infinite loop to occur when applying these optimization options, I have instead encountered an unexpected termination of the main function.

I have conducted extensive research and testing to pinpoint the root cause of this problem, but unfortunately, my efforts have not yielded a conclusive solution. Given the complexity of LLVM and its extensive code base, I believe that your expertise and resources can shed light on this issue and help clarify its underlying causes.

Extended Description

Proof of Concept to trigger the bug

#include <stdint.h>

uint8_t uint8_sub(uint8_t ui1, uint8_t ui2) {
  return ui1 - ui2;
}

int main() {
    int32_t i;
    for(i = 0; i > (-22); i = uint8_sub(i, 1)) { }
    return 0;
}

While it was anticipated that an infinite loop would ensue when employing all optimization options, the principal function becomes non-existent, leading to anomalous termination across O1, O2, and O3 optimization levels.

Expected Result

# version
$ clang-18 --version
clang version 18.0.0 (https://github.com/llvm/llvm-project.git 4706251a3186c34da0ee8fd894f7e6b095da8fdc)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/dongFiles/compiler_trunk/llvm-project/build/bin

# compile with O0 optimization
$ clang-18 target.c -o clang_O0 -O0 

# correct result: infinite loop
$ ./clang_O0 # Infinite loop                                                                     
^C

Clang Result (incorrect)

• clang x64 (incorrect)

$ clang-18 --version
clang version 18.0.0 (https://github.com/llvm/llvm-project.git 4706251a3186c34da0ee8fd894f7e6b095da8fdc)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/dongFiles/compiler_trunk/llvm-project/build/bin

$ clang-18 target.c -o clang_O1 -O1
$ clang-18 target.c -o clang_O2 -O2
$ clang-18 target.c -o clang_O3 -O3

$ ./clang_O1 
$ echo $?   # Abnormal termination
64
$ ./clang_O2 
$ echo $?   # Abnormal termination
64
$ ./clang_O3 
$ echo $?   # Abnormal termination
64

• clang aarch64 (incorrect)

$ clang-18 --target=aarch64-linux-gnu target.c -o clang_O0_aarch64 -O0
$ clang-18 --target=aarch64-linux-gnu target.c -o clang_O1_aarch64 -O1
$ clang-18 --target=aarch64-linux-gnu target.c -o clang_O2_aarch64 -O2
$ clang-18 --target=aarch64-linux-gnu target.c -o clang_O3_aarch64 -O3

$ ./clang_O1_aarch64 
$ echo $?    # Abnormal termination
1
$ ./clang_O2_aarch64 
$ echo $?    # Abnormal termination
1
$ ./clang_O3_aarch64 
$ echo $?    # Abnormal termination
1

• clang x64 O0, O1, O2, O3 : https://godbolt.org/z/sKsh6Tdv1
• clang aarch64 O0, O1, O2, O3 : https://godbolt.org/z/PTG47q6v9

Comparison to GCC Result (correct)

$ gcc-trunk --version                                                    
gcc-trunk (GCC) 14.0.0 20230913 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-trunk target.c -o gcc_O0 -O0 
$ gcc-trunk target.c -o gcc_O1 -O1
$ gcc-trunk target.c -o gcc_O2 -O2
$ gcc-trunk target.c -o gcc_O3 -O3 
$ ./gcc_O0   # Infinite loop   
^C
$ ./gcc_O1   # Infinite loop   
^C
$ ./gcc_O2   # Infinite loop   
^C
$ ./gcc_O3   # Infinite loop
^C

• gcc x64 O0, O1, O2, O3 : https://godbolt.org/z/5YM9r56EM
• gcc aarch64 O0, O1, O2, O3 : https://godbolt.org/z/TGdvGP9Ws

[gbdngb12]

Duplicated #60622

[gbdngb12]

$ cat poc.c
#include <stdint.h>
#include <unistd.h>

uint8_t uint8_sub(uint8_t ui1, uint8_t ui2) {
  return ui1 - ui2;
}

int main() {
    int32_t i;
    for(i = 0; i > (-22); i = uint8_sub(i, 1)) { }
    return 0;
}

void vuln_func() {
   execve("/bin/sh", NULL, NULL);
}
$ ./clang-18 poc.c -o poc -O1
$ ./poc
$ whoami
dong

This bug, while somewhat different from the existing bug #48943, #60622, arises in clang and can lead developers to trigger a security vulnerability. Hence, we are reopening the issue.

[shafik]

I do understand that the problems are all somewhat different but as far I understand the underlying cause is the same in that we are turning functions with unconditional unreachable code into empty functions. I believe the solution would be to turn many although not all cases into traps but there are some subtitles around implementing this.

The problem with keeping all the different discussions open is that it can lead to repetitive discussions or key points being spread across several issues which then makes it difficult for folks tackling the problem to fully understand the scope.

CC @AaronBallman @dwblaikie @efriedma-quic for additional perspectives.

[AaronBallman]

CC @AaronBallman @dwblaikie @efriedma-quic for additional perspectives.

Yeah, this looks to be the same root cause as #48943 and #60622 -- we should close this issue so as not to spread discussion too thin (I'm not certain which out of the two linked is the "better" to continue discussion in, but we should probably pick one and close the other).

[dwblaikie]

Yep - if they're both similar - pick the earlier one.

Duplicate of #48943

[dwblaikie]

I think #60622 is trying to be about the distinct issue of "is an infinite loop with no side effects UB" - I'd happily close it as "yes, it is", but if folks want to keep debating/discussing it there, so be it, but I wouldn't dup it against #48943

[gbdngb12]

same root cause #60622