instead (dot-asm:
So that both assembly modules export SHA3_absorb_vsx... Either way,
it makes lesser sense to deploy vector keccak1600p8-ppc.pl, because
benefits are not that clear. It's only nominally faster than scalar
module on POWER8 but significantly slower on POWER9. Because POWER9
is better equipped to handle non-vector code. On related note,
there is version optimized for little-endian, as well as 32-bit
version. [And since MIPS was mentioned, there is even MIPS module...]
a softint from the network stack.
Don't recurse through scsipi_command() when we have multiple packets
in the send queue - use a loop instead. This means that we no longer
need sestart(), as we can now handle everything in sedone().
Fix a couple of XXX's.
Rework the locking logic slightly from the previous revision.
Now this works with DIAGNOSTIC+LOCKDEBUG.
division by zero is not correctly trapped for i386 and amd64:
https://bugs.launchpad.net/qemu/+bug/1668041
Make trigger_fpe() cause integer division by zero for x86, and
floating-point one for other architectures. Also, assertions for
si_code in *_crash_fpe tests are commented out for now. They
should be cleaned up after the bug is fixed.
Now, *_crash_fpe tests are working also on powerpc.
Suggested by kamil.
- Respect destination directory specified by -d option.
- Accept check and fix options. For the former, do not modify anything as
users normally expect.
http://mail-index.netbsd.org/source-changes-d/2020/06/21/msg012745.html
- Revive __lwp_settcb(), and call _lwp_setprivate(2) from it.
- Keep l_private opaque pointer for kernel; store raw value of %r2 in it.
In the previous commit message, I wrote,
http://mail-index.netbsd.org/source-changes/2020/06/21/msg118524.html
> - Make sure that, like other ports, l_private represents address of tcb,
> not biased one as in %r2.
but, it turned out to be wrong. mips stores a biased address, at least.
It is userland responsibility to interpret returned values from
lwp_getprivate(2).
until QEMU bug #1668041 is fixed:
https://bugs.launchpad.net/qemu/+bug/1668041
by which floating-point division by zero is not trapped correctly
both on amd64 and i386.
Skip *_crash_fpe tests on powerpc, where integer division by zero
is never trapped.
Revert my recent 1.85 revision that fixed "make tags". It causes too
much build breakage elsewhere in the tree that needs to be resolved first.
Issues include:
- Directories using TESTS_CXX with .cpp and .cxx extension instead of the
default .cc extension (see bsd.prog.mk). Most of these have been fixed.
- external/gpl3/gcc build of .cc files. (No idea what's wrong there).
Disable events on entry to be safe.
It should have been mostly safe for most cases, but for FPU traps
we need to reload the FPU state if we got interrupted at trap entry.
Hopefully fixes:
panic: kernel diagnostic assertion "curlwp->l_md.md_flags & MDL_FPU_IN_CPU" failed: file "/home/source/ab/HEAD/src/sys/arch/x86/x86/fpu.c", line 524
when running tests.
Otherwise the ABSENT_NUMERIC(-1) or CANCELLED_NUMERIC(-2) will be converted
incorrectly to size_t and then down to uint16/32_t.
Picked up by DIAGNOSTIC builds.
Thanks to Michael Forney for the fix for PR lib/52293.
