https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC| |linkw at gcc dot gnu.org,
| |meissner at gcc dot gnu.org,
| |segher at gcc dot gnu.org
Last reconfirmed| |2023-12-01
--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
Confirmed.
A reduced test case:
long double a, b, c;
long double d() { return -__builtin_fmaf128_round_to_odd(c, b, a); }
c.0_1 = c;
b.1_2 = b;
a.2_3 = a;
_4 = __builtin_fmaf128_round_to_odd (c.0_1, b.1_2, a.2_3);
_6 = -_4;
return _6;
206├───> gcc_assert (m_operator->operand_check_p (type, lh.type (), rh.type
()));
stmt: _6 = -_4;
(gdb) pge lh.type()
_Float128
(gdb) pge rh.type()
long double
The root cause is the same to what's in PR107299, TYPE_PRECISION of rh.type is
127 while that of lh.type is 128, some attempts were tried to fix this
precision difference before but failed to, like:
https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd...@linux.ibm.com/.
ranger makes use of type precision directly instead of something like
types_compatible_p. I wonder if we can introduce a target hook (or hookpod) to
make ranger unrestrict this check a bit, the justification is that for float
type its precision information is encoded in its underlying real_format, if two
float types underlying modes are the same, the precision are actually the same.
btw, the operand_check_ps seems able to call range_compatible_p?
