[clang][bytecode] Remove base casts in builtin_object_size (#176111)
If UseFieldDesc is set, we should use the "closest surrounding
subobject", which apparently cannot be a subclass pointer.
Fixes https://github.com/llvm/llvm-project/issues/176079
InstCombine: Fold known-qnan results to a literal nan
Previously we only considered fcNan to fold to qnan for canonicalizing
results, ignoring the simpler case where we know the nan is already
quiet.
devel/llvm1[4567]: keep backport patches local
The patches generated by adding .patch to a github commit URL are
unstable and the output of some of them changed recently. It's
concivable this will be fixed, but they probably won't make any
long term guarantees so store the patches in the ports tree instead of
downloading them.
PR: 292291
MFH: 2026Q1
Sponsored by: DARPA, AFRL
See also: https://github.com/orgs/community/discussions/184094
(cherry picked from commit d5c827648ead25c364859541c957a09ba0c276fb)
[Serialization] Load only needed partial specializations
Similar as the last commit, it is unclear why we need to load all
specializations, including non-partial ones, when we have a TPL.
Reviewed as part of https://github.com/llvm/llvm-project/pull/133057
[AMDGPU] Limit allocation of lo128 registers for occupancy
Parent change allows allocation of lo128 VGPRs from all 4 banks.
That may result in the undesired allocation leaving a hole of
maximum 128 registers in case if for example v0-v127 are allocated,
and v128-v255 are free.
Limit the available allocation order to the occupancy. Both hard
occupancy limits and occupancy achieved during scheduling are
considered. That is better to spill a register than to drop occupancy
in this case.
[RISCV] Add missing arch features of tt-ascalon-d8 (#176071)
A GCC patch has been landed, which can be used as a reference for the
architectural features of tt-ascalon-d8. The patch is missing Zvfbfmin
(reported to GCC patch author), but we should align the architectural
features in LLVM with that tested patch otherwise.
Ref: https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705300.html
[MLIR][SCFToOpenMP] Fix crash when lowering vector reductions (#173978)
This patch fixes a crash in the SCF to OpenMP conversion pass when
encountering scf.parallel with vector reductions.
- Extracts scalar element types for bitwidth calculations.
- Uses DenseElementsAttr for vector splat initializers.
- Bypasses llvm.atomicrmw for vector types (not supported in LLVM IR).
Fixes #173860
---------
Co-authored-by: Aniket Singh <amiket.singh.3200.00 at gmail.com>
[clang][c23] Avoid assertion on an invalid static constexpr variable (#175927)
In C static variables should have constant expressions in initializers
so we were checking this twice for constexpr variables and failing with
an assertion that was makes sure we don't do it.
This patch postpones the check just like it is done for file
scope constexpr variables in C already.
Fixes https://github.com/llvm/llvm-project/issues/173605
(cherry picked from commit 5b0270cb72f707f55e2ff5e97fc938afb3b81053)
[AMDGPU] Limit allocation of lo128 registers for occupancy
Parent change allows allocation of lo128 VGPRs from all 4 banks.
That may result in the undesired allocation leaving a hole of
maximum 128 registers in case if for example v0-v127 are allocated,
and v128-v255 are free.
Limit the available allocation order to the occupancy. Both hard
occupancy limits and occupancy achieved during scheduling are
considered. That is better to spill a register than to drop occupancy
in this case.
[analyzer] Invalidate the object in opaque ctor calls regardless if an arg refers to it (#170887)
The conservative call invalidation logic is a bit complicated, and would
deserve some refactoring.
When a call has some arguments, we escape them. Except, if its a pointer
to constant storage - because we assume that the program honors
const-correctness.
In that case, it puts it in the "Preserved" list to keep its contents.
However, if we had a constructor call that's job is to initialize an
object had a const pointer/reference parameter then the invalidation
didn't take place.
This meant that if the object was on the stack, that we start warning
about uninitialized fields when accessed. (See the example) Similar
could be achieved on the heap of course.
We should have honored the fact that the constructor should initialize
[9 lines not shown]
devel/cargo-nextest: update to 0.9.102
Added
- iTerm now supports the OSC 9;4 progress protocol for progress bar integration. Thanks case for your first contribution!
Fixed
- Fixed an issue where the progress bar displayed stale statistics during test runs (#2930).
