On 06/26/2018 12:50 PM, G 3 wrote:
>
> If FPSCR[ZE] is set or not set, answer = 0x7ff0000000000000. This indicates to
> me that the fdiv instruction needs a little work. This is what I think should
> happen. If division by zero takes place and the FPSCR[ZE] bit is set, then
> the
> value in the destination register should not be altered (rather than returning
> zero).
I have not tested, but I suspect the same will be true for all other
floating-point exceptions.
E.g. try fmul of DBL_MAX * DBL_MAX with FPSCR[OE] set.
To my eye we would need to rearrange all of the fp operations:
(1) Remove helper_reset_fpstatus.
Every fp operation should leave 0 in the exception_flags.
Failure to do so indicates we're missing the post-operation
processing of exceptions via float_check_status. Which is
in fact exactly the bug here for fdiv. And based on a quick
browse, also fmul, fsub, and fadd.
(2) float_check_status should be re-organized.
(a) if status == 0, early exit,
(b) otherwise, set_float_exception_flags(&env->fp_status, 0) immediately.
(3) I suspect that all of the exception special cases can be
reordered such that we test them after the operation, as
they should all be unlikely.
A good example is target/tricore/fpu_helper.c, in which
we test the exception flags, do special cases when we
find e.g. float_flags_invalid set, and then process the
exceptions that were raised.
r~
