Skip to content

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

Open
@RalfJung

Description

@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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-shimsArea: This affects the external function shimsC-spec-questionCategory: it is unclear what the intended behavior of Miri for this case is

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions