TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint,
in which case control flow would incorrectly flow into ParseImplicitInt.
Reenter the loop in this case.
Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint
and changing a test case which is broken due to a separate bug (will be reported and handled separately).
transparent context.
(The same crash would happen if a class template with a friend was
declared in an 'export' block, but there are more issues with that
case.)
Avoid copying of the orignal variable if it is going to be marked as
firstprivate in task regions. For taskloops, still need to copy the
non-trvially copyable variables to correctly construct them upon task
creation.
This reapplies the following patch, which was reverted because it caused
neon CodeGen tests to fail:
https://reviews.llvm.org/rGa6150b48cea00ab31e9335cc73770327acc4cb3a
I've added checks to detect half precision neon vectors and avoid
promiting them to vectors of floats.
See the discussion here: https://reviews.llvm.org/rG825235c140e7
Original commit message:
This fixes an assertion in Sema::CreateBuiltinBinOp that fails when one
of the vector operand's element type is a typedef of __fp16.
rdar://problem/55983556
The SVE ACLE doesn't allow arrays of sizeless types. At the moment
clang accepts the TU:
__SVInt8_t x[2];
but trying to code-generate it triggers the LLVM assertion:
llvm/lib/IR/Type.cpp:588: static llvm::ArrayType* llvm::ArrayType::get(llvm::Type*, uint64_t): Assertion `isValidElementType(ElementType) && "Invalid type for array element!"' failed.
This patch reports an appropriate error instead.
The rules are slightly more restrictive than for general incomplete types.
For example:
struct s;
typedef struct s arr[2];
is valid as far as it goes, whereas arrays of sizeless types are
invalid in all contexts. BuildArrayType therefore needs a specific
check for isSizelessType in addition to the usual handling of
incomplete types.
Differential Revision: https://reviews.llvm.org/D76082
Since fields can't have sizeless type, it also doesn't make sense
to capture sizeless types by value in lambda expressions. This patch
makes sure that we diagnose that and that we use "sizeless type" rather
"incomplete type" in the associated message. (Both are correct, but
"sizeless type" is more specific and hopefully more user-friendly.)
Differential Revision: https://reviews.llvm.org/D75738
The SVE ACLE doesn't allow fields to have sizeless type. At the moment
clang accepts things like:
struct s { __SVInt8_t x; } y;
but trying to code-generate it leads to LLVM asserts like:
llvm/include/llvm/Support/TypeSize.h:126: uint64_t llvm::TypeSize::getFixedSize() const: Assertion `!IsScalable && "Request for a fixed size on a scalable object"' failed.
This patch adds an associated clang diagnostic.
Differential Revision: https://reviews.llvm.org/D75737
function and an overridden function until we know whether the overriding
function is deleted.
We previously did these checks when we first built the declaration,
which was too soon in some cases. We now defer all these checks to the
end of the class.
Also add missing check that a consteval function cannot override a
non-consteval function and vice versa.
clang accepts a TU containing just:
__SVInt8_t x;
However, sizeless types are not allowed to have static or thread-local
storage duration and trying to code-generate the TU triggers an LLVM
fatal error:
Globals cannot contain scalable vectors
<vscale x 16 x i8>* @x
fatal error: error in backend: Broken module found, compilation aborted!
This patch adds an associated clang diagnostic.
Differential Revision: https://reviews.llvm.org/D75736
It would be difficult to guarantee atomicity for sizeless types,
so the SVE ACLE makes atomic sizeless types invalid. As it happens,
we already rejected them before the patch, but for the wrong reason:
error: _Atomic cannot be applied to type 'svint8_t' (aka '__SVInt8_t')
which is not trivially copyable
The SVE types should be treated as trivially copyable; a later
patch fixes that.
Differential Revision: https://reviews.llvm.org/D75734
A previous patch rejected alignof for sizeless types. This patch
extends that to cover the "aligned" attribute and _Alignas. Since
sizeless types are not meant to be used for long-term data, cannot
be used in aggregates, and cannot have static storage duration,
there shouldn't be any need to fiddle with their alignment.
Like with alignof, this is a conservative position that can be
relaxed in future if it turns out to be too restrictive.
Differential Revision: https://reviews.llvm.org/D75573
clang current accepts:
void foo1(__SVInt8_t *x, __SVInt8_t *y) { *x = *y; }
void foo2(__SVInt8_t *x, __SVInt8_t *y) {
memcpy(y, x, sizeof(__SVInt8_t));
}
The first function is valid ACLE code and generates correct LLVM IR.
However, the second function is invalid ACLE code and generates a
zero-length memcpy. The point of this patch is to reject the use
of sizeof in the second case instead.
There's no similar wrong-code bug for alignof. However, the SVE ACLE
conservatively treats alignof in the same way as sizeof, just as the
C++ standard does for incomplete types. The idea is that layout of
sizeless types is an implementation property and isn't defined at
the language level.
Implementation-wise, the patch adds a new CompleteTypeKind enum
that controls whether RequireCompleteType & friends accept sizeless
built-in types. For now the default is to maintain the status quo
and accept sizeless types. However, the end of the series will flip
the default and remove the Default enum value.
The patch also adds new ...CompleteSized... wrappers that callers can
use if they explicitly want to reject sizeless types. The callers then
use diagnostics that have an extra 0/1 parameter to indicats whether
the type is sizeless or not.
The idea is to have three cases:
1. calls that explicitly reject sizeless types, with a tweaked diagnostic
for the sizeless case
2. calls that explicitly allow sizeless types
3. normal/old-style calls that don't make an explicit choice either way
Once the default is flipped, the 3. calls will conservatively reject
sizeless types, using the same diagnostic as for other incomplete types.
Differential Revision: https://reviews.llvm.org/D75572
a dependent context.
This matches the GCC behavior.
We track the enclosing template depth when determining whether a
statement expression is within a dependent context; there doesn't appear
to be any other reliable way to determine this.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
We would assign the incorrect DeclContext when transforming the RequiresExprBodyDecl, causing incorrect
handling of 'this' inside RequiresExprBodyDecls (bug #45162).
Assign the current context as the DeclContext of the transformed decl.
Fix a bug in IRGen where it wasn't destructing compound literals in C
that are ObjC pointer arrays or non-trivial structs. Also diagnose jumps
that enter or exit the lifetime of the compound literals.
rdar://problem/51867864
Differential Revision: https://reviews.llvm.org/D64464
induction variable abends.
Used incorrect loop bound when trying to calculate the index in the vec
array for doacross construct in the loops with the reverse order.
Summary:
This patch generalizes the existing code to support CDE intrinsics
which will share some properties with existing MVE intrinsics
(some of the intrinsics will be polymorphic and accept/return values
of MVE vector types).
Specifically the patch:
* Adds new tablegen backends -gen-arm-cde-builtin-def,
-gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema,
-gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on
existing MVE backends.
* Renames the '__clang_arm_mve_alias' attribute into
'__clang_arm_builtin_alias' (it will be used with CDE intrinsics as
well as MVE intrinsics)
* Implements semantic checks for the coprocessor argument of the CDE
intrinsics as well as the existing coprocessor intrinsics.
* Adds one CDE intrinsic __arm_cx1 to test the above changes
Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen
Reviewed By: simon_tatham
Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D75850
This adds infrastructure for a multiversioning whitelist, plus adds
'used' to the allowed list with 'target'. The behavior here mirrors the
implementation in GCC, where 'used' only applies to the single
declaration and doesn't apply to the ifunc or resolver.
This is not being applied to cpu_dispatch and cpu_specific, since the
rules are more complicated for cpu_specific, which emits multiple
symbols. Additionally, the author isn't currently aware of uses in the
wild of this combination, but is aware of a number of target+used
combinations.
RebuildLambdaScopeInfo
Previously the type of the variable was being passed, which was causing
clang to crash when a non-reference variable was captured by reference
or a reference variable was captured by value by a lambda and a block
nested inside the lambda body was referencing the variable.
Original patch by JF Bastien.
rdar://problem/47550338
Differential Revision: https://reviews.llvm.org/D58164
Clang is missing a warning for
builtin_return_address/builtin_frame_address called with > 0 argument.
Gcc provides a warning for this via -Wframe-address:
https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html
As calling these functions with argument > 0 has caused several crashes
for us, we would like to have the same warning as gcc here. This diff
adds the warning and makes it part of -Wmost.
Differential Revision: https://reviews.llvm.org/D75768
GCC does not warn on casts from pointers to enumerators, while clang
currently does: https://godbolt.org/z/3DFDVG
This causes a bunch of extra warnings in the Linux kernel, where
certain structs contain a void pointer to avoid using a gigantic
union for all of the various types of driver data, such as
versions.
Add a diagnostic that allows certain projects like the kernel to
disable the warning just for enums, which allows those projects to
keep full compatibility with GCC but keeps the intention of treating
casts to integers and enumerators the same by default so that other
projects have the opportunity to catch issues not noticed before (or
follow suite and disable the warning).
Link: https://github.com/ClangBuiltLinux/linux/issues/887
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D75758
__builtin_os_log_format
This is needed to keep all the objects, including temporaries returned
by function calls, written to the buffer alive until os_log_pack_send is
called.
rdar://problem/60105410
deduction guides.
Previously if an implicit deduction guide had a default argument with a
cleanup, we'd leave the 'pending cleanup' flag set after declaring the
implicit guide. But it turns out that there's no reason to even
substitute into the default argument when declaring an implicit
deduction guide: we only need to record that the default argument
exists, not what it is, since we never actually form a call to a
deduction guide.
GetContainedInventedTypeParmVisitor would not account for the case where TemplateTypeParmType::getDecl() is
nullptr, causing bug #45102.
Add the nullptr check.
Summary:
The messages for two of the warnings are misleading:
* warn_for_range_const_reference_copy suggests that the initialization
of the loop variable results in a copy. But that's not always true,
we just know that some conversion happens, potentially invoking a
constructor or conversion operator. The constructor might copy, as in
the example that lead to this message [1], but it might also not.
However, the constructed object is bound to a reference, which is
potentially misleading, so we rewrite the message to emphasize that.
We also make sure that we print the reference type into the warning
message to clarify that this warning only appears when operator*
returns a reference.
* warn_for_range_variable_always_copy suggests that a reference type
loop variable initialized from a temporary "is always a copy". But
we don't know this, the range might just return temporary objects
which aren't copies of anything. (Assuming RVO a copy constructor
might never have been called.)
The message for warn_for_range_copy is a bit repetitive: the type of a
VarDecl and its initialization Expr are the same up to cv-qualifiers,
because Sema will insert implicit casts or constructor calls to make
them match.
[1] https://bugs.llvm.org/show_bug.cgi?id=32823
Reviewers: aaron.ballman, Mordante, rtrieu
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D75613
Various vload and vstore builtins were missing or misdefined in the
TableGen description. Align the OpenCL vload* and vstore* builtins of
the `-fdeclare-opencl-builtins` option to those of `opencl-c.h`.
Reviewed-by: Stuart Brady <stuart.brady@arm.com>
We need to make sure that PluginAttrInstances is deleted before shared libraries
are unloaded, because otherwise when deleting its contents we'll try to access
a virtual destructor which no longer exists.
As shared libraries are managed using ManagedStatic we can do this by also using
ManagedStatic for PluginAttrInstances as ManagedStatics are deleted in reverse
order of construction and we know that PluginAttrInstances will only be
accessed, and thus constructed, after shared libraries have been loaded.
Use castAs if we know the cast should succeed (or we're dereferencing without check), the castAs will assert as well so we can remove local non-null asserts.
Summary:
This changes introduces an enum to represent dependencies as a bitmask
and extract common patterns from code that computes dependency bits into
helper functions.
Reviewers: rsmith, martong, shafik, ilya-biryukov, hokein
Subscribers: hokein, sammccall, Mordante, riccibruno, merge_guards_bot, rnkovacs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71920
dependent contexts.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
Saar Raz