[parisc-linux] floating point exception error

[John David Anglin]

> This corresponds to the following instruction:
> 
>     15e0:       32 f6 0c 19     fcmp,dbl,<> fr23,fr22,
> 
> As you can see GCC has generated a trap-on-unordered comparison
> condition (<>) here.  The HP compiler generates the != condition
> instead.  However if I hex-edit the binary to change the condition:
> 
>     15e0:       32 f6 0c 1a     fcmp,dbl,!= fr23,fr22,

Under hpux 10.20, I find that both GCC and the HP compiler generate
the != predicate.  If you look at the `Y' predicates generated in pa.c
for floating point compares, I can't see how <> could be generated.
If it actually is generating <> for fcmp's under linux, this should
be looked at.

Compared to the i386 implementation, GCC provides only a basic floating
point compare implementation.  The CCFP and CCFPU modes are supposed to
be compare with and without exceptions, respectively.  However, it
doesn't appear that the form with exceptions is generated by GCC on the
PA even though the mode is specified as CCFP. Not sure how these two
modes are selected.

> Then I still get a trap!

The print out above indicates that log has returned a signaling NaN.
This should cause an exception in the fcmp instruction if the invalid
operation exception is enabled.  Under hpux on a 735, log returns a
quiet NaN (7ff4000000000000).

> Well, on reflection, I notice that the high 6 bits indicate an
> Unimplemented exception with opcode 0xC.  Yes, "Unimplemented", not
> "Invalid".  WTF!

The exception code seems to be 001001 (overflow & unimplemented?).  The
manual that I have doesn't specify what this code means.  I did see
a comment in the hpux floating point guide that when an invalid operation
occurs when invalid operation traps are disabled, then the system
substitutes a quiet NaN as the result of the operation.  Maybe HP is
using the unimplemented exception to do this.  This happens when an
implementation chooses not to execute an instruction.  Thus, I agree
with you that some sort of floating point completion code is going
to be needed in the kernel.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)