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 /gotools | |
| 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 'gotools')
0 files changed, 0 insertions, 0 deletions