Figure out behavior of powf/powi(sNaN, 0)

[RalfJung]

The C standard annex F.10 says that the result of x^0 = 1 for all x, even a NaN. For pown it explicitly calls out "for all x not a signalling NaN" (and doesn't say what happens on a signalling NaN); for powf it just says "any x, even a NaN" -- it is unclear whether that is an intentional difference or not since C generally leaves everything about the behavior of signalling NaNs unspecified. I am not sure what the IEEE spec says. This is a somewhat odd case as usually in C, operations behave the same for qNaN and sNaN, but some widely-used libc implementations return a qNaN for sNan^0 but return 1 for qNan^0 (the latter part being required by the standard), therefore clearly distinguishing qNaN and sNaN.

The "easiest" choice for us is to say that our functions return either 1 or a NaN non-deterministically, and if they do return a NaN the usual NaN propagation rules apply -- since one input is an sNaN, the payload if the returned NaN is completely arbitrary (in particular, it can be a qNaN or an sNaN). glibc and musl seem to disagree on the result here (see https://rust.godbolt.org/z/chsbv5v4d), so requiring more consistent behavior would involve convincing one of them that they are wrong.

@tgross35 does that sound reasonable? Should https://doc.rust-lang.org/nightly/std/primitive.f32.html#method.powf talk and friends about this case or is that not worth it?

[tgross35]

The "easiest" choice for us is to say that our functions return either 1 or a NaN non-deterministically, and if they do return a NaN the usual NaN propagation rules apply -- since one input is an sNaN, the payload if the returned NaN is completely arbitrary (in particular, it can be a qNaN or an sNaN).

Agreed that this is probably the best we can do here for now. If we want more deterministic behavior, the best thing to do would probably be to quiet sNaNs ourselves in this and any other functions where behavior seems to vary - though needing to pay for this would be a bit unfortunate.

Cc rust-lang/rust#138062 (comment) where there was a bit more discussion. Asking on the glibc mailing list would probably still be a good idea (@LorrensP-2158466 you didn't happen to reach out already did you?)

[LorrensP-2158466]

I have not, sorry. It's hectic at school at the moment. I'll try this weekend if that's okey.

[tgross35]

I have not, sorry. It's hectic at school at the moment. I'll try this weekend if that's okey.

This is open source, there are no deadlines and school is important :) reach out whenever you get the chance, or I'll write something up if you don't get to it.

[LorrensP-2158466]

Yeah :) I forget that sometimes. I'll keep u guys updated!