https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The MODE_COMPOSITE_P handling can be surely enabled for other modes too, I have
guarded it just because it slows compile time down a little bit and for usual
IEEE754 modes it should be always true, shouldn't it?
If i386/m68k XFmode is a problem too, we'd need some predicate how to find out
it is also problematic (the problem is the unnormals and other weird
representations in it, basically that not all bit patterns are valid).
native_decode_rtx has the same MODE_COMPOSITE_P handling:
rtx ret = native_decode_rtx (outermode, buffer, 0);
if (ret && MODE_COMPOSITE_P (outermode))
{
auto_vec<target_unit, 128> buffer2 (buffer_bytes);
if (!native_encode_rtx (outermode, ret, buffer2, 0, buffer_bytes))
return NULL_RTX;
for (unsigned int i = 0; i < buffer_bytes; ++i)
if (buffer[i] != buffer2[i])
return NULL_RTX;
}
so again, it could be enabled for all scalar floating modes or composite and
the XF-ish modes.
