Anyone relying on signaling NaNs?

[kinke via Digitalmars-d]

On Saturday, 1 October 2016 at 19:10:47 UTC, Martin Nowak wrote:
> Just tried to fix the float/double initialization w/ signaling 
> NaNs [¹], but it seems we can't reliably do that for all 
> backends/architectures. Any additional move of float might 
> convert SNaNs to QNaNs (quiet NaNs). This has also been the 
> finding of other people [²][³].
>
> The biggest problem w/ the current situation is that float 
> fields of a struct sometimes are initialized to QNaNs and fail 
> `s.field is float.init`.
>
> We thought about giving up on SNaNs as default float init 
> values. Is anyone relying on them?

I just had the same 'fun' with LDC. Both LDC 1.3 and DMD 2.074.0 
produce special quiet NaNs for float.init and double.init on 
Win64 (both most significant mantissa bits set). I also tried to 
fix it, but it seems impossible when the x87 FPU (and not SSE) is 
used. This leads to a Win64 LDC build using signalling inits when 
cross-compiling via `-m32`, while the native Win32 LDC compiler 
uses quiet ones etc.

So I'm all in for consistent special quiet NaNs as init values 
for all 3 floating-point types (already implemented, 
https://github.com/ldc-developers/ldc/pull/2207). If someone 
relies on signalling NaNs and missed the original post, here's 
your chance to speak up.