]> git.ipfire.org Git - thirdparty/gcc.git/commit
range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755]
authorJakub Jelinek <jakub@redhat.com>
Wed, 26 Jul 2023 08:50:50 +0000 (10:50 +0200)
committerJakub Jelinek <jakub@redhat.com>
Wed, 26 Jul 2023 08:50:50 +0000 (10:50 +0200)
commit21da32d995c8b574c929ec420cd3b0fcfe6fa4fe
treece7b84ed1a95848d9f0b00993d7dd11522b0e9e2
parent96a839233ced3a0bfc3d5492a6d8b102e6981472
range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755]

IEEE754 says that x + (-x) and x - x result in +0 in all rounding modes
but rounding towards negative infinity, in which case the result is -0
for all finite x.  x + x and x - (-x) if it is zero retain sign of x.
Now, range_arithmetic implements the normal rounds to even rounding,
and as the addition or subtraction in those cases is exact, we don't do any
further rounding etc. and e.g. on the testcase below distilled from glibc
compute a range [+0, +INF], which is fine for -fno-rounding-math or
if we'd have a guarantee that those statements aren't executed with rounding
towards negative infinity.

I believe it is only +- which has this problematic behavior and I think
it is best to deal with it in frange_arithmetic; if we know -frounding-math
is on, it is x + (-x) or x - x and we are asked to round to negative
infinity (i.e. want low bound rather than high bound), change +0 result to
-0.

2023-07-26  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/110755
* range-op-float.cc (frange_arithmetic): Change +0 result to -0
for PLUS_EXPR or MINUS_EXPR if -frounding-math, inf is negative and
it is exact op1 + (-op1) or op1 - op1.

* gcc.dg/pr110755.c: New test.
gcc/range-op-float.cc
gcc/testsuite/gcc.dg/pr110755.c [new file with mode: 0644]