diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2023-12-21 11:14:55 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2023-12-21 11:16:02 +0100 |
| commit | 0e7f5039c52a020c3ed5f18a2b3ee1fb42b78f62 (patch) | |
| tree | c380f7ddfba0158255f7f84b5b1eb38686ee24e1 /gcc/tree-vect-loop-manip.cc | |
| parent | 3d1bdbf64c2ed5be70fbff687b2927e328297b81 (diff) | |
| download | gcc-0e7f5039c52a020c3ed5f18a2b3ee1fb42b78f62.zip gcc-0e7f5039c52a020c3ed5f18a2b3ee1fb42b78f62.tar.gz gcc-0e7f5039c52a020c3ed5f18a2b3ee1fb42b78f62.tar.bz2 | |
ubsan: Add workaround for missing bitint libubsan support for shifts [PR113092]
libubsan still doesn't support bitints, so ubsan contains a workaround and
emits value 0 and TK_Unknown kind for those. If shift second operand has
the large/huge _BitInt type, this results in internal errors in libubsan
though, so the following patch provides a temporary workaround for that
- in the rare case where the last operand has _BitInt type wider than
__int128 (or long long on 32-bit arches), it will pretend the shift count
has that type saturated to its range. IMHO better than crashing in
the library. If the value fits into the __int128 (or long long) range,
it will be printed correctly (just print that it has __int128/long long
type rather than say _BitInt(255)), if it doesn't, user will at least
know that it is a very large negative or very large positive value.
2023-12-21 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/113092
* c-ubsan.cc (ubsan_instrument_shift): Workaround for missing
ubsan _BitInt support for the shift count.
* gcc.dg/ubsan/bitint-4.c: New test.
Diffstat (limited to 'gcc/tree-vect-loop-manip.cc')
0 files changed, 0 insertions, 0 deletions