This patch implements Clang front end support for the OpenMP TR8
`present` motion modifier for `omp target update` directives. The
next patch in this series implements OpenMP runtime support.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D84711
It was unclear what `isa` was supposed to mean so we did not provide any
traits for this context selector. With this patch we will allow *any*
string or identifier. We use the target attribute and target info to
determine if the trait matches. In other words, we will check if the
provided value is a target feature that is available (at the call site).
Fixes PR46338
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D83281
This patch introduces 2 new address spaces in OpenCL: global_device and global_host
which are a subset of a global address space, so the address space scheme will be
looking like:
```
generic->global->host
->device
->private
->local
constant
```
Justification: USM allocations may be associated with both host and device memory. We
want to give users a way to tell the compiler the allocation type of a USM pointer for
optimization purposes. (Link to the Unified Shared Memory extension:
https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/USM/cl_intel_unified_shared_memory.asciidoc)
Before this patch USM pointer could be only in opencl_global
address space, hence a device backend can't tell if a particular pointer
points to host or device memory. On FPGAs at least we can generate more
efficient hardware code if the user tells us where the pointer can point -
being able to distinguish between these types of pointers at compile time
allows us to instantiate simpler load-store units to perform memory
transactions.
Patch by Dmitry Sidorov.
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D82174
This patch implements Clang front end support for the OpenMP TR8
`present` motion modifier for `omp target update` directives. The
next patch in this series implements OpenMP runtime support.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D84711
types.
We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.
We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.
We found a case where Typedef Name Declarations were not being added
correctly when importing builtin types. This exposed the need for a
TypedefNameDecl visitor so these types can be added by RecordDecl and
fields.
This code is covered by the ASTImporterTest cases that use the implicit
struct __NSConstantString_tag definitions.
Thanks to @martong for the debugging assist!
Depends on D83970.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D83992
Implement AIX default `power` alignment rule by adding `PreferredAlignment` and
`PreferredNVAlignment` in ASTRecordLayout class.
The patchh aims at returning correct value for `__alignof(x)` and `alignof(x)`
under `power` alignment rules.
Differential Revision: https://reviews.llvm.org/D79719
Once we start the definition of an ObjCInterfaceDecl we won't attempt to ImportDeclContext
later on. Unlike RecordDecl case which uses DefinitionCompleter to force completeDefinition
we don't seem to have a similar mechanism for ObjCInterfaceDecl.
This fix was needed due to a bug we see in LLDB expression parsing where an initial expression
cause an ObjCInterfaceDecl to be defined and subsequent expressions during import do not call
ImportDeclContext and we can end up in a situation where ivars are imported out of order and not all ivars are imported.
Differential Revision: https://reviews.llvm.org/D83972
This change allow a CallExpr to have optional FPOptionsOverride object,
stored in trailing storage. The implementaion is made similar to the way
used in BinaryOperator.
Differential Revision: https://reviews.llvm.org/D84343
I was trying to pick this up a bit when reviewing D48426 (& perhaps D69778) - in any case, looks like D48426 added a module level flag that might not be needed.
The D48426 implementation worked by setting a module level flag, then code generating contents from the PCH a special case in ASTContext::DeclMustBeEmitted would be used to delay emitting the definition of these functions if they came from a Module with this flag.
This strategy is similar to the one initially implemented for modular codegen that was removed in D29901 in favor of the modular decls list and a bit on each decl to specify whether it's homed to a module.
One major difference between PCH object support and modular code generation, other than the specific list of decls that are homed, is the compilation model: MSVC PCH modules are built into the object file for some other source file (when compiling that source file /Yc is specified to say "this compilation is where the PCH is homed"), whereas modular code generation invokes a separate compilation for the PCH alone. So the current modular code generation test of to decide if a decl should be emitted "is the module where this decl is serialized the current main file" has to be extended (as Lubos did in D69778) to also test the command line flag -building-pch-with-obj.
Otherwise the whole thing is basically streamlined down to the modular code generation path.
This even offers one extra material improvement compared to the existing divergent implementation: Homed functions are not emitted into object files that use the pch. Instead at -O0 they are not emitted into the IR at all, and at -O1 they are emitted using available_externally (existing functionality implemented for modular code generation). The pch-codegen test has been updated to reflect this new behavior.
[If possible: I'd love it if we could not have the extra MSVC-style way of accessing dllexport-pch-homing, and just do it the modular codegen way, but I understand that it might be a limitation of existing build systems. @hans / @thakis: Do either of you know if it'd be practical to move to something more similar to .pcm handling, where the pch itself is passed to the compilation, rather than homed as a side effect of compiling some other source file?]
Reviewers: llunak, hans
Differential Revision: https://reviews.llvm.org/D83652
Summary:
This patch implements semantics for the 'arm_sve_vector_bits' type
attribute, defined by the Arm C Language Extensions (ACLE) for SVE [1].
The purpose of this attribute is to define fixed-length (VLST) versions
of existing sizeless types (VLAT).
Implemented in this patch is the the behaviour described in section 3.7.3.2
and minimal parts of sections 3.7.3.3 and 3.7.3.4, this includes:
* Defining VLST globals, structs, unions, and local variables
* Implicit casting between VLAT <=> VLST.
* Diagnosis of ill-formed conditional expressions of the form:
C ? E1 : E2
where E1 is a VLAT type and E2 is a VLST, or vice-versa. This
avoids any ambiguity about the nature of the result type (i.e is
it sized or sizeless).
* For vectors:
* sizeof(VLST) == N/8
* alignof(VLST) == 16
* For predicates:
* sizeof(VLST) == N/64
* alignof(VLST) == 2
VLSTs have the same representation as VLATs in the AST but are wrapped
with a TypeAttribute. Scalable types are currently emitted in the IR for
uses such as globals and structs which don't support these types, this
is addressed in the next patch with codegen, where VLSTs are lowered to
sized arrays for globals, structs / unions and arrays.
Not implemented in this patch is the behaviour guarded by the feature
macros:
* __ARM_FEATURE_SVE_VECTOR_OPERATORS
* __ARM_FEATURE_SVE_PREDICATE_OPERATORS
As such, the GNU __attribute__((vector_size)) extension is not available
and operators such as binary '+' are not supported for VLSTs. Support
for this is intended to be addressed by later patches.
[1] https://developer.arm.com/documentation/100987/latest
This is patch 2/4 of a patch series.
Reviewers: sdesmalen, rsandifo-arm, efriedma, cameron.mcinally, ctetreau, rengolin, aaron.ballman
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D83551
If an expression is contains-error and its type is unknown (dependent), we
don't treat it as a null pointer constant.
Fix a recovery-ast crash on C.
Differential Revision: https://reviews.llvm.org/D84222
Reapply 49e5f603d4
which had been reverted in c94332919b.
Originally reverted because I hadn't updated it in quite a while when I
got around to committing it, so there were a bunch of missing changes to
new code since I'd written the patch.
Reviewers: aaron.ballman
Differential Revision: https://reviews.llvm.org/D76646
When a semantic checking fails on a syntactic InitListExpr, we will
get an ill-formed semantic InitListExpr (e.g. some inits are nullptr),
using this semantic InitListExpr in clang (without setting the err-bits) is crashy.
Differential Revision: https://reviews.llvm.org/D84140
Summary:
This patch implements parsing support for the 'arm_sve_vector_bits' type
attribute, defined by the Arm C Language Extensions (ACLE, version 00bet5,
section 3.7.3) for SVE [1].
The purpose of this attribute is to define fixed-length (VLST) versions
of existing sizeless types (VLAT). For example:
#if __ARM_FEATURE_SVE_BITS==512
typedef svint32_t fixed_svint32_t __attribute__((arm_sve_vector_bits(512)));
#endif
Creates a type 'fixed_svint32_t' that is a fixed-length version of
'svint32_t' that is normal-sized (rather than sizeless) and contains
exactly 512 bits. Unlike 'svint32_t', this type can be used in places
such as structs and arrays where sizeless types can't.
Implemented in this patch is the following:
* Defined and tested attribute taking single argument.
* Checks the argument is an integer constant expression.
* Attribute can only be attached to a single SVE vector or predicate
type, excluding tuple types such as svint32x4_t.
* Added the `-msve-vector-bits=<bits>` flag. When specified the
`__ARM_FEATURE_SVE_BITS__EXPERIMENTAL` macro is defined.
* Added a language option to store the vector size specified by the
`-msve-vector-bits=<bits>` flag. This is used to validate `N ==
__ARM_FEATURE_SVE_BITS`, where N is the number of bits passed to the
attribute and `__ARM_FEATURE_SVE_BITS` is the feature macro defined under
the same flag.
The `__ARM_FEATURE_SVE_BITS` macro will be made non-experimental in the final
patch of the series.
[1] https://developer.arm.com/documentation/100987/latest
This is patch 1/4 of a patch series.
Reviewers: sdesmalen, rsandifo-arm, efriedma, ctetreau, cameron.mcinally, rengolin, aaron.ballman
Reviewed By: sdesmalen, aaron.ballman
Differential Revision: https://reviews.llvm.org/D83550
This patch adds override to several overriding virtual functions that were missing the keyword within the clang/ directory. These were found by the new -Wsuggest-override.
We don't allow runtime-sized flexible array members, nor initialization
of flexible array members, but it seems reasonable to support the most
basic case where the flexible array member is empty.
The expr dependent-bits described that the expression somehow
depends on a template paramter.
With RecoveryExpr, we have generalized it to "the expression depends on
a template parameter, or an error". This patch updates/cleanups all related
comments of dependence-bits.
Differential Revision: https://reviews.llvm.org/D83213
There is a version that just tests (also called
isIntegerConstantExpression) & whereas this version is specifically used
when the value is of interest (a few call sites were actually refactored
to calling the test-only version) so let's make the API look more like
it.
Reviewers: aaron.ballman
Differential Revision: https://reviews.llvm.org/D76646
Summary:
If no valid interface definition was found previously we would crash.
With this change instead we just print `<<error-type>>` in place
of the NULL interface. In the future this could be improved by
saving the invalid interface's name and using that.
Reviewers: sammccall, gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D83513
lambda when instantiating a call operator specialization.
We previously incorrectly thought that such substitution was happening
in the context of substitution into a local scope, which is a context
where we should perform eager default argument instantiation.
a default argument.
Default arguments can (after recent language changes) refer to
parameters of the same function. Make sure they're added to the local
instantiation scope before transforming a default argument so that we
can remap such references to them properly.
in places such as constant folding
Previously some places that should have handled
__builtin_expect_with_probability is missing, so in some case it acts
differently than __builtin_expect.
For example it was not handled in constant folding, thus in the
following program, the "if" condition should be constantly true and
folded, but previously it was not handled and cause warning "control may
reach end of non-void function" (while __builtin_expect does not):
__attribute__((noreturn)) extern void bar();
int foo(int x, int y) {
if (y) {
if (__builtin_expect_with_probability(1, 1, 1))
bar();
}
else
return 0;
}
Now it's fixed.
Differential Revisions: https://reviews.llvm.org/D83362
variable's initializer is not known.
The hope is that a better diagnostic for this case will reduce the rate
at which duplicates of non-bug PR41093 are reported.
Currently the ItaniumRecordLayoutBuilder when laying out base classes has the virtual
and non-virtual bases mixed up when pulling the base class layouts from the external source.
This came up in an LLDB bug where on arm64 because of differences in how it deals with
tail padding would layout the bases differently without the correct layout from the
external source (LLDB). This would result in some fields being off by 4 bytes.
Differential Revision: https://reviews.llvm.org/D83008
RecoveryExpr was always lvalue, but it is wrong if we use it to model
broken function calls, function call expression has more compliated rules:
- a call to a function whose return type is an lvalue reference yields an lvalue;
- a call to a function whose return type is an rvalue reference yields an xvalue;
- a call to a function whose return type is nonreference type yields a prvalue;
This patch makes the recovery-expr align with the function call if it is
modeled a broken call.
Differential revision: https://reviews.llvm.org/D83201
Summary:
Import declarations in correct order if a class contains
multiple redundant friend (type or decl) declarations.
If the order is incorrect this could cause false structural
equivalences and wrong declaration chains after import.
Reviewers: a.sidorin, shafik, a_sidorin
Reviewed By: shafik
Subscribers: dkrupp, Szelethus, gamesh411, teemperor, martong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D75740
Currently APValues are dumped as a single string. This becomes quickly
completely unreadable since APValue is a tree-like structure. Even a simple
example is not pretty:
struct S { int arr[4]; float f; };
constexpr S s = { .arr = {1,2}, .f = 3.1415f };
// Struct fields: Array: Int: 1, Int: 2, 2 x Int: 0, Float: 3.141500e+00
With this patch this becomes:
-Struct
|-field: Array size=4
| |-elements: Int 1, Int 2
| `-filler: 2 x Int 0
`-field: Float 3.141500e+00
Additionally APValues are currently only dumped as part of visiting a
ConstantExpr. This patch also dump the value of the initializer of constexpr
variable declarations:
constexpr int foo(int a, int b) { return a + b - 42; }
constexpr int a = 1, b = 2;
constexpr int c = foo(a, b) > 0 ? foo(a, b) : foo(b, a);
// VarDecl 0x62100008aec8 <col:3, col:57> col:17 c 'const int' constexpr cinit
// |-value: Int -39
// `-ConditionalOperator 0x62100008b4d0 <col:21, col:57> 'int'
// <snip>
Do the above by moving the dump functions to TextNodeDumper which already has
the machinery to display trees. The cases APValue::LValue, APValue::MemberPointer
and APValue::AddrLabelDiff are left as they were before (unimplemented).
We try to display multiple elements on the same line if they are considered to
be "simple". This is to avoid wasting large amounts of vertical space in an
example like:
constexpr int arr[8] = {0,1,2,3,4,5,6,7};
// VarDecl 0x62100008bb78 <col:3, col:42> col:17 arr 'int const[8]' constexpr cinit
// |-value: Array size=8
// | |-elements: Int 0, Int 1, Int 2, Int 3
// | `-elements: Int 4, Int 5, Int 6, Int 7
Differential Revision: https://reviews.llvm.org/D83183
Reviewed By: aaron.ballman
The error-bit was missing, and the unexpandedpack bit seemed to be
set incorrectly.
Reviewed By: sammccall, erichkeane
Differential Revision: https://reviews.llvm.org/D83114
In general there is no way to get to the ASTContext from most AST nodes
(Decls are one of the exception). This will be a problem when implementing
the rest of APValue::dump since we need the ASTContext to dump some kinds of
APValues.
The ASTContext* in ASTDumper and TextNodeDumper is not always non-null.
This is because we still want to be able to use the various dump() functions
in a debugger.
No functional changes intended.
Reverted in fcf4d5e449 since a few dump()
functions in lldb where missed.
In general there is no way to get to the ASTContext from most AST nodes
(Decls are one of the exception). This will be a problem when implementing
the rest of APValue::dump since we need the ASTContext to dump some kinds of
APValues.
The ASTContext* in ASTDumper and TextNodeDumper is not always
non-null. This is because we still want to be able to use the various
dump() functions in a debugger.
No functional changes intended.
05843dc6ab changed the serialization of the body
of LambdaExpr to avoid a mutation in LambdaExpr::getBody and to avoid a missing
body in LambdaExpr::children.
Unfortunately this replaced one bug by another: we are now duplicating the body
during deserialization; that is after deserialization the identity:
E->getBody() == E->getCallOperator()->getBody() does not hold.
Fix that by instead lazily loading the body from the call operator when needed.
Differential Revision: https://reviews.llvm.org/D83009
Reviewed By: martong, aaron.ballman, vabridgers
Summary:
This patch is removing the custom enumeration for OpenMP Directives and Clauses and replace them
with the newly tablegen generated one from llvm/Frontend. This is a first patch and some will follow to share the same
infrastructure where possible. The next patch should use the clauses allowance defined in the tablegen file.
Reviewers: jdoerfert, DavidTruby, sscalpone, kiranchandramohan, ichoyjx
Reviewed By: DavidTruby, ichoyjx
Subscribers: jholewinski, cfe-commits, dblaikie, MaskRay, ymandel, ichoyjx, mgorny, yaxunl, guansong, jfb, sstefan1, aaron.ballman, llvm-commits
Tags: #llvm, #flang, #clang
Differential Revision: https://reviews.llvm.org/D82906
For the Itanium C++ ABI, this implements the rule added in
https://github.com/itanium-cxx-abi/cxx-abi/pull/83
For the MS C++ ABI, this implements the direction that seemed most
plausible based on personal correspondence with MSVC developers, but is
subject to change as they decide their ABI rule.
This reverts commit defd43a5b3.
with correction to solve msan report
To solve https://bugs.llvm.org/show_bug.cgi?id=46166 where the
floating point settings in PCH files aren't compatible, rewrite
FPFeatures to use a delta in the settings rather than absolute settings.
With this patch, these floating point options can be benign.
Reviewers: rjmccall
Differential Revision: https://reviews.llvm.org/D81869
This reverts commit b55d723ed6.
Reapply Modify FPFeatures to use delta not absolute settings
To solve https://bugs.llvm.org/show_bug.cgi?id=46166 where the
floating point settings in PCH files aren't compatible, rewrite
FPFeatures to use a delta in the settings rather than absolute settings.
With this patch, these floating point options can be benign.
Reviewers: rjmccall
Differential Revision: https://reviews.llvm.org/D81869
Summary:
Assignment and comma operators for fixed-point types were being constevaled as other
binary operators, but they need special treatment.
Reviewers: rjmccall, leonardchan, bjope
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73189
Summary:
Diagnostics for overflow were not being produced for fixed-point
evaluation. This patch refactors a bit of the evaluator and adds
a proper diagnostic for these cases.
Reviewers: rjmccall, leonardchan, bjope
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73188
Summary: We are missing the error-bit somehow if the error-bit is propagated
through the code path: "error type/expr" -> "template argument" ->
"template specialization type", which will lead to crashes.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82102
C++ unqualified name lookup searches template parameter scopes
immediately after finishing searching the entity the parameters belong
to. (Eg, for a class template, you search the template parameter scope
after looking in that class template and its base classes and before
looking in the scope containing the class template.) This is complicated
by the fact that scope lookup within a template parameter scope looks in
a different sequence of places prior to reaching the end of the
declarator-id in the template declaration.
We used to approximate the proper lookup rule with a hack in the scope /
decl context walk inside name lookup. Now we instead compute the lookup
parent for each template parameter scope.
In order to get this right, we now make sure to enter a distinct Scope
for each template parameter scope, and make sure to re-enter the
enclosing class scopes properly when handling delay-parsed regions
within a class.
Summary:
As discussed previously when landing patch for OpenMP in Flang, the idea is
to share common part of the OpenMP declaration between the different Frontend.
While doing this it was thought that moving to tablegen instead of Macros will also
give a cleaner and more powerful way of generating these declaration.
This first part of a future series of patches is setting up the base .td file for
DirectiveLanguage as well as the OpenMP version of it. The base file is meant to
be used by other directive language such as OpenACC.
In this first patch, the Directive and Clause enums are generated with tablegen
instead of the macros on OMPConstants.h. The next pacth will extend this
to other enum and move the Flang frontend to use it.
Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp
Reviewed By: jdoerfert, jdenny
Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits
Tags: #llvm, #openmp, #clang
Differential Revision: https://reviews.llvm.org/D81736
Currently, using the nullPointerConstant AST matcher can lead to
assertions in situations where a node to be matched does not have a
valid type associated with it, such as a ParenListExpr. This patch
addresses that by saying such nodes cannot be a null pointer constant.
This addresses PR46353.
templated class.
When a defaulted operator<=> results in the injection of a defaulted
operator==, that operator== can be named by unqualified name within the
same class, even if the class is templated. To make this work, perform
the transform from defaulted operator<=> to defaulted operator== in the
template definition context instead of the template instantiation
context.
This results in our substituting into a declaration from a context where
we don't have a full list of template arguments (or indeed any), for
which we are now more careful to not spuriously instantiate declarations
that are not dependent on the arguments we're substituting.
These operations do member-wise versions of the all of the listed
operations. This patch implements all of the binaryoperators for these
types. Note that the test is required to use codegen as I could not come
up with a good way to validate the values without the array-subscript
operator implemented (which is likely a much more involved change).
Differential Reivision: https://reviews.llvm.org/D79755
The serialization of ConstantExpr has currently a number of problems:
- Some fields are just not serialized (ConstantExprBits.APValueKind and
ConstantExprBits.IsImmediateInvocation).
- ASTStmtReader::VisitConstantExpr forgets to add the trailing APValue
to the list of objects to be destroyed when the APValue needs cleanup.
While we are at it, bring the serialization of ConstantExpr more in-line
with what is done with the other expressions by doing the following NFCs:
- Get rid of ConstantExpr::DefaultInit. It is better to not initialize
the fields of an empty ConstantExpr since this will allow msan to
detect if a field was not deserialized.
- Move the initialization of the fields of ConstantExpr to the constructor;
ConstantExpr::Create allocates the memory and ConstantExpr::ConstantExpr
is responsible for the initialization.
Review after commit since this is a straightforward mechanical fix
similar to the other serialization fixes.
1. Provides no piroirity supoort && disables three priority related
attributes: init_priority, ctor attr, dtor attr;
2. '-qunique' in XL compiler equivalent behavior of emitting sinit
and sterm functions name using getUniqueModuleId() util function
in LLVM (currently no support for InternalLinkage and WeakODRLinkage
symbols);
3. Add testcases to emit IR sample with __sinit80000000, __dtor, and
__sterm80000000;
4. Temporarily side-steps the need to implement the functionality of
llvm.global_ctors and llvm.global_dtors arrays. The uses of that
functionality in this patch (with respect to the name of the functions
involved) are not representative of how the functionality will be used
once implemented.
Differential Revision: https://reviews.llvm.org/D74166
not be a pack expansion type.
Using a pack expansion type for a pack declaration makes sense, but
general expressions should never have pack expansion types. If we have a
pack `T *...V`, then the type of `V` is the type `T *`, which contains
an unexpanded pack, and is a pointer type.
This allows us to better diagnose issues where a template is invalid due
to some non-dependent portion of a dependent type of a non-type template
parameter pack.
Summary:
The new SVE builtin type __SVBFloat16_t` is used to represent scalable
vectors of bfloat elements.
Reviewers: sdesmalen, efriedma, stuij, ctetreau, shafik, rengolin
Subscribers: tschuett, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81304
The body of LambdaExpr is currently not properly serialized. Instead
LambdaExpr::getBody checks if the body has been already deserialized and if
not mutates LambdaExpr. This can be observed with an AST dump test, where
the body of the LambdaExpr will be null.
The mutation in LambdaExpr::getBody was left because of another bug: it is not
true that the body of a LambdaExpr is always a CompoundStmt; it can also be
a CoroutineBodyStmt wrapping a CompoundStmt. This is fixed by returning a
Stmt * from getBody and introducing a convenience function getCompoundStmtBody
which always returns a CompoundStmt *. This function can be used by callers who
do not care about the coroutine node.
Happily all but one user of getBody treat it as a Stmt * and so this change
is non-intrusive.
Differential Revision: https://reviews.llvm.org/D81787
Reviewed By: aaron.ballman
templated class.
When a defaulted operator<=> results in the injection of a defaulted
operator==, that operator== can be named by unqualified name within the
same class, even if the class is templated. To make this work, perform
the transform from defaulted operator<=> to defaulted operator== in the
template definition context instead of the template instantiation
context.
This results in our substituting into a declaration from a context where
we don't have a full list of template arguments (or indeed any), for
which we are now more careful to not spuriously instantiate declarations
that are not dependent on the arguments we're substituting.
We weren't re-entering template scopes in the right order, causing this
to break self-host with -fdelayed-template-parsing.
This reverts commit 237c2a23b6.
C++ unqualified name lookup searches template parameter scopes
immediately after finishing searching the entity the parameters belong
to. (Eg, for a class template, you search the template parameter scope
after looking in that class template and its base classes and before
looking in the scope containing the class template.) This is complicated
by the fact that scope lookup within a template parameter scope looks in
a different sequence of places prior to reaching the end of the
declarator-id in the template declaration.
We used to approximate the proper lookup rule with a hack in the scope /
decl context walk inside name lookup. Now we instead compute the lookup
parent for each template parameter scope. This gets the right answer and
as a bonus is substantially simpler and more uniform.
In order to get this right, we now make sure to enter a distinct Scope
for each template parameter scope. (The fact that we didn't before was
already a bug, but not really observable most of the time, since
template parameters can't shadow each other.)
Prevent IR-gen from emitting consteval declarations
Summary: with this patch instead of emitting calls to consteval function. the IR-gen will emit a store of the already computed result.
Summary: with this patch instead of emitting calls to consteval function. the IR-gen will emit a store of the already computed result.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76420
The AAPCS specifies that the tuple types such as `svint32x2_t`
should use their `arm_sve.h` names when mangled instead of their
builtin names.
This patch also renames the internal types for the tuples to
be prefixed with `__clang_`, so they are not misinterpreted as
specified internal types like the non-tuple types which *are* defined
in the AAPCS. Using a builtin type for the tuples is a purely
a choice of the Clang implementation.
Reviewers: rsandifo-arm, c-rhodes, efriedma, rengolin
Reviewed By: efriedma
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81721
This saves sizeof(void *) bytes per LambdaExpr.
Review-after-commit since this is a straightforward change similar
to the work done on other nodes. NFC.
Also invert the sense of the return value.
As pointed out by the FIXME that this change resolves, isHidden() wasn't
a very accurate name for this function.
I haven't yet changed any of the strings that are output in
ASTDumper.cpp / JSONNodeDumper.cpp / TextNodeDumper.cpp in response to
whether isHidden() is set because
a) I'm not sure whether it's actually desired to change these strings
(would appreciate feedback on this), and
b) In any case, I'd like to get this pure rename out of the way first,
without any changes to tests. Changing the strings that are output in
the various ...Dumper.cpp files will require changes to quite a few
tests, and I'd like to make those in a separate change.
Differential Revision: https://reviews.llvm.org/D81392
Reviewed By: rsmith
This patch contains all of the clang changes from D72959.
- Generalize the relative vtables ABI such that it can be used by other targets.
- Add an enum VTableComponentLayout which controls whether components in the
vtable should be pointers to other structs or relative offsets to those structs.
Other ABIs can change this enum to restructure how components in the vtable
are laid out/accessed.
- Add methods to ConstantInitBuilder for inserting relative offsets to a
specified position in the aggregate being constructed.
- Fix failing tests under new PM and ASan and MSan issues.
See D72959 for background info.
Differential Revision: https://reviews.llvm.org/D77592
Summary:
Added codegen for use_device_addr clause. The components of the list
items are mapped as a kind of RETURN components and then the returned
base address is used instead of the real address of the base declaration
used in the use_device_addr expressions.
Reviewers: jdoerfert
Subscribers: yaxunl, guansong, sstefan1, cfe-commits, caomhin
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80730
...enumerations from TokenKinds.def and use the new macros from TokenKinds.def
to remove the hard-coded lists of traits.
All the information needed to generate these enumerations is already present
in TokenKinds.def. The motivation here is to be able to dump the trait spelling
without hard-coding the list in yet another place.
Note that this change the order of the enumerators in the enumerations (except
that in the TypeTrait enumeration all unary type traits are before all binary
type traits, and all binary type traits are before all n-ary type traits).
Apart from the aforementioned ordering which is relied upon, after this patch
no code in clang or in the various clang tools depend on the specific ordering
of the enumerators.
No functional changes intended.
Differential Revision: https://reviews.llvm.org/D81455
Reviewed By: aaron.ballman
This reverts commit 2e009dbcb3.
Reverting since there were some test failures on buildbots that used the
new pass manager. ASan and MSan are also finding some bugs in this that
I'll need to address.
This patch contains all of the clang changes from D72959.
- Generalize the relative vtables ABI such that it can be used by other targets.
- Add an enum VTableComponentLayout which controls whether components in the
vtable should be pointers to other structs or relative offsets to those structs.
Other ABIs can change this enum to restructure how components in the vtable
are laid out/accessed.
- Add methods to ConstantInitBuilder for inserting relative offsets to a
specified position in the aggregate being constructed.
See D72959 for background info.
Differential Revision: https://reviews.llvm.org/D77592
Haojian Wu