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

    <tr>
        <th>Summary</th>
        <td>
            UBSan output is incorrect for non power-of-2 sized _BitInt types
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            c23
      </td>
    </tr>

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

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

<pre>
    Consider this test case:
```
unsigned foo(unsigned _BitInt(44) x) {
 _BitInt(9) c = -2;
    return x >> c;
}

int main() {
  return foo(5) ? 1 : 0;    
}
```
As shown by https://godbolt.org/z/M614qnhco , the result when compiling and running this program (with ubsan) is weird:
```
/app/example.c:3:14: runtime error: shift exponent 510 is too large for 64-bit type 'unsigned _BitInt(44)'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /app/example.c:3:14 
```
The expected error here would be "shift exponent -2 is negative". But it is not only the detection of isNegative for the exponent that is wrong, it also reports an incorrect bitwidth (64-bit type) for the shifted value.

Afaict the problem is that the TypeDescriptor encoding (compiler-rt/lib/ubsan/ubsan_value.h) encodes the _BitInt types like ordinary integer types:
```
    /// An integer type. Lowest bit is 1 for a signed value, 0 for an unsigned
    /// value. Remaining bits are log_2(bit width). The value representation is
    /// the integer itself if it fits into a ValueHandle, and a pointer to the
 /// integer otherwise.
    TK_Integer = 0x0000,
```
But using log_2(bit width) does not work that well when having non-power-of-two bit widths.

One idea could be to introduce a new TK_BitInt kind, that encodes the bit wifth in some other way? Although I have no idea how big impact that has on the rest of the code.

This problem was found when running tests with the fix from https://github.com/llvm/llvm-project/pull/88004
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyUVdFv27gP_muUFyKBIztN8pCHdF3wG363O2DrDrinQrboWJsi-iS6bvbXHygn7Tp0BxwQJI5ofvxIfqRMSu4YEHdqdatWdzMzcEdxV3-lHmc12fPuHYXkLEbgziVgTAyNSajKvSruVLFXN8Xlk_8OIQNaaImU3jz_fbh1_CGw0puqUnoLT_Kl1reT1w_mrRgaUOUdzLUqry8AQEQeYoAnUOV7Vb6H5tmq1neXh_ztAsPJuKD05nWUK8TEbZWN5QGWoMo9FKq8lTA_Q77Ob58gdTQGqM_QMfdJCqEPSh-OZGvyvKB4VPrwXenDx5tl9XfoGgKl3wF3CBHT4BnGDgM0dOqdd-EIJliIQwjynKvcRzpGcwKlN6PjDoY6mSBsXYIRXbS_qr7SB9P3Sh_wyZx6j4tGlftSlftlJSnGIbA7IWCMFOUgda5lwKeeAgaG1bKQEEwE3sQjQksRbqp57Rj43CMovf5VR5VeTxw-f_n4cf_pL4H_Eiy2LqC9xc48OoqfTXDsvmMOPlyt8_pihn_hD28mfN-h0MeG0U5pQYcRYaTBW6iFsf4pybmWHAMeDbtHVFov4HZgcJyPiYGCP-duWWRs2FEAasGl3y8uuSo8BZ4guTPZe4wUjtJrx2B8IojYU-QEJoALDcWIDUPteHSWO2nvD8WV_l6RM2W08Gj8gIsftb1vjWs4v9RHqj2ecseEgJzdn3u8w9RE1zNFwNCQFVkpvZn0hnEeWemDd7XSh4uwpt-HKVonRLIjpox5aXQmmcC7bwgUrQsmnsEFxqMsB7H9SpV5qvKMKH2AfXjltYDfaJStUk8dWOYiGLioLHOSkhbTeYCrAN_CnjKATyjjL3nXTqofETwdH7TSG4mSq6_0dgEin-wjnYqYMLDJDXfpLXipxpW744S-BddKs1sJ4wITGPhT8P5ngvWZtwy3gZ7ELwKTgFywX4CvoMQdxtGla88l_P3_Hz5czLIUi6eiKAql371ZalHykCTztxIGSzhpfKT4bVLNiN5PC0lmMBwhUJj3NGKcUzvnkeAZIb1S4h8BwVk00FxnjUkSiWSHBsFAwFHIX9TzzQU7rUHDr-Q1wbfcgQuQ6IRTFWA0Z1nOe88dDccOPghBhEBT1I5GqN0R3Kk3zWUEO5OAwnXTsoytPEusV9TvL0s2j89oErQ0BDtV4XkRY-IEef0KRuueoI10-nnpO-6GetHQSWbKP15_5n2kr9jIpPWD90ofNpuiqGZ2V9ptuTUz3C3XS31TVStdzrpdvV22rbWrui1xe2PXRaVXVWONbexmWa7qmdvpQldFVWyLm3Kly8V6qTVWRVuUa1uXuFRVIar3Cwkvl9DMpTTgbrMptuXMmxp9yre81o0uldZy3cddJlsPx6SqwrvE6cWfHXvcfbn9bALQwP2Q5_Nlj8k8BgrwLBYNyX1_uRmmpTAbot_956Jl7mkq27b8JwAA__97McI_">