AMDGPU: Remove xnack-any-only subtarget feature and handling
This reverts commit f4caa0a172d96597c375e6b6b2192c289723a6b9.
This feature was added to gfx12-5-generic only, which does not make
sense given that both gxf1250 and gfx1251 have the same unconditional
xnack handling. It also does not make sense to diagnose trying to use
a specific xnack mode on the generic target only, and only from the
backend.
The current feature management is a confusing mess, given that we have
2 parallel feature systems. AMDGPUTargetParser has a table containing
a bitmask of features, which already contained FEATURE_XNACK_ALWAYS
for gfx1250/gfx1251, but not gfx12-5-generic. Add this handling there
so the sanitizer detection is consistent on the generic target.
These 2 feature tables probably should be unified in some way. We also
probably should have a subtarget feature for the xnack handling, but it
should be inverted. xnack-any-only is an antifeature, in that it removes
[2 lines not shown]
[lld-macho] Ignore labels on sections ld64 treats as ignoreLabel (#194275)
In ld64, labels on records in some sections never become named atoms and
never enter the symbol table:
- Unconditionally: __cfstring, __objc_classrefs, and __objc_selrefs
- Prefix-gated on `L`/`l`: __literal{4,8,16} and __cstring-family
sections such as __objc_methname
LLD, however, ran every such label through `SymbolTable::addDefined`,
which diverged from ld64 whenever an identically-named symbol appeared
in another section. This patch mirrors ld64's behavior in LLD. The
Defined is still created for the affected labels, but it bypasses the
symbol table entirely and cannot collide with any cross-TU symbol.
I have encountered a few link failures caused by this, and reduced them
into the regression tests in the patch.
[RISCV] Fix the AST type printing code for VectorKind::RVVFixedLengthMask_1/2/4 (#204498)
These types have a fixed size of 1, 2, 4. The formula used for the other
types does not apply.
Assisted-by: Claude
zsh: Matthew Martin takes maintainer, ok sthen
It's been many years since the former maintainer gave an ok for this port
or even touched it. Matthew has been maintaining this shell for well over
a decade, so this change simply reflects reality.
witness: add tunables debug.witness.lock_order_{data_count,hash_size}
Add tunable debug.witness.lock_order_data_count to allow adjusting the
number of witness lock order data entries (stacks) without recompiling
the kernel. This may help to display stacks when a lock order reversal
is reported but the number of entries is exhausted before recording the
first lock order, by allowing the user to reboot with an adjusted
tunable and try again.
Tunable debug.witness.lock_order_hash_size is also provided to allow the
hash table load factor to be managed, though that is not required.
Also tweak witness_lock_order_add to avoid computing a hash when it
won't be needed because the lock order data entries are exhausted.
Reviewed by: kib, markj
Sponsored by: Dell Inc.
Differential Revision: https://reviews.freebsd.org/D57600
witness: actually set read-only tunables in time for witness_startup
SYSCTL_XXX with CTLFLAG_RDTUN and without CTLFLAG_NOFETCH should not be
used for values that are needed before SI_SUB_KLD. Otherwise they are
tuned after they are needed. Set CTLFLAG_RDTUN | CTLFLAG_NOFETCH for
the debug.witness.witness_count and debug.witness.skipspin sysctls and
add separate tunables for them, which run at SI_SUB_TUNABLES time, i.e.,
in time for witness_startup.
Reviewed by: kib, markj
Sponsored by: Dell Inc.
Differential Revision: https://reviews.freebsd.org/D57613
[clang-cl][test] Use /Zs to avoid writing unnecessary output files (#204501)
#194779 adds a test clang/test/Preprocessor/init-datetime-macros.c which
verifies some diagnostics. However, it does so with `/c`, which will
unnecessarily generate an output, and when run on a build system that
does not run tests in a writeable dir by default, will cause the test to
fail.
Since we don't care about the resulting object file, use `/Zs`
(equivalent of `-fsyntax-only`) to check the diagnostics but not produce
any output files.
documentation: Turn on verbose asciidoctor build
The other builds are verbose by default.
This will increase consistency and reduce cargo-culting.
Discussed with: dch, kevans
math/py-petsc4py: remove deprecated dry_run parameter from build_ext
...to fix build with newer setuptools
While here, correct name of file for stripping
Co-authored by: Hiroo Ono
Approved by: maintainer timeout
PR: 294431
Event: FreeBSD Developer Summit June 2026
Event: BSDCan 2026
[offload][OpenMP] Fix record replay when no memory is used
Progams that do not use any memory (e.g., no mappings) were failing because
we were trying to execute zero size transfers.
documentation: Modernize custom macros
Convert our custom macros to output asciidoctor instead of raw html,
silencing 6500 warnings. This will enable us to turn verbose builds
on, which will enable us to actually understand what is going on in
the doc tree.
Reviewed by: dch, kevans
[RFC][BOLT] Add a new parallel DWARF processing(2/2) (#197859)
This PR implements a new parallel DWARF debug info processing pipeline
for BOLT that significantly speeds up `--update-debug-sections` for
large binaries. It is the second part of the split from the overall RFC
changes
RFC - [[RFC][BOLT] A New Parallel DWARF Processing Approach in
BOLT](https://discourse.llvm.org/t/rfc-bolt-a-new-parallel-dwarf-processing-approach-in-bolt/90736)
(The overall changes.)
This PR does the following:
1. **Equivalence-class CU partitioning:** Replaces batchsize grouping
with union-find over DW_FORM_ref_addr references. Connected CUs share a
bucket; isolated CUs become singletons.
> For the non-LTO case, CUs have no cross-CU dependencies, so each CU is
placed into its own singleton bucket and processed fully in parallel.
> For the LTO case, CUs with cross-CU dependencies are grouped into the
same bucket and processed sequentially within that bucket, while
[7 lines not shown]
