diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2022-12-06 10:23:55 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2022-12-06 10:23:55 +0100 |
| commit | 0525a7fad2a5b1d933a9662c11aa074b38cfa3d5 (patch) | |
| tree | f3c1a4d33a99178060ac3e5e793608f6df62f0dc /gcc/c | |
| parent | 9f80367e539839fff1df2c85fc2640638199fc9e (diff) | |
| download | gcc-0525a7fad2a5b1d933a9662c11aa074b38cfa3d5.zip gcc-0525a7fad2a5b1d933a9662c11aa074b38cfa3d5.tar.gz gcc-0525a7fad2a5b1d933a9662c11aa074b38cfa3d5.tar.bz2 | |
range-op-float: Fix up ICE in lower_bound [PR107975]
According to https://gcc.gnu.org/pipermail/gcc-regression/2022-December/077258.html
my patch caused some ICEs, e.g. the following testcase ICEs.
The problem is that lower_bound and upper_bound methods on a france assert
that the range isn't VR_NAN or VR_UNDEFINED.
All the op1_range/op2_range methods already return early if lhs.undefined_p,
but the other cases (when lhs is VR_NAN or the other opN is VR_NAN or
VR_UNDEFINED) aren't. float_binary_op_range_finish will DTRT for those
cases already.
2022-12-06 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/107975
* range-op-float.cc (foperator_mult::op1_range,
foperator_div::op1_range, foperator_div::op2_range): Just
return float_binary_op_range_finish result if lhs is known
NAN, or the other operand is known NAN or UNDEFINED.
* gcc.dg/pr107975.c: New test.
Diffstat (limited to 'gcc/c')
0 files changed, 0 insertions, 0 deletions