<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=http://email.email.llvm.org/c/eJzNV8ly4zYQ_RrpgpJKomzJPujgZVzl69hJJrmoILIpYkwCDABa5nx9XgOkttGMU3FVEpeshQQfenmvu7E2Wbu8SVNjM6U3whvhCxJPXupM2kwMkqvB5e3g8g7v9FbbsaZt-HU_vsAbbhfe14PZzSB5wIuoHCuHL-kgucUrszL3fJ0flVk2SGYXg-Qar3HYJzdlaba8cWoyYpjJ_WDSv88n8dWBxaueqrqUHovvfFuTlhWJ58HsU7ybltI58fwrpTMxWHSP1M26VOkOXYhn8WWQ3Inf-e2Pwey2vx6dEM8FORLSkmh0RrnSlIk1FfJVGSu2BWl6JYvFi0fcfsOnUE5oo0ffyJpxD6Z0iSfFaiW9t2rdeFqtOJzJFS6VW9m6VVzClzkkcCOZC1OTld7YEHYOsNJedBtd730S-LPkG6tDjpL5Fwa5vI0r8eCBV4v7D9j0jkGp0c5_zCz-0l_e5fyQCIjumUTk-Je63QVevMqyISdMLvB83HA-GR8C_U6eU74lkRmNvHlRW5M1KQWgrbQaVHQB2RfY1RnrGQ8_9IafROK12Cpf8Baj35gHbbw5n7DDUE23BiwRjYvmMNOx4CSQeKIiX5jMCVnXJG0EhlRAVuVP_QqaEQ8wLZWM-87iO1wSzkuvUjgny9bBH6YpUYYoQueOKFiGEKxLqgB-s7Me2KbxP4WXfbxAqkyl2IjLRyG9UAjy4mzK1FFq2JygpB361jQlL-fI5U0ZtoGnBLxMaAlaybJs2SxKPRvv3gksu2nwQ1WIGHBTPA-DQuxOeROYLXKZBo5Ylj8eXxldtqvTZycxG0-MzekXpXo5KF_zSRcbXNqx4HQ_ZtlhDbHkmtIjSfpM6E4UEQOFDFaC14nRqAt9SA0SFhZEiodV8AQuSGyYaKNcCz9LR6PaOOXVKwKcHAnl4fkzA6GaMu-RzKfIpJueSXjaQETk4h7a-KChGIxA_p27ih3snQ5F1VGG4N2CYI9BWi-Bh2gPsMVgBxQV1Hh6U77lwJ2y2BV75-BUx-jzoj3yChl-AumVcw14A7Iks8vZbLLYNzK362QbpLlZj2EJfpTla_8xgly-EnPkIeBws4sgXC_vuqoEikp2gUPBPCrOl7CYclxBzu-fPuF3ZV45gkxa-G1s1FoqG8eXpbCNHjGbkT9VNpYQx-dC6pdA9cHFJC9koQWXIfzQ6gVxi4Ehhfpi7AtvpTLSXuVtVOyuAvB3ILIjB0H7TNxtszgZRH5VbXDGOp4SGKSQrC4kPZDwuLGjtlkj04LVLoWTOYIiW4bLzHHCAlGiaP7bMeDf7NyR3CvUdA9XgHPDTuxb5_-vqR9bHJf-A7vf7frP-4L2CK2_UqRYYF7gmKpq6MOhZETebRT3LnCM_mxIo6mDU5n0Et2gWoOtfSt2zBUmTegvkIoUtYH_Yaa7CouYxWHBdbzVjcZGUwdS8bOe61xrGugTotIp5AthoSBk1H2PUD06dyPwHx1MpiksD9ZoUptibSxvcWhtVyEhVziJ6SAtolwVSz2TbYgLlAefu0rIzkPHvA3qDLvFqYp2KH081we70hK4sMY1dQ0NuoCOfR_3bfARSkbEg-eZcmlzEG-k3luJ3s9Ny3M7RFtWueJGGcyTfie24-JKepyiLFCOeoNEdVV2y-eGuuZCi7bTyA3i_9DF7pAYj9zS_laRcN42GBTujqjMTH9j89o9_xb3It2TtJs6OZU3on4Tg9k9mDFPx29YI3bHhNDSmA9Yonh-SA4SzYuT5ASJGIkBk1sxZazvkegEqobMQuqIs5CfxW33FrY_sLA9Z2G7Q-pcRtEkC8wrtgOYwdyWtby3tbvsyXHaIYat6QnuQFWWZCR-JzS0dVbpvpKc_HWwFXoCGhV_YJgAgS0dmQZHO6OOInemqYYJVkWpR4eYsTyrnCCfrTrd5IMHm6qfaMMEhBOy5amTa-WYu-TRojCHntjYjbhnhrk4KoTy8RhmW5Zx12HDNMSVL0eRRqtX3yQ7wGOwDecW1EEcAFiSP5orduBSrCoYibq4ErKCkEOf5aN23AMHIR61FA8qPNbygNMN4Rvy3w0bXBvg_g1mv5_GaO_c7pzFhw0-Y4FxXHVwMenHgK4kbq0KM-TPBvowyxwcf45rPdNtxGU7Oy6kCPcwW86y69m1HMoGQHa5_WoV5qvtsLHl8kOT38ViWCwXl4nML5M0m12kaXZFV-tM5tP1ep6l12maz4elXFPplmHoTDRt4xDK-ru8H37cArVMJkkymSbTBKPo5WI8vbie5pN8mk-ni8liOsc0SBWyOGacsbGboV0GyHWzcbhZIhpuf5NJs8FgvYwZGHrlS1p-6o-Dv-wod9urjqXVzZWqPyXJnl2RRd2ZaBhsXwbD_wJbDuaU>53347</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Explicit Undefined Behavior not identified with a compile-time warning
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

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

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

