misc/59282: pmax testbed runs in flush-to-zero mode

[campbell+netbsd%mumble.net@localhost]

>Number:         59282
>Category:       misc
>Synopsis:       pmax testbed runs in flush-to-zero mode
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 12 17:40:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The PmaxFTZ Foundation
>Environment:
>Description:
*** Check failed: /tmp/build/2025.04.11.04.54.02-pmax/src/tests/lib/libc/gen/t_fpclassify.c:149: fpclassify(d1) != FP_SUBNORMAL: [1] fpclassify(0x0p+0)=4 FP_SUBNORMAL=3
*** Check failed: /tmp/build/2025.04.11.04.54.02-pmax/src/tests/lib/libc/gen/t_fpclassify.c:152: [1] d1=0x0p+0 d0=0x1p-1022
...

https://releng.netbsd.org/b5reports/pmax/2025/2025.04.11.04.54.02/test.html#lib_libc_gen_t_fpclassify_fpclassify_double

d1 at this point is the result of DBL_MIN/2, which should be subnormal (FP_SUBNORMAL=3), not zero (FP_ZERO=4).  So this machine appears to be running in flush-to-zero mode, or can't distinguish between subnormal and zero operands.
>How-To-Repeat:
cd /usr/tests/lib/libc/gen
atf-run t_fpclassify | atf-report
>Fix:
Yes, please!

Not sure if this is a qemu bug or a hardware bug or a NetBSD kernel bug in configuring the FPU.