This patch adds a lit test to clang format to ensure that the
ClangFormatStyleOptions doc page has been updated appropriately. The
test just runs the automatic update script and diffs the outputs to
ensure they are the same.
The AMDGPUAnnotateKernelFeatures pass infers the "amdgpu-calls" and
"amdgpu-stack-objects" attributes, which are used to infer whether we
need to initialize flat scratch. This is, however, not precise. Instead,
we should use AMDGPUAttributor and infer amdgpu-no-flat-scratch-init on
kernels. Refer to https://github.com/llvm/llvm-project/issues/63586 .
Adds support for the following MSVC intrinsics:
* `_InterlockedCompareExchangePointer_acq`
* `_InterlockedCompareExchangePointer_rel`
* `_InterlockedExchangePointer_acq`
* `_InterlockedExchangePointer_nf`
* `_InterlockedExchangePointer_rel`
These are documented at:
<https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=msvc-170#interlocked-intrinsics>
NOTE: `_InterlockedCompareExchangePointer_nf` is not being added since
it already exists, although it was incorrectly added for all
architectures instead of being Arm & AArch64 specific.
This change also unifies how the pointer and non-pointer interlocked
compare-exchange intrinsics are being handled.
The original implementation rejected some valid constructs. The rule is
supposed to be:
Gang-on-Kernel cannot have a gang in its region
Worker cannot have a worker or gang in its region
Vector cannot have worker, gang, or vector in its region.
The previous implementation improperly implemented that vector wasnt'
allowed in the other two. This patch fixes it and adds testing for it.
Currently, we support `-wdeprecated-array-compare` for C++20 or above
and don't report any warning for older versions, this PR supports
`-Warray-compare` for older versions and for GCC compatibility.
Fixes#114770
The meaning of `__ARM_NEON_SVE_BRIDGE` was changed here:
https://github.com/ARM-software/acle/pull/362
Such that it should be defined to `1` if the `arm_neon_sve_bridge.h`
header file is available, which is the case for Clang.
This reverts commit 54db16221c92eb52efbea90ad5b5d2a1d00cda3e.
Check for existence of __SIZOEF_INT128__ so we don't run those
tests on targets that don't have int128.
This consists of:
* Make these instructions part of FPMathOperator.
* Adjust bitcode/ir readers/writers to expect fast math flags on these
instructions.
* Make IRBuilder set the fast math flags on these instructions.
* Update langref and release notes.
* Update a bunch of tests. Some of these are due to InstCombineCasts
incorrectly adding fast math flags to fptrunc, which will be fixed in a
later patch.
This aligns with the logic in `TreeTransform::RebuildQualifiedType()`
where we refrain from adding const qualifiers to function types.
Previously, we seemed to overlook this edge case when copy-capturing a
variable that is of function type within a const-qualified lambda.
This issue also reveals other related problems as in incorrect type
printout and a suspicious implementation in DeduceTemplateArguments. I
decide to leave them in follow-up work.
Fixes#84961
Fixes https://github.com/llvm/llvm-project/issues/115990.
MSVC mangling got inadvertently broken here,
https://github.com/llvm/llvm-project/pull/83997, when it was fixed what
decl context a lambda is apart of for uneval contexts.
https://godbolt.org/z/K6jb5v145 for reference.
Given the following code snippet
```
template <typename T>
concept C = requires(const T& t)
{
{ T::test([](){}) };
};
template<typename T, typename = void>
struct Widget;
template <C T>
struct Widget<T> {};
struct Baz
{
template<typename F>
static constexpr decltype(auto) test(F&& f) {}
};
void test()
{
Widget<Baz> w;
}
```
`Baz::test` has a deduced return type which means we must instantiate
that template even in an unevaluated context.
The lambda inside the concept is within the decl context of `struct
Widget<T> {};`. So we end up needing to mangle a name of
`Baz::test<Widget<template-type-0-0>::lambda()>>()` since the lambda
isn't apart of an instantiated substituted class `Widget` yet at the
point the lambda is instantiated.
Upon template instantation of `test` we end up asking for the mangled
name so we can add this instantiation to `CodeGenModule::DefferredDecls`
since `test` is now referenced but not yet used.
I think the longer term more correct solution is to key `DefferedDecls`
off of something else than the mangled name to avoid having to mangle
names for instantations that are referenced but will never be used since
they are only instantiated from an unevaluated context.
As a fix for the regression I just created a custom mangling scheme for
this case since MSVC has no comparable naming scheme as such a template
will never be emitted into the resulting obj as it will never be used.
Get inout/out parameters working for HLSL Arrays.
Utilizes the fix from #109323, and corrects the assignment behavior
slightly to allow for Non-LValues on the RHS.
Closes#106917
---------
Co-authored-by: Chris B <beanz@abolishcrlf.org>
Make the new diagnostic group a subgroup of the following diagnostic
groups:
-Wpre-c23-compat
-Wgnu-zero-variadic-macro-arguments
-Wc++20-extensions
-Wc23-extensions
This change is needed as 5231005193afb8db01afe9a8a1aa308d25f60ba1 made
it impossible to use -Wno-gnu-zero-variadic-macro-argumentsis to silence
the warning.
rdar://139234984
This allows
`__attribute__((target("prefer-256-bit")))` /
`__attribute__((target("no-prefer-256-bit")))` to create variants of a
functions with 256/512 bit vector sizes within the same application.
This PR addresses #116880
Updated
[LanguageExtensions.rst](https://github.com/llvm/llvm-project/blob/main/clang/docs/LanguageExtensions.rst)
to include support for C++11 enumerations with a fixed underlying type
in C. Included a note that this is only a language extension prior to
C23.
Updated
[Features.def](https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/Features.def)
to support for `__has_extension(c_fixed_enum)` by added it as a feature
(for C23) and an extension (for <C23).
Updated
[enum.c](https://github.com/llvm/llvm-project/blob/main/clang/test/Sema/enum.c)
to ensure support of C++11 enumerations with a fixed underlying type in
both <C23 and C23, as well as the functionality of
`__has_extension(c_fixed_enum)`.
---
In enum.c, I encountered a warning when testing enumerations with a
fixed underlying type in pre-C23 modes. Specifically, the test produces
the warning: `enumeration types with a fixed underlying type are a C23
extension`. I am unsure if this warning is expected behavior, as
enumerations with a fixed underlying type should behave identically in
pre-C23 and C23 modes. I expected that adding `c_fixed_enum` as an
extension would fix this warning. Feedback on whether this is correct or
requires adjustment would be appreciated.
I was also unsure of the best location for the additions in
`Features.def`, I would appreciate advice on this as well
Note that this is my first PR to LLVM, so please liberally critique it!
'num_gangs', 'num_workers', and 'vector_length' are similar to
eachother, and are all the same implementation as for compute
constructs, so this patch just enables them and adds the necessary
testing to ensure they work correctly. These will get more complicated
when they get combined with 'gang', 'worker', 'vector' and 'reduction',
but those restrictions will be implemented when those clauses are
enabled.
Unlike the previous version
(https://github.com/llvm/llvm-project/pull/114978), this patch also
removes an unnecessary assert that causes Clang to crash when compiling
such tests. (clang/lib/AST/DeclCXX.cpp)
https://lab.llvm.org/buildbot/#/builders/52/builds/4021
```c++
template <class T>
class X {
public:
X() = default;
virtual ~X() = default;
virtual int foo(int x, int y, T &entry) = 0;
void bar() {
struct Y : public X<T> {
Y() : X() {}
int foo(int, int, T &) override {
return 42;
}
};
}
};
```
the assertions:
```c++
llvm-project/clang/lib/AST/DeclCXX.cpp:2508: void clang::CXXMethodDecl::addOverriddenMethod(const CXXMethodDecl *): Assertion `!MD->getParent()->isDependentContext() && "Can't add an overridden method to a class template!"' failed.
```
I believe that this assert is unnecessary and contradicts the logic of
this patch. After its removal, Clang was successfully built using
itself, and all tests passed.
Temporarily revert the patch to give downstream teams some time to clean up their codebases.
This reverts commit 4849d593ab07c47f9f520bea636f62d159d57006.
Emit the "cannot be applied to types" warning instead of silently
ignoring the attribute when it's attempted to be used on a type (instead
of a function argument or the function definition).
Before this commit, the warning has been printed when the attribute was
(mis)used on a decl-specifier, but not in other places in a declarator.
Examples where the warning starts being emitted with this commit:
```
int * [[clang::lifetimebound]] x;
void f(int * [[clang::lifetimebound]] x);
void g(int * [[clang::lifetimebound]]);
```
Note that the last example is the case of an unnamed function parameter.
While in theory Clang could've supported the `[[clang::lifetimebound]]`
analysis for unnamed parameters, it doesn't currently, so the commit at
least makes the situation better by highlighting this as a warning
instead of a silent ignore - which was reported at #96034.
The NTTP argument appearing inside a trailing return type of a generic
lambda would have us check for potential lambda captures, where the
function needs GLTemplateParameterList of the current LSI to tell
whether the lambda is generic.
The lambda scope in this context is rebuilt by the
LambdaScopeForCallOperatorInstantiationRAII when substituting the lambda
operator during template argument deduction. Thus, I think the template
parameter list should be preserved in the rebuilding process, as it
seems otherwise innocuous to me.
Fixes#115931
This introduces `__builtin_hlsl_resource_getpointer`, which lowers to
`llvm.dx.resource.getpointer` and is used to implement indexing into
resources.
This will only work through the backend for typed buffers at this point,
but the changes to structured buffers should be correct as far as the
frontend is concerned.
Note: We probably want this to return a reference in the HLSL device
address space, but for now we're just using address space 0. Creating a
device address space and updating this code can be done later as
necessary.
Fixes#95956
Like collapse, this clause has only mild changes that need to be made.
Most of the associated work for the RAII container was already done
previously, so this is mostly just updating the diagnostics to properly
emit the right construct.
Most of the restrictions on 'collapse' involve the contents of the loop,
so this extends enforcement of all of that to all combined construct
loops, and alters the diagnostics to better reflect the construct it is
associated with.
