[InstrProf] Do not emit metadata for zero values with zero counts (#199380)
If we have a indirect call site with a profile that has VP information
for said callsite that only contains zero values with zero counts, we
would start to emit invalid profile information after
1d146967d51ba76b8379d9e12961aa23e5745701. VP metadata in this case is at
best redundant with BFI. So we restrict metadata emission to only if we
have a sufficient number of values for the VP metadata to be valid.
[mlir][async] Lazily create the coroutine destroy-cleanup block
`setupCoroMachinery` previously emitted a `cleanupForDestroy` block
unconditionally, alongside the normal `cleanup` block. That block is
only ever used as the "destroy" successor of an `async.coro.suspend`,
so for coroutines that never suspend (e.g. an `async.func` whose body
contains no `async.await`) it ended up unreachable in the lowered CFG.
Make `cleanupForDestroy` mirror the existing `setError` pattern and
materialize it lazily via a new `setupCleanupForDestroyBlock` helper,
called only from the two places (`outlineExecuteOp` and the
`async.await` lowering) that actually wire it up. Store the coroutine
id on `CoroMachinery` so the helper can rebuild the block contents
without keeping the original `async.coro.id` op around.
Assisted-by: Opus 4.7
[mlir][async] Lazily create the coroutine destroy-cleanup block
`setupCoroMachinery` previously emitted a `cleanupForDestroy` block
unconditionally, alongside the normal `cleanup` block. That block is
only ever used as the "destroy" successor of an `async.coro.suspend`,
so for coroutines that never suspend (e.g. an `async.func` whose body
contains no `async.await`) it ended up unreachable in the lowered CFG.
Make `cleanupForDestroy` mirror the existing `setError` pattern and
materialize it lazily via a new `setupCleanupForDestroyBlock` helper,
called only from the two places (`outlineExecuteOp` and the
`async.await` lowering) that actually wire it up. Store the coroutine
id on `CoroMachinery` so the helper can rebuild the block contents
without keeping the original `async.coro.id` op around.
Assisted-by: Opus 4.7
Revert "[compiler-rt][ASan] Add function copying annotations (#91702)" (#194204)
This reverts commit c76045d9bf3bd1c7a381dc85d1db63a38fd69aa4.
It does not look like this has been used anywhere since it was
implemented. I see no uses of it in LLVM, anywhere in our internal
monorepo, or across the entirety of Github outside of other copies of
LLVM tests. Given that, remove it. The intended use case around SSO ASan
string annotations is also likely to be significantly reworked soon.
[lit] Normalize RLIM_INFINITY to "infinity" in print_limits.py for Python 3.15+ (#190953)
Python 3.15 changed resource.getrlimit() to return the platform's
maximum value (e.g., 18446744073709551615 on 64-bit systems) instead of
-1 for RLIM_INFINITY. This breaks lit tests that expect -1 for unlimited
resource limits.
This patch normalizes the return value to "infinity" when it equals
RLIM_INFINITY to maintain compatibility with existing tests across all
Python versions.
Fixes test failure: shtest-ulimit-nondarwin.py
Expected: RLIMIT_FSIZE=-1
Got: RLIMIT_FSIZE=18446744073709551615
Reference:
https://github.com/python/cpython/commit/0324c726dea702282a0300225e989b19ae23b759
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2448969
[7 lines not shown]
[ProfData] Remove HWAsan exclusion (#199582)
This passes locally for me with HWAsan enabled on a AArch64 machine, so
it seems like this might have been fixed since adding the opt-out.
universe: emit warning instead of error for bad/missing KERNCONF
When doing a large `make universe` build with multiple KERNCONFS,
it should not be an error when a particular target has a missing
KERNCONF.
In this example,
```
$ make universe TARGETS='arm64 riscv' KERNCONFS='QEMU VIRT'
```
Currently, arm64 does not have a QEMU conf, and riscv
does not have a VIRT conf. However, this command should still
succeed instead of failing with the following message:
```
make[2]: /usr/src/Makefile:767: Target architecture for riscv/conf/VIRT unknown. config(8) likely too old.
in .for loop from /usr/src/Makefile:761 with kernel = VIRT
[15 lines not shown]
ZTS/alloc_class: move file_in_special_vdev to alloc_class.kshlib
Move the function into the shared library.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #18584
ZTS: zpool_expand_005_pos: correct variable name in expandsize check
The check referenced $zpool_expandsize, which is not defined in this
test; the variable assigned two lines above is $expandsize. A "-"
value returned by zpool reopen therefore did not trigger the
intended log_fail, and the failure surfaced only at the later
post-online-e size check with a less specific message.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #18580
[AMDGPU] Don't assume non-erased DenseMap entries remain valid after erase. NFC (#199578)
In preparation for DenseMap change that relocates surviving entries on
erase, replace erase-while-iterating with remove_if.
zpl_xattr: stop heap-allocating prefixed xattr names
The six __zpl_xattr_{user,trusted,security}_{get,set} entry points
built their prefixed name via kmem_asprintf("%s%s", prefix, name)
and freed it with kmem_strfree on the way out.
The Linux xattr API caps the full prefix+name length at
XATTR_NAME_MAX (255), the same bound fs/xattr.c's syscall handlers
rely on with their stack-resident struct xattr_name, and so do
the same in our xattr handlers.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Rob Norris <rob.norris at truenas.com>
Reviewed-by: Ameer Hamza <ahamza at ixsystems.com>
Signed-off-by: Andrew Walker <andrew.walker at truenas.com>
Closes #18570
[NVPTX] Don't assume non-erased DenseMap entries remain valid after erase. NFC (#199575)
GenericToNVVM erases entries from GVMap while iterating it. In
preparation for DenseMap change that relocates surviving entries on
erase, snapshot the map and erase by key.
cast a struct sockaddr * to typedef of struct sockaddr_bird * (which is
just a padded sockaddr *), the subsequent address extraction (involving
a bit of indirection) doesn't touch the bytes of padding, removes warning
seen with llvm19 which becomes an error
drop some now-bogus configure args while there
[LifetimeSafety] Fix false negative for GSL Owner methods inherited from a non-Owner base (#197864)
- Take the implicit object's actual type (e.g., the type before any
`DerivedToBase` cast) into account when checking for GSL Owner. Other
`isGslOwnerType` call sites with the same pattern (e.g.,
`isGslOwnerType(MCE->getImplicitObjectArgument()->getType())` in
`VisitCXXMemberCallExpr`) lack a real-world trigger today and are
deferred to a follow-up.
- Unify the GSL Owner checks inside `shouldTrackImplicitObjectArg` so
they share a single source of truth.
Fixes: #188832
