[VectorCombine] Fold sign-bit check for multiple vectors (#182911)
## Alive2 proofs
| Reduction | Shift | Cmp | Sources | Proof |
|-----------|-------|----------|---------|-------|
| add | lshr | == 0 | 2 | [proof](https://alive2.llvm.org/ce/z/f44vco) |
| add | lshr | == 8 | 2 | [proof](https://alive2.llvm.org/ce/z/Ks_nea) |
| add | ashr | == 0 | 2 | [proof](https://alive2.llvm.org/ce/z/ZsXJ5k) |
| add | ashr | == -8 | 2 | [proof](https://alive2.llvm.org/ce/z/HZfans)
|
| add | lshr | == 0 | 3 | [proof](https://alive2.llvm.org/ce/z/x-dEdz) |
| add | lshr | == 12 | 3 | [proof](https://alive2.llvm.org/ce/z/sfNvhr)
|
These proofs are not very exhaustive, but somewhat show that it works
for addition. Apart from the fact that we use multiple vectors, the
proofs from the previous changes generally apply here as well because we
effectively match on reductions of size M x N.
zfs: reject read() on directory
right now, netbsd in general allows read() on directory for
the compatibility with historical applications. (i have not
seen such an application by myself though. is anyone around
here still keeping such ancient binaries? i'm curious if such
a binary still works on today's UFS.)
this commit makes zfs reject such an attempt because zfs is
not prepared to produce the historical UFS dirent structure.
x86 tsc: decrease the timecounter quality for NVMM
NVMM vcpu loses its TSC "ticks" when switching to a different host cpu.
from the POV of the guest OS (ie. this code), it's observed as random
TSC drifts, which makes it unsuitable for a timecounter source.
sched_4bsd.c: honor the upper bound of l_estcpu
otherwise, certain threaded workloads can quickly
accumulate too large l_estcpu.
this change fixes mysterious long (eg 10 seconds) pauses
i've seen occasionally with git. git seems to spawn worker
threads internally these days and happens to hit the condition
of this bug. with very large l_estcpu, the lwp gets effective
priority 0 for a long time. on a busy system, such an lwp
basically will never get a chance to run until the estcpu decay
will eventually make it possible to run again.
it seems this bug has been there since 2007.
("Merge scheduler changes from the vmlocking branch")
at that time, while i had been using netbsd heavily for daily
things, i haven't noticed this issue at all. it seems that
threaded programs got ubiquitous in this decades.
zfs: fix data loss with some combinations of mmap and write
in write(), make a mmap page clean only when we are overwriting the
whole page. otherwise, modifications made via mmap which are outside
the overwritten region will be lost.
tested with https://github.com/yamt/garbage/blob/master/c/ubc/ubctest.c
zfs: fix a deadlock in read()
while zfs on netbsd is a non-UBC filesystem, we have a logic to try
mimicking UBC-like consistency between mmap and read/write, which
some "broken" applications might rely on. however, the logic is not
safe as indicated by the XXXNETBSD comment. it isn't safe because
touching user pages can involve page faults, which may need to block
on other (or even same) pages with an undefined locking order.
this commit fixes it by using an intermediate buffer to avoid touching
user pages while keeping a file page busy.
although this probably can be optimized by checking VV_MAPPED, i'm not
in a mood to complicate this already-complicated code further. because
zfs doesn't use UBC, if a file has uvm pages, it almost certainly has
VV_MAPPED anyway.
tested with https://github.com/yamt/garbage/blob/master/c/ubc/ubctest.c
[5 lines not shown]
math/octave: restrict required java version to 11+ (+)
octave require java-1.9+ to build java bindings and skip it if found java-1.8
checking for Java version... 1.8.0_482
configure: WARNING: Java version is too old (< 1.9). Octave will not be able to call Java methods.
...
pkg-static: Unable to access file /usr/ports/math/octave/work/stage/usr/local/share/octave/11.1.0/m/java/octave.jar:No such file or directory
Reported by: root at dc365.ru
Approved by: portmgr blanket
solaris vfs_optionisset: treat 0 as unspecified
this allows users to leave it default.
before this change, when a user runs "zfs mount -a",
it was processed as "mount them read-write, overriding readonly property".
i don't think it's what the user usually intends.
looking at the illumos code, it seems that mount options there are
basically tri-state. that is, "ro", "rw", and unspecified.
as NetBSD only has a single bit, MNT_RDONLY or !MNT_RDONLY, this commit
maps !MNT_RDONLY to unspecified, which i believe more often matches
the user's intention. it also seems like what illumos does for the legacy
MS_RDONLY bit if i read their code correctly. that is, if MS_RDONLY is set,
it sets MNTOPT_RO. on the other hand, a lack of MS_RDONLY doesn't imply
MNTOPT_RW.
references:
"Temporary Mount Point Properties" section of zfs(8)
[3 lines not shown]
[mlir][python] Add stable ABI (abi3) support (#183856)
Add `MLIR_ENABLE_PYTHON_STABLE_ABI` cmake flag to build bindings against
the Python limited/stable API (abi3 / PEP 384). This allow for
compatibility across different >=3.12 versions with a single .so /
wheel. We also require CMake >=3.26.
The stable ABI restricts usage to a subset of the CPython C API: frame
and code object structs are opaque, so introspection APIs like
`PyCode_Addr2Location`, `PyFrame_GetLasti`, and `PyFrame_GetCode` are
unavailable. The traceback-based auto-location logic is dropped because
we don’t have stable ABI to produce complete locations.
Assisted-by: claude
[mlir][test] Fix crash in ReifyBoundOp with invalid 'type' attribute (#184004)
The `ReifyBoundOp::getBoundType()` called `llvm_unreachable("invalid
bound type")` when the `type` attribute was set to a value other than
"EQ", "LB", or "UB" (e.g., "scalable"). This caused an abort instead of
a user-visible diagnostic.
Add a verification check that rejects invalid `type` values with a
proper error message before `getBoundType()` is ever called.
Fixes #128805
qgis: Adjust \todo in Makefile and TODO
The only significant change is a decision to create a default-off
option for qtwebengine, because it's beastly and I don't understand
how qgis with it does anything more useful.