nullfs: close a race when syncing inotify flags from the lower vnode
After a bypassed VOP, nullfs mirrors the lower vnode's inotify state
onto the upper vnode. The flags were checked with lockless reads
before being updated with the asserting flag set/unset primitives, so
two threads syncing the same vnode concurrently (or a sync racing a
watch being established) could both decide to make the same change;
the loser then trips the "flags already set" assertion on an
INVARIANTS kernel. On other kernels the race is harmless.
Keep the lockless check as the fast path, but re-make the decision
under the vnode interlock before actually changing the flags.
Reproduced in a 4-CPU VM with one thread cycling an inotify watch on
a lower-filesystem file while several threads stat(2) the same file
through a nullfs mount: the unpatched INVARIANTS kernel panics under
this load, the patched kernel runs it to completion.
Fixes: f1f230439fa4 ("vfs: Initial revision of inotify")
[6 lines not shown]
libc: Add strfromd, strfromf, and strfroml per C23
strfromd(), strfromf(), and strfroml() are implemented directly
in terms of gdtoa. If a non-conforming format string is passed,
the string "EDOOFUS" is returned and errno set to EDOOFUS as an
extension.
Reviewed by: fuz
MFC after: 1 month
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2301
Signed-off-by: Faraz Vahedi <kfv at kfv.io>
[ORC] Generalize RTBridge Callers to any runtime function (#213526)
An RTBridge Caller is a controller-side handle for calling a function in
the runtime. Until now the abstraction assumed every such function was a
trampoline -- a runtime function whose job is to invoke *another*
function at an address the controller supplies (run-as-main, run-as-int,
etc.) -- so every Caller carried a dedicated ExecutorAddr parameter for
that target.
Generalize Callers to call runtime functions of any shape. Invoking a
supplied target is now just one kind of call, with the target address an
ordinary leading argument rather than a built-in parameter: e.g.
MainCaller becomes Caller<int64_t(ExecutorAddr, ArrayRef<std::string>)>.
The SPS signatures already led with an SPSExecutorAddr for the target,
so this is a pure interface change -- the SPS wrappers and all call
sites are unaffected. It lets Callers model runtime functions that do
the work themselves, such as the memory-access wrappers, rather than
only those that dispatch to another function.
[offload][OpenMP] Add atomic cross-team reductions (#209298)
Regular cross-team reductions have two phases: the intra-team reduction
and the inter-team reduction. Atomic cross-team reductions replace the
second phase with a atomic instruction which is used by the main thread
of each team to directly fold the result of the intra-team reduction
into the final result. Since this requires a combination of "data type"
and "combine operation" for which an atomic instruction is available,
only some (but very common) reductions can be transformed to atomic
reductions. In cases where multiple reductions are performed on the same
construct, the atomic path is only taken if all reductions can be
transformed. Otherwise, we fall back to the regular cross-team reduction
using a buffer with per-team slots. This is not strictly necessary, but
hybrid reductions would induce more complexity with questionable
benefit.
Selecting an atomic path might not be the best option for every
situation, which is why it is not enabled by default. Instead, it can be
enabled via `-fopenmp-target-atomic-reduction`. Note that enabling the
[17 lines not shown]
[VPlan] Handle step where sign cannot be determined optimizeFindIVRed. (#213450)
optimizeFindIVReductions uses the step to determine if min or max is
needed. Bail out if the direction of the step cannot be determined via
SCEV.
Fixes https://github.com/llvm/llvm-project/issues/213424
py-vcs-versioning: updated to 2.2.3
2.2.3 (2026-07-28)
Fixed
- Fix `ValueError` when parsing `.git_archival.txt` of a tagged commit whose tag contains more than one dash (e.g. `llvmorg-23.1.0-rc2`) - the `git describe` suffix is now matched precisely instead of splitting on the last two dashes.
py-libcst: updated to 1.9.0
1.9.0 - 2026-07-29
Added
* Add support for Python 3.15
* Add `CodemodCommand` helpers for adding and removing imports
Fixed
* Recognize Python 3.14 parser configurations
* Allow a trailing comma after `**rest` in class patterns
Updated
* Document the new `CodemodCommand` import helpers
* Fix the `tokenize` function's docstring grammar
* Remove the retired macOS 13 runner from CI
msun: add asinpi, acospi, and atanpi
This commit implements the inverse half-cycle
trigonometric functions:
asinpi(x) = asin(x) / pi Eq. (1)
acospi(x) = acos(x) / pi
atanpi(x) = atan(x) / pi
Implemention details are contained in src/s_asinpi.c and
src/a_atanpi.c, where the details for acospi(x) appear in
the former.
*************
CAVEAT EMPTOR: The ld128 code has been only compiled. It has
not been tested for correctness due to lack of hardware.
*************
[125 lines not shown]
libc/merge.c: use memcpy() for copying
Currently mergesort() uses ICOPY_*() to copy data as four byte blocks
instead of one byte. However, this is only achievable when both size and
base arguments are aligned to four bytes.
Use of memcpy() is ideal as 1) it is cleaner and 2) the library will use
SIMD for copying when the hardware supports it. Compared to ICOPY_*(),
SIMD can support up to 64 bytes. When the SIMD-backed memcpy() find the
address is unaligned, it can first copy data up to the nearest aligned
address, and then use SIMD operations for faster transfer. Thus memcpy()
can give better performance than mergesort()'s own implementation.
This is benchmarked on amd64 where there isn't a SIMD-backed
implementation yet. However, the baseline implementation in assembly
already delivers better performance in unaligned cases although there is
some performance drops in aligned cases. The benchmark results and
script is available in the Phabricator review. Ideally, more performance
improvements will come when amd64 gets SIMD implementation of memcpy().
[5 lines not shown]
libutil++: Include <cerrno> in stringf.cc
stringf.cc uses errno and related macros without including <cerrno>.
Their availability is guaranteed only when the corresponding header
is included; transitive exposure is implementation-defined.
Modern libc++ has been progressively reducing incidental transitive
includes as part of its header removal policy (see LLVM libc++ Header
Removal Policy and D132284), making such dependencies brittle.
This change includes <cerrno> explicitly to make the dependency
well-defined. No functional or behavioural change intended.
Approved by: fuz
Signed-off-by: Faraz Vahedi <kfv at kfv.io>
Pull-Request: https://github.com/freebsd/freebsd-src/pull/2188
[lldb] std::move unique_ptrs, rather than calling .release. (#213525)
These .release() calls are legacy from the std::auto_ptr to
std::unique_ptr transition.
bhyve: tidy up bhyve_config.5
There are few warnings reported by mandoc -Tlint:
bhyve_config.5:255:31: WARNING: new sentence, new line
bhyve_config.5:257:43: WARNING: new sentence, new line
bhyve_config.5:422:2: WARNING: missing section argument: Xr nm_open
bhyve_config.5:469:24: WARNING: skipping no-space macro
bhyve_config.5:483:2: WARNING: wrong number of cells: 2 columns, 4 cells
bhyve_config.5:484:2: WARNING: wrong number of cells: 2 columns, 4 cells
bhyve_config.5:541:24: WARNING: skipping no-space macro
- "new sentence, new line" is a trivial formatting fix.
- "missing section": there is actually no nm_open() manual page,
so use .Nm instead of .Xr for it.
- "no-space macro": format without .Oc and .Ns, similarly to
how it is already done in bhyve.8 for VNC addresses.
- "wrong number of cells": also a trivial fix.
[6 lines not shown]
bhyve: tidy up bhyve_config.5
There are few warnings reported by mandoc -Tlint:
bhyve_config.5:255:31: WARNING: new sentence, new line
bhyve_config.5:257:43: WARNING: new sentence, new line
bhyve_config.5:422:2: WARNING: missing section argument: Xr nm_open
bhyve_config.5:469:24: WARNING: skipping no-space macro
bhyve_config.5:483:2: WARNING: wrong number of cells: 2 columns, 4 cells
bhyve_config.5:484:2: WARNING: wrong number of cells: 2 columns, 4 cells
bhyve_config.5:541:24: WARNING: skipping no-space macro
- "new sentence, new line" is a trivial formatting fix.
- "missing section": there is actually no nm_open() manual page,
so use .Nm instead of .Xr for it.
- "no-space macro": format without .Oc and .Ns, similarly to
how it is already done in bhyve.8 for VNC addresses.
- "wrong number of cells": also a trivial fix.
[6 lines not shown]
[LLD][COFF] Replace ARM64EC TLS directory chunks with native chunks when available (#212845)
On ARM64X targets, CRT provides separate TLS directory chunks, expecting
the linker to sort it out. TLS directory uses _tls_start and _tls_end
symbols to reference .tls section. Those symbols use section sorting to
ensure that they are emitted at the start and end of .tls section, but that's
not enough when we have two separate chunks for views: only one of them
can really be the first one. Following MSVC, merge those chunks instead so
that both symbol tables point to the same chunk.
Additionally apply the same logic to _tls_used and _tls_index. This
allows entire TLS directory to be shared between EC and native views. To
achieve that, CRT additionally needs to mark each TLS callback with
-arm64xsameaddress. This matches how MSVC linker and libraries work, but
it requires EC and native views to use the same set of TLS callbacks. We
may emit separate TLS directories in the future to make it more robust.
