On Wed, 10 Jun 2020, Patrick McGehearty wrote: > I see your point about other floating point formats. > According to the C standard, DOUBLE precision must > have a DBL_MAX of at least 1E+37. That is (slightly) > greater than 0x1.0p+63. > > Would > #define RMIN2 (0x1.0p-53) > #define RMINSCAL (0x1.0p+51) > be acceptable? > Those will be in range for any architecture that supports the C standard.
But this code is used for different machine modes, not just double. In particular, on Arm / AArch64 it may be used to build __divhc3. And those constants are certainly outside the range of HFmode (IEEE binary16). I think you need to work out appropriate logic for what values are correct for a given machine mode, in terms of the parameters of that mode (maximum and minimum exponents etc.). Then, if you can't represent the logic for determining those values (with the correct type, not hardcoding the absence of a suffix which would mean double) directly in C, see how c-cppbuiltin.c predefines extra macros if -fbuilding-libgcc (macros relating to built-in function suffixes and the number of bits in the mantissa of a floating-point mode are included there - it would certainly make sense to add more such macros if necessary). -- Joseph S. Myers jos...@codesourcery.com
