[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20250521182049.GE288056@port70.net>
Date: Wed, 21 May 2025 20:20:49 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Lorrens Pantelis <lorrens.pantelis@...dent.uhasselt.be>
Cc: libc-help@...rceware.org, tmgross@...ch.edu, post@...fj.de,
musl@...ts.openwall.com
Subject: Re: Handling of Signaling NaN in pow functions
* Lorrens Pantelis <lorrens.pantelis@...dent.uhasselt.be> [2025-05-21 18:41:24 +0200]:
> Adding the author.
CC += musl
> Op wo 21 mei 2025 om 18:17 schreef Lorrens Pantelis
> <lorrens.pantelis@...dent.uhasselt.be>:
> >
> > Dear libc mailing list people,
> >
> > I’m currently working on simulating non-determinism in floating-point
> > operations within Rust’s Miri interpreter
> > (https://github.com/rust-lang/miri). Specifically, we simulate
> > imprecision by adding a 16 ULP relative error to the outputs of some
> > floating-point operations. However, for certain operations (e.g.,
> > involving fixed outputs), this is not applicable. While handling these
> > cases, we encountered interesting behavior with the `pow` function
> > between glibc and musl.
> >
> > The operation `pow(x, 0)` is defined differently between the IEEE 754
> > standard and the C standard:
> > - IEEE 754: `pow(x, 0) = 1` if `x` is not a sNaN.
> > - C standard: `pow(x, 0) = 1` for all `x`, including sNaNs.
> >
> > When testing the behavior of `pow(SNaN, 0)`:
> > - glibc returns a quieted NaN — this seems to align with IEEE 754, but
> > not strictly.
> > - musl returns `1`, matching the C standard.
> >
> > The discussion we had in the Rust community is linked here for reference:
> > https://github.com/rust-lang/rust/pull/138062#discussion_r2033840426
> >
> > We’re curious to understand the rationale behind glibc's choice. Is
> > there a guiding principle or policy you follow when handling sNaNs in
> > math functions?
for behaviour across libc implementations
https://www.openwall.com/lists/libc-coord/
maybe a better list.
i think in c99 "NaN" means quiet nan,
snan support was not required, can be treated as qnan,
even in annex f.
c23 still does not require snan support,
so you can probably find the nan === qnan
text in it, but it specifies the c functions
to ieee754 mappings, so in case one interested
in snan support, the semantics should be clear.
iirc glibc tried to support snan even before c99.
and the principle is to follow the latest ieee754
standard.
in musl snan is not supported, treated as qnan.
i think all qnans are treated equal (no care about
payload or sign).
fdlibm code sometimes tried to support snan with
code like
if(isnan(x)) return x+x;
where + is only there to handle snan, musl inherited
some such code, but it does not try to go out of its
way to have dedicated snan logic.
> >
> > Thank you for your time and insights!
> >
> > Best regards,
> > Lorrens Pantelis
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
