Fix for regression #130917, changes in #111992 were too broad. This change reduces scope of previous fix. Added `ExternalASTSource::wasThisDeclarationADefinition` to detect cases when FunctionDecl lost body due to declaration merges.
CK is using either inline assembly or inline LLVM-IR builtins to
generate buffer_load_dword lds instructions.
This patch exposes this instruction as a Clang builtin available on gfx9 and gfx10.
Related to SWDEV-519702 and SWDEV-518861
In ecc7e6ce4, we tried to inspect the `LambdaScopeInfo` on stack to
recover the instantiating lambda captures. However, there was a mismatch
in how we compared the pattern declarations of lambdas: the constraint
instantiation used a tailored `getPatternFunctionDecl()` which is
localized in SemaLambda that finds the very primal template declaration
of a lambda, while `FunctionDecl::getTemplateInstantiationPattern` finds
the latest template pattern of a lambda. This difference causes issues
when lambdas are nested, as we always want the primary template
declaration.
This corrects that by moving `Sema::addInstantiatedCapturesToScope` from
SemaConcept to SemaLambda, allowing it to use the localized version of
`getPatternFunctionDecl`.
It is also worth exploring to coalesce the implementation of
`getPatternFunctionDecl` with
`FunctionDecl::getTemplateInstantiationPattern`. But I’m leaving that
for the future, as I’d like to backport this fix (ecc7e6ce4 made the
issue more visible in clang 20, sorry!), and changing Sema’s ABI would
not be suitable in that regards. Hence, no release note.
Fixes https://github.com/llvm/llvm-project/issues/133719
A previous checkin used a workaround to generate the nsw flag where
needed for unary ops. This change upstreams a subsequent change that was
made in the incubator to generate the flag correctly.
Cmake automatically generates dependency files with all compilation
options provided by users. When users use `--offload-compress` for HIP
compilation, it causes warnings when cmake generates dependency files.
Claim this option to suppress warnings.
With -fpatchable-function-entry (or the patchable_function_entry
function attribute), we emit records of patchable entry locations to the
__patchable_function_entries section. Add an additional parameter to the
command line option that allows one to specify a different default
section name for the records, and an identical parameter to the function
attribute that allows one to override the section used.
The main use case for this change is the Linux kernel using prefix NOPs
for ftrace, and thus depending on__patchable_function_entries to locate
traceable functions. Functions that are not traceable currently disable
entry NOPs using the function attribute, but this creates a
compatibility issue with -fsanitize=kcfi, which expects all indirectly
callable functions to have a type hash prefix at the same offset from
the function entry.
Adding a section parameter would allow the kernel to distinguish between
traceable and non-traceable functions by adding entry records to
separate sections while maintaining a stable function prefix layout for
all functions. LKML discussion:
https://lore.kernel.org/lkml/Y1QEzk%2FA41PKLEPe@hirez.programming.kicks-ass.net/
OpenACC Github PR#499 defines the pqr-list as having at least 1 item. We
already handle that for all but 'wait', so this patch just does the work
to add it for 'wait', plus adds tests.
This patch introduces the `vmem-to-lds-load-insts` target feature, which
can be used to enable builtins `__builtin_amdgcn_global_load_lds` and
`__builtin_amdgcn_raw_ptr_buffer_load_lds` on platforms which have this
feature.
This feature is only available on gfx9/10.
A limitation of using a common target feature for both builtins is that
we could have made `__builtin_amdgcn_raw_ptr_buffer_load_lds` available
on gfx6,7,8.
This was added in OpenACC PR #511 in the 3.4 branch. From an AST/Sema
perspective this is pretty trivial as the infrastructure for 'if'
already exists, however the atomic construct needed to be taught to take
clauses. This patch does that and adds some testing to do so.
This PR does the following:
1. Use SPIR-V backend to do LLVM to SPIR-V translation inside
clang-sycl-linker
2. Remove llvm-spirv translator from clang-sycl-linker Currently, no
SPIR-V extensions are enabled for SYCL compilation flow. This will be
updated in subsequent commits.
Thanks
Note: This is one of the many PRs being introduced to add SYCL
programming model support to LLVM
([RFC](https://discourse.llvm.org/t/rfc-add-sycl-programming-model-support/50812)).
---------
Signed-off-by: Arvind Sudarsanam <arvind.sudarsanam@intel.com>
Reverts llvm/llvm-project#133265
This causes the whole libc++ CI to fail, since we're not building
against a compiler built from current trunk. Specifically, the CMake
changes causes some feature detection to fail, resulting in CMake
being unable to configure libc++.
For btf_type_tag implementation, in order to have the same results with
clang (__attribute__((btf_type_tag("...")))), gcc intends to use c2x
syntax '[[...]]'. Clang also supports similar c2x syntax. Currently, the
clang selftest contains the following five tests:
```
attr-btf_type_tag-func.c
attr-btf_type_tag-similar-type.c
attr-btf_type_tag-var.c
attr-btf_type_tag-func-ptr.c
attr-btf_type_tag-typedef-field.c
```
Tests attr-btf_type_tag-func.c and attr-btf_type_tag-var.c already have
c2x syntax test.
Test attr-btf_type_tag-func-ptr.c does not support c2x syntax when
'__attribute__((...))' is replaced with with '[[...]]'. This should not
be an issue since we do not have use cases for function pointer yet.
This patch added '[[...]]' syntax for
```
attr-btf_type_tag-similar-type.c
attr-btf_type_tag-typedef-field.c
```
Split diagnosing base class qualifiers from the ``-Wignored-Qualifiers``
diagnostic group into a new ``-Wignored-base-class-qualifiers``
diagnostic group (which is grouped under ``-Wignored-qualifiers``).
Fixes#131935
C99 introduced macros of the form `INTn_C(v)` which expand to a signed
or unsigned integer constant with the specified value `v` and the type
`int_leastN_t`. Clang's initial implementation of these macros used
token pasting to form the integer constants, but this means that users
cannot define a macro named `L`, `U`, `UL`, etc before including
`<stdint.h>` (in freestanding mode, where Clang's header is being used)
because that could form invalid token pasting results. The new
definitions now use the predefined `__INTn_C` macros instead of using
token pasting. This matches the behavior of GCC.
Fixes#85995
There is special logic to detect the hip runtime when llvm is installed
with Spack. It works by matching the install prefix of llvm against
`llvm-amdgpu-*` followed by effectively globbing for
```
<llvm dir>/../hip-x.y.z-*/
```
and checking there is exactly one such directory.
I would suggest to remove autodetection for the following reasons:
1. In the Spack ecosystem it's by design that every package lives in
its own prefix, and can only know where its dependencies are
installed, it has no clue what its dependents are and where they are
installed. This heuristic detection breaks that invariant, since `hip`
is a dependent of `llvm`, and can be surprising to Spack users.
2. The detection can lead to false positives, since users can be using
an llvm installed "upstream" with their own build of hip locally, and
they may not realize that clang is picking up upstream hip instead of
their local copy.
3. It only works if the directory name is `llvm-amdgpu-*` which happens
to be the name of AMD's fork of `llvm`, so it makes no sense that
this code lives in the main LLVM repo for which the Spack package
name is `llvm`. Feels wrong that LLVM knows about Spack package
names, which can change over time.
4. Users can change the install directory structure, meaning that this
detection is not robust under config changes in Spack.
During additional testing I spotted that vector deleting dtor calls
operator delete, not operator delete[] when performing array deletion.
This patch fixes that.
pragma-loop.cpp contains tests for loop metadata generated by pragma
directives. These tests didn't work as (perhaps) expected. This is
because the regex `.*` consumes multiple elements in the metadata. For
example, there was a check directive like this.
```
// CHECK: ![[LOOP_9]] = distinct !{![[LOOP_9]], ![[WIDTH_8:.*]], ![[FIXED_VEC]], ...}
```
In the above case, `[[WIDTH_8]]` would have been expected to match a
node like `[[WIDTH_8]] = !{!"llvm.loop.vectorize.width", i32 8}`.
However, since there is no check directive to verify the contents of
`[[WIDTH_8]]`, the regex `.*` consumed more than one element. There were
other similar cases.
This patch fixes the problem by not using regex matcher in the metadata
content (except for follow-up metadata). Instead, it uses string
variables whose contents are validated elsewhere.
Related:
https://github.com/llvm/llvm-project/pull/131985#discussion_r2014369699
This is a follow-up to #132129.
Currently, only `Parser` and `SemaBase` get a `DiagCompat()` helper; I’m
planning to keep refactoring compatibility warnings and add more helpers
to other classes as needed. I also refactored a single parser compat
warning just to make sure everything works properly when diagnostics
across multiple components (i.e. Sema and Parser in this case) are
involved.
This reverts an earlier attempt
(adb0d8ddceb143749c519d14b8b31b481071da77 and
50e5411e4247421fd606f0a206682fcdf0303ae3) to support these expansions,
which was limited to type arguments and which subverted the purpose
of SubstTemplateTypeParmType.
This propagates the ArgumentPackSubstitutionIndex along with the
AssociatedConstraint, so that the pack expansion works, without
needing any new transforms or otherwise any changes to the template
instantiation process.
This keeps the tests from the reverted commits, and adds a few more
showing the new solution also works for NTTPs.
Fixes https://github.com/llvm/llvm-project/issues/131798
This PR has the following changes:
Replace llvm-link with calls to linkInModule to link device files Add
-print-linked-module option to dump linked module for testing Added a
test to verify that linking is working as expected. We will eventually
move to using thin LTO for linking device inputs.
Thanks
---------
Signed-off-by: Arvind Sudarsanam <arvind.sudarsanam@intel.com>
The combination of `-fcomplex-arithmetic=promoted` and `mno-x87` for
`double` complex division is leading to a crash.
See https://godbolt.org/z/189G957oY
This patch fixes that.
Implement all single-multi {BF/F/S/U/SU/US}MOP4{A/S} instructions in
clang and llvm following the acle in
https://github.com/ARM-software/acle/pull/381/files.
This PR depends on https://github.com/llvm/llvm-project/pull/127797
This patch updates the semantics of template arguments in intrinsic
names for clarity and ease of use. Previously, template argument numbers
indicated which character in the prototype string determined the final
type suffix, which was confusing—especially for intrinsics using
multiple prototype modifiers per operand (e.g., intrinsics operating on
arrays of vectors). The number had to reference the correct character in
the prototype (e.g., the ‘u’ in “2.u”), making the system cumbersome and
error-prone.
With this patch, template argument numbers now refer to the operand
number that determines the final type suffix, providing a more intuitive
and consistent approach.
Fixes an assertion when referencing an out-of-bounds parameter via a
function attribute whose argument list refers to parameters by index and
the function is variadic. e.g.,
__attribute__ ((__format_arg__(2))) void test (int i, ...) { }
Fixes#61635
In `Sema::BuildStdInitializerList`, check that the synthesized
template-id `std::initializer_list<T>` is valid (which might not be the
case if the template has associated constraints or subsequent parameters
with default arguments) before forming the type.
Fixes#132256
Destructor calls were emitted without convergence intrinsics when building for SPIR-V, which means invalid IR since we
mixed controlled and non-controlled convergence.
Currently arm_neon.h emits C-style casts to do vector type casts. This
relies on implicit conversion between vector types to be enabled, which
is currently deprecated behaviour and soon will disappear. To ensure
NEON code will keep working afterwards, this patch changes all this
vector type casts into bitcasts.
Co-authored-by: Momchil Velikov <momchil.velikov@arm.com>
Prior to this PR, we were emitting warnings for Objective-C ivars and
properties if the forward declaration of the type appeared first in a
non-system header. This PR fixes the checker so tha we'd ignore ivars
and properties defined for a forward declared type.
Although combining -fveclib=ArmPL with -nostdlib is a rare situation, it
should still be supported correctly and should effect in avoidance of
linking against libm.
