https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112112
Bug ID: 112112
Summary: Improper Arithmetic Type Conversion in
s390x-linux-gnu-gcc
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 22s302h0659 at sonline20 dot sen.go.kr
Target Milestone: ---
### Environment
- Compiler: s390x-linux-gnu-gcc (64bit)
- Version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
- Platform: Windows 11_5.15.90.1-microsoft-standard-WSL2
- Build Optimization Options: O0, O1, O2, O3
I installed the s390x-linux-gnu toolchain using the 'apt' package manager in
Ubuntu and utilized s390x-linux-gnu-gcc (version 11.4.0) from it.
### Summary
Using the legacy C code generator 'csmith' to generate test cases, I am
performing fuzzing on the GCC compiler for various architectures and
optimization options. I have discovered a bug specific to the s390x
architecture, and I will be reporting it.
### Source Code
I have prepared an 'binarys.zip' archive containing two versions of the bug PoC
code, along with '[c.sh](http://c.sh/)' for compiling them and
'[r.sh](http://r.sh/)' for running them
```bash
1 // bug_Poc1.c
2 #include <stdio.h>
3 char v1 = -1;
4 short v2 = 1;
5 int main()
6 {
7 printf("bug = %d\n", v1 <= v2);
8 return 0;
9 }
```
```bash
// result
bug_O0 = 0
bug_O1 = 0
bug_O2 = 1
bug_O3 = 1
```
Line 7 yields a correct result of 1 for the normal comparison operation.
However, with the O0 and O1 optimization options, it returns 0. With O2 and O3,
it correctly returns 1. I conducted tests to confirm the possibility of this
bug occurring in cross-compilers for the same version but different
architectures, but it consistently output the correct value of 1.
```bash
1 // bug_Poc2.c
2 #include <stdio.h>
3 char v1 = -1;
4 short v2 = 1;
5 int main()
6 {
7 printf("bug = %d\n", v1 >= v2);
8 return 0;
9 }
```
```bash
// result
bug_O0 = 1
bug_O1 = 1
bug_O2 = 0
bug_O3 = 0
```
On the 7th line, the normal comparison operation results in 0. However, with
the O0 and O1 optimization options, it returns 01. With O2 and O3, it correctly
returns 0. I conducted tests to confirm the possibility of this bug occurring
in cross-compilers for the same version but different architectures, but it
consistently output the correct value of 0.
### Coclusion
The commonality in the two bug code examples above appears to be the treatment
of -1 as unsigned rather than signed. My suspicion is that there might be an
issue with the integer arithmetic types or instructions on the s390x
architecture.
