Invalid NaN literal about wabt

[binji]

spec repo gives a clearer error (for nan:0x7ff8000000000000):

test6.wast:2.41-2.63: constant out of range: nan payload must not overlap with exponent bits

basically, nan:0x<hexdigits> should only be the nan tag of the float, not its entire bit pattern.

[jfbastien]

Hmm, that's a problem: it's unspecified by IEEE-754 what the NaN encoding means. Encoding the payload makes more sense honestly, but then how do we encode the sign?

We could just fix binaryen, but I'd like us to figure out how exactly.

When looking at parsing these it did occur that it would be convenient and clear in some contexts to be able to just specify the raw bits. Is there a good reason this is not allowed. For example, change nan:... to raw:... or bits:...

[jfbastien]

Hexadecimal floating-point is the way to go for this... except for NaNs.

[binji]

@jfbastien -nan:0xbeef works too. See https://github.com/WebAssembly/sexpr-wasm-prototype/blob/master/test/parse/expr/const.txt#L23.

[jfbastien]

Right, what I mean is that the hexadecimal floating-point specification handles all values precisely, but NaNs aren't a value and they're not handled by hexfloat.

A producer might not even want to mess with hexfloat, just reliably emit the raw bit, and could do so using the same method as for nan:... It would not seem to complicate the consumer, perhaps even avoid a few tests.

[jfbastien]

@JSStats discussed here: WebAssembly/design#292

[sunfishcode]

To address one specific detail here: IEEE 754 defines unary negation as a purely bitwise operation with behavior defined even on NaNs: it just sets the sign bit. Consequently, it's reasonably consistent to use -nan... for NaNs with the sign bit set.

[jfbastien]

@sunfishcode ooh cute! I like :)

[jfbastien]

See WebAssembly/binaryen#151

[jfbastien]

I'll call this bug fixed by the binaryen PR.