[mlir][IR] Avoid Clang 21 crash during SFINAE overload resolution (#208359)
Clang 21.1.8 segfaults during SFINAE overload resolution for
T::getChecked
when matching non-pointer arguments against an unconstrained
MLIRContext*
parameter.
This patch avoids the crash by adding an explicit SFINAE constraint to
the second overload of StorageUserBase::getChecked, ensuring that it is
only considered when the second argument is convertible to MLIRContext*.
Assisted-by: Antigravity
[Clang] Define `__WCHAR_MIN__` and related macros (#208135)
Define `__WCHAR_MIN__`, `__WINT_MIN__`, and `__SIG_ATOMIC_MIN__` for
compatibility with GCC.
This also fixes targets such as `riscv*-netbsd` that define `WCHAR_MIN`
from `__WCHAR_MIN__`.
Reference:
https://gcc.gnu.org/onlinedocs/gcc-16.1.0/cpp/Common-Predefined-Macros.html
Closes #199678
BPF: Fix misfolding subregisters
This would end up introducing a copy between registers
with mismatched sizes previously. Defends against verifier
failures in a future change.
The actual transform here should be deleted. Optimizations should
not be trying to introduce SUBREG_TO_REG.
newvers.sh: Avoid spurious -dirty in git revision
If git is installed and .git exists but git rev-parse failed to report a
hash we previously produced just "-dirty" as the git revision. Gate the
git commit count and -dirty check on the rev-parse passing.
Reviewed by: jlduran
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57995
(cherry picked from commit 465a3b7adc008c068741594f6c922ede98924f39)
(cherry picked from commit 45da2c1e1d202ab190f156dd63403be79fb11e94)
newvers.sh: Avoid spurious -dirty in git revision
If git is installed and .git exists but git rev-parse failed to report a
hash we previously produced just "-dirty" as the git revision. Gate the
git commit count and -dirty check on the rev-parse passing.
Reviewed by: jlduran
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57995
(cherry picked from commit 465a3b7adc008c068741594f6c922ede98924f39)
[NVVM][MLIR] Fixed valgrind leak in MMAOp (#208063)
MmaOp::getIntrinsicID triggers an uninitialized-read warning under
Valgrind. `intOverflowBehavior` is optional; in the generated selector
its `has_value()` guarded access can be speculatively loaded before the
guard, reading the empty std::optional's uninitialized payload.
The read is benign: the payload is correctly stack-allocated but
uninitialized while empty, and the loaded value is discarded by the
guard, so this is not incorrect / undefined behavior.
This MR keeps the attribute as optional, but the lowering now resolves
it to a concrete value (wrapped when omitted) before calling
getIntrinsicID, so the selector always reads an initialized value.
`wrapped` matches the PTX spec and the existing lowering, where an
omitted attribute already selected the non-satfinite intrinsic;
intrinsic selection and printed IR are unchanged. Documentation updated
to correct the stale default.
[SPIR-V] Tie Int64ImageEXT to R64i/R64ui image format, not sampled type (#203005)
The capability is required by the R64i/R64ui Image Format per
SPV_EXT_shader_image_int64 spec, not by a 64-bit integer sampled type
Related SPIRV-LLVM-Translator PR that fixes this issue there:
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/3773
[SPIR-V] Fix truncated LinkageAttributes OpDecorate for numeric-named functions (#207332)
LLVM IR allows functions with numeric names (e.g. `@0`). There function
return empty strings on `getName()`, so emitting a `LinkageAttributes`
decoration for it is meaningless.
Fix: skip emitting the `LinkageAttributes` decoration for non-entry
functions with an empty name. Also add a `report_fatal_error` for the
case where an entry point function has no name, since that is invalid
input.
offload: Use amdgpu triple name in plugin build
The PGO tests expect the produced filename to match the triple.
The tool pulls the triple name from the binary's triple name, and the
RUN lines expect it to match the triple the build was configured with.
[LLVM][NFC] Remove some global constructors (#208407)
Largely by converting relevant functions or variables to constexpr,
changing the type, converting to static locals, or by outright removal.
PunnedPointer assignment can never be constexpr, because std::memcpy is
not constexpr and type punning is not permitted in a constant-evaluated
context.