tree 63ce5887d3fa34662c04a7ce7dc5e475b4e0c36a
parent 7727283e512e9ff0b014092a483560afbf7dddfe
author Jan Beulich <jbeulich@suse.com> 1628663788 +0200
committer Jan Beulich <jbeulich@suse.com> 1628663788 +0200

gas: support NaN flavors

Like for infinity, there isn't just a single NaN. The sign bit may be
of interest and, going beyond infinity, whether the value is quiet or
signalling may be even more relevant to be able to encode.

Note that an anomaly with x86'es double extended precision NaN values
gets taken care of at the same time: For all other formats a positive
value with all mantissa bits set was used, while here a negative value
with all non-significant mantissa bits clear was chose for an unknown
reason.

For m68k, since I don't know their X_PRECISION floating point value
layout, a warning gets issued if any of the new flavors was attempted
to be encoded that way. However likely it may be that, given that the
code lives in a source file supposedly implementing IEEE-compliant
formats, the bit patterns of the individual words match x86'es, I didn't
want to guess so. And my very, very old paper doc doesn't even mention
floating point formats other than single and double.