As reported in PR45298 and PR45299, vector_size type checking would
crash when done in a situation where the scalar is dependent, such as
a member of the current instantiation.
This is because the scalar checking ensures that you can implicitly
convert a value to a vector-type as long as it doesn't require
truncation. It does this by using the constant evaluator to get the
value as a float. Unfortunately, if the scalar is dependent (such as a
member of the current instantiation), we would hit the assert in the
evaluator.
This patch suppresses the truncation- of-value check in the first phase
of translation. All values are properly errored upon instantiation. This
has one minor regression, in that previously in a non-asserts build,
template<typename T>
struct S {
float4 f(float4 f) {
return k + f;
}
static constexpr k = 1.1; // causes a truncation on conversion.
};
would error immediately. Because 'k' is value dependent (as a
member-of-the-current-instantiation), this would still be evaluatable
(despite normally asserting). Due to this patch, this diagnostic is
delayed until instantiation time.
Summary:
This patch implements the following CDE intrinsics:
T __arm_vcx1q_m(int coproc, T inactive, uint32_t imm, mve_pred_t p);
T __arm_vcx2q_m(int coproc, T inactive, U n, uint32_t imm, mve_pred_t p);
T __arm_vcx3q_m(int coproc, T inactive, U n, V m, uint32_t imm, mve_pred_t p);
T __arm_vcx1qa_m(int coproc, T acc, uint32_t imm, mve_pred_t p);
T __arm_vcx2qa_m(int coproc, T acc, U n, uint32_t imm, mve_pred_t p);
T __arm_vcx3qa_m(int coproc, T acc, U n, V m, uint32_t imm, mve_pred_t p);
The intrinsics are not part of the released ACLE spec, but internally at
Arm we have reached consensus to add them to the next ACLE release.
Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen
Reviewed By: simon_tatham
Subscribers: kristof.beyls, hiraditya, danielkiss, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76610
Summary:
This patch adds a virtual method `getCPUCacheLineSize()` to `TargetInfo`. Currently, I've only implemented the method in `X86TargetInfo`. It's extremely important that each CPU's cache line size correct (e.g., we can't just define it as `64` across the board) so, it has been a little slow getting to this point.
I'll work on the ARM CPUs next, but that will probably come later in a different patch.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74918
to reduce spurios changes in patches after clang-formatting them. In
particular, these files contain long enums that clang-format reformats
in their entirety if e.g. an element is added.
Reviews having this problem include https://reviews.llvm.org/D76342 and
https://reviews.llvm.org/D71447.
SPIRV2.0 Spec only specifies Linux mangling, however our downstream has
use for a Windows mangling for these types.
Unfortunately, the SPIRV
spec specifies a single mangling for all pipe types, despite clang
allowing overloading on these types. Because of this, this patch
chooses to mangle the read/writability and element type for the windows
mangling.
The windows manglings in the test all demangle according to demangler:
"void __cdecl test1(struct __clang::ocl_pipe<int,1>)
"void __cdecl test2(struct __clang::ocl_pipe<float,0>)
"void __cdecl test2(struct __clang::ocl_pipe<int,1>)
"void __cdecl test3(struct __clang::ocl_pipe<int const,1>)
"void __cdecl test4(struct __clang::ocl_pipe<union
__clang::__vector<unsigned char,3>,1>)
"void __cdecl test5(struct __clang::ocl_pipe<union
__clang::__vector<int,4>,1>)
"void __cdecl test_reserved_read_pipe(struct __clang::_ASCLglobal<struct
Person > * __ptr64,struct __clang::ocl_pipe<struct Person,1>)
Differential Revision: https://reviews.llvm.org/D75685
Currently square-bracket-style (CXX11/C2X) attribute names are normalised to
start with :: if they don't have a namespace. This is a bit odd, as such
names are rejected when parsing, so don't do this.
Differential Revision: https://reviews.llvm.org/D76704
In order to support non-user-named kernels, SYCL needs some way in the
integration headers to name the kernel object themselves. Initially, the
design considered just RTTI naming of the lambdas, this results in a
quite unstable situation in light of some device/host macros.
Additionally, this ends up needing to use RTTI, which is a burden on the
implementation and typically unsupported.
Instead, we've introduced a builtin, __builtin_unique_stable_name, which
takes a type or expression, and results in a constexpr constant
character array that uniquely represents the type (or type of the
expression) being passed to it.
The implementation accomplishes that simply by using a slightly modified
version of the Itanium Mangling. The one exception is when mangling
lambdas, instead of appending the index of the lambda in the function,
it appends the macro-expansion back-trace of the lambda itself in the
form LINE->COL[~LINE->COL...].
Differential Revision: https://reviews.llvm.org/D76620
Casts from an SVE type to itself aren't very useful, but they are
supposed to be valid, and could occur in things like macro expansions.
Such casts already work for C++ and are tested by sizeless-1.cpp.
This patch makes them work for C too.
Differential Revision: https://reviews.llvm.org/D76694
When compiling C, a ?: between two values of the same SVE type
currently gives an error such as:
incompatible operand types ('svint8_t' (aka '__SVInt8_t') and 'svint8_t')
It's supposed to be valid to select between (cv-qualified versions of)
the same SVE type, so this patch adds that case.
These expressions already work for C++ and are tested by
SemaCXX/sizeless-1.cpp.
Differential Revision: https://reviews.llvm.org/D76693
Summary:
These were accidentally left out of D76123. I added tests for the
other three instructions in this small cross-product family (vqdmlah,
vqrdmlah, vqrdmlash) but missed this one.
Reviewers: miyuki
Reviewed By: miyuki
Subscribers: kristof.beyls, dmgreen, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76714
The code was pretending to be doing something useful with vectors, but
really it was doing nothing: the element type of a vector is always a
scalar type, so constWithPadding would always just return the input constant.
Split off from D75661 so it can be reviewed separately.
While I'm here, also add testcase to show missing vector handling.
Differential Revision: https://reviews.llvm.org/D76528
Summary:
After we parse the switch condition, we don't do the type check for
type-dependent expr (e.g. TypoExpr) (in Sema::CheckSwitchCondition), then the
TypoExpr is corrected to an invalid-type expr (in Sema::MakeFullExpr) and passed
to the ActOnStartOfSwitchStmt, which triggers the assertion.
Fix https://github.com/clangd/clangd/issues/311
Reviewers: sammccall
Subscribers: ilya-biryukov, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76592
The argument after -Xarch_device will be added to the arguments for CUDA/HIP
device compilation and will be removed for host compilation.
The argument after -Xarch_host will be added to the arguments for CUDA/HIP
host compilation and will be removed for device compilation.
Differential Revision: https://reviews.llvm.org/D76520
Summary:
This clears the way for adding an Error dependence bit to Type and having it
mostly-automatically propagated.
Reviewers: hokein
Subscribers: jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76424
Summary:
The next release of LLVM will support the full ACLE spec for MVE intrinsics,
so it's worth saying so in the release notes.
Reviewers: kristof.beyls
Reviewed By: kristof.beyls
Subscribers: cfe-commits, hans, dmgreen, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D76513
Normally clang avoids creating expressions when it encounters semantic
errors, even if the parser knows which expression to produce.
This works well for the compiler. However, this is not ideal for
source-level tools that have to deal with broken code, e.g. clangd is
not able to provide navigation features even for names that compiler
knows how to resolve.
The new RecoveryExpr aims to capture the minimal set of information
useful for the tools that need to deal with incorrect code:
source range of the expression being dropped,
subexpressions of the expression.
We aim to make constructing RecoveryExprs as simple as possible to
ensure writing code to avoid dropping expressions is easy.
Producing RecoveryExprs can result in new code paths being taken in the
frontend. In particular, clang can produce some new diagnostics now and
we aim to suppress bogus ones based on Expr::containsErrors.
We deliberately produce RecoveryExprs only in the parser for now to
minimize the code affected by this patch. Producing RecoveryExprs in
Sema potentially allows to preserve more information (e.g. type of an
expression), but also results in more code being affected. E.g.
SFINAE checks will have to take presence of RecoveryExprs into account.
Initial implementation only works in C++ mode, as it relies on compiler
postponing diagnostics on dependent expressions. C and ObjC often do not
do this, so they require more work to make sure we do not produce too
many bogus diagnostics on the new expressions.
See documentation of RecoveryExpr for more details.
original patch from Ilya
This change is based on https://reviews.llvm.org/D61722
Reviewers: sammccall, rsmith
Reviewed By: sammccall, rsmith
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69330
Some methods are sometimes declared in the @implementation blocks which
can cause undiagnosed clashes.
Just write a checkObjCDirectMethodClashes() for this purpose.
Also make sure that "unavailable" selectors do not inherit
objc_direct_members.
Differential Revision: https://reviews.llvm.org/D76643
Signed-off-by: Pierre Habouzit <phabouzit@apple.com>
Radar-ID: rdar://problem/59332804, rdar://problem/59782963
On Windows, when the LLVM toolchain is in the current path (%PATH%), fusing the linker yields c:\{path}\lld.exe whereas the hip tests did not expect the .exe part.
This only happens if LLD is not present in the build folder, which consequently makes the code in Driver::GetProgramPath() to fall back to %PATH% and platform-specific search, which includes the .exe part (see https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/Driver.cpp#L4733).
Differential Revision: https://reviews.llvm.org/D76631
TableGen and .def files (which are meant to be used with the preprocessor) come
with obvious downsides. One of those issues is that generated switch-case
branches have to be identical. This pushes corner cases either to an outer code
block, or into the generated code.
Inspect the removed code in AnalysisConsumer::DigestAnalyzerOptions. You can see
how corner cases like a not existing output file, the analysis output type being
set to PD_NONE, or whether to complement the output with additional diagnostics
on stderr lay around the preprocessor generated code. This is a bit problematic,
as to how to deal with such errors is not in the hands of the users of this
interface (those implementing output types, like PlistDiagnostics etc).
This patch changes this by moving these corner cases into the generated code,
more specifically, into the called functions. In addition, I introduced a new
output type for convenience purposes, PD_TEXT_MINIMAL, which always existed
conceptually, but never in the actual Analyses.def file. This refactoring
allowed me to move TextDiagnostics (renamed from ClangDiagPathDiagConsumer) to
its own file, which it really deserved.
Also, those that had the misfortune to gaze upon Analyses.def will probably
enjoy the sight that a clang-format did on it.
Differential Revision: https://reviews.llvm.org/D76509
The only reason we export symbols from these tools is to support
plugins; if we don't have plugins, exporting symbols just bloats the
executable and makes LTO less effective.
See review of D75879 for the discussion that led to this patch.
Differential Revision: https://reviews.llvm.org/D76527
Erich Keane