TargetParser: Move triple to CMake system name mapping into CMake
Reimplement the triple -> CMAKE_SYSTEM_NAME derivation added in #208773
entirely in CMake, dropping the Python script it introduced.
The previous mechanism widened TRIPLE_OS/TRIPLE_ENV in TripleName.def with
a CMake system name column and parsed it from a Python helper invoked by
CMake at configure time. Two problems motivated this rework:
- The CMake system name is a property of CMake (and can vary by CMake
version), not of llvm::Triple, so it does not belong in the shared
triple name table. The C++ never consumed the added column.
- Invoking Python from CMake at configure time is an unwanted build
dependency, and the Python-driven lit test broke Windows bots where the
interpreter path contains a space.
Revert the TripleName.def/Triple.cpp column back to the two-argument
macros, delete the Python script and its unittest, and reimplement the
mapping as a self-contained pure-CMake module. The classification still
[6 lines not shown]
[X86] Fix null dereference in optimizeCompareInstr after lzcnt/tzcnt (#224282)
#210069 added `LTZCNTInst` to the exit condition of the backward scan of
`optimizeCompareInstr()`:
```c++
if (MI || Sub || LTZCNTInst)
break;
```
but it assigns `MI = LTZCNTInst` only inside the *forward* scan's
"EFLAGS is
used by this instruction" branch. When the forward scan never reaches
that
branch, both `MI` and `Sub` stay null.
However later code was built on the idea that one of them is not null.
Added a MIR test that would crash before but gets fixed by this
additional check.
Used AI for code review and comment/PR/test formatting/writing
java/openjdk27: Add port
Upstream release notes:
https://jdk.java.net/27/release-notes
In addition this release contains the following BSD specific fixes:
- Fix os::naked_short_nanosleep on OpenBSD when < 20 miliseconds.
- Only return symbols that match the requested address for dladdr(3) on
BSD.
Reviewed by: pkubaj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59519
java/openjdk27: Add port
Upstream release notes:
https://jdk.java.net/27/release-notes
In addition this release contains the following BSD specific fixes:
- Fix os::naked_short_nanosleep on OpenBSD when < 20 miliseconds.
- Only return symbols that match the requested address for dladdr(3) on
BSD.
Reviewed by: pkubaj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59519
[SLP]Fix APInt assertion in emitReusedOps for narrow types
The repeat count of a reused scalar may not fit the reduction element
type (e.g. count 2 in i1), tripping the APInt isUIntN assertion when
building the to-mul scale constant. Truncate the count to the element
bitwidth; the modular reduction arithmetic keeps the result equivalent.
Fixes #225279
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/225376
[flang][cuda] Record implicit pinned attribution in module files
Under -gpu=mem:pinned an unattributed ALLOCATABLE is attributed as pinned by
the compiler, the same way -gpu=mem:managed attributes one as managed, but
only the latter recorded that it had done so. The module file therefore spelled
an implicitly applied PINNED the same as one the user wrote, and a reader
treated it as a user requirement: adding -gpu=mem:pinned to a module's build
rejected its OpenACC-only consumers over an attribute the user never wrote.
Record the attribution for pinned as well, so it is written as
PINNED(IMPLICIT) and consumers can tell the two apart.
[flang][cuda] Record implicit managed attribution in module files (#224601)
An implicit attribute the compiler applied under `-gpu=mem:managed` is
written into the module file the same way a user-written one is, so a
reader cannot tell them apart. It then treats the attribute as a user
requirement: allocating such a component in a DEVICE object is rejected,
and the memory space the user did ask for on the object no longer wins.
Spell the distinction in the module file as `MANAGED(IMPLICIT)`,
modelled on `INTENT(IN)`: CUDA-data-attr gains an optional parenthesized
qualifier, carried by a new CUDADataAttrSpec parse-tree node in AttrSpec
and ComponentAttrSpec. ATTRIBUTES(...) keeps the bare attribute, so the
qualifier cannot be written there.
The attribute itself is still written out, so a component keeps the same
memory space no matter which options a consumer is compiled with.
Also stop an implicitly applied attribute from making a module a definer
of CUDA symbols. Without this, adding `-gpu=mem:managed` to a module's
build rejects its OpenACC-only consumers over an attribute the user
never wrote.
[SLP]Fix SCEV type mismatch when a checked base crosses a cross-width addrspacecast
getUnderlyingObject strips addrspacecast, so a base object can have a
different address type than the access pointer, mixing SCEV types in the
bounds computation.
Fixes #225280
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/225374
[clang][bytecode] Add a bytecode RUN line for constant-builtins-2.c (#225305)
So changes to this file correctly trigger changes to the bytecode
interpreter.
[clang][OpenMP] Fix statement expressions in loop bounds being emitted more than once (#224939)
Fixes #153987
When Sema builds the helper expressions for an OpenMP loop, a bound that
evaluates to a constant is reused directly instead of being captured
into a `.capture_expr.` variable, so the same expression node is spliced
into the init, update, final and precondition helpers. That is fine for
`10 + 1`, but a statement expression like `({int a = 0; 0;})` declares a
variable, and emitting the shared node several times re-declares `a` and
trips `Decl already exists in LocalDeclMap!` in CodeGen. The report only
looked like a bytecode-interpreter issue because the old evaluator
happened to refuse `({float a = 0; a;})` and the new one didn't; the
unused-variable form crashes with both.
The capture decision now treats any expression containing a statement
expression as non-constant, so it goes through the existing capture
path: evaluated once in the pre-init statement, with every helper
reading the captured value. A bound of a non-rectangular loop can't be
[2 lines not shown]
[flang][debug] Do not scope device subprograms at the host procedure. (#225121)
A target device module holds the internal procedures and the outlined
target regions, but not the host procedure they are contained in, which
only the host runs. Scoping them at it leaves a DW_TAG_subprogram with
no code as their parent, and a debugger does not look inside such a
subtree, so the variables of a device internal procedure, and of a
kernel outlined from one, cannot be read even though they are in the
DWARF.
Scope them at the file instead when compiling for the device. Nothing on
the device reads a variable through the host procedure's scope. An
omp.target region is IsolatedFromAbove, so a variable of the host that
the region uses is brought in as one of the region's own arguments
rather than through host association, and a declare target internal
procedure that does need the host association tuple cannot be called
from a target region at all, because passing the tuple in would be the
same violation. Only the name qualification is lost: a frame prints
"add" rather than "test::add", and the full nesting is still in the
[4 lines not shown]
