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

    <tr>
        <th>Summary</th>
        <td>
            -Wunsequenced is too strict on pre-increments
        </td>
    </tr>

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

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

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

<pre>
    Consider the following example that uses only pre-increments:
```cpp
constexpr int inc(int i)
{
  auto f = [](int i, int j){
    return i + j;
 };
  return f(++i, ++i);
}

int main() {
    constexpr int h = 3;
    static_assert(inc(h) == 9, "");
    int i = 3;
    return inc(i);
}
```
We issue the following diagnostic since C++17:
```cpp
<source>:6:12: warning: multiple unsequenced modifications to 'i' [-Wunsequenced]
  return f(++i, ++i);
           ^ ~~
```
Despite the fact that [P0145R3](https://wg21.link/p0145r3) "Refining Expression Evaluation Order for Idiomatic C++" and [P0400R0](https://wg21.link/p0400r0) "Wording for Order of Evaluation of Function Arguments" were adopted for C++17. Since [then](https://timsong-cpp.github.io/cppwp/n4659/expr.call#5) [[expr.call]](http://eel.is/c++draft/expr.call#7.sentence-2) states the following: `The initialization of a parameter, including every associated value computation and side effect, is indeterminately sequenced with respect to that of any other parameter`. Note that "indeterminately sequenced" means that `f` is called with `(4, 5)` or `(5, 4)`, and `i == 5` by the time we return from `inc()`, leading to static_assert not firing, and program returning 9.

Compilers agree, except for GCC runtime evaluation, which produces 10: https://godbolt.org/z/M8r8rvndT. I don't see an interpretation of the Standard since 17 that makes 10 a conforming result, so I believe there is a bug to file against GCC.

That said, I consider this code bug-prone. But "unsequenced" part of diagnostic message doesn't hold since C++17, and can even be misleading, because it shouldn't take users too many hops to reach a conclusion that unsequenced modification means a data race.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyUVs9v27gS_mvoyyCCTEm2dfAhtuOHHN57i7ZAjwuaHElsKVJLUnHSQ__2xVD-mU13sYXR0PTMN8OZbz5ShKBbi7hm1YZVu5kYY-f8-skqbYyZHZx6W2-dDVqhh9ghNM4Yd9S2BXwV_WAQYicijAEDOGveYPD4oK302KONgRWPLN-x_JEt8ukjh2Hakc6GiK-DB20jaCsZX6UV4_XJZ7mZFgBijA4aYMUOpkyvxtvk_428rvYAHuPoLWhgfAPfWHH-iS131y9nq4bxFeMbxjcJ8LKsL6bkNi3S_xSyF9omvxruIt8frEtJFzcxAUIUUcvfRQjoYzoJHb5LSMWO7OspDZ4-9Z1zOvYHoOcDT4X8OPdzE6avXxF0CCO-a6zSorUuRC0haCsRtlM95su_6SYrtsGNXiIrnljxuGDF45yz4hGOwlttW1r2o4maKDPagH-MaCUq6J3SjZYiamcDRAeMLzXjS-rzw9cbS2r6v-0aXP-x6gl-_vywDjsMg46nMggZJ0qzavNbPi-rT8VEty7GIfGZ7xnfH1s-z4y23xnfD2Tmi9Q-zj9ho-nE8PQ6eAxBOwtPL8KM6Yjwf0-j1DgPz0q7nohwLjDjHIRVU-Qyzz_l_xy5zHOfnyJ_dV5RYAKfwrjmNrRrYD9amdaPvh2nCeUcjugRhHJDRJW8Lx3P4HOiAKs2sUP7UT5R98HZ9kEOQ9bq2I2HTDvG93IYjgPje1suqprxPU1EJoUxjBdVypgGeXPdrnZX-As6osl0ILgpJeVFE9-hLbOANhJJHmha0nhhuGc18Y8t8i8dgrY6amH0j0tVBAzCix4j-klPpBlTJfEF_RuIEJzUgopDxUSQrh_GOLlTw0geAZsGZUz-AbRVhNZrKyKaN7jy_ahjBx7DgEQ0N3GNcrBv4GKH_iaXRZ7B_1w8aSzj_Jew1MUeBU1QMl3kDVvklAnV6ByWGM9XJeVIHSAL50-7Fe2W0y4tExEXuT4rUkXWh7dU1ah7hCNe5tC7Ptkm6blCGBSpitHdKx5YF6HRntpyijR413rRnxDJqc5u9Xbr-kEb9AFE6xHJDV8lDjHR9T_bLfjRprTwwncyOnZadoSuRokB5jnx4J6_rVMHZ2LmfMv4_gfj-_-u_Mq_WPUlg2dQBLSMEBBBkLxG9IPHeCEPFeRzFFYJr06COV9ObejF9xQUBF0KjaPGtdT80SSiBAfPcECj8SWpjydBBgGHMRWt0QZBtELbEOmMdxX5QgGC0IqAntOlc7qkqelOIaE8DN5ZzGAzJvrcqinnRLREvRvB7zEE0SIoh2E6d-eM-ss9cOqaFJZGxMIBodfh1G_69YBSjAFBRwidG42awKL4jvRW8KT0DnoifeeGpPseheymSkkzJtmcnha_uCxOfBegRBTghcRsptaFqotazHA9X6zqRbUqSz7r1kKKeV01Kq9kWdfL-WpZN01dz0Up5rwp5Uyvec6LfDlf5VVR5jxrhKrnqjlUTSXkMl-xMsdeaJMZ89ITV2bp6lwvirqoZkYc0IT0iOJcGpH05lpWEll6Xfk1eT8cxjawMjc6xHDFizoaXN9decQGqlOIXssIzr57Xc1Gb9bv2DwpsHQ943vCPv0hJnxL-rRPiZOkptz_DAAA__9rXCC0">