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
