<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/124868>124868</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Inconsistencies with -fno-strict-overflow between Clang and GCC
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            clang
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          JustinStitt
      </td>
    </tr>
</table>

<pre>
    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 
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJykVsFu4zgPfhrlQsSQZTtJDzmk6Z9ifsxiBp25L2SJibWRJY-kJM0-_YK206ZtuovFFkbtiKRIfhQ_SsZodg5xyap7Vj1M5CE1Piz_f4jJuB_JpDSpvT4vn1ChS_D9CZqUusiKFRMbJjY7k5pDnSnfMrGx9nh5Tbvg_0CVmNh0B2uZ2ORClIsZKCtNGyF5aOUegQnBqvvp1vlpTMGoNPVHDFvrT6x6AN8l4x0o76KJiQKQKvgY4XG9Buk0rK10OyZExviK8dUXiIiQGpkgNSZSuCZC7FCZrVHS2jME3GJAp4zbAZvxm55nHCSFuNtZUqt9agbdU5DdsRc7fbUy7bxxCQNJ6kOi5GqEFA72fB17bPzBasfEPA3Gt_za6MG0nT2_RPfR6WXx2i8FTCmbCCfKn1X3BJL2GFn1wMTiXd2UynbukPmwY2LjnTUOtVdxEA06a69x-ohu-q0vQ8ya1FomCuM0Pn-MXtyxYjPUgfHV43rNxDyC8m0rnZ6SgxfwcTwGrFgBqc_4-PDVx3356iclNp4FwsZghFcU4CMgPVSnBh043MmE-srsYvPGIHsXRe8UQR1CoMqRNbbokuxj2AbfwvcnJorxUBPKQ13xWapkz9DKpJqhIjU28mh8yGDjAynQZlSIAaprrwT7ChLGlClgol_gK3xOGByoRgZa7FJgxT3jK-MStNI4JhZHbzQTd8DmJAAwW2Bi0SUyuIccWLEGsrtSAQiYDsFBPuwGwOYPgDbiRWWUiys5BTn8fwvW2ywK8K5v0bzMRDaslbBTCqbfxCW9dxWAD4WH6Y9h8yyj8mRfN_d8gA3Gv0xtze8xyZC64BUJWn-0JGGiFEysgYkK5fOVScD0fgN0ejQfnyH-eqG0qlCKeZmrOZZ8Jupa5Hkt1ZwXRb64q0u94GLMThET_Zf8yC0TVV1n77Js_fEXval-JX_89vP7-ul_X5lYMFEF01HfDZmGN5lezEZF-fyZokXZK-a3NFWvqdpu3GsQX8te3f098rGuLwr8rULA9OvGMRpaUNb-iJeuIQo9RUC5w0DM0hmLoWeG1vzZ92aEmLBtibb7LrVS7cFvb5P1S8nJUd9uq59fH56GLzA9PV147DPCvhDL58TsNDQyQhdQoe7Jj-wBnw3N2N3t0LJhtF0xi_Y9nRB0rTzXCK2JFqWmLTQe0foOA5G_h4BSQ2qIby3KiOB8woFsZ5xydXh6oaWBqrCfqdkLKF-2cEIm5gFpTv_DsBzIjhp-GHFwwmGQDSP-E-RGivT-dWyIgrpgvY6Mr3rc-zp6u48fOJfUS-7M3ihgJY-N3Jo9fa1k8O5eWttKR79_k3H_JM_0uUeMMNHLQt8Vd3KCy3xeLPK8XFRi0izzshY55tW8nutaF4taKKGqmS5qXGjN84lZCi4qnos7npe8Etms5vP8TgmZ83xbb7es5NhKYzO6AdFonZgYD7jMKeDFxMoabexvWkKo8eZCl66w7K9M9WEXWcmtiSm-bpFMsrj84l4uEoqO28mkBm7VA2pMJ0Q3nh86fY_r9eQQ7PJf39z66GN_d-sTOC7FXwEAAP__mlYmaQ">