diff options
| author | Kewen Lin <linkw@linux.ibm.com> | 2023-12-12 20:39:34 -0600 |
|---|---|---|
| committer | Kewen Lin <linkw@linux.ibm.com> | 2023-12-12 20:39:34 -0600 |
| commit | fda8e2f8292a90dac9fcaf952bad6fff3aa7fff2 (patch) | |
| tree | 7ff4270df6983ee70b827e620f34e908fc1ab570 /gcc | |
| parent | 1243a057beb53074c40805490b0e204e64000291 (diff) | |
| download | gcc-fda8e2f8292a90dac9fcaf952bad6fff3aa7fff2.zip gcc-fda8e2f8292a90dac9fcaf952bad6fff3aa7fff2.tar.gz gcc-fda8e2f8292a90dac9fcaf952bad6fff3aa7fff2.tar.bz2 | |
range: Workaround different type precision between _Float128 and long double [PR112788]
As PR112788 shows, on rs6000 with -mabi=ieeelongdouble type _Float128
has the different type precision (128) from that (127) of type long
double, but actually they has the same underlying mode, so they have
the same precision as the mode indicates the same real type format
ieee_quad_format.
It's not sensible to have such two types which have the same mode but
different type precisions, some fix attempt was posted at [1].
As the discussion there, there are some historical reasons and
practical issues. Considering we passed stage 1 and it also affected
the build as reported, this patch is trying to temporarily workaround
it. I thought to introduce a hookpod but that seems a bit overkill,
assuming scalar float type with the same mode should have the same
precision looks sensible.
[1] https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd5b4@linux.ibm.com/
PR tree-optimization/112788
gcc/ChangeLog:
* value-range.h (range_compatible_p): Workaround same type mode but
different type precision issue for rs6000 scalar float types
_Float128 and long double.
Diffstat (limited to 'gcc')
| -rw-r--r-- | gcc/value-range.h | 10 |
1 files changed, 8 insertions, 2 deletions
diff --git a/gcc/value-range.h b/gcc/value-range.h index 33f204a..d0a8475 100644 --- a/gcc/value-range.h +++ b/gcc/value-range.h @@ -1558,7 +1558,13 @@ 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_PRECISION (type1) == TYPE_PRECISION (type2) - && TYPE_SIGN (type1) == TYPE_SIGN (type2)); + 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))); } #endif // GCC_VALUE_RANGE_H |