On 13/09/16 13:43, Joseph Myers wrote:
On Tue, 13 Sep 2016, Tamar Christina wrote:
On 12/09/16 23:33, Joseph Myers wrote:
Why is this boolean false for ieee_quad_format, mips_quad_format and
ieee_half_format? They should meet your description (even if the x86 /
m68k "extended" formats don't because of the leading mantissa bit being
set for infinities).
Ah, I played it a bit too safe there. I will change this and do some
re-testing and update the patch.
It occurred to me that there might be an issue with your approach of
overlaying the floating-point value with a single integer, when the quad
formats are used on 32-bit systems where TImode isn't fully supported as a
scalar mode. However, if that's an issue the answer isn't to mark the
formats as non-IEEE, it's to support ORing together the relevant parts of
multiple words when determining whether the mantissa is nonzero (or some
equivalent logic).
I have been trying to reproduce this on the architectures I have access to
but have been unable to so far. In practice if this does happen though
isn't it
the fault of the system for advertising partial TImode support and
support of
IEEE types?
It seems to me that in order for me to be able to do this fpclassify
would incur
a rather large costs in complexity. Also wouldn't this be problematic
for other functions
as well such as expand_builtin_signbit?
