diff options
author | Jakub Jelinek <jakub@redhat.com> | 2024-04-18 09:45:14 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2024-04-18 09:45:14 +0200 |
commit | 6c152c9db3b5b9d43e12846fb7a44977c0b65fc2 (patch) | |
tree | b34bf7adaaec17cbe92764278ac6dc3ce511e667 /libgcc | |
parent | 6e62ede7aaccc6ebe027c8e00224f65e226072e9 (diff) | |
download | gcc-6c152c9db3b5b9d43e12846fb7a44977c0b65fc2.zip gcc-6c152c9db3b5b9d43e12846fb7a44977c0b65fc2.tar.gz gcc-6c152c9db3b5b9d43e12846fb7a44977c0b65fc2.tar.bz2 |
internal-fn: Temporarily disable flag_trapv during .{ADD,SUB,MUL}_OVERFLOW etc. expansion [PR114753]
__builtin_{add,sub,mul}_overflow{,_p} builtins are well defined
for all inputs even for -ftrapv, and the -fsanitize=signed-integer-overflow
ifns shouldn't abort in libgcc but emit the desired ubsan diagnostics
or abort depending on -fsanitize* setting regardless of -ftrapv.
The expansion of these internal functions uses expand_expr* in various
places (e.g. MULT_EXPR at least in 2 spots), so temporarily disabling
flag_trapv in all those spots would be hard.
The following patch disables it around the bodies of 3 functions
which can do the expand_expr calls.
If it was in the C++ FE, I'd use some RAII sentinel, but I don't think
we have one in the middle-end.
2024-04-18 Jakub Jelinek <jakub@redhat.com>
PR middle-end/114753
* internal-fn.cc (expand_mul_overflow): Save flag_trapv and
temporarily clear it for the duration of the function, then
restore previous value.
(expand_vector_ubsan_overflow): Likewise.
(expand_arith_overflow): Likewise.
* gcc.dg/pr114753.c: New test.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions