diff options
| author | Aldy Hernandez <aldyh@redhat.com> | 2023-02-03 17:28:52 +0100 |
|---|---|---|
| committer | Aldy Hernandez <aldyh@redhat.com> | 2023-02-03 21:30:28 +0100 |
| commit | 10bd26d6efe88a8cf03a6a325351bc470a910cab (patch) | |
| tree | 04af29d9c439c3ac55ade0cb0d5f95862509ca40 /libgcc | |
| parent | 093e2e1b201c0f324e0d8bfe6487aa2d470a13e7 (diff) | |
| download | gcc-10bd26d6efe88a8cf03a6a325351bc470a910cab.zip gcc-10bd26d6efe88a8cf03a6a325351bc470a910cab.tar.gz gcc-10bd26d6efe88a8cf03a6a325351bc470a910cab.tar.bz2 | |
range-ops: Handle undefined ranges in frange op[12]_range [PR108647]
This patch gracefully handles undefined operand ranges for the floating
point op[12]_range operators. This is very low risk, as we would have
ICEd otherwise.
We don't have a testcase that ICEs for floating point ranges, but it's
only a matter of time. Besides, this dovetails nicely with the integer
versions Jakub is testing.
gcc/ChangeLog:
PR tree-optimization/108647
* range-op-float.cc (foperator_lt::op1_range): Handle undefined ranges.
(foperator_lt::op2_range): Same.
(foperator_le::op1_range): Same.
(foperator_le::op2_range): Same.
(foperator_gt::op1_range): Same.
(foperator_gt::op2_range): Same.
(foperator_ge::op1_range): Same.
(foperator_ge::op2_range): Same.
(foperator_unordered_lt::op1_range): Same.
(foperator_unordered_lt::op2_range): Same.
(foperator_unordered_le::op1_range): Same.
(foperator_unordered_le::op2_range): Same.
(foperator_unordered_gt::op1_range): Same.
(foperator_unordered_gt::op2_range): Same.
(foperator_unordered_ge::op1_range): Same.
(foperator_unordered_ge::op2_range): Same.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions