Hi, Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639140.html BR, Kewen on 2023/12/4 17:49, Kewen.Lin wrote: > Hi, > > 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. > > Bootstrapped and regtested on powerpc64-linux-gnu P7/P8/P9 and > powerpc64le-linux-gnu P9/P10. > > Is it ok for trunk? > > [1] > https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd...@linux.ibm.com/ > > BR, > Kewen > ---- > 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. > --- > gcc/value-range.h | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/gcc/value-range.h b/gcc/value-range.h > index 33f204a7171..d0a84754a10 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 > -- > 2.42.0 >
