aboutsummaryrefslogtreecommitdiff
path: root/gcc/range.h
diff options
context:
space:
mode:
authorAldy Hernandez <aldyh@redhat.com>2022-10-19 14:27:46 +0200
committerAldy Hernandez <aldyh@redhat.com>2022-10-19 16:00:48 +0200
commitd32969898e113e86e1c42b0c6f096f8228cbf1ff (patch)
treed400ccaa0e9fa8128b9d6a55ff147020c16ae26a /gcc/range.h
parentf036d759ecee538555fa8c6b11963e4033732463 (diff)
downloadgcc-d32969898e113e86e1c42b0c6f096f8228cbf1ff.zip
gcc-d32969898e113e86e1c42b0c6f096f8228cbf1ff.tar.gz
gcc-d32969898e113e86e1c42b0c6f096f8228cbf1ff.tar.bz2
[PR tree-optimization/107312] Make range_true_and_false work with 1-bit signed types.
range_true_and_false() returns a range of [0,1], which for a 1-bit signed integer gets passed to the irange setter as [0, -1]. These endpoints are out of order and cause an ICE. Through some dumb luck, the legacy code swaps out of order endpoints, because old VRP would sometimes pass endpoints reversed, depending on the setter to fix them. This swapping does not happen for non-legacy, hence the ICE. The right thing to do (apart from killing legacy and 1-bit signed integers ;-)), is to avoid passing out of order endpoints for 1-bit signed integers. For that matter, a range of [-1, 0] (signed) or [0, 1] (unsigned) is just varying. PR tree-optimization/107312 gcc/ChangeLog: * range.h (range_true_and_false): Special case 1-bit signed types. * value-range.cc (range_tests_misc): New test. gcc/testsuite/ChangeLog: * gcc.target/i386/pr107312.c: New test.
Diffstat (limited to 'gcc/range.h')
-rw-r--r--gcc/range.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/gcc/range.h b/gcc/range.h
index 8138d6f..ba3a6b2 100644
--- a/gcc/range.h
+++ b/gcc/range.h
@@ -50,6 +50,8 @@ static inline int_range<1>
range_true_and_false (tree type)
{
unsigned prec = TYPE_PRECISION (type);
+ if (prec == 1)
+ return int_range<2> (type);
return int_range<2> (type, wi::zero (prec), wi::one (prec));
}