| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
set is also enabled.
Summary: This is needed to make the v64i8 and v32i16 types legal for the 512-bit VBMI instructions. Fixes PR30912.
Reviewers: delena, zvi
Subscribers: RKSimon, cfe-commits
Differential Revision: https://reviews.llvm.org/D26306
llvm-svn: 286340
|
| |
|
|
|
|
|
|
|
|
|
| |
ObjC class when they come from a typedef.
The ObjC class protocol list assumes there is an associated location for each protocol but no location is provided
when the protocol list comes from a typedef, and we end up with a buffer overflow when trying to get locations for the protocol names.
Fixes crash of rdar://28980278.
llvm-svn: 286331
|
| |
|
|
| |
llvm-svn: 286324
|
| |
|
|
|
|
|
|
|
| |
Add a check to the DeclCache before emitting debug info for a
GlobalVariable a second time and just attach the previsously created one to it.
<rdar://problem/26721101>
llvm-svn: 286322
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously we'd look at the GVALinkage of whatever FunctionDecl you
happened to be calling.
This is not right. In the absence of the gnu_inline attribute, to be
handled separately, the function definition determines the function's
linkage. So we need to wait until we get a def before we can know
whether something is known-emitted.
Reviewers: tra
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D26268
llvm-svn: 286313
|
| |
|
|
|
|
|
|
|
|
| |
Summary: This reverts commit a8804ddd9fe71304b28e5b834d134fe93e568ee0.
Subscribers: cfe-commits, pirama, eugenis, tberghammer, danalbert
Differential Revision: https://reviews.llvm.org/D26422
llvm-svn: 286298
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Bug: https://llvm.org/bugs/show_bug.cgi?id=30940
This macro (along with __ANDROID__) should always be defined for Android
targets. We set it to the major (only) version of the Android API being
compiled for. The Android version is able to be set as an integer suffix
for any valid Android target.
Reviewers: danalbert, eugenis
Subscribers: cfe-commits, pirama, eugenis, tberghammer, danalbert
Differential Revision: https://reviews.llvm.org/D26385
llvm-svn: 286295
|
| |
|
|
|
|
|
|
| |
int2mask/mask2int intrinsics.
Differential Revision: https://reviews.llvm.org/D26021
llvm-svn: 286229
|
| |
|
|
|
|
|
|
|
| |
vector bool char vec_cmpeq (vector bool char, vector bool char);
vector bool int vec_cmpeq (vector bool int, vector bool int);
vector bool long long vec_cmpeq (vector bool long long, vector bool long lon
vector bool short vec_cmpeq (vector bool short, vector bool short);
llvm-svn: 286205
|
| |
|
|
| |
llvm-svn: 286189
|
| |
|
|
|
|
|
|
|
| |
- Infer the right symbol kind.
- Provide a templated USR, similar to how we handle class templates.
rdar://28980398
llvm-svn: 286154
|
| |
|
|
| |
llvm-svn: 286153
|
| |
|
|
| |
llvm-svn: 286151
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansions by calling getSpellingLoc(). That's great in most cases, but for
macros defined in the '<built-in>' source file, the source file is invalid
and does not import correctly, causing an assertion failure (the assertion
is Invalid SLocOffset or bad function choice).
A more reliable way to avoid this is to use getFileLoc(), which does not
return built-in locations. This avoids the crash but still preserves valid
source locations.
I've added a testcase that covers the previously crashing scenario.
https://reviews.llvm.org/D26054
llvm-svn: 286144
|
| |
|
|
|
|
|
|
|
|
|
|
| |
constructs.
For __real/__imag unary expressions clang emits lvalue with the
associated type from the original complex expression, but not the
underlying builtin integer or float type. This causes crash in codegen
for atomic constructs, if __real/__imag expression are used in atomic
constructs.
llvm-svn: 286129
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26302
llvm-svn: 286114
|
| |
|
|
| |
llvm-svn: 286106
|
| |
|
|
|
|
| |
After some changes in codegen capturing of VLA variables in OpenMP regions was broken, causing compiler crash. Patch fixes this issue.
llvm-svn: 286103
|
| |
|
|
|
|
|
| |
This reverts commit r286098 because the modified test breaks on many of the
buildbots.
llvm-svn: 286102
|
| |
|
|
|
|
|
| |
After some changes in codegen capturing of VLA variables in OpenMP
regions was broken, causing compiler crash. Patch fixes this issue.
llvm-svn: 286098
|
| |
|
|
| |
llvm-svn: 285994
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26285
llvm-svn: 285984
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Present tests for the functionality provided by command lime option
`-ast-print` check only absence of crash. This change tries to make
testing better, - the output produced by the compiler is compiled again
with option `-print-ast` and both outputs are compared. Such test at
least checks that the output is valid code. This change fixes only the
test for pure C.
This is recommit of r285882.
llvm-svn: 285981
|
| |
|
|
|
|
| |
<rdar://problem/18616046>
llvm-svn: 285960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* if the base is produced by a series of derived-to-base conversions, check
the expression inside them when looking for an expression with a known
dynamic type
* step past MaterializeTemporaryExprs when checking for a known dynamic type
* when checking for a known dynamic type, treat all class prvalues as having
a known dynamic type after skipping all relevant rvalue subobject
adjustments
* treat callees formed by pointer-to-member access for a non-reference member
type like callees formed by member access.
llvm-svn: 285954
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and FatalErrorOccurred are both set.
This fixes a crash that occurs when a warning promoted to a fatal error
leaves the AST in an incomplete state, and then later CFG analysis is
run on the incomplete AST.
rdar://problem/28558923
Differential Revision: https://reviews.llvm.org/D26166
llvm-svn: 285923
|
| |
|
|
|
|
| |
It broke buildbot on Windows.
llvm-svn: 285889
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use better heuristics to detect if a '{' might be the start of the constructor body
or not. Especially when there is a completion token.
Fix the test 'test/CodeCompletion/ctor-initializer.cpp ' when clang defaults to c++11
The problem was is how we recover invalid code in the ctor-init part as we skip the
function body. In particular, we want to know if a '{' is the begining of the body.
In C++03, we always consider it as the beginng of the body. The problem was that in
C++11, it may be the start of an initializer, so we skip over it, causing further
parse errors later. (It is important that we are able to parse correctly the rest
of the class definition, to know what are the class member, for example)
This commit is improving the heuristics to decide if the '{' is starting a function
body. The rules are the following: If we are not in a template argument, and that the
previous tokens are not an identifier, or a >, then it is much more likely to be the
function body. We verify that further by checking the token after the matching '}'
The commit also fix the behavior when there is a code_completion token in the
ctor-initializers.
Differential Revision: https://reviews.llvm.org/D21502
llvm-svn: 285883
|
| |
|
|
|
|
|
|
|
|
|
| |
Present tests for the functionality provided by command lime option
`-ast-print` check only absence of crash. This change tries to make
testing better, - the output produced by the compiler is compiled again
with option `-print-ast` and both outputs are compared. Such test at
least checks that the output is valid code. This change fixes only the
test for pure C.
llvm-svn: 285882
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-reference-related types.
Summary:
[expr.cast.static] states:
> 3. A glvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible
> with “cv1 T1”. The result refers to the object or the specified base class subobject thereof. If T2 is
> an inaccessible or ambiguous base class of T1, a program that necessitates such a cast is
> ill-formed.
>
> 4. Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_-
> cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t. [...]
Currently when checking p3 Clang will diagnose `static_cast<T&&>(e)` as invalid if the argument is not reference compatible with `T`. However I believe the correct behavior is to also check p4 in those cases. For example:
```
double y = 42;
static_cast<int&&>(y); // this should be OK. 'int&& t(y)' is well formed
```
Note that we still don't check p4 for non-reference-compatible types which are reference-related since `T&& t(e);` should never be well formed in those cases.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26231
llvm-svn: 285872
|
| |
|
|
|
|
| |
proposal on cxx-abi-dev earlier today.
llvm-svn: 285870
|
| |
|
|
|
|
|
|
|
|
|
| |
new' function.
Part of this is to allow creating a USR for the canonical decl of that which is implicit and does
not have a source location.
rdar://28978992
llvm-svn: 285868
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the following code would warn on the use of "T":
template <typename T>
struct X {
typedef T *type;
};
...because nullability is /allowed/ on template parameters (because
they could be pointers). (Actually putting nullability on this use of
'T' will of course break if the argument is a non-pointer type.)
This fix doesn't handle the case where a template parameter is used
/outside/ of a typedef. That seems trickier, especially in parameter
position.
llvm-svn: 285856
|
| |
|
|
|
|
|
|
|
|
| |
Because standard functions can be defined differently on different platforms,
this commit introduces a method for constructing summaries with multiple
variants, whichever matches better. It is also useful for supporting overloads.
Differential Revision: https://reviews.llvm.org/D25940
llvm-svn: 285852
|
| |
|
|
|
|
|
|
|
|
| |
This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.
Differential Revision: https://reviews.llvm.org/D25204
llvm-svn: 285849
|
| |
|
|
|
|
|
|
|
| |
This commit simplifies and clarifies the test code
that was added in r285289.
Suggested by David Blaikie.
llvm-svn: 285825
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit improves the "must have C++ linkage" error diagnostics that are
emitted for C++ declarations like templates and literal operators by adding an
additional note that points to the appropriate extern "C" linkage specifier.
rdar://19021120
Differential Revision: https://reviews.llvm.org/D26189
llvm-svn: 285823
|
| |
|
|
|
|
|
| |
redeclaration in C++1z mode. We need the exception specification in order for
the function's type to be complete.
llvm-svn: 285779
|
| |
|
|
|
|
|
|
|
| |
Change "use of 'self'..." to "Use of 'self'...". The convention is to
start diagnostics with a capital letter.
rdar://problem/28322494
llvm-svn: 285759
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the test run to declare missing HAVE_LIBZ value in stand-alone
builds, using the LLVM_ENABLE_ZLIB that is exported in LLVMConfig.cmake.
When using in-tree builds, HAVE_LIBZ is declared in
cmake/config-ix.cmake as a result of LLVM's CMake checks. When building
stand-alone, this value is not available and as a result caused clang to
wrongly assume that LLVM was built without zlib support.
To fix it, set it to the value of LLVM_ENABLE_ZLIB. While this variable
is originally used to control the user preference, LLVM updates its
value to 0 if zlib checks fail. Therefore, we can use it to reliably
determine whether LLVM was built with zlib support or not.
Differential Revision: https://reviews.llvm.org/D24869
llvm-svn: 285741
|
| |
|
|
| |
llvm-svn: 285733
|
| |
|
|
|
|
|
|
|
|
| |
Certain OpenCL builtin functions are supposed to be executed by all threads in a work group or sub group. Such functions should not be made divergent during transformation. It makes sense to mark them with convergent attribute.
The adding of convergent attribute is based on Ettore Speziale's work and the original proposal and patch can be found at https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg22271.html.
Differential Revision: https://reviews.llvm.org/D25343
llvm-svn: 285725
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds a command line option '-cl-ext' to control a set of
supported OpenCL extensions. Option accepts a comma-separated list
of extensions prefixed with '+' or '-'.
It can be used together with a target triple to override support for some
extensions:
// spir target supports all extensions, but we want to disable fp64
clang -cc1 -triple spir-unknown-unknown -cl-ext=-cl_khr_fp64
Special 'all' extension allows to enable or disable all possible
extensions:
// only fp64 will be supported
clang -cc1 -triple spir-unknown-unknown -cl-ext=-all,+cl_khr_fp64
Patch by asavonic (Andrew Savonichev).
Reviewers: joey, yaxunl
Subscribers: yaxunl, bader, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D23712
llvm-svn: 285700
|
| |
|
|
|
|
|
| |
This patch corresponds to review https://reviews.llvm.org/D26092.
Committing on behalf of Tony Jiang.
llvm-svn: 285694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit on behalf of: Coby Tayree
1.'v' constraint for (x86) non-avx arch imitates the already implemented 'x' constraint, i.e. allows XMM{0-15} & YMM{0-15} depending on the apparent arch & mode (32/64).
2.for the avx512 arch it allows [X,Y,Z]MM{0-31} (mode dependent)
This patch applies the needed changes to clang
LLVM patch: https://reviews.llvm.org/D25005
Differential Revision: https://reviews.llvm.org/D25005
llvm-svn: 285688
|
| |
|
|
|
|
|
| |
This patch corresponds to review https://reviews.llvm.org/D26073.
Committing on behalf of Sean Fertile.
llvm-svn: 285679
|
| |
|
|
|
|
|
|
| |
shufflevectors and selects.
Unfortunately, the backend currently doesn't fold masks into the instructions correctly when they come from these shufflevectors. I'll work on that in a future commit.
llvm-svn: 285667
|
| |
|
|
|
|
|
|
| |
on cxx-abi-dev (thread starting 2016-10-11). This is currently hidden behind a
cc1-only -m flag, pending discussion of how best to deal with language changes
that require use of new symbols from the ABI library.
llvm-svn: 285664
|
| |
|
|
|
|
|
|
| |
specification to resolve the exception specification as part of the type check,
in C++1z onwards. This is not actually part of P0012 / CWG1330 rules for when
an exception specification is "needed", but is necessary for sanity.
llvm-svn: 285663
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes pr29152.
Reviewers: rsmith, pirama, krememek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24010
llvm-svn: 285657
|