[lldb] Fix a couple of return type / return value mismatches (#191464)
* `EmulateInstruction::ReadMemory()` returns a boolean value and is used
in boolean contexts, but the return type is specified as `size_t`.
Change it to `bool`. This also aligns it with `WriteMemory()`.
* `ClangExpressionDeclMap::GetSymbolAddress()` returns `false` if
`Target` is not available, but it is expected to return an address.
Change it to return `LLDB_INVALID_ADDRESS`.
* `ValueObject::GetPointeeData()` returns `true`, whereas a return value
of type `size_t` is expected. Change it to return 0 (this code is
unreachable).
[NFC][LowerTypeTests] Add AArch64 and X86 jump table tests with debug info (#192735)
It just recommits test copied from non dbg version.
Implementation is https://github.com/llvm/llvm-project/pull/192736.
[offload] Fix synchronization when record replay is enabled (#193291)
When kernel record replay was enabled, the operations on the current
stream were not synchronized. That's because the current stream was
"ignored", and a new stream was used when RR is active. This is invalid
when there are pending operations on the original stream and can lead to
invalid prologue recording data.
This commit addresses this issue by using the original stream and
synchronizing it explicitly before and after kernel launch. This way, we
ensure the operations are completed before performing the prologue and
epilogue data recording. Additionally, the kernel record replay entry
points are moved to the same layer, in `GenericKernelTy::launch()`.
[runtimes] Enable Fortran only with explicit CMAKE_Fortran_COMPILER (#193332)
Only enable Fortran support when the user (or the bootstrapping build)
passes `-DCMAKE_Fortran_COMPILER=...`.
`enable_language(...)` other than C/CXX reveals problems with the
current build system. LLVM likes to add
`-Wl,--color-diagnostics`
to `CMAKE_EXE_LINKER_FLAGS` whenever possible. The problem is that
`CMAKE_EXE_LINKER_FLAGS` is added to the linker line regardless of which
language is used, but `HandleLLVMOptions.cmake` probes only
`CMAKE_CXX_COMPILER`. Other languages' compilers such as
`CMAKE_CUDA_COMPILER` (`nvcc`) or `CMAKE_Fortran_COMPILER` (`gfortran`)
may not accept the flag. CMake then fails when those compilers are "not
able to compile a simple test program." because it does not accept the
`--color-diagnostics` flag.
`CMAKE_EXE_LINKER_FLAGS` does not support generator expression such that
`$<$<COMPILE_LANGUAGE:C,CXX>:-Wl,--color-diagnostics>` does not work
[6 lines not shown]
[BoundsSafety][NFC] Move LateParsedAttribute outside Parser class; move LateParsedAttrList to DeclSpec.h (#192145)
Preparatory refactoring for llvm/llvm-project#179612, which introduces
late parsing of bounds-safety attributes as type attributes. The new
approach needs LateParsedAttribute accessible from DeclSpec.h (to store
late attr pointers in DeclaratorChunk, Declarator, and DeclSpec), which
cannot depend on Parser.h.
- Move LateParsedDeclaration and LateParsedAttribute to namespace level
in Parser.h
- Move LateParsedAttrList to DeclSpec.h with a forward declaration of
LateParsedAttribute
Other LateParsedDeclaration subclasses (LateParsedClass,
LateParsedPragma, LateParsedMemberInitializer, etc.) remain inside
Parser as they are only created and consumed within Parser and don't
need to cross the Parser/Sema boundary.
Support loader arguments in GPU hermetic tests (#193341)
GPU tests require arguments passed to the loader (like llvm-gpu-loader)
to be placed before the test binary on the command line.
Updated LLVMLibCTestRules.cmake to generate a three-part .params file to
separate loader flags from test arguments and pass environment
overrides. Implicitly added LIBOMPTARGET_STACK_SIZE for NVPTX targets.
Modified format.py to parse this new format and position the loader
arguments correctly before the binary.
[libcxx][Github] Bump container version (#193351)
Now that the rebuilt container images are available with an upgraded
Github runner, bump to the latest image.
[LFI][libunwind] Avoid writing to reserved registers on the `aarch64_lfi` target (#192739)
The registers `x25`, `x26`, `x27`, and `x28` are reserved for the
`aarch64_lfi` target and should not be written/used. See
`llvm/docs/LFI.rst` for more details. They contain fixed constants or
temporaries used as part of assembly-level rewrites of load/store
instructions. The rewriter will reject programs that attempt to write to
these registers. It is technically OK to save/read them (in
`UnwindRegistersSave.S`), but there is no point since there is no need
to restore them (and to maintain LFI's security invariant, they in fact
cannot be written).
[CI] Fix cross-project-tests dependencies (#193323)
We error out in CMake otherwise if we do not enable `clang`. Avoid
adding other dependencies for now as they are optional and otherwise
cause us to build them when using cross-project-tests to test other
projects like lld.
[SSAF] Fix -Wunused-variable (#193344)
We currently take the return value of inserting into a map (the iterator
and insertion boolean) to assert on the value of the insertion boolean.
This is unused in non-asserts builds, so mark it [[maybe_unused]] given
we cannot inline due to the insertion having side effects.
[libcxx][Github] Bump Github Runner to 2.334.0 (#193339)
To stay ahead of the support horizon. Use the same base image to prevent
any differences beyond the runner binary.
[mlir][func] Avoid to create duplicate symbol during conversion (#192342)
`LLVM::lookupOrCreateFn` only checks for an existing `LLVM::LLVMFuncOp`
before creating a new function declaration. When a symbol with the same
name exists as a different op type (e.g., `func.func` that hasn't been
converted to LLVM dialect yet), the function blindly creates a duplicate
`LLVMFuncOp`, which either causes a "redefinition of symbol" error or
silently introduces a renamed symbol (`@free_0`) that won't resolve at
link time.
This happens in practice when user code declares function that is also
used internally by MLIR lowerings. For example, a Fortran `bind(c,
name="free")` declaration produces a `func.func @free` in the IR. When
`memref.dealloc` is lowered (via DeallocOpLowering), it calls
lookupOrCreateFreeFn which calls lookupOrCreateFn — and since the
existing `func.func @free` is not an LLVMFuncOp, a conflicting duplicate
is created.
The fix adds a check in lookupOrCreateFn: before creating a new
[3 lines not shown]
[clang] Suppress glibc C11 extension warning in c-index-test
`c-index-test.c` is still compiled as gnu89 on purpose. That acts as
a useful guard rail: it helps keep the file compatible with older C
dialects instead of silently picking up newer C features because Clang
defaults to a newer language mode.
Ubuntu 26.04 LTS updates glibc's string.h so `strchr`, `strrchr` and
`strstr` are routed through `_Generic`-based macros. When Clang compiles
`c-index-test.c` with `-std=gnu89` and `-pedantic`, that now triggers
`-Wc11-extensions` warnings even though the source itself is not using
C11 features.
Keep the gnu89 check in place and suppress this warning only for Clang
when building c-index-test.
[compiler-rt][profile] Use runtimes-libc-headers in the GPU runtimes build (#192814)
When compiler-rt is built for a GPU target in the same runtimes build
as LLVM-libc, the profile sources `#include <string.h>`, `<limits.h>`,
... Those headers are generated by LLVM-libc for the GPU triple.
A concrete example is the amdgcn runtimes build:
-DLLVM_RUNTIME_TARGETS='default;amdgcn-amd-amdhsa'
-DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES='compiler-rt;libc'
-DRUNTIMES_amdgcn-amd-amdhsa_RUNTIMES_USE_LIBC=llvm-libc
Even though `libc` is configured before `compiler-rt`, both sets of
targets live in the same ninja graph and race each other. Ninja can
start compiling `compiler-rt/lib/profile/InstrProfiling.c` before
LLVM-libc has finished generating its GPU `string.h`, and even when
hdrgen has finished, the profile compile needs `-isystem` pointing at
the generated header tree.
[26 lines not shown]
