Joseph,
Thank you again for your prompt and insightful response.
It's now clear that I was engaged in wishful thinking that I only needed
to handle double precision in my proposed change. I understand now that
the text above the routine:
- - - - -
#if defined(L_divhc3) || defined(L_divsc3) || defined(L_divdc3) \
|| defined(L_divxc3) || defined(L_divtc3)
- - - - -
implies the same code is to be built for
L_divhc3 half precision
L_divsc3 single precision
L_divdc3 double precision
L_divxc3 extended precision
L_divtc3 quad precision
I will need expand my test suites for these other floating point formats
and do my best to understand how the libgcc build mechanisms work before
I'm ready to resubmit.
At first glance, assuming only one of the L_div?c3 names are defined at
a time,
it seems like something like:
#ifdef L_divhc3
#define RBIG (correct value for half precision)
#define RMIN (correct value for half precision)
#define RMIN2 ... (correct value for half precision)
#define RMINSCAL ... (correct value for half precision)
#endif
#ifdef L_divsc3
#define RBIG FLT_MAX
#define RMIN FLT_MIN
#define RMIN2 ...
#define RMINSCAL ...
#endif
...
would get the job done once I determine (and test) the correct
values for all formats.
- Patrick McGehearty
On 6/9/2020 6:11 PM, Joseph Myers wrote:
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).
