On Thu, 11 Jun 2020, Patrick McGehearty wrote:
> I will study real.c carefully along with the C99 std
> to determine if I can find useful values for RMIN2 and RMINSCAL
> for each format which are within range for all instances
> of that format. A quick skim of real.c shows we have ieee half
I will study real.c carefully along with the C99 std
to determine if I can find useful values for RMIN2 and RMINSCAL
for each format which are within range for all instances
of that format. A quick skim of real.c shows we have ieee half precision
and two arm half precision formats, for example.
On Wed, 10 Jun 2020, Patrick McGehearty wrote:
> #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
>
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) ||
A follow up note relating to use of fused multiply add in complex divide:
While reviewing bugs relating to complex divide in libgcc, I
rediscovered bug 59714 - complex division is surprising on targets
with FMA.
The specific concern was when you divide (1.0 + 3.0i) by itself and
fused multiply
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
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
On Fri, 5 Jun 2020, Patrick McGehearty wrote:
> diff --git a/libgcc/libgcc2.c b/libgcc/libgcc2.c
> index e0a9fd7..2a1d3dc 100644
> --- a/libgcc/libgcc2.c
> +++ b/libgcc/libgcc2.c
> @@ -2036,26 +2036,77 @@ CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c,
> MTYPE d)
> CTYPE
>
The following patch to libgcc/libgcc2.c __divdc3 provides an
opportunity to gain important improvements to the quality of answers
for the default double precision complex divide routine when dealing
with very large or very small exponents.
The current code correctly implements Smith's method
