[parisc-linux] glibc 2.3.1 - It's alive! - patches

[Jim Hull]

John David Anglin wrote:

> 2) A fcpy insn should raise an exception if it depends on the
>    result of a pending trapping insn (the current code doesn't).
>    It would be best to not use register 0 or the source register
>    for the destination register since in theory the processor
>    would then know the operation is a nop.  Then, the insn could
>    be reordered or discarded.  The fcpy insn is nice since it
>    is non-arithmetic and doesn't cause an invalid operation
>    exception when a NaN is copied.  The fcmp insn isn't quite
>    as nice since it will generate an invalid operation when one
>    of the values is a signaling NaN, or if the low-order bit
>    of the condition code is 1 and one of the values is an NaN.

This isn't right.  According to "Delayed Trapping" on p. 10-5 of the
PA-RISC 2.0 book, an fcpy need not raise a pending exception, because it
is not mentioned in the "delayed trap must occur" list.

Now, it's possible that it might (usually) work on the processor
implementations you're interested in, but it's not architecturally
guaranteed.

 -- Jim
    HP PA-RISC (and IPF) Processor Architect