<pre>
    According to the Standard ([\[expr.new\].4](http://eel.is/c++draft/expr.add#4)). the following code:

```c++
template<typename T>
class TVec3 {
public:
  T X, Y, Z;
  // These are undefined behavior whenever 'Index' is non-zero.
  inline __attribute__((__always_inline__)) T& operator[](int Index) {
    return (&X)[Index];
  }
  inline __attribute__((__always_inline__)) T operator[](int Index) const {
    return (&X)[Index];
  }
};
```

is undefined behavior for any non-zero values of `Index`.

Yet, we don't produce any warnings for this sort of thing, even with `-Weverything` (and even when uses of the `operator[]` methods appear with explicit non-zero values).  For cases with explicit non-zero values, no static analysis is needed to see the problem.  And even without explicit non-zero values, a warning indicating that it's undefined behavior if `Index` is ever non-zero would be useful, as we'd naturally expect these `operator[]` methods to sometimes be called with non-zero values (in fact, rare to _only_ be called with 0).  Something like:
`warning: uses of non-zero values for 'Index' results in undefined behavior`

would seem fine -- that is, it wouldn't seem to be a "noisy false-positive".

FTR, clang's Static Analysis also doesn't note anything when non-zero index values are used.  But I think the additional complexity of static analysis shouldn't be needed for this sort of thing.

(See issue [#53307](https://github.com/llvm/llvm-project/issues/53307), for an example where this undefined behavior resulted in DSE removing some stores, causing a run-time failure.  Thanks to @fhahn and @nikic for their work in identifying the problem there.)

Related to this, my understanding has been that the following approach is a safe way to do this sort of indexing:

```c++
template<typename T>
class TVec3 {
public:
  T X, Y, Z;
  inline __attribute__((__always_inline__)) T& operator[](int Index) {
    return (static_cast<T*>(&X))[Index];
  }
  inline __attribute__((__always_inline__)) T operator[](int Index) const {
    return (static_cast<const T*>(&X))[Index];
  }
};
```

That is, I've been under the impression that given a sequence of data members of the same type, and a pointer (of that type) pointing to one of them, then you can increment/decrement that pointer to safely access the neighboring data members.  But in researching this today, I haven't been able to find a statement in the Standard that clearly supports this.  In fact, I found one discussion that contradicts it.  Specifically, at:
https://en.cppreference.com/w/cpp/language/pointer

I see:

```c++
struct C {
   int x, y;
} c;
 
int* px = &c.x;   // value of px is "pointer to c.x"
int* pxe= px + 1; // value of pxe is "pointer past the end of c.x"
int* py = &c.y;   // value of py is "pointer to c.y"
 
assert(pxe == py); // == tests if two pointers represent the same address
                   // may or may not fire
 
*pxe = 1; // undefined behavior even if the assertion does not fire
```

FTR, assuming that's correct (i.e., assuming the `*pxe = 1;` is undefined behavior), then I'd have to think that if optimizations were done based on this undefined behavior, then a _massive_ amount of code that we compile with llvm would get run-time failures.  (Also, assuming that's correct, then I don't see any "clean" way to safely write an `operator[]` method for cases with a sequence of same-typed data members.)
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzNV8ly4zYQ_RrpgpJKojbroIOXcZWvYyeZ5KKCyKaIMQUwAGiZ8_V5DZDaRjOTylQlcclaSKDRy3vdjxuTNavbNDU2U3orvBG-IPHspc6kzUQvuenN7nqze7zTe2WHmvbh18NwijfcLryvepPbXvKIF1E5VA5f0l5yh1dmZe75Om-VWdZLJtNessRrGM7JTVmaPR-cmozYzOihN-re56P4ao3Fq552VSk9Ft_7piItdyReepMP8W5aSufEy6-UTkRv0W6p6k2p0oN1IV7Ep15yL37ntz96k7vuegxCvBTkSEhLotYZ5UpTJjZUyDdlrNgXpOmNLBYvnnD7HZ9COaGNHnwha4adMaVL7BTrtfTeqk3tab3mdCY3uFTuZePWcQlf5pQgjGQuTEVWemND2jnBSnvRHrQ8xiTwZ8nXVocaJfNPbGR2F1di40lUi4ef8OkHDqVGO_9zbvGX7vKh5qdAQHavFCLHv9TNIfHiTZY1OWFygf3xwPloeGrod_Jc8j2JzGjUzYvKmqxOKRjaS6sBRRcs-wKnOmM928MPveWdKLwWe-ULPmLwG-OgiTfnIw4YrGnXACWidtEdRjoWXCQSO3bkC5M5IauKpI2GQRWAVfnLuAJnxCNcSyXb_cHie1wSzkuvUgQny8YhHoYpUYYsgueOKHiGFGxK2sH47cF72Da1_6552eULoMpUioO4fRTSC4UkL66WTJ2Vht0JTDpY35u65OWcubwuwzGIlGAvE1oCVrIsG3aLUs_Oux8klsM0-KF2yBjsptgPh0LuLnETkC1ymQaMWKY_tq-NLpv15d5RrMYz2-byi1K9nrSv-ajNDS4dUHB5HqPstIdYcnXpUSR9JXUXjIiJQgV3gteJwaBNfSgNChYWRIiHVYgEIUgcmGijXIM4S0eDyjjl1RsSnJwR5fHlIxtCN2Xco5jPEUm3HZKw24BE5OIZ2vjAoZiMAP5DuIoD7IIOTdVRhuTdAWBPgVqvAYcYD_DF4AQ0FfR4ele-4cRdotgVx-AQVIvo66Q9iwoVfgbolXM1cAOwJJPZZDJaHAeZO0yyLcpcb4bwBD_K8q37GIAun4kx8hjs8LCLRrhf3rddCRCVHAKngnFUXG9hseS4gpo_PH_A75154wwyaBG3sZFrqawdX5bC1nrAaEb9VFlbQh5fCqlfA9R701FeyEILbkP4odUr8hYTQwr9xdhXPkplpL3Km8jYQwfg77DIgZwk7SPxtM2iMoj42jUhGOtYJbCRQjK7UPQAwvPBjt5mjUwLZrsUTuZIimzYXGbOCxaAEknz38qAf3NyR3Cv0dM9QoGdWw7iODr_f0P93OO49B_4_cOp_3JsaE_g-htFiAXkBYypXQV-OLSMiLut4tkFjNGfNWkMdWAqk15iGuw2QGs3ih1jhUET5guoIkVlEH_QdDdhEaM4LFjGW600NppaIzve67nPNaYGP0EqnYK-IBYaQkbt92iqs87TCPjHBJNpCs-DN5rUttgYy0ecett2SNAVQUIdpEWkq2KqZ7IJeQHzEHPbCTl48JiPQZ_hsLhU0Q-lz3V98CstYRfeuLqqwEEXrOPcp-MYfAKTkfEQeaZcWp_kG6X3VmL289DyPA4xllWueFAG96Q_kO28uZIepmgLlKPfoFBtl93zc0NVcaPF2KnlFvl_bHN3CownHml_q0k4b2sIhfszKDPS39m95oi_xYNIjyBtVSeX8lZU76I3eQAy5unwHWvE4TEhjDTGA5Yo1g_JSaF5cZJcWCK2xAaTOzFmW19bogtTFWgWSkdchfyq3eboYfMND5trHjYHS23IaJpkYfOG_YDN4G7DXD762l725LjsIMPedAB3gCpTMgK_JRrGOrP02Eku_lqzO8wEDCr-gJgAgC2duYZAW6fOMndlqAYFqyLVY0CMWNYqF5avdp1W-WBjvesUbVBAeEK2rDq5Vw55Sp4tCjr0wsdW4l4Rc1EqhPbxFLQt07idsEENcefL0aQx6tUXyQGwDLbhuQV9EA8ATMlv6YqDcSnWOziJvrgWcgcihznLj9rxDDwIsdRSLFRY1rLAaUX4lvxXYoN7A8K_hfb7bo6OwR2es_hhg5-xgDjuOriYdDKgbYl7q4KG_J6gD1rm5PHnvNcz3AbctrPzRop097PVJFtOlrLvlS9p9aF7sPnlkLy7Dj8MklYhqU7vyy5PMR-tuu_Xtlz9lGycLvrFarqYTxfTzWyyWGyWk3S5kbPlbCOz2Ti9mWSLTb-UGyrdKijWRNM-Klgm7-yhr1bJKElG42ScQIXOFsPxdDnOR_k4H48Xo8V4DiFIOxRwyH4Mjd327Sq4tKm3DjdLBSYfbzJettDUq5j8vqyRebvaf7ZYZ_b9cPYq-P4XJCvPrA">