[PATCH] D128261: [Fortran] Relax relative tolerance for FCVS tests

Thu Jun 30 13:05:45 PDT 2022

Meinersbur added a comment.

In D128261#3622945 <https://reviews.llvm.org/D128261#3622945>, @klausler wrote:

> See above.  f18's runtime will emit a minimal representation that reads back to the same bit representation (of the same real kind) when Fortran allows it to do so (viz., list-directed and NAMELIST output).
>
> The binary-to-decimal conversion algorithm in flang/lib/Decimal is not the whole story.  See the code in flang/runtime/edit-output.cpp to see how the Decimal library is driven for all of Fortran's various output editing modes.

Thanks for this pointing out. I don't pretend to know how it works, but having also looked into the state of the art reference implementation Ryu <https://github.com/ulfjack/ryu>, I expected it to require more code.

>> - fpcmp was not written with whether two string representations parse to the same IEEE bit pattern in mind. Only to account for the general fuzziness that comes with floating point processing, including effects through `-ffast-math`, transcendental functions that only compute approximations, during string formatting, etc.. Considering that single only has ~7.2 significant mantissa bits, a relative tolerance of 1.0e-11 effectively only allows exact matches.
>
> IEC599/IEEE754 32-bit single precision has 24 effective fractional bits, enough to accurately distinguish 7 decimal digits.

My mistake, I meant "~7.2 significant mantissa **decimal digits**" which matches your statement.

> The hard part is that you can't tell from the output whether the runtime was editing single-precision data (or half, double, extended, or quad precision), and if you relax tolerances to allow single precision to differ, you can miss errors in double.

My impression was that the tests don't require a specific decision, hence should not expect results to conform to more than the minimum precision. If we want to test higher precisions, these could be separate tests.

> FPCMP probably can't detect output formatting errors of quad-precision data as it is.

Correct. However, fpcmp was not intended for IEEE-conformance tests, but for "not obviously wrong" tests. It started when SPEC CPU was integrated and an equivalent for spec's `specdiff` was needed (which is a Perl script also using double precision).

Repository:
  rT test-suite

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128261/new/

https://reviews.llvm.org/D128261