Further info:
netbsd panics in the kernel trap handler; unfortunately it does
not include the fsr in the panic message, but I expect it will be
the same as on Solaris.
linux raises SIGFPE in the application that caused the exception. Not surprising since we've seen before that linux is blissfully unaware of the floating point queue.
-- Carl
On 8/16/24 15:05, Richard Henderson
wrote:
On 8/17/24 07:46, Carl Hauser wrote:
OK, I think the problem is the handling of dc->fsr_qne in trans_STDFQ, lines 4583 and 4593 -- the code is evaluating dc->fsr_qne at translation time and not at runtime.
That's what patch 4 does, ensure that the runtime value is available at translation time.
r~
