[AArch64] Add vector floating-point round+convert patterns (#177801)
Stacked on https://github.com/llvm/llvm-project/pull/177800.
We were previously able to fuse *scalar* floating-point round + convert
to integer sequences into a single "rounding conversion" instruction.
This PR extends that to vectors.
www/py-flatnotes: New port: Self-hosted, database-less note taking web app
Flatnotes is a self-hosted, database-less note-taking web app that
utilises a flat folder of markdown files for storage.
WWW: https://github.com/dullage/flatnotes/
[RISCV] Rename Tenstorrent Ascalon D8 to Ascalon X (#178199)
As per the official release document. D8 is a former name, used
internally.
Ref: Brief from https://tenstorrent.com/en/ip/risc-v-cpu
[lldb] Enable locate module callback for main executable in launch mode (#176266)
During target creation for launch mode, the locate module callback was
not invoked for the main executable because the Target doesn't exist yet
when ModuleList::GetSharedModule is called. This prevented custom module
location logic from being applied to the main executable.
This change adds a PlatformSP to ModuleSpec so that GetSharedModule can
call the locate module callback using the Platform directly, even when
Target is not available. The Platform is now set on the ModuleSpec in
TargetList::CreateTargetInternal before calling ResolveExecutable.
Co-authored-by: George Hu <georgehuyubo at gmail.com>
Import OpenSSL-3.5.5 (previous was 3.5.1)
Changes between 3.5.4 and 3.5.5 [27 Jan 2026]
Fixed Improper validation of PBMAC1 parameters in PKCS#12 MAC verification.
Severity: Moderate
Issue summary: PBMAC1 parameters in PKCS#12 files are missing
validation which can trigger a stack-based buffer overflow, invalid
pointer or NULL pointer dereference during MAC verification.
Impact summary: The stack buffer overflow or NULL pointer dereference
may cause a crash leading to Denial of Service for an application
that parses untrusted PKCS#12 files. The buffer overflow may also
potentially enable code execution depending on platform mitigations.
Reported by: Stanislav Fort (Aisle Research) and Petr #ime#ek (Aisle
Research) and Hamza (Metadust)
[346 lines not shown]
tests/kern: make ssl_sendfile:truncate and ssl_sendfile:grow less flaky
First problem is a trivial race that the client thread doesn't see updated
c.sbytes. Second problem applies only to the truncate test. On a machine
with huge default buffer sizes, there is a chance that sendfile(2) will
fill both buffers with amount of data that is larger than the size we plan
to truncate. To minimise chances for this scenario, increase file size
and truncate it less aggressively, also try to decrease buffer sizes.
[clangd] Find implementations recursively (#177564)
This makes `textDocument/implementation` return not just direct implementations
(e.g. directly derived classes) but indirect ones (e.g. derived classes of derived
classes) as well.
This is a step towards fixing https://github.com/clangd/clangd/issues/2499.
[mlir] Update all-reduce (& vector tests) to use workgroup barriers (#178285)
This commit updates the lowering of all-reduce operations to annotate
the generated barriers with `memfence [#gpu.address_space<workgroup>]`
so that these barriers do not force unrelated global memory operations
to complete. It similarly sets up the warp synchronization function in
the vectory distribuhte tests, since they also only read/write shared
memory.
In additon, this commit adds convenience builders for gpu.barrier, which
will allow it to either fence on a given address space or on the address
space of a provided memref.
netbsd-tests: Fix regcomp_too_big flakiness
The test sometimes crashes with ASLR enabled. This seems to happen when
regcomp() grows the process stack and happens to run into the virtual
memory limit set at the beginning of the test. ASLR triggers the
problem since it introduces a bit of fragmentation and thus introduces
cases where stack allocation can be the trigger of virtual memory
exhaustion, rather than dynamic memory allocation in regcomp().
Make the test stable by priming the stack before doing anything else.
This effectively reserves 16MB of virtual memory for the stack, which in
practice is enough to make the test stable on amd64.
PR: 259971
Reviewed by: ngie, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54880
