https://gcc.gnu.org/g:fa86f510f51e6d940a28ea997fca3a6e3f50b4d3
commit r15-2086-gfa86f510f51e6d940a28ea997fca3a6e3f50b4d3
Author: Kewen Lin <li...@linux.ibm.com>
Date: Wed Jul 17 00:17:42 2024 -0500
ranger: Revert the workaround introduced in PR112788 [PR112993]
This reverts commit r14-6478-gfda8e2f8292a90 "range:
Workaround different type precision between _Float128 and
long double [PR112788]" as the fixes for PR112993 make
all 128 bits scalar floating point have the same 128 bit
precision, this workaround isn't needed any more.
PR target/112993
gcc/ChangeLog:
* value-range.h (range_compatible_p): Remove the workaround on
different type precision between _Float128 and long double.
Diff:
---
gcc/value-range.h | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 334ea1bc338c..03af758d152c 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -1764,13 +1764,7 @@ range_compatible_p (tree type1, tree type2)
// types_compatible_p requires conversion in both directions to be useless.
// GIMPLE only requires a cast one way in order to be compatible.
// Ranges really only need the sign and precision to be the same.
- return TYPE_SIGN (type1) == TYPE_SIGN (type2)
- && (TYPE_PRECISION (type1) == TYPE_PRECISION (type2)
- // FIXME: As PR112788 shows, for now on rs6000 _Float128 has
- // type precision 128 while long double has type precision 127
- // but both have the same mode so their precision is actually
- // the same, workaround it temporarily.
- || (SCALAR_FLOAT_TYPE_P (type1)
- && TYPE_MODE (type1) == TYPE_MODE (type2)));
+ return (TYPE_PRECISION (type1) == TYPE_PRECISION (type2)
+ && TYPE_SIGN (type1) == TYPE_SIGN (type2));
}
#endif // GCC_VALUE_RANGE_H
