| Issue |
124868
|
| Summary |
Inconsistencies with -fno-strict-overflow between Clang and GCC
|
| Labels |
clang
|
| Assignees |
|
| Reporter |
JustinStitt
|
Recent PR https://github.com/llvm/llvm-project/pull/122486 claims to make "[-fno-strict-overflow] option consistent across GCC and Clang".
I see that this PR is specifically referencing `-fno-strict-overflow` as toggling both `-fwrapv` and `-fwrapv-pointer` but to be truly consistent shouldn't `-fstrict-overflow` also imply `-fno-wrapv` and `-fno-wrapv-pointer` as this is what [GCC does](https://gcc.gnu.org/onlinedocs/gcc//Code-Gen-Options.html#index-fstrict-overflow)?
GCC's command-line reference claims:
```
-fstrict-overflow
This option implies -fno-wrapv -fno-wrapv-pointer and when negated implies -fwrapv -fwrapv-pointer.
```
The current implementation from PR#122486 doesn't exactly match this behavior. For example:
```
/* test.c */
extern char *ptr;
int main(void) {
if (ptr + 1 < ptr) {
return 1;
} else {
return 2;
}
}
```
```
# on GCC 14.2.0
$ gcc -O2 test.c -fwrapv-pointer -fstrict-overflow -S
...
.LFB0:
.cfi_startproc
movl $2, %eax
ret
.cfi_endproc
# on b8cdc5ea2741c7e4062bb211bac7033189b4d802
$ clang -O2 test.c -fwrapv-pointer -fstrict-overflow -S
...
# %bb.0:
movq ptr@GOTPCREL(%rip), %rax
movq (%rax), %rax
leaq 1(%rax), %rcx
cmpq %rax, %rcx
movl $2, %eax
sbbl $0, %eax
retq
```
The above example shows eager compiler optimizations stemming from lack of `-fwrapv-pointer`
The **TLDR** is: GCC's `-fstrict-overflow` implies `-fno-wrapv-pointer` and has precedence over existing `-fwrapv-pointer`. Clang doesn't do this, maybe misleading developers who read the release notes: `The new behavior matches GCC.`
If we're making `-fno-strict-overflow` match GCC should we also make `-fstrict-overflow` match too?
## CCs
CC'ing folks from PR#122486
@nikic @shafik @AaronBallman @MaskRay @kees
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
