Oops, forgot to fix up Maciej's email address... On 5 February 2015 at 16:37, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 9 December 2014 at 01:54, Maciej W. Rozycki <ma...@codesourcery.com> wrote: >> Fix sNaN handling in floating-point format conversion operations, that >> are classified by the IEEE 754-2008 standard as general-computational >> operations [1]:
>> This is in particular how MIPS hardware operates, other processors >> supposedly do the same if they claim compliance to IEEE 754. > > ARM currently handles this issue by calling the _maybe_silence_nan() > function in all target-specific helper functions that call > float-to-float conversion functions (but that has its own > issues, see below). > > Have you looked at the other architectures that use these > functions to convert float values to see what their NaN > handling semantics are? I agree about what the spec says, > but we may well have targets which are not fully IEEE > compliant and rely on the current semantics (x86 springs to > mind). > > Also in this area, ARM has a problem where we don't give the > correct answers for fp-to-fp conversions from a higher precision > to a lower precision where the input is a signaling NaN whose > non-zero mantissa bits are all at the low end such that the > truncation of the mantissa into the lower precision format > would drop them all. The result is the wrong value of quiet NaN > (we return the default NaN, which has the sign bit clear, but the > FPConvertNaN pseudocode specifies that we should effectively get > the default NaN but with the same sign bit as the input SNaN). > > I think this means that: > (1) we want to put handling of silencing the signaling NaNs > into the NaN conversion functions themselves (since it's > too late to do it correctly once the commonNaNtoFloat16 > function has thrown away data) > (2) that handling needs to be target specific, as most details > of quiet vs signaling NaNs are > > I note in passing that the float*ToCommonNaN and commonNaNToFloat* > functions are used only in the back-to-back call sequence of > return commonNaNToFloatX(floatYToCommonNaN(...)) > for handling the NaN inputs on FP-to-FP conversion. > > thanks > -- PMM
