[mlir][xegpu] Raise the reduction vector size to match maxReduceVectorSize (#225122)
`maxReduceVectorSize` was pinned at 1, so a lane reduced one element at
a time no
matter how much data it held. This raises it to 16 and makes the layout
computation actually spend it, so a lane's reduce vector matches the
per-lane
budget.
```cpp
- int64_t maxReduceVectorSize = 1; // could extend to spirv vector Size
+ int64_t maxReduceVectorSize = 16; // extend to spirv vector Size
```
The PR only raises the vector size for the innermost dim, and only when
that dim is reduced and carries a single lane.
The reason we don't raise vector size for outer dim: Raising the vector
size for the outer dim means the vector may be strided in flat element
[10 lines not shown]
[alpha.webkit.NoDeleteChecker] Support nodelete on constructors and destructors (#218822)
This PR adds the support for specifying nodelete annotation on C++
constructors and destructors. To do this, we recognize
[[clang::annotate("webkit.nodelete")]] on function declarations instead
of [[clang::annotate_type("webkit.nodelete")]] on the return value.
---------
Co-authored-by: Balázs Benics <benicsbalazs at gmail.com>
[clang][Driver] Prevent Safe Stack runtime from linking if enabled then disabled (#228537)
Currently:
```
$ ./clang -fsanitize=safe-stack -fno-sanitize=safe-stack -Wl,--trace -x c++ -o- - < /dev/null
...
.../libclang_rt.safestack.a
...
```
See https://godbolt.org/z/e63za9sjn
With this change, `libclang_rt.safestack.a` is not included when Safe
Stack is disabled as the last option. This is because `Kinds` is the
final resolved set of sanitizers after removals via `-fno-sanitize`.
`AllAddedKinds` is the set of all sanitizers which were seen at least
once even if they were removed. This change makes it so we check against
`Kinds` instead of `AllAddedKinds`.
[5 lines not shown]
py-nodeenv: update to 1.11.0
New Features
* feat(certifi): optionally use certifi certificates
* feat(nodeenv): accept npm-style semver ranges in --node
* feat(nodeenv): add --prefer-system to use system node when available
* feat(nodeenv): add --isolate-npm to keep npm config inside the
environment
* feat(nodeenv): install local packages from a requirements file
* feat(nodeenv): write the posix activate on Windows for git-bash
Fixed bugs
* fix: repair Windows CI (ZipFile.extractall filter, test_smoke layout)
* fix(nodeenv): replace leftover debug print with logger.debug
* fix(nodeenv): stop -p from reinstalling node that is already there
* fix(nodeenv): let -p target a virtualenv nodeenv isn't installed in
* fix(nodeenv): report the url and proxy instead of a traceback
[24 lines not shown]
sysv_shm: claim the vm_shm slot after uvm_map(), not before
sys_shmat() chose a free slot in the per-vmspace vm_shm array, then slept
in uvm_map(), then published into the slot it had chosen. Nothing marked
the slot taken across the sleep, so a sibling thread entering sys_shmat()
scanned the same array, found the same slot still reading -1, and took it
too. Both uvm_map() calls succeed at different addresses and the thread
that stores last wins; the other mapping is left with no vm_shm entry, so
shmdt() returns EINVAL for it and shmexit() cannot drop its shm_nattch.
The permanently raised count keeps IPC_RMID from deallocating the segment,
which then sits in shmsegs[] reachable by nobody; 128 of those and
shmget() returns ENOSPC system-wide.
uvm_map() is the only sleep between choosing the slot and filling it in,
so moving the scan below the map closes the window without a reserved
state that shmdt(), shmexit() and shmfork() would each have to learn
about. EMFILE is now discovered after the mapping exists, so that path
undoes it.
[9 lines not shown]
cad/sweethome3d: update Sweet Home 3D to version 7.5
- Mitigate long-standing "Surface not cachable" error
by running with -Dsun.java2d.opengl=true (alternative
setting -Dsun.java2d.xrender=false should also work)
- Drop -Xmx1024m from Java options, it made sense when
default MaxHeapSize value was half the available RAM
with a minimum of 16 MB and a maximum of 512 MB, but
had been changed around 2020 to 25% physical memory
up to 25 GB, so this adjustment is no longer needed
- Prepare YafaRay renderer for modern CMake while here
JDK issue: https://bugs.openjdk.org/browse/JDK-8201631
PR: 274849
Reported by: portscout
Merge tag 'edac_urgent_for_v7.3_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
Pull EDAC fixes from Borislav Petkov:
"This is more of the new normal of LLM-induced fixes of error paths. Oh
well, they should be done eventually and hopefully we'll be back to
normal soon-ish... one would hope... :-P
AMD Versal NET:
- Properly release a remote processor reference which was acquired at
probe time, on memory controller instance remove
A handful of Altera EDAC driver fixes:
- Fix device node reference leaks covering both the success path and
the various error paths, and route the single-bit setup function
through the common exit label
- Fix a use-after-free by releasing the devres group before freeing
[22 lines not shown]
[libc++][string] Improve constexpr performance
Adding `if (__libcpp_is_constant_evaluated()) return` allows
significantly increase complexity of extression.
In case of Asan it changed from 1000 to 6000.
Pull Request: https://github.com/llvm/llvm-project/pull/184724
etc/etc.evbarm/Makefile.inc: follow-on hash generation fix
Revs. 141 & 142 introduced a guard that tried to prevent checksum
consolidation from running in contexts where there's nothing to process
-- that is, images aren't created at all. However, it then also
prevented clean builds that do include images from consolidating their
checksums as intended, since the "exists" check that was added reflects
too early a file system state on clean builds ("gzimg" doesn't exist
yet). It also didn't address the fact that there can be targets that
do in fact create and populate a "gzimg" directory, yet don't actually
generate any images as presently construed/defined are relevant for
hash generation, as happens with the evbearmv4-el arch.
Another fix for PR install/59195. Tested with earmv5hf (no images, no
"gzimg" directory created), evbearmv4-el (no images, "gzimg" directory
is created), and aarch64 (images and "gzimg" directory are created),
with clean builds into new directory structures and subsequent update
builds tested for each arch.
T4: pin boot tests to shared harness v0.2.3 (banner→prompt login) (#513)
* T4: boot gates run on the shared nextbsd-ci harness @v0.2.1 (login-only)
img-boot-test.sh + iso-boot-test.sh become thin entry points onto the shared
harness (NB_LOGIN_ONLY; the live ISO adds NB_MEDIA=cd): they extract the
zipped artifact, check out nextbsd/nextbsd-ci at v0.2.1 (pinned tag = no drift),
and run harness/boot-test.sh. The loader un-mute dance, the arch-aware qemu
argv, login detection and teardown now come from the shared harness (one place,
every arch, kept green by its selftest) instead of the in-repo copies.
Delete the 1512-line tests/boot-test.sh monolith (nothing in CI invoked it) and
the in-repo tests/loader.exp.inc + tests/qemu-arch.sh (superseded by the
harness's contract.exp.inc + qemu-arch.sh). The jobs' serial-log dumps point at
the harness transcript. Both gates stay NON-GATING as before (not in release's
needs); the gate is the harness exit class.
* Bump the shared-harness pin to v0.2.2 in the thin img/iso boot wrappers
[4 lines not shown]
Wyles/update libclctests (#228681)
Using libclc with different versions of clang emit different output.
computeConstantRange now pushes ranges through zext and sext so we now
can prove noundef. This test returns AMDGPU workgroup ID which is zero
extended, so we can now prove it needs noundef.
At some point we may need to update the CI targets to look at libclc?
