Tamar Christina wrote:
> 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
> for other functions as well such as expand_builtin_signbit?
Yes, if there are targets which don't implement TImode operations then surely
they should be automatically split into DImode operations before or during
GCC's implementation of types larger than the register int type is generally
poor as it is missing such an expansion (practically all compilers do this), so
would improve things significantly.
So for now it would seem best to keep the boolean false for quad formats on