This patch adds a concept AST node (`ConceptLoc`) and uses it at the corresponding places.
There are three objects that might have constraints via concepts:
`TypeConstraint`, `ConceptSpecializationExpr` and `AutoTypeLoc`.
The first two inherit from `ConceptReference` while the latter has
the information about a possible constraint directly stored in `AutoTypeLocInfo`. It would be nice if the concept information would be stored the same way in all three cases.
Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` can only be done with quite ugly hacks.
So we think that it makes sense to create a new AST node for such concepts.
In details we propose the following:
- Rename `ConceptReference` to `ConceptLoc` (or something else what is approriate)
and make it the new AST node.
- `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from `ConceptReference` but store a pointer to a `ConceptLoc`.
- `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept info in `AutoTypeLocInfo`.
This patch implements a first version of this idea which compiles and where the existing tests pass.
To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the `ConceptLoc`s.
Differential Revision: https://reviews.llvm.org/D155858
Currently, for MS, the linkage for the inheriting constructors is set to
internal. However, the comdat attribute is also set like:
define internal noundef ptr @"??0?$B@_N@@qeaa@AEBVF@@aebua@@@z"(ptr noundef nonnull returned align 1 dereferenceable(1) %this, ptr noundef nonnull align 1 dereferenceable(1) %0, ptr noundef nonnull align 1 dereferenceable(1) %1) unnamed_addr comdat
This could cause linker to fail.
The change is to remove comdat attribute for the inheriting constructor
to make linker happy.
Differential Revision: https://reviews.llvm.org/D158538
This code was copied from SVE and modified for RVV. For SVE, there
is only one size for builtin types so they didn't need to check
the size. For RVV, due to LMUL there are 7 different sizes of builtin
types so we do need to check the size.
I'm not sure we should have lax vector conversions at all for RVV.
That appears to be contributing to https://github.com/llvm/llvm-project/issues/64404
This patch at least fixes the obvious correctness issue.
This should be backported to LLVM 17.
Reviewed By: jacquesguan
Differential Revision: https://reviews.llvm.org/D157130
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
Close https://github.com/llvm/llvm-project/issues/63544.
Background: We landed std modules in libcxx recently but we haven't
landed the corresponding in-tree tests. According to @Mordante, there
are only 1% libcxx tests failing with std modules. And the major
blocking issue is the lambda expression in the require clauses.
The root cause of the issue is that previously we never consider any
lambda expression as the same. Per [temp.over.link]p5:
> Two lambda-expressions are never considered equivalent.
I thought this is an oversight at first but @rsmith explains that in the
wording, the program is as if there is only a single definition, and a
single lambda-expression. So we don't need worry about this in the spec.
The explanation makes sense. But it didn't reflect to the implementation
directly.
Here is a cycle in the implementation. If we want to merge two
definitions, we need to make sure its implementation are the same. But
according to the explanation above, we need to judge if two
lambda-expression are the same by looking at its parent definitions. So
here is the problem.
To solve the problem, I think we have to profile the lambda expressions
actually to get the accurate information. But we can't do this
universally. So in this patch I tried to modify the interface of
`Stmt::Profile` and only profile the lambda expression during the
process of merging the constraint expressions.
Differential Revision: https://reviews.llvm.org/D153957
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
In getRVVTypeSize(clang::ASTContext &, clang::BuiltinType const *) potential integer overflow occurs on expression VScale->first * MinElts with type unsigned int (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type uint64_t (64 bits, unsigned).
To avoid integer overflow, this patch changes the types of variables MinElts and EltSize to uint64_t from unsigned instead of the cast.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D153146
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
The first patch supported only LMUL=1 types. This patch supports
LMUL!=1.
LMUL is length multiplier that allows multiple vector registers to
be treated as one large register or a fraction of a single vector
register. Supported values for LMUL are 1/8, 1/4, 1/2, 1, 2, 4, and 8.
An LMUL=2 type will be twice as large as an LMUL=1 type. An LMUL=1/2
type will be half the size as an LMUL=1 type.
Type name with "m2" is LMUL=2, "m4" is LMUL=4.
Type name with "mf2" is LMUL=1/2, "mf4" is LMUL=1/4.
For the LMUL!=1 types the user will need to scale __riscv_v_fixed_vlen
by the LMUL before passing to the attribute.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D150926
There is no initialization of the data between allocation
and first getBeginLoc call.
allocation: llvm-project/clang/lib/AST/ASTContext.cpp:3022
use: llvm-project/clang/lib/AST/TypeLoc.cpp:222
Msan report https://reviews.llvm.org/P8306
Reviewed By: thurston
Differential Revision: https://reviews.llvm.org/D150499
Decl::isInAnotherModuleUnit
Refactor `Sema::isModuleUnitOfCurrentTU` to `Decl::isInAnotherModuleUnit`
to make code simpler a little bit. Note that although this patch
introduces a FIXME, this is an existing issue and this patch just tries
to describe it explicitly.
For the cover letter of this patch-set, please checkout D146872.
Depends on D146873.
This is the 3rd patch of the patch-set. This patch originates from
D99593.
Note: This patch is a proof-of-concept and will be extended to full
coverage in the future. Currently, the old non-tuple unit-stride
segment load is not removed, and only signed integer unit-strided
segment load of NF=2, EEW=32 is defined here.
When replacing the old intrinsics, the extra `IsTuple` parameter under
various places will be redundant and removed.
Authored-by: eop Chen <eop.chen@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D147731
We can use the minimum value of the BuiltinType's ElementCount and
the element size.
This needs to be done to support LMUL!=1 types anyway.
I did have to make an ordering change in the error checks in
HandleRISCVRVVVectorBitsTypeAttr to check if the type is an RVV
VLS type before checking the size.
The original name "ASTContext::getNamedModuleForCodeGen" is not properly
reflecting the usage of the interface. This interface can be used to
judge the current module unit in both sema analysis and code generation.
So the original name was not so correct.
dependent on f109b10
Given
f109b10168 (commitcomment-113477829),
we need to revert f109b10. So it will be better to make this patch not
dependent on f109b10 as much as possible.
even if its initializer has side effects
Close https://github.com/llvm/llvm-project/issues/61892
The variables whose initializer has side effects will be emitted even if
it is not used. But it shouldn't be true after we introduced modules.
The variables in other modules shouldn't be emitted if it is not used
even if its initializer has size effects.
Also this patch rename `Decl::isInCurrentModuleUnit` to
`Decl::isInAnotherModuleUnit` to make it closer to the semantics.
Decl::isInCurrentModuleUnit
Refactor `Sema::isModuleUnitOfCurrentTU` to `Decl::isInCurrentModuleUnit`
to make code simpler a little bit. Note that although this patch
introduces a FIXME, this is an existing issue and this patch just tries
to describe it explicitly.
Reported by Coverity:
In clang::ASTContext::hasUniqueObjectRepresentations(clang::QualType, bool): Return value of function which returns null is dereferenced without checking.
(Ty->isMemberPointerType()) {
//returned_null: getAs returns nullptr.
//var_assigned: Assigning: MPT = nullptr return value from getAs.
const auto *MPT = Ty->getAs<MemberPointerType>();
//dereference: Dereferencing a pointer that might be nullptr MPT when calling getMemberPointerInfo. (The virtual call resolves to
<unnamed>::ItaniumCXXABI::getMemberPointerInfo.)
return !ABI->getMemberPointerInfo(MPT).HasPadding;
}
ABIs assume the parameter passed to `getMemberPointerInfo` is non-null.
This patch checks type by doing a `if (const auto *MPT = Ty->getAs<MemberPointerType>())` instead.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D149922
RISCVTargetParser.h has a dependency on a tablegen generated file.
Using RISCVISAInfo.h instead avoids this dependency.
We just need this constant somewhere visible to the frontend and
backend and I'm trying to avoid adding a header just for it.
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
We only need the list of constriant template arguments when we have a
valid constraint. We give up on merging the auto-type constraints if
the template arguments don't match, but neglected to clear the
collection of template arguments. The result was we had an AutoType
where we initialized the number of template arguments, but never
initialized the template arguments themselves.
This patch adds an assert to catch this in the future, plus ensures we
clear out the vector so we don't try to create the AutoType incorrectly.
Reported by Coverity:
AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.
1. Inside "SemaDeclCXX.cpp" file, in <unnamed>::DiagnoseUninitializedFields(clang::Sema &, clang::CXXConstructorDecl const *): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.
2. Inside "ClangAttrEmitter.cpp" file, in clang::EmitClangAttrParsedAttrImpl(llvm::RecordKeeper &, llvm::raw_ostream &): Using the auto keyword without an & causes the copy of an object of type pair.
3. Inside "Marshallers.h" file, in clang::ast_matchers::dynamic::internal::MapAnyOfBuilderDescriptor::buildMatcherCtor(clang::ast_matchers::dynamic::SourceRange, llvm::ArrayRef<clang::ast_matchers::dynamic::ParserValue>, clang::ast_matchers::dynamic::Diagnostics *): Using the auto keyword without an & causes the copy of an object of type ParserValue.
4. Inside "CGVTables.cpp" file, in clang::CodeGen::CodeGenModule::GetVCallVisibilityLevel(clang::CXXRecordDecl const *, llvm::DenseSet<clang::CXXRecordDecl const *, llvm::DenseMapInfo<clang::CXXRecordDecl const *, void>> &): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.
5. Inside "ASTContext.cpp" file, in hasTemplateSpecializationInEncodedString(clang::Type const *, bool): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.
6. Inside "ComputeDependence.cpp" file, in clang::computeDependence(clang::DependentScopeDeclRefExpr *): Using the auto keyword without an & causes the copy of an object of type TemplateArgumentLoc.
Reviewed By: tahonermann, erichkeane
Differential Revision: https://reviews.llvm.org/D148812
This patch adds a new trait to allow standard libraries to forward `std::equal` calls to `memcmp` in more cases.
Reviewed By: aaron.ballman
Spies: Mordante, shafik, xbolva00, libcxx-commits, cfe-commits, ldionne
Differential Revision: https://reviews.llvm.org/D147175
An assertion in Qualifiers::addObjCLifetime fails when the ObjC lifetime
bits are already set.
Instead of calling operator+=, call addConsistentQualifiers, which
allows the lifetime bits to be set again as long the new value doesn't
conflict with the old value.
This fixes https://github.com/llvm/llvm-project/issues/61419.
Differential Revision: https://reviews.llvm.org/D147263
This change reverts the functional change from D144626 but retains its
test. Instead of dealing with the possibility that a trailing requires
clause might have been rewritten into some other incorrect form, just
stop rewriting it.
No functionality changes intended.
Reviewed By: erichkeane, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D147281
This is necessary in order for type equality checking, for example
across redeclarations, to require constraints to match. This is also a
prerequisite for including the constraints in manglings.
In passing, fix a bug where TemplateArgument::Profile would produce the
same profile for two structurally different template names, which caused
this change to re-expose the crash previously addressed by D133072,
which it turns out had not quite addressed all problematic cases.
This follows C++ [temp.over.link]/6, which says that constraints are not
part of what determines whether two template parameters are equivalent.
This allows templates that have different constraints on nested template
template parameters to be ordered by their constraints.
constrained friend".
When a friend declaration has a requires-clause, and either it's a
non-template function or it's a function template whose requires-clause
depends on an enclosing template parameter, it is member-like for the
purpose of redeclaration checking. Specifically, the lexically enclosing
class becomes part of its signature, so it can only be redeclared by
another declaration within the same class. In this change, we call such
functions "member-like constrained friends".
No functional change intended.
Previously, distinct lambdas would get merged, and multiple definitions
of the same lambda would not get merged, because we attempted to
identify lambdas by their ordinal position within their lexical
DeclContext. This failed for lambdas within namespace-scope variables
and within variable templates, where the lexical position in the context
containing the variable didn't uniquely identify the lambda.
In this patch, we instead identify lambda closure types by index within
their context declaration, which does uniquely identify them in a way
that's consistent across modules.
This change causes a deserialization cycle between the type of a
variable with deduced type and a lambda appearing as the initializer of
the variable -- reading the variable's type requires reading and merging
the lambda, and reading the lambda requires reading and merging the
variable. This is addressed by deferring loading the deduced type of a
variable until after we finish recursive deserialization.
This also exposes a pre-existing subtle issue where loading a
variable declaration would trigger immediate loading of its initializer,
which could recursively refer back to properties of the variable. This
particularly causes problems if the initializer contains a
lambda-expression, but can be problematic in general. That is addressed
by switching to lazily loading the initializers of variables rather than
always loading them with the variable declaration. As well as fixing a
deserialization cycle, that should improve laziness of deserialization
in general.
LambdaDefinitionData had 63 spare bits in it, presumably caused by an
off-by-one-error in some previous change. This change claims 32 of those bits
as a counter for the lambda within its context. We could probably move the
numbering to separate storage, like we do for the device-side mangling number,
to optimize the likely-common case where all three numbers (host-side mangling
number, device-side mangling number, and index within the context declaration)
are zero, but that's not done in this change.
Fixes#60985.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D145737
circumstances when parsing ASTs
Fix ArgsAsWritten being null for ConceptSpecializationExpr in certain
circumstances when parsing ASTs
ASTStmtWriter::VisitConceptSpecializationExpr specifically expects
getTemplateArgsAsWritten() to return true, which it wasn't when parsed
by ASTContext.cpp in certain edge cases.
Fixes: #61486
Differential Revision: https://reviews.llvm.org/D146678
This patch adds the builtin type __SVCount_t to Clang, which is an opaque
scalable type defined in the SME2 C and C++ Language Extensions.
The type maps to the `target("aarch64.svcount")` LLVM IR type.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D136864
definition correctly
Close https://github.com/llvm/llvm-project/issues/61067
Previously we will only handle the defaulted member functions as
discardable ODR. But we need to handle defaulted friend function in this
way too. Otherwise we may run into the problems the above issue report
mentions.
Close https://github.com/llvm/llvm-project/issues/60890.
For the following example:
```
export module a;
export template<typename T>
struct a {
friend void aa(a) requires(true) {
}
};
```
```
export module b;
import a;
struct b {
a<int> m;
};
```
```
export module c;
import a;
struct c {
void f() const {
aa(a<int>());
}
};
```
```
import a;
import b;
import c;
void d() {
aa(a<int>());
}
```
The current clang will reject this incorrectly. The reason is that the
require clause will be replaced with the evaluated version
(efae3174f0/clang/lib/Sema/SemaConcept.cpp (L664-L665)).
In module 'b', the friend function is instantiated but not used so the
require clause of the friend function is `(true)`. However, in module
'c', the friend function is used so the require clause is `true`. So
deserializer classify these two function to two different functions
instead of one. Then here is the bug report.
The proposed solution is to try to compare the trailing require clause
of the primary template when performing ODR checking.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D144626
