Mail Archives: djgpp-workers/2000/03/16/11:45:33
On Thu, 16 Mar 2000, Hans-Bernhard Broeker wrote:
> So the only test that would work to check if a given number is an
> unnormal, rather than a signalling NaN would have to operate outside the
> FPU, by checking bit patterns directly:
>
> if (MSB(mantissa)==0) {
> if (exponent == max_exponent)
> it's a signalling NaN /* nan, to C99 nomenclature */
> else if (exponent == min_exponent)
> it's a denormal /* subnormal, to C99 */
> else
> it's an unnormal /* undefined in C99 */
> }
This is what the internal function `isspeciall' does as part of doprnt.c
(the change for unnormals was introduced in preparation for v2.03).
> Thus, it's our choice what behaviour signalling NaNs and unnormals
> should cause. Not only in printf(), but everywhere. I see two
> possibilities, roughly:
>
> 1) provide a default SIGFPE handler for the 'inavlid operation' excetion
> that reads the offending FPU register and 'repairs' it. It would convert a
> signalling NaN to a quiet NaN, and an unnormal to a normal (or denormal,
> where necessary), respectively. This might be a slow method, but it should
> be possible.
>
> 2) define signalling NaNs and unnormals to belong to class 'nan' of the C
> standard. AFAICS, this should fix everything quite nicely.
We already kinda took the first alternative: we mask all numerical
exceptions at startup. This causes unnormals to produce a NaN, which is
then dragged on through the entire computation, usually yielding a NaN in
the end. So we don't need to worry about unnormals in the absolute
majority of cases.
`printf' is special because it must specifically test for the NaN as a
bit pattern, to produce the appropriate string required by the standard.
Since the existing code tested for the special numbers up front, and
then did all the rest under an assumption that the argument is finite, an
unnormal would fail it in the way I described. I could, of course, force
_doprnt to perform some FP operation on the argument, which would convert
it to NaN. However, given the complexity of _doprnt and v2.03 being a
bug-fix release, I opted for a safer solution. IMHO, the different
string printed helps to spot these cases, which _must_ be bugs. So this
solution also has a bonus.
> So the current behaviour would also be allowed by the standard. Just let
> such programs get what they asked for: a crash of the program by SIGFPE.
I'm not sure it's a good idea to enable FP exceptions. They make ANSI
compliance in math functions next to impossible, since AFAIK the standard
explicitly forbids math functions to crash the program. I think our move
to mask all FP exceptions in v2.02 and later was in the right direction.
- Raw text -