nearbyint(double) on aarch64 vs. riscv
Joseph Myers
joseph@codesourcery.com
Tue Jul 21 20:26:02 GMT 2020
On Tue, 21 Jul 2020, Vineet Gupta via Libc-alpha wrote:
> On 7/20/20 12:52 PM, Joseph Myers wrote:
> > On Mon, 20 Jul 2020, Adhemerval Zanella via Libc-alpha wrote:
> >
> >> I am not sure exactly why the documentation does state that a floating-point
> >> exception can be generated by frinti.
> >
> > Because the "invalid" exception would be generated for signaling NaNs, and
> > the architecture-specific "input denormal" exception might also be
> > generated by the FPUnpack part of the operation.
>
> But even for these arcane cases, isn't nearbyint() expected to "hold" FP
> exceptions. It would be really easy to test/break this even with existing math tests.
math/test-nearbyint-except-2.c verifies that nearbyint works when traps on
"inexact" are enabled. The generic libm tests cover the case of default
exception handling, including for sNaN arguments. There are no
expectations that glibc does anything in particular with non-IEEE
exceptions such as "input denormal".
"hold" is not an IEEE concept. Floating-point exceptions are signaled,
which, with default exception handling, generally results in a flag being
raised and a default result returned. The requirements on nearbyint
relate to its observable behavior, which in standard C means the return
value and (standard) exception flags raised when it returns. The
requirements include that an sNaN argument results in a qNaN return value
with "invalid" raised, but that noninteger (finite) arguments do not
result in "inexact" raised. Whether the implementation just uses an
instruction with the relevant effect, or whether it has to save and
restore exception state internally, doesn't matter as long as the observed
behavior is as expcted.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list