aboutsummaryrefslogtreecommitdiff
path: root/gcc/ccmp.cc
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2023-11-29 12:26:50 +0100
committerJakub Jelinek <jakub@redhat.com>2023-11-29 12:26:50 +0100
commit5c95bf945c632925efba86dd5dceccdb9da8884c (patch)
tree26f49cc0ce608962c2e20b784eb962d08e679dbc /gcc/ccmp.cc
parentd65eb8a6bbeae7533dd41cb307b427f3f8585d9b (diff)
downloadgcc-5c95bf945c632925efba86dd5dceccdb9da8884c.zip
gcc-5c95bf945c632925efba86dd5dceccdb9da8884c.tar.gz
gcc-5c95bf945c632925efba86dd5dceccdb9da8884c.tar.bz2
fold-const: Fix up multiple_of_p [PR112733]
We ICE on the following testcase when wi::multiple_of_p is called on widest_int 1 and -128 with UNSIGNED. I still need to work on the actual wide-int.cc issue, the latest patch attached to the PR regressed bitint-{38,39}.c, so will need to debug that, but there is a clear bug on the fold-const.cc side as well - widest_int is a signed representation by definition, using UNSIGNED with it certainly doesn't match what was intended, because -128 as the second operand effectively means unsigned 131072 bit 0xfffff............ffff80 integer, not the signed char -128 that appeared in the source. In the INTEGER_CST case a few lines above this we already use case INTEGER_CST: if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom)) return false; return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom), SIGNED); so I think using SIGNED with widest_int is best there (compared to the other choices in the PR). 2023-11-29 Jakub Jelinek <jakub@redhat.com> PR middle-end/112733 * fold-const.cc (multiple_of_p): Pass SIGNED rather than UNSIGNED for wi::multiple_of_p on widest_int arguments. * gcc.dg/pr112733.c: New test.
Diffstat (limited to 'gcc/ccmp.cc')
0 files changed, 0 insertions, 0 deletions