Fixes: https://github.com/llvm/llvm-project/issues/65806
Currently clang put extern shared var ODR-used by host device functions
in global var __clang_gpu_used_external. This behavior was due to
https://reviews.llvm.org/D123441. However, clang should not do that for
extern shared vars since their addresses are per warp, therefore cannot
be accessed by host code.
The goal of this change is to clean up some of the code surrounding
HLSL using CXXThisExpr as a non-pointer l-value. This change cleans up
a bunch of assumptions and inconsistencies around how the type of
`this` is handled through the AST and code generation.
This change is be mostly NFC for HLSL, and completely NFC for other
language modes.
This change introduces a new member to query for the this object's type
and seeks to clarify the normal usages of the this type.
With the introudction of HLSL to clang, CXXThisExpr may now be an
l-value and behave like a reference type rather than C++'s normal
method of it being an r-value of pointer type.
With this change there are now three ways in which a caller might need
to query the type of `this`:
* The type of the `CXXThisExpr`
* The type of the object `this` referrs to
* The type of the implicit (or explicit) `this` argument
This change codifies those three ways you may need to query
respectively as:
* CXXMethodDecl::getThisType()
* CXXMethodDecl::getThisObjectType()
* CXXMethodDecl::getThisArgType()
This change then revisits all uses of `getThisType()`, and in cases
where the only use was to resolve the pointee type, it replaces the
call with `getThisObjectType()`. In other cases it evaluates whether
the desired returned type is the type of the `this` expr, or the type
of the `this` function argument. The `this` expr type is used for
creating additional expr AST nodes and for member lookup, while the
argument type is used mostly for code generation.
Additionally some cases that used `getThisType` in simple queries could
be substituted for `getThisObjectType`. Since `getThisType` is
implemented in terms of `getThisObjectType` calling the later should be
more efficient if the former isn't needed.
Reviewed By: aaron.ballman, bogner
Differential Revision: https://reviews.llvm.org/D159247
Consider the following code:
#include <windows.h>
#include <TraceLoggingActivity.h>
#include <TraceLoggingProvider.h>
#include <winmeta.h>
TRACELOGGING_DEFINE_PROVIDER(
g_hMyComponentProvider,
"SimpleTraceLoggingProvider",
// {0205c616-cf97-5c11-9756-56a2cee02ca7}
(0x0205c616,0xcf97,0x5c11,0x97,0x56,0x56,0xa2,0xce,0xe0,0x2c,0xa7));
void test()
{
TraceLoggingFunction(g_hMyComponentProvider);
}
int main()
{
TraceLoggingRegister(g_hMyComponentProvider);
test();
TraceLoggingUnregister(g_hMyComponentProvider);
}
It compiles with MSVC, but clang-cl reports an error:
C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\shared/TraceLoggingActivity.h(377,30): note: expanded from macro '_tlgThisFunctionName'
#define _tlgThisFunctionName __FUNCTION__
^
.\tl.cpp(14,5): error: cannot initialize an array element of type 'char' with an lvalue of type 'const char[5]'
TraceLoggingFunction(g_hMyComponentProvider);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The second commit is not needed to support above code, however, during isolated tests in ms_predefined_expr.cpp
I found that MSVC accepts code with constexpr, whereas clang-cl does not.
I see that in most places PredefinedExpr is supported in constant evaluation, so I didn't wrap my code with ``if(MicrosoftExt)``.
Reviewed By: cor3ntin
Differential Revision: https://reviews.llvm.org/D158591
The original diagnostic does not cover all cases according to my reading
of the spec.
For the interrupt attribute, the spec indicates that if the compiler
does not support saving SSE, MMX, or x87 then the function should
be compiled with '-mgeneral-regs-only' (GCC requires this).
Alternatively, calling functions with the `no_caller_saved_registers`
attribute will not clobber state and can be done without disabling
these features.
The warning as implemented in upstream only detects the latter case but
does not consider that disabling the above features also solves the issue
of these register saves being undesirable due to inefficiency.
For the no_caller_saved_registers attribute, the interrupt spec also
indicates that in the absence of saving SSE, MMX and x87 state, these
functions should be compiled with '-mgeneral-regs-only' (also required
by GCC). It does not make any statements about calling other functions
with the attribute, but by extension the result is the same as with the
interrupt attribute (in clang, at least).
This patch handles the remaining cases by adjusting the diagnostic to:
1. Not be shown if the function is compiled without the SSE, MMX or x87
features enabled (i.e. with '-mgeneral-regs-only')
2. Also be shown for functions with the 'no_caller_saved_registers'
attribute
3. In addition to advising that the function should only call functions
with the `no_caller_saved_registers` attribute, the text also suggests
compiling with `-mgeneral-regs-only` as an alternative.
The interrupt spec is available at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5ed3cc7b66af4758f7849ed6f65f4365be8223be
and was taken from the issue that resulted in this diagnostic being
added (#26787)
Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D159068
When checking the constraint of a lambda, we need to respect the constness
of the call operator when establishing the type of capture variables.
In D124351, this was done by adding const to the captured variable...
However, that would change the type of the variable outside of the scope
of the lambda, which is clearly not the desired outcome.
Instead, to ensure const-correctness, we need to populate
a LambdaScopeInfo with the capture variables before checking the
constraints of a generic lambda.
There is no changelog as I'd like to tentatively propose we backport
this change to RC3 as it is a regression introduced in the Clang 17
cycle.
Fixes#61267
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D158433
Since we also have VLST for rvv now, it is not clear to keep using `isVLSTBuiltinType`, so I added prefix SVE to it.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D158045
This does the rename for most internal uses of C2x, but does not rename
or reword diagnostics (those will be done in a follow-up).
I also updated standards references and citations to the final wording
in the standard.
Predefined identifiers like __FUNCTION__ are treated like string
literals in MSVC, which means they can be concatentated together with
an adjacent string literal. Clang now supports this behavior as well,
in Microsoft extensions mode.
Fixes https://github.com/llvm/llvm-project/issues/63563
Differential Revision: https://reviews.llvm.org/D153914
This patch adds all the language-level function keywords defined in:
https://github.com/ARM-software/acle/pull/188 (merged)
https://github.com/ARM-software/acle/pull/261 (update after D148700 landed)
The keywords are used to control PSTATE.ZA and PSTATE.SM, which are
respectively used for enabling the use of the ZA matrix array and Streaming
mode. This information needs to be available on call sites, since the use
of ZA or streaming mode may have to be enabled or disabled around the
call-site (depending on the IR attributes set on the caller and the
callee). For calls to functions from a function pointer, there is no IR
declaration available, so the IR attributes must be added explicitly to the
call-site.
With the exception of '__arm_locally_streaming' and '__arm_new_za' the
information is part of the function's interface, not just the function
definition, and thus needs to be propagated through the
FunctionProtoType::ExtProtoInfo.
This patch adds the defintions of these keywords, as well as codegen and
semantic analysis to ensure conversions between function pointers are valid
and that no conflicting keywords are set. For example, '__arm_streaming'
and '__arm_streaming_compatible' are mutually exclusive.
Differential Revision: https://reviews.llvm.org/D127762
This reverts commit dfdfd306cfaf54fbc43e2d5eb36489dac3eb9976.
An issue is reported for wrong warning, this has to be reconsidered.
Differential Revision: https://reviews.llvm.org/D157352
This is a C++ feature that allows the use of `_` to
declare multiple variable of that name in the same scope;
these variables can then not be referred to.
In addition, while P2169 does not extend to parameter
declarations, we stop warning on unused parameters of that name,
for consistency.
The feature is backported to all C++ language modes.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D153536
This patch does a few things:
* Fix aggregate initialization.
When an aggregate has an initializer that is immediate-escalating,
the context in which it is used automatically becomes an immediate function.
The wording does that by rpretending an aggregate initialization is itself
an invocation which is not really how clang works, so my previous attempt
was... wrong.
* Fix initialization of defaulted constructors with immediate escalating
default member initializers.
The wording was silent about that case and I did not handled it fully
https://cplusplus.github.io/CWG/issues/2760.html
* Fix diagnostics
In some cases clang would produce additional and unhelpful
diagnostics by listing the invalid references to consteval
function that appear in immediate escalating functions
Fixes https://github.com/llvm/llvm-project/issues/63742
Reviewed By: aaron.ballman, #clang-language-wg, Fznamznon
Differential Revision: https://reviews.llvm.org/D155175
Invalidate BlockDecl with implicit return type, in case any of the return value exprs is invalid.
Propagating the error info up by replacing BlockExpr with a RecoveryExpr.
The idea of this fix is given by @hokein(Haojian Wu)
Fix https://github.com/llvm/llvm-project/issues/63863.
Differential Revision: https://reviews.llvm.org/D155396
Such jumps are not allowed by GCC and allowing them
can lead to situations where we jumps into unevaluated
statements.
Fixes#63682
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D154696
This fix PR37919
The below code produces -Wconstant-logical-operand for the first statement,
but not the second.
void foo(int x) {
if (x && 5) {}
if (5 && x) {}
}
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D142609
Such jumps are not allowed by GCC and allowing them
can lead to situations where we jumps into unevaluated
statements.
Fixes#63682
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D154696
This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whereas `IsEmbedded` becomes
`IsTargetDevice`. The `-fopenmp-is-device` compiler option is also renamed to
`-fopenmp-is-target-device` and the `omp.is_device` MLIR attribute is renamed
to `omp.is_target_device`. Getters and setters of all these renamed properties
are also updated accordingly. Many unit tests have been updated to use the new
names, but an alias for the `-fopenmp-is-device` option is created so that
external programs do not stop working after the name change.
`IsGPU` is set when the target triple is AMDGCN or NVIDIA PTX, and it is only
valid if `IsTargetDevice` is specified as well. `IsTargetDevice` is set by the
`-fopenmp-is-target-device` compiler frontend option, which is only added to
the OpenMP device invocation for offloading-enabled programs.
Differential Revision: https://reviews.llvm.org/D154591
This patch proposes to handle in an uniform fashion
the parsing of strings that are never evaluated,
in asm statement, static assert, attrributes, extern,
etc.
Unevaluated strings are UTF-8 internally and so currently
behave as narrow strings, but these things will diverge with
D93031.
The big question both for this patch and the P2361 paper
is whether we risk breaking code by disallowing
encoding prefixes in this context.
I hope this patch may allow to gather some data on that.
Future work:
Improve the rendering of unicode characters, line break
and so forth in static-assert messages
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D105759
Since an immediate invocation is a full expression itself - it requires
an additional ExprWithCleanups node, but it can participate to a bigger
full expression which actually requires cleanups to be run after.
Thanks @ilya-biryukov for helping reducing the reproducer and confirming
that the analysis is correct.
Fixes https://github.com/llvm/llvm-project/issues/60709
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D153962
Consider the following piece of code:
```
void func( int aa,
int bb,
int cc) {}
void arity_mismatch() {
func(2, 4);
}
```
BEFORE:
```
source.cpp:6:3: error: no matching function for call to 'func'
6 | func(2, 4);
| ^~~~
source.cpp:1:6: note: candidate function not viable: requires 3 arguments, but 2 were provided
1 | void func( int aa,
| ^
```
AFTER:
```
source.cpp:6:3: error: no matching function for call to 'func'
6 | func(2, 4);
| ^~~~
source.cpp:1:6: note: candidate function not viable: requires 3 arguments, but 2 were provided
1 | void func( int aa,
| ^ ~~~~~~~
2 | int bb,
| ~~~~~~~
3 | int cc) {}
| ~~~~~~
```
Reviewed By: cjdb, aaron.ballman
Differential Revision: https://reviews.llvm.org/D153267
This patch uses castAs instead of getAs which will assert if the type doesn't match and adds nullptr check if needed.
Also this patch improves the codes and passes I.getData() instead of doing a lookup in dumpVarDefinitionName()
since we're iterating over the same map in LocalVariableMap::dumpContex().
Reviewed By: aaron.ballman, aaronpuchert
Differential Revision: https://reviews.llvm.org/D153033
When build CallExpr for error-recovery where we have any dependent
child nodes), we should set a dependent type for CallExpr to avoid
running into some unexpected following semantic analysis.
This also aligns with the C++ behavior.
This fixes the symptom crashes: https://github.com/llvm/llvm-project/issues/50244
Differential Revision: https://reviews.llvm.org/D152561
This commit implements support for WebAssembly table types and
respective builtins. Table tables are WebAssembly objects to store
reference types. They have a large amount of semantic restrictions
including, but not limited to, only being allowed to be declared
at the top-level as static arrays of zero-length. Not being arguments
or result of functions, not being stored ot memory, etc.
This commit introduces the __attribute__((wasm_table)) to attach to
arrays of WebAssembly reference types. And the following builtins to
manage tables:
* ref __builtin_wasm_table_get(table, idx)
* void __builtin_wasm_table_set(table, idx, ref)
* uint __builtin_wasm_table_size(table)
* uint __builtin_wasm_table_grow(table, ref, uint)
* void __builtin_wasm_table_fill(table, idx, ref, uint)
* void __builtin_wasm_table_copy(table, table, uint, uint, uint)
This commit also enables reference-types feature at bleeding-edge.
This is joint work with Alex Bradbury (@asb).
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D139010
This patch uses castAs instead of getAs which will assert if the type doesn't match in checkSizelessVectorShift(clang::Sema &, clang::ActionResult<clang::Expr *, true> &, clang::ActionResult<clang::Expr *, true> &, clang::SourceLocation, bool).
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D152107
_Generic accepts an expression operand whose type is matched against a
list of associations. The expression operand is unevaluated, but the
type matched is the type after lvalue conversion. This conversion loses
type information, which makes it more difficult to match against
qualified or incomplete types.
This extension allows _Generic to accept a type operand instead of an
expression operand. The type operand form does not undergo any
conversions and is matched directly against the association list.
This extension is also supported in C++ as we already supported
_Generic selection expressions there.
The RFC for this extension can be found at:
https://discourse.llvm.org/t/rfc-generic-selection-expression-with-a-type-operand/70388
Differential Revision: https://reviews.llvm.org/D149904
Pursuant to discussions at
https://discourse.llvm.org/t/rfc-c-23-p1467r9-extended-floating-point-types-and-standard-names/70033/22,
this commit enhances the handling of the __bf16 type in Clang.
- Firstly, it upgrades __bf16 from a storage-only type to an arithmetic
type.
- Secondly, it changes the mangling of __bf16 to DF16b on all
architectures except ARM. This change has been made in
accordance with the finalization of the mangling for the
std::bfloat16_t type, as discussed at
https://github.com/itanium-cxx-abi/cxx-abi/pull/147.
- Finally, this commit extends the existing excess precision support to
the __bf16 type. This applies to hardware architectures that do not
natively support bfloat16 arithmetic.
Appropriate tests have been added to verify the effects of these
changes and ensure no regressions in other areas of the compiler.
Reviewed By: rjmccall, pengfei, zahiraam
Differential Revision: https://reviews.llvm.org/D150913
Clang 16 changed to consider dereferencing a void* to be a
warning-as-error, plus made this an error in SFINAE contexts, since this
resulted in incorrect template instantiation. When doing so, the Clang
16 documentation was updated to reflect that this was likely to change
again to a non-disablable error in the next version.
As there has been no response to changing from a warning to an error, I
believe this is a non-controversial change.
This patch changes this to be an Error, consistent with the standard and
other compilers.
This was discussed in this RFC:
https://discourse.llvm.org/t/rfc-can-we-stop-the-extension-to-allow-dereferencing-void-in-c/65708
Differential Revision: https://reviews.llvm.org/D150875
The logic of whether an entity needs to be captured has become
quite complex and the recent changes in https://reviews.llvm.org/D124351
ad a mesurable negative impact on compile times.
However, in the absence of capturing scopes (lambda, block, region)
we usually can avoid running most of that logic
(except that we do need to diagnostic when a nested function
refers to a local variable in the scope of the outer function.).
This patch track whether there is currently an active capturing
scope and exit `tryCaptureVariable` early when there isn't.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D150038
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
Sema.h is huge. This makes a small reduction to it by moving
EnterExpressionEvaluationContext into a new header, since it is an
independent component.
Differential Revision: https://reviews.llvm.org/D149796
We filed some CD ballot comments which WG14 considered during the
ballot comment resolution meetings in Jan and Feb 2023, and this
updates our implementation based on the decisions reached. Those
decisions were (paraphrased for brevity):
US 9-034 (REJECTED)
allow (void *)nullptr to be a null pointer constant
US 10-035 (ACCEPTED)
accept the following code, as in C++:
void func(nullptr_t); func(0);
US 22-058 (REJECTED)
accept the following code, as in C++:
nullptr_t val; (void)(1 ? val : 0); (void)(1 ? nullptr : 0);
US 23-062 (REJECTED)
reject the following code, as in C++:
nullptr_t val; bool b1 = val; bool b2 = nullptr;
US 24-061 (ACCEPTED)
accept the following code, as in C++:
nullptr_t val; val = 0;
US 21-068 (ACCEPTED)
accept the following code, as in C++:
(nullptr_t)nullptr;
GB-071 (ACCEPTED)
accept the following code, as in C++:
nullptr_t val; (void)(val == nullptr);
This patch updates the implementation as appropriate, but is primarily
focused around US 10-035, US 24-061, and US 23-062 in terms of
functional changes.
Differential Revision: https://reviews.llvm.org/D148800
When constructing an array expression where the index expression
was a pack expansion, we would construct an ArraySubscriptExpr
instead of an CreateOverloadedArraySubscriptExpr, and pack
expansion would not occur - leading a crash during code gen
or a failure during constant evaluation
Reviewed By: erichkeane, shafik
Differential Revision: https://reviews.llvm.org/D149637
This fixes a regression introduced by ca61961380, that would lead
to a segfault due to stack exhaustion when recursively calling
a default member initializer.
Fixes#60082
I'm not able to get clang to emit a stack exhaustion warning,
which it seems like it should be able to.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D142401
This allows the user to set the size of the scalable vector so they
can be used in structs and as the type of global variables. This works
by representing the type as a fixed vector instead of a scalable vector
in IR. Conversions to and from scalable vectors are made where necessary
like function arguments/returns and intrinsics.
This features has been requested here
https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/176
I know arm_sve_vector_bits is used by the Eigen library so this
could be used to port Eigen to RVV.
This patch adds a new preprocessor define `__riscv_v_fixed_vlen` that
is set when -mrvv_vector_bits is passed on the command line.
The code is largely based on the AArch64 code. A lot of code was
copy/pasted and then modiied to RVV. There may be some opportunities
for sharing.
This first patch only supports the LMUL=1 types. Additional changes
will be needed to support other LMULs. I have also not supported
mask vectors.
Differential Revision: https://reviews.llvm.org/D145088
The relevant language rule from C11 is 6.5.16.1p1: "the left operand is
an atomic, qualified, or unqualified pointer, and the right is a null
pointer constant; or". We correctly handled qualified or unqualified
pointer types, but failed to handle atomic-qualified pointer types. Now
we look through the atomic qualification before testing the constraint
requirements.
Fixes https://github.com/llvm/llvm-project/issues/49563
Differential Revision: https://reviews.llvm.org/D148730
