On Thu, 15 Dec 2016, Tamar Christina wrote: > > Note that on some systems we even disable 64bit floating point support. > > I suspect this check needs a little re-thinking as I don't think that > > checking for a specific UNITS_PER_WORD is correct, nor is checking the > > width of the type. I'm not offhand sure what the test should be, just > > that I think we need something better here. > > I think what I really wanted to test here is if there was an integer > mode available which has the exact width as the floating point one. So I > have replaced this with just a call to int_mode_for_mode. Which is > probably more correct.
I think an integer mode should always exist - even in the case of TFmode on 32-bit systems (32-bit sparc / s390, for example, use TFmode long double for GNU/Linux, and it's supported as _Float128 and __float128 on 32-bit x86). It just be not be usable for arithmetic or declaring variables of that type. I don't know whether TImode bitwise operations, such as generated by this fpclassify work, will get properly lowered to operations on supported narrower modes, but I hope so (clearly it's simpler if you can write things straightforwardly and have them cover this case of TFmode on 32-bit systems automatically through lowering elsewhere in the compiler, than if covering that case would require additional code - the more cases you cover, the more opportunity there is for glibc to use the built-in functions even with -fsignaling-nans). -- Joseph S. Myers jos...@codesourcery.com
