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
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.
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
dependent contexts.
We previously assumed they were neither value- nor
instantiation-dependent under any circumstances, which would lead to
crashes and other misbehavior.
Compute and propagate conversion kind to diagnostics helper in C++
to provide more specific diagnostics about incorrect implicit
conversions in assignments, initializations, params, etc...
Duplicated some diagnostics as errors because C++ is more strict.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74116
Use the more accurate location when emitting the location of the
function being called's prototype in diagnostics emitted when calling
a function with an incorrect number of arguments.
In particular, avoids showing a trace of irrelevant macro expansions
for "MY_EXPORT static int AwesomeFunction(int, int);". Fixes PR#23564.
This patch removes the explicit call graph for CUDA/HIP/OpenMP deferred
diagnostics generated during parsing since it is error prone due to
incomplete information about function declarations during parsing. In stead,
this patch does a post-parsing AST traverse and emits deferred diagnostics
based on the use graph implicitly generated during the traverse.
Differential Revision: https://reviews.llvm.org/D70172
Summary:
Changes:
- Calls to consteval function are now evaluated in constant context but IR is still generated for them.
- Add diagnostic for taking address of a consteval function in non-constexpr context.
- Add diagnostic for address of consteval function accessible at runtime.
- Add tests
Reviewers: rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: mgrang, riccibruno, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63960
A constrained function with an auto return type would have it's definition
instantiated in order to deduce the auto return type before the constraints
are checked.
Move the constraints check after the return type deduction.
In passing, split it up into three values (no explicit functions /
explicit conversion functions only / any explicit functions) in
preparation for using that in a future change.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
We would previously try to evaluate atomic constraints of non-template functions as-is,
and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656).
Substitute into atomic constraints of non-template functions as we would atomic constraints
of template functions, in order to rebuild the expressions in a constant-evaluated context.
Target regions have implicit outer region which may erroneously capture
some globals when it should not. It may lead to a compiler crash at the
compile time.
Implement support for C++2a requires-expressions.
Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair.
Differential Revision: https://reviews.llvm.org/D50360
Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates.
Differential Revision: https://reviews.llvm.org/D43357
This covers:
* usual arithmetic conversions (comparisons, arithmetic, conditionals)
between different enumeration types
* usual arithmetic conversions between enums and floating-point types
* comparisons between two operands of array type
The deprecation warnings are on-by-default (in C++20 compilations); it
seems likely that these forms will become ill-formed in C++23, so
warning on them now by default seems wise.
For the first two bullets, off-by-default warnings were also added for
all the cases where we didn't already have warnings (covering language
modes prior to C++20). These warnings are in subgroups of the existing
-Wenum-conversion (except that the first case is not warned on if either
enumeration type is anonymous, consistent with our existing
-Wenum-conversion warnings).
function as referenced, not before.
No functionality change intended. This is groundwork for computing the
exception specification of a defaulted comparison, for which we'd like
to use the implicit body where possible.
Copy the block to the heap before passing it to the callee in case the
block escapes in the callee.
rdar://problem/55683462
Differential Revision: https://reviews.llvm.org/D71431
In looking into some other code, I came across this issue where a
float converted to a gcc integer vector via a splat causes it to miss
the float-to-integral cast, which causes some REALLY strange codegen
bugs.
The AST looked like:
`-ImplicitCastExpr <col:13>
'gcc_int_2':'__attribute__((__vector_size__(2 * sizeof(int)))) int' <VectorSplat>
`-ImplicitCastExpr <col:13> 'float' <LValueToRValue>
`-DeclRefExpr <col:13> 'float' lvalue ParmVar
0x556f16a5dc90 'f' 'float'
Despite the type of the VectorSplat cast as printed, it ended up
becoming a vector of float, which caused non-matching instructions. For
example, IntVector + a float constant resulted in:
add <2 x i32> %8, <2 x float> <float 3.000000e+00, float 3.000000e+00>
This patch corrects the conversion so that the float is first converted
to an integral, THEN splatted.
Array members are not yet handled. In addition, defaulted comparisons
can't yet find comparison operators by unqualified lookup (only by
member lookup and ADL). These issues will be fixed in follow-on changes.
Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048
The original patch is modified to set the strictfp IR attribute
explicitly in CodeGen instead of as a side effect of IRBuilder.
In the 2nd attempt to reapply there was a windows lit test fail, the
tests were fixed to use wildcard matching.
Differential Revision: https://reviews.llvm.org/D62731
Summary:
As noted in PR, we have a poor test coverage for this warning. I think macro support was just overlooked. GCC warns in these cases.
Clang missed a real bug in the code I am working with, GCC caught it.
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70624
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
Clang was creating an UncheckedDerivedToBase ImplicitCastExpr that was
also casting between address spaces. Insert an ImplicitCastExpr node
for doing the address space conversion.
Differential Revision: https://reviews.llvm.org/D69810
Alexey Bataev