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

    <tr>
        <th>Summary</th>
        <td>
            ubsan vs. _BitInt
        </td>
    </tr>

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

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

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

<pre>
    Consider
```c
_BitInt(15) foo (_BitInt(15) x, _BitInt(15) y) { return x + y; }
_BitInt(115) bar (_BitInt(115) x, _BitInt(115) y) { return x + y; }
_BitInt(385) baz (_BitInt(385) x, _BitInt(385) y) { return x + y; }
int
main ()
{
 volatile _BitInt(15) a = foo (16383wb, 1wb);
  volatile _BitInt(115) b = bar (20769187434139310514121985316880383wb, 1wb);
  volatile _BitInt(385) c = baz (39402006196394479212279040100143613805079739270465446667948293404245721771497210611414266254884915640806627990306815wb, 1wb);
}
```
with -fsanitize=undefined.
At least on godbolt with clang trunk I'm getting
/app/example.c:1:59: runtime error: signed integer overflow: 16383 + 1 cannot be represented in type '_BitInt(15)'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.c:1:59 in 
/app/example.c:2:62: runtime error: signed integer overflow: 0x0003ffffffffffffffffffffffffffff + 1 cannot be represented in type '_BitInt(115)'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.c:2:62 in 
UndefinedBehaviorSanitizer: CHECK failed: ubsan_value.cpp:86 "((0 && "unexpected bit width")) != (0)" (0x0, 0x0) (tid=1)
The ubsan_value.{h,cpp} representation I guess is fine for very small _BitInt, the ones which fit into ValueHandle, the compiler
can/will sign/zero extend the values to ValueHandle bits.  For slightly larger _BitInt (33 to 64 on 32-bit arches, 65 to 128 on 64-bit arches), I guess the compiler could sign/zero extend it in memory, but anything larger will simply not be handled by the library.
I wonder if we shouldn't add Tk_BitInt = 0x0002 and have TypeInfo in that case be the _BitInt precision rather than ceil log2 of it,
though that field is just 16-bit and I think LLVM currently supports even larger _BitInt.

I guess for now I'll add GCC -fsanitize=undefined support just for what can be encoded in the current scheme, but it would be really nice to have libubsan support even for larger _BitInts.

@AaronBallman
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy0Vl9v47gR_zT0yyAGRVKU9OAH_6l7QW9fensH9OlASWOLG5oUSMqO99MXpORsk9suegc0CCKZ5MzvzwzHUSHos0XckHJHysNKTXFwfvNFvUztFzTa4suqdf19s3c26B49oQdCt0TS-bebP_--0_HZRsLqoiSsgZNzQFj9cfmVsD18XLynP6Tagcc4eQuvQNgO7oTvgFSHP-Sfg1rlPwB8H-GvQPB6gfj6HmJZ_wCxrP4vENrG-eWitE25CWsWP6vd_AJXZ1TUBv9gkwLCDw9jC8lrfmsTkyI9GsIfCb6bYTEtp1isY7SSTVFXgouCN7ygZSEKVjR1yQtZ1_RPASwmdAtANo43gjJKZdFI3ghRNaxgrGqooAWlheCy4DUtadVUvGEVFbIUQkpZNaJmDRdUMFFWrKiqQjQVK6gsClEIJiUrRV2LpiiloDWVklVNQzmVdVF-l_Gb_29dO3-86TjA0ykoq6P-ioQfJtvjSVvs1_OJbQSDKkRwFs6ub52JkKM6o-wZop_sCzwTVl3gjDFqe16A2FGNI2FHfFWX0eC6I3xbEL4tG8K34Ccb9QUBvXc-LeQ72IO2Ec_owV3Rn4y7pa1c6dxLBXTKWhehRfA4egxoY46CeB8RCKs-9Axh1cznl18_fdr-818p368PiTsc1FU7_8siPxN5M-CpXbbhB1oS9A8EM8K3kv1ZwfSVUspPP_j5C278n-2YlX6z48dZ9z_9bf8POCltsM8obVD296syE667cSR8W0sgjOUBUVMgTBKWVyaLryN2SWerUyv2ccgHmzx9WJGuX4rJKyy_vtJ0JfIjHamj7gk_FG-j5_OA7xiQajcQtk9EqsM3a1XUzsIznCcMAXSApA9OzsMV_R3CRRnzbSDsIQ4IzmKA26C7AU46pmo7-C2B_KRsb_BxrHOXUZvHV0unLGHHmzYmdwlhx6_oHeBrRNvn85lngPfJkiFhDXB0HoLR5yGaOxjlU3sttPJQ4ilOinSjOXtKLirfDRgSGVmmzYLVaVeKd7tNOvCQ_5-soXOT6b_HNUuGC16cv6fodoqg7D0O2p4f1Badl9HcYenmIevpob1nHKNbr_x9mUjPcHO2Rw_6BDeEMCRwS1gVQfU9fH5508oP81VioGwPg7oifL6P-GxPLl-SQUXoVMAEmXAegaPHTodUbK_igD6dtNChNmDcmYE7gU4VnvnEwU3nYc520mj61BpfphChkLN_todnSJpf4Oeff_sE3eQ92lSdMI2j8zEAXtF-qNUi9yF6tj11m3W3PHGNyYL_vt__lxH-SD-zSaG3WbJNitF2rl_GRSrmTApCN-AFH8VKVywXN88YZVKNdIepSbKfRrf55rxBZSEJ6r2Y8E4NEXSrvLM7ZcxF2VW_4X3DG7XCTSEbyppaVnw1bPBUlXXdVqqRZYkCT62sOl52VcUlIlYrvWGUcVqxsiiZ4HytWl6yEjkXVAolSiIoXpQ2a2Oul7Xz55UOYcKNFAWlK6NaNCH_48eYxRvkzTROysPKb1LMUzudAxHU6BDDtyxRR4ObWfo1rB8yV5M3myHGMRCevhEIO551HKZ23bkLYccUvzyeRu--YBcJO2bUQNgxs_p3AAAA__9YjT5V">