[flang][cuda] Implicitly attribute allocatables/pointers under -gpu=unified (#209292)
When `-gpu=unified` is in effect, allocatables and pointers with no
explicit CUDA data attribute were left with no data attribute, and were allocated
as ordinary host memory. Under unified memory, such objects must be
reachable from the device; leaving them as plain host allocations makes device kernels
fault on systems that do not provide transparent host-memory access.
The existing code here already assigned `Managed` implicitly under
`-gpu=managed` (when CUDA Fortran is enabled). This extends that handling to
`-gpu=unified`: prefer the `Unified` attribute where it is legal (host subprogram, main
program, or derived-type component) so generic resolution still selects the unified
specific, and fall back to `Managed` elsewhere (module scope, device
subprograms). Both attributes route allocation through the same managed
allocator, so this keeps the allocation device-accessible while avoiding
spurious `ATTRIBUTES(UNIFIED)` legality errors.
The attribution stays gated on CUDA Fortran being enabled, preserving
the existing behavior for non-CUDA-Fortran translation units.
[Hexagon] Fix fpround fp32 -> fp16 pattern (#199704)
The pattern was passing hi and lo in the wrong order to `vcvt` causing
the final output after `vdeal` to be incorrect.
[orc-rt] Hoist run-alloc-actions functions, add error reporting. (#209356)
Hoist runFinalizeActions and runDeallocActions into AllocAction.h and
turn them into function templates with a ReportErrorFn argument that
enables error reporting. This is used to report errors from dealloc
actions.
Update SimpleNativeMemoryMap to direct such errors to the Session via
ReportErrorsViaSession.
Add unit tests covering the new error-reporting paths.
textproc/py-commonmark: Remove duplicate
textproc/py-CommonMark should be renamed into textproc/py-commonmark though
to match https://pypi.org/project/commonmark/
PR: 296071
Reported by: Matthew Wener <bugzilla at FreeBSD.org>
[SystemZ][z/OS] Add z/OS archive writing support (#200087)
This patch implement z/OS archive writing in ArchiveWriter and adds the
option `llvm-ar --format=zos`.
Moreover, This patch teaches `llvm-ar` to emit z/OS-compatible archives
by:
- Detecting GOFF object files as z/OS members
- Writing z/OS member headers and archive magic
- Converting archive headers and symbol-name string tables to EBCDIC
- Emitting z/OS symbol table entries
- Using EBCDIC newline padding bytes
- Add a z/OS-specific workaround for empty symbol tables by emitting a
dummy blank symbol to satisfy binder requirements.
[Hexagon] Register MachineKCFILegacy pass in LLVMInitializeHexagonTarget (#209245)
Hexagon's target-init function never called
initializeMachineKCFILegacyPass(PR), unlike X86, ARM, AArch64, and
RISCV. Since PassRegistry is process-wide and each target's init
function registers passes as a side effect when linked into the same
binary, whether test/CodeGen/Hexagon/kcfi.ll passed depended on whether
some other target providing that registration was also built into llc,
rather than on Hexagon's own configuration.
Wait for the default route to appear during docker startup check
## Problem
Apps fail to start on every boot with "Unable to determine default interface" whenever the default route is installed asynchronously -- e.g. a DHCP bridge that has to converge through STP forward-delay before dhcpcd can acquire a lease and install the route. `validate_interfaces` read the route table exactly once at system.ready and gave up immediately if no default route was present yet, so the check lost the race by a few seconds. Unsetting and re-setting the apps pool only worked around it because that re-runs the check later, after the route already exists.
## Solution
`wait_for_default_interface_link_state_up` now polls `get_default_interface()` once a second within the existing IFACE_LINK_STATE_MAX_WAIT budget instead of reading once, so a late-arriving default route is picked up rather than aborting startup. Returns (None, False) only if no default interface shows up within the whole window.
(cherry picked from commit 849a61e236a0f73c39fd115b154410d338608c5a)
NAS-141446 / 27.0.0-BETA.1 / Wait for the default route to appear during docker startup check (#19279)
## Problem
Apps fail to start on every boot with "Unable to determine default
interface" whenever the default route is installed asynchronously --
e.g. a DHCP bridge that has to converge through STP forward-delay before
dhcpcd can acquire a lease and install the route. `validate_interfaces`
read the route table exactly once at system.ready and gave up
immediately if no default route was present yet, so the check lost the
race by a few seconds. Unsetting and re-setting the apps pool only
worked around it because that re-runs the check later, after the route
already exists.
## Solution
`wait_for_default_interface_link_state_up` now polls
`get_default_interface()` once a second within the existing
IFACE_LINK_STATE_MAX_WAIT budget instead of reading once, so a
late-arriving default route is picked up rather than aborting startup.
Returns (None, False) only if no default interface shows up within the
whole window.
[SSAF] Filter out type-constrained pointers from all reachable unsafe pointers
Integrate the TypeConstrainedPointers analysis results into
UnsafeBufferReachableAnalysis. The final result is filtered with
type-constrainted pointers.
The pointer flow graph is untouched. Removing type-constrained
pointers from the graph will introduce unsoundness.
Final step for rdar://179151541&179151882
[compiler-rt][GWP-ASan] Use no-op backtrace if execinfo.h missing (#201266)
Guard backtrace_linux_libc.cpp with __has_include(<execinfo.h>) so that
targets without it (e.g. musl libc) get null stubs instead of a build
failure.
ena: Put taskqueues into correct domain if !RSS
When compiled without 'options RSS', the ena driver created taskqueues
using taskqueue_start_threads_cpuset passing a mask value of NULL,
both in the ena_setup_tx_resources path (for enqueues) and in the
ena_create_io_queues path (for the completion-processing).
In the default configuration, on most EC2 instances, this results in
taskqueues running in the right NUMA domain, but only by accident; in
non-default configurations (e.g. with with multiple EBS volumes
attached and associated NVMe taskqueues) the taskqueues may land in
the wrong NUMA domain even on instance types where the one-EBS-one-ENA
case produces the desired results.
Set (struct ena_que)->domain and use that to inform the choice of CPU
sets. On a c8gn.48xlarge EC2 instance this doubles throughput on a
32-TCP-stream benchmark.
Reviewed by: akiyano
[3 lines not shown]
[BPF][NewPM] Port AsmPrinter
This is necessary to make the new pass manager fully supported for BPF.
This should be the last patch in the series.
Reviewers: yonghong-song, arsenm, eddyz87
Pull Request: https://github.com/llvm/llvm-project/pull/207854
[BPF][NewPM] Port BPFMIPreEmitCheckingPass
Standard pass porting. Needed to make BPF fully support the NewPM.
Reviewers: yonghong-song, aeubanks, eddyz87
Pull Request: https://github.com/llvm/llvm-project/pull/207850
