We already evaluate the initializers for all global variables, as
required by the standard. Leverage that evaluation instead of trying to
separately validate static class members.
This has a few benefits:
- Improved diagnostics; we now get notes explaining what failed to
evaluate.
- Improved correctness: is_constant_evaluated is handled correctly.
The behavior follows the proposed resolution for CWG1721.
Fixes#88462. Fixes#99680.
Fixes https://github.com/llvm/llvm-project/issues/142430
firstbit intrinsics were using the wrong vector type which causes some
conversions to fail. This PR switches them to ExtVector which resolves
the issue
This separates semantic analysis from parsing by moving `RootSignatureDecl` creation, scope storage, and lookup logic into
`SemaHLSL`.
For more context see:
https://github.com/llvm/llvm-project/issues/142834.
- Define `ActOnStartRootSignatureDecl` and `ActOnFinishRootSignatureDecl` on `SemaHLSL`
- NFC so no test changes.
Resolves: https://github.com/llvm/llvm-project/issues/142834
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
This adds a number of functions to ASTContext to query whether a
type contains data protected with address discriminated pointer
authentication, and whether the protected values are just vtable
pointers, or if there are other address discriminated types included.
For the standardized version, __builtin_is_cpp_trivially_relocatable
this means accepting types where the only address discriminated
values are vtable pointers. Other address discriminated types are
not considered relocatable. In addition to that any union containing
any address discriminated data, including vtable pointers, is not
relocatable.
For the old deprecated __builtin_is_trivially_relocatable we reject
any type containing any address discriminated value, as it is
semantically intended as being a "is this memcopyable" which is
not true for anything with address discrimination.
This PR does not update the codegen for __builtin_trivially_relocate,
that will be in a follow on PR that is much more complex.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
fix https://github.com/llvm/llvm-project/issues/141789
The direct cause of infinite recursion is that `T` is changing from
`struct X` and `S<X>` infinitely, this pr add a check that if `T`
visited before then return false directly.
```plaintext
/home/backlight/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:7196] FD->getType().getAsString()=struct X, T.getAsString()=S<X>, FD->getType().getCanonicalType().getUnqualifiedType().getAsString()=struct X, CanUnqualT.getAsString()=struct S<struct X>,
/home/backlight/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:7196] FD->getType().getAsString()=S<X>, T.getAsString()=struct X, FD->getType().getCanonicalType().getUnqualifiedType().getAsString()=struct S<struct X>, CanUnqualT.getAsString()=struct X,
```
https://github.com/llvm/llvm-project/pull/104829 fix similar infinite
recursion, but I think it is no longer needed so I kind of revert it.
Reverts llvm/llvm-project#143309
Someone needs to go through the libc++ tests and update the diagnostics
checks in those tests (ie, i don't believe there was anything wrong with
the PR, but it impacts libc++ tests nonetheless
Followup to #125526. This expands the logic of the
unique-object-duplication warning so that it also works for windows
code.
For the most part, the logic is unchanged, merely substituting "has no
import/export annotation" in place of "has hidden visibility". However,
there are some small inconsistencies between the two; namely, visibility
is propagated through nested classes, while import/export annotations
aren't.
This PR:
1. Updates the logic for the warning to account for the differences
between posix and windows
2. Changes the warning message and documentation appropriately
3. Updates the tests to cover windows, and adds new test cases for the
places where behavior differs.
This PR was tested by building chromium (cross compiling linux->windows)
with the changes in place. After accounting for the differences in
semantics, no new warnings were discovered.
Added explanation why a is constructible evaluated to false. Also fixed
problem with ```ExtractTypeTraitFromExpression```. In case
```std::is_xxx_v<>``` with variadic pack it tries to get template
argument, but fails in expression ```Arg.getAsType()``` due to
```Arg.getKind() == TemplateArgument::ArgKind::Pack```, but not
```TemplateArgument::ArgKind::Type```.
Add parentheses around the assert conditions.
Without this gcc warned like
../lib/Target/AMDGPU/GCNSchedStrategy.cpp:2250: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
2250 | NewMI != RegionBounds.second && "cannot remove at region end");
and
../../clang/lib/Sema/SemaOverload.cpp:11326:39: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
11326 | DeferredCandidatesCount == 0 &&
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
11327 | "Unexpected deferred template candidates");
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This builds upon #101101 from @jyu2-git, which used compiler-generated
mappers when mapping an array-section of structs with members that have
user-defined default mappers.
Now we do the same when mapping arrays of structs.
When the definition of a special member function was defaulted we would
not consider it user-provided, even when the first declaration was not
defaulted.
Fixes#143599
This commit is using the same mechanism as vk::ext_builtin_input to
implement the SV_Position semantic input.
The HLSL signature is not yet ready for DXIL, hence this commit only
implements the SPIR-V side.
This is incomplete as it doesn't allow the semantic on hull/domain and
other shaders, but it's a first step to validate the overall
input/output
semantic logic.
Fixes https://github.com/llvm/llvm-project/issues/136969
Codegen support for reduction over private variable with reduction
clause. Section 7.6.10 in in OpenMP 6.0 spec.
- An internal shared copy is initialized with an initializer value.
- The shared copy is updated by combining its value with the values from
the private copies created by the clause.
- Once an encountering thread verifies that all updates are complete,
its original list item is updated by merging its value with that of the
shared copy and then broadcast to all threads.
Sample Test Case from OpenMP 6.0 Example
```
#include <assert.h>
#include <omp.h>
#define N 10
void do_red(int n, int *v, int &sum_v)
{
sum_v = 0; // sum_v is private
#pragma omp for reduction(original(private),+: sum_v)
for (int i = 0; i < n; i++)
{
sum_v += v[i];
}
}
int main(void)
{
int v[N];
for (int i = 0; i < N; i++)
v[i] = i;
#pragma omp parallel num_threads(4)
{
int s_v; // s_v is private
do_red(N, v, s_v);
assert(s_v == 45);
}
return 0;
}
```
Expected Codegen:
```
// A shared global/static variable is introduced for the reduction result.
// This variable is initialized (e.g., using memset or a UDR initializer)
// e.g., .omp.reduction.internal_private_var
// Barrier before any thread performs combination
call void @__kmpc_barrier(...)
// Initialization block (executed by thread 0)
// e.g., call void @llvm.memset.p0.i64(...) or call @udr_initializer(...)
call void @__kmpc_critical(...)
// Inside critical section:
// Load the current value from the shared variable
// Load the thread-local private variable's value
// Perform the reduction operation
// Store the result back to the shared variable
call void @__kmpc_end_critical(...)
// Barrier after all threads complete their combinations
call void @__kmpc_barrier(...)
// Broadcast phase:
// Load the final result from the shared variable)
// Store the final result to the original private variable in each thread
// Final barrier after broadcast
call void @__kmpc_barrier(...)
```
---------
Co-authored-by: Chandra Ghale <ghale@pe31.hpc.amslabs.hpecorp.net>
fix https://github.com/llvm/llvm-project/issues/107629
After some more debugging, I find out that we will check access here at
8e010ac5a1/clang/lib/Sema/SemaInit.cpp (L7807)
And for `f()` inside code below, `Found.getAccess()` is `AS_none` hence
`CheckAddressOfMemberAccess` return `AR_accessible` directly.
```cpp
struct Base {
public:
int f(int);
private:
int f(); // expect-note {{declared private here}}
};
struct Derived : public Base {};
void f() {
int(Derived::* public_f)(int) = &Derived::f;
int(Derived::* private_f)() = &Derived::f; // expect-error {{'f' is a private member of 'Base'}}
}
```
I think the `Found.getAccess()` is intended to be `AS_none` so I just
add one more access check for the `UnresolvedLookupExpr` when
`Found.getAccess()` is `AS_none`. If add the check unconditionally clang
will report lots of duplicate errors and cause several unit tests to
fail.
I also test the UB mentioned in
https://github.com/llvm/llvm-project/issues/107629 and clang now display
4 `false` as expecetd.
Co-authored-by: Erich Keane <ekeane@nvidia.com>
* Translate the following versions to 26.
* watchOS 12 -> 26
* visionOS 3 -> 26
* macos 16 -> 26
* iOS 19 -> 26
* tvOS 19 -> 26
* Emit diagnostics, but allow conversion when clients attempt to use
invalid gaps in OS versioning in availability.
* For target-triples, only allow "valid" versions for implicit
conversions.
Current approach generates intrinsic records when users specify
corresponding required features by using command line option.
However it's not able to handle features passed by using target
attributes correctly where each function might have different
features.
This patch resolves this by generating all of intrinsic records which
carry the required features in their function declaration using
attribute and check the required extensions in CheckBuiltinFunctionCall.
This should fix
[56592](https://github.com/llvm/llvm-project/issues/56592),
[134962](https://github.com/llvm/llvm-project/issues/134962) and
[121603](https://github.com/llvm/llvm-project/issues/121603)
Use the definition of trivially relocatable types to short-circuit some
checks for trivial_abi.
Note that this is mostly a no-op as there is a lot of overlap between
trivial_abi and trivial relocatability (ie, I can't envision a scenario
in which there would be a trivially relocatable type that would not be
eligible for trivial_abi based on its special member function... which
is good!)
Note that for bases and members, we need to check CanPassInRegister
rather than just relocation. So we do these checks first, which leads to
better diagnostics.
Static analysis flagged that Var could be nullptr but we were not
checking in the branch and unconditionally dereferences the pointer.
Note, code was added by 576161cb6069
https://cplusplus.github.io/CWG/issues/2496.html
We failed to diagnose the following in C++23 mode
```
struct S {
virtual void f(); // expected-note {{previous declaration is here}}
};
struct T : S {
virtual void f() &;
};
```
Remove `[expr.prim.req.nested]` check which restrict that local
parameters in constraint-expressions can only appear as unevaluated
operands. This change makes the treatment of examples like `requires`
expressions and other constant expression contexts uniform, consistent
with the adoption of P2280.
References: https://cplusplus.github.io/CWG/issues/2517.html
Fixes #132825
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Fix the logic in rewriteBuiltinFunctionDecl to work when the builtin
has a pointer parameter with an address space and one without a fixed
address space. A builtin fitting these criteria was recently added.
Change the attribute string to perform type checking on it, so without
the sema change compilation would fail with a wrong number of arguments
error.
CWG2369 revealed another case where we were SFINAE'ing out the invalid
result of substitution, but the expression now makes the way into evaluation.
We switch to the concept specialization's context before we check it.
This ensures that we're able to realize the invalid expression earlier,
so we can avoid evaluating invalid expression, which is a hard error.
This also fixes#115838
We have multiple different attributes in clang representing device
kernels for specific targets/languages. Refactor them into one attribute
with different spellings to make it more easily scalable for new
languages/targets.
---------
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
This introduces the attribute discussed in
https://discourse.llvm.org/t/rfc-function-type-attribute-to-prevent-cfi-instrumentation/85458.
The proposed name has been changed from `no_cfi` to
`cfi_unchecked_callee` to help differentiate from `no_sanitize("cfi")`
more easily. The proposed attribute has the following semantics:
1. Indirect calls to a function type with this attribute will not be
instrumented with CFI. That is, the indirect call will not be checked.
Note that this only changes the behavior for indirect calls on pointers
to function types having this attribute. It does not prevent all
indirect function calls for a given type from being checked.
2. All direct references to a function whose type has this attribute
will always reference the true function definition rather than an entry
in the CFI jump table.
3. When a pointer to a function with this attribute is implicitly cast
to a pointer to a function without this attribute, the compiler will
give a warning saying this attribute is discarded. This warning can be
silenced with an explicit C-style cast or C++ static_cast.
The original change caused issues on MSVC due to a new warning thrown
inside MSVC headers. That was fixed
[here](https://github.com/llvm/llvm-project/pull/142019), so reapply
this commit. Original description below.
Instead of defining ARM ACLE intrinsics only on MSVC and guarding
wrapper functions in headers with __has_builtin, universally define the
intrinsics as target header builtins.
This variable attribute is used in HLSL to add Vulkan specific builtins
in a shader.
The attribute is documented here:
17727e88fd/proposals/0011-inline-spirv.md
Those variable, even if marked as `static` are externally initialized by
the pipeline/driver/GPU. This is handled by moving them to a specific
address space `hlsl_input`, also added by this commit.
The design for input variables in Clang can be found here:
355771361e/proposals/0019-spirv-input-builtin.md
Co-authored-by: Justin Bogner <mail@justinbogner.com>
With pointer authentication it becomes non-trivial to correctly load the
vtable pointer of a polymorphic object.
__builtin_get_vtable_pointer is a function that performs the load and
performs the appropriate authentication operations if necessary.
Fixes#106445 by using the lexer to find the correct range for the
removal FixIts. Previously the ranges that were generated assuming no
unsurprising formatting, which for the most part works. Being correct in
all cases requires using the lexer to find the bounding tokens for the
region to remove.
As part of this it adds Sema::getRangeForNextToken to wrap
Lexer::findNextToken.