Description
Recent PR #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?
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
Metadata
Metadata
Assignees
Type
Projects
Status