[PATCH v2] Fix for powerpc64 long double complex divide failure

[Segher Boessenkool]

Hi!

On Thu, Jul 29, 2021 at 05:11:49PM +0000, Patrick McGehearty wrote:
> The MAX and MIN values have only modest changes since the exponent
> field for IBM 128-bit floating point values is the same size as
> the exponent field for IBM 64-bit floating point values.

This is misleading / wrong / not enough of the story to mean much, as I
explained before.  "The maximum and minimum values are about the same as
for double precision" is more correct, and more direct as well :-)

> However
> the EPSILON field is considerably different. Due to how small
> values can be represented in the lower 64 bits of the IBM 128-bit
> floating point,

... "while the high 64 bits are a not-so-small number".  Yes.

> EPSILON is extremely small, so far beyond the
> desired value that inversion of the value overflows and even
> without the overflow, the RMAX2 is so small as to eliminate
> most usage of the test.

Right.

> Instead of just replacing the use of KF_EPSILON with DF_ESPILON, we

(typo, s/SP/PS/)

> replace all uses of KF_* with DF_*. Since the exponent fields are
> essentially the same, we gain the positive benefits from the new
> formula while avoiding all under/overflow issues in the #defines.
> 
> The change has been tested on gcc135.fsffrance.org and gains the
> expected improvements in accuracy for long double complex divide.

> libgcc/
> 	PR target/101104
> 	* config/rs6000/_divkc3.c (RBIG, RMIN, RMIN2, RMINSCAL, RMAX2):
> 	Fix long double complex divide for native IBM 128-bit.

"Use more correct values."?

Okay for trunk.  Thank you!


Segher