https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Kewen Lin <li...@gcc.gnu.org>: https://gcc.gnu.org/g:fda8e2f8292a90dac9fcaf952bad6fff3aa7fff2 commit r14-6478-gfda8e2f8292a90dac9fcaf952bad6fff3aa7fff2 Author: Kewen Lin <li...@linux.ibm.com> Date: Tue Dec 12 20:39:34 2023 -0600 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-05a75e1fd...@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.
