Revert "LangRef: Clarify llvm.minnum and llvm.maxnum about sNaN and signed zero (#112852)" (#168838)
This reverts commit 363b05944f9212511ee6811d0eb1af841c177226.
This is a follow up of #166912. Sorry for not noticing the change at the
beginning, but I disagree with both sNaN and signed zero semantics
change.
I have 3 justifications:
- llvm.minnum and llvm.maxnum are common intrinsics, we cannot change
the definition just because "some architectures" support the changed
semantic. For example, X86 min/max instructions neither distinguish sNaN
nor signed zero. We have to add couples of extra instructions to match
with the new definition, which makes the intrinsics less efficient. But
efficient is not the reason for the objection. I object because such
cost is unnecessary;
- As the example ``minnum(fadd(sNaN, -0.0), 1.0)`` shows, minnum/maxnum
themself cannot guarantee consistent result if multiple FP arithmetic
[10 lines not shown]
Fix constraints on _DistTuple columns. This makes the DistTuple entries
in sqlports complete. (Before only the last set was shown.)
From espie, instigated by a less correct diff from me. Also feedback
from sthen@ ("makes a lot of sense")
archivers/libarchive: update to 3.8.3
Security fixes:
* 7zip: Fix out-of-boundary access
* tar reader: fix checking the result of strftime (CVE-2025-25724)
* lib: Create temporary files in the target directory
* lha: Fix for an out-of-bounds buffer overrun when using p[H_LEVEL_OFFSET]
* 7-zip: Fix a buffer overrun when reading truncated 7zip headers
security/wolfssl: Update to 5.8.4
Changes since 5.8.2:
To download the release bundle of wolfSSL visit the download page at
www.wolfssl.com/download/
PR stands for Pull Request, and PR references a GitHub pull request number
where the code change was added.
Vulnerabilities
* [Low CVE-2025-12888] Vulnerability in X25519 constant-time cryptographic
implementations due to timing side channels introduced by compiler
optimizations and CPU architecture limitations, specifically with the
Xtensa-based ESP32 chips. If targeting Xtensa it is recommended to use the
low memory implementations of X25519, which is now turned on as the default
for Xtensa. Thanks to Adrian Cinal for the report. Fixed in PR 9275.
* [Med. CVE-2025-11936] Potential DoS vulnerability due to a memory leak
[130 lines not shown]
*/*: Return to pool
I'll be away from keyboard soon and am not sure if I will return. So
return all ports that I currently maintain to pool hoping new
volunteers take care of them.
*/*: Return to pool
I'll be away from keyboard soon and am not sure if I will return. So
return all ports that I currently maintain to pool hoping new
volunteers take care of them.
pmap_bootstrap1() has some macros to aid translation between virtual and
physical addresses. Move these into <m68k/pmap_68k.h> and put them into
two groups.
The first group (PMAP_BOOTSTRAP_RELOC_GLOB() and PMAP_BOOTSTRAP_RELOC_PA())
are for referencing global symbols and physical addresses from within the
context of pmap_bootstrap1() (or similar function) itself.
The second group (PMAP_BOOTSTRAP_VA_TO_PA() and PMAP_BOOTSTRAP_PA_TO_VA())
are for translating addresses that will be used in the context of the running
kernel once the MMU is enabled.
The former group is necessary because some platforms may call pmap_bootstrap1()
with the MMU *enabled* but running on foreign mappings whereby global
references work without relocation but access to physical addresses require
relocation (this is the case on mac68k systems that place the frame buffer
at physical address $0000.0000, in which case MacOS uses the MMU to simulate
the traditional MacOS memory map and we're running on those mappings when
the kernel starts).
[4 lines not shown]
pfctl_parser.c, ifa_load() should distinguish between broadcast
and PPP peer address when it populates interface table for rule
parser.
OK @claudio, OK @dlg
