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
Before this patch it was expected that if there was several immediate
invocations they all belong to the same expression evaluation context.
During parsing of non local variable initializer a new evaluation context is
pushed, so code like this
```
namespace scope {
struct channel {
consteval channel(const char* name) noexcept { }
};
consteval const char* make_channel_name(const char* name) { return name;}
channel rsx_log(make_channel_name("rsx_log"));
}
```
produced a nested immediate invocation whose subexpressions are attached
to different expression evaluation contexts. The constructor call
belongs to TU context and `make_channel_name` call to context of
variable initializer.
This patch removes this assumption and adds tracking of previously
failed immediate invocations, so it is possible when handling an
immediate invocation th check that its subexpressions from possibly another
evaluation context contains errors and not produce duplicate
diagnostics.
Fixes https://github.com/llvm/llvm-project/issues/58207
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D146234
This implements support for allowing {} to consistently zero initialize
objects. We already supported most of this work as a GNU extension, but
the C2x feature goes beyond what the GNU extension allowed.
The changes in this patch are:
* Removed the -Wgnu-empty-initializer warning group. The extension is
now a C2x extension warning instead. Note that use of
`-Wno-gnu-empty-initializer seems` to be quite low in the wild
(https://sourcegraph.com/search?q=context%3Aglobal+-file%3A.*test.*+%22-Wno-gnu-empty-initializer%22&patternType=standard&sm=1&groupBy=repo
which currently only gives 8 hits total), so this is not expected to
be an overly disruptive change. But I'm adding the clang vendors
review group just in case this expectation is wrong.
* Reworded the diagnostic wording to be about a C2x extension, added a
pre-C2x compat warning.
* Allow {} to zero initialize a VLA
This functionality is exposed as an extension in all older C modes
(same as the GNU extension was), but does *not* allow the extension for
VLA initialization in C++ due to concern about handling non-trivially
constructible types.
Differential Revision: https://reviews.llvm.org/D147349
This patch is to isolate the lax vector conversions warning only for PPC,
the reason is that SystemZ wants different logic in terms of
vector bool compatibility.
Reviewed By: lei
Differential Revision: https://reviews.llvm.org/D145506
Add '__builtin_FILE_NAME()', which expands to the filename because the
full path is not always needed. It corresponds to the '__FILE_NAME__'
predefined macro and is consistent with the other '__builin' functions
added for predefined macros.
Differential Revision: https://reviews.llvm.org/D144878
This results in expressions that appear in default function argument not
being checked for being actual constant expressions.
This aligns clang's behavior with the standard and fixes one of the
examples from https://wg21.link/P1073R3.
Reviewed By: shafik, cor3ntin
Differential Revision: https://reviews.llvm.org/D145251
Based on Richard's suggestion in D126341:
`If we can actually describe a rule that we provide for initialization
order of instantiated variables, and we can easily implement that rule
and be confident we won't want to substantially weaken it later, and we
can thereby assure our users that we will satisfy that rule, then I
think that could be interesting, but anything less than that doesn't
seem worthwhile to me.`
I'm giving it try here. IMHO the implementation is pretty simple and
does not change behavior for unrelated constructs like the timing when
instantiated variables are passed to CodeGen.
This is based on the same ordering guarantee needed for inline variables D127233.
To provide this guarantee, we also need to
emit DeferredDeclsToEmit in the DFS order. e5df59ff78
originally supported this but it is not exactly DFS order for cases like
the one in cwg362. For the example of Fib<5>, it triggers the instantiation
of Fib<4> and Fib<3>. However, due to the way GlobalEagerInstantiationScope
is implemented, Fib<4> does not actually trigger Fib<3> instantiation
since it is already triggered by Fib<5>. This breaks the guarantee.
This patch makes sure DeferredDeclsToEmit is emitted in DFS order by moving
DeferredDeclsToEmit storage from the call stack to an explicit stack-like
data structure. Then the DFS order could be enforced.
Differential Revision: https://reviews.llvm.org/D127259
This implements P2036R3 and P2579R0.
That is, explicit, int, and implicit capture become visible
at the start of the parameter head.
Reviewed By: aaron.ballman, rupprecht, shafik
Differential Revision: https://reviews.llvm.org/D124351
These 2 spots are protecting calls to SVE specific functions. If RISC-V
sizeless types end up in there we trigger assertions.
Use the more specific isSVESizelessBuiltinType() to avoid letting
RISC-V vectors through.
Reviewed By: asb, c-rhodes
Differential Revision: https://reviews.llvm.org/D144772
This case was being picked up by SVE code and printing an SVE
specific message.
This patch distinquishes RVV from SVE and provides a correct error
message for RVV.
The use of the generic isSizelessBuiltinType was also picking up
WebAssembly reference types which was probably an accident so I've
removed that.
I've named the test similar to SVE's test that contains this check.
Their test also tests the arm_sve_vector_bits attribute. I plan to
add something similar for RISC-V soon so I've adopted this naming.
Reviewed By: c-rhodes
Differential Revision: https://reviews.llvm.org/D144613
The `_invoke` function of lambdas was not respecting
the constexpr/consteval specifier of the call operator, so it was possible
to take its address in a non-immmediately invoked context,
even if the call operator was itself consteval.
In addition, we improve the diagnostic emmited in the lambda case
not to show that `invoke` method.
Fixes#57682
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D144627
This patch includes the commit 01adf96ebc86 and a fix of unhandled declaration
references.
When looking up base classes, Clang first checks whether a base class is a
template and takes the specialized template based on it. However, the base class
might be instantiated, and the above behavior can lose information.
This patch fixes the problem by first checking whether a base class is a record
declaration, so the instantiated one will be taken.
Differential Revision: https://reviews.llvm.org/D143840
This patch is to fix some missing lax-vector-conversion warnings including
cases that involve vector bool and vector pixel, also to fix the vector
compatibility check for the warnings.
Differential Revision: https://reviews.llvm.org/D143210
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122215
The interfaces for designators (i.e. C99 designated initializers) was
done in two slightly different ways. This was rather wasteful as the
differences could be combined into one.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D140584
