aboutsummaryrefslogtreecommitdiff
path: root/gcc/function.h
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2023-03-17 16:10:14 +0100
committerJakub Jelinek <jakub@redhat.com>2023-03-17 16:10:14 +0100
commit103d423f6ce72ccb03d55b7b1dfa2dabd5854371 (patch)
treee522e6af56d03357381d2ff7deba0aca243521e7 /gcc/function.h
parent6bfb5eae96b65894da1301e966568fdf32bf64d0 (diff)
downloadgcc-103d423f6ce72ccb03d55b7b1dfa2dabd5854371.zip
gcc-103d423f6ce72ccb03d55b7b1dfa2dabd5854371.tar.gz
gcc-103d423f6ce72ccb03d55b7b1dfa2dabd5854371.tar.bz2
c, ubsan: Instrument even shortened divisions [PR109151]
On the following testcase, the C FE decides to shorten the division because it has a guarantee that INT_MIN / -1 division won't be encountered, the first operand is widened from narrower unsigned and/or the second operand is a constant other than all ones (in this case both are true). The problem is that the narrower type in this case is _Bool and ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE or REAL_TYPE. Strangely this doesn't happen in C++ FE. Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible, so I think we should be fine even with -fstrict-enums in C++ in case it shortened to ENUMERAL_TYPEs. The following patch just instruments those on the ubsan_instrument_division side. Perhaps only the first hunk and testcase might be needed because we shouldn't shorten if the other case could be triggered. 2023-03-17 Jakub Jelinek <jakub@redhat.com> PR c/109151 * c-ubsan.cc (ubsan_instrument_division): Handle all scalar integral types rather than just INTEGER_TYPE. * c-c++-common/ubsan/div-by-zero-8.c: New test.
Diffstat (limited to 'gcc/function.h')
0 files changed, 0 insertions, 0 deletions