aboutsummaryrefslogtreecommitdiff
path: root/libgcc
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2024-04-18 09:45:14 +0200
committerJakub Jelinek <jakub@redhat.com>2024-04-18 09:45:14 +0200
commit6c152c9db3b5b9d43e12846fb7a44977c0b65fc2 (patch)
treeb34bf7adaaec17cbe92764278ac6dc3ce511e667 /libgcc
parent6e62ede7aaccc6ebe027c8e00224f65e226072e9 (diff)
downloadgcc-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