Added doxygen comments to avxintrin.h's intrinsics. As of now, around 75% of the
intrinsics in this file are documented here. The patches for the other 25% will be se
nt out later.
Removed extra spaces in emmitrin.h.
Note: The doxygen comments are automatically generated based on Sony's intrinsics document.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
[index] Fix issue with protocol name locations in conformance list of an 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.
Justin Lebar [Tue, 8 Nov 2016 23:45:51 +0000 (23:45 +0000)]
[CUDA] Use only the GVALinkage on function definitions.
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.
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.
Add a method to get the list of registered static analyzer checkers.
Summary:
This provides a better interface for clang-tidy and encapsulates the knowledge
about experimental checkers instead of leaving this to the clients.
IR, Bitcode: Change bitcode reader to no longer own its memory buffer.
Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as this patch shows, ownership can
often reside at a higher level. With the upcoming change to allow multiple
modules in a single bitcode file, it will no longer be appropriate for
modules to generally have unique ownership of their memory buffer.
The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext
and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for
the module to own the memory buffer. This patch does so by adding an owned
memory buffer field to Module, and using it in a few other places where it
is convenient.
Stephen Hines [Tue, 8 Nov 2016 05:50:14 +0000 (05:50 +0000)]
clang-format: Use git-ls-tree to get file mode in diff mode
Summary:
If a file has been renamed/deleted from the filesystem and --diff mode
with two commits is active, attempting to get the file's mode will fail.
This change uses git-ls-tree instead to get the correct permissions for
the given revision.
Justin Bogner [Tue, 8 Nov 2016 05:02:33 +0000 (05:02 +0000)]
cmake: Don't try to install exports if there aren't any
When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for clang's
export list to be empty. If this happens the install(EXPORTS) command
will fail, but since there isn't anything to install anyway we really
just want to skip it.
Bitcode: Decouple block info block state from reader.
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html
Move block info block state to a new class, BitstreamBlockInfo.
Clients may set the block info for a particular cursor with the
BitstreamCursor::setBlockInfo() method.
At this point BitstreamReader is not much more than a container for an
ArrayRef<uint8_t>, so remove it and replace all uses with direct uses
of memory buffers.
Justin Bogner [Mon, 7 Nov 2016 23:46:05 +0000 (23:46 +0000)]
cmake: Support exports correctly with LLVM_DISTRIBUTION_COMPONENTS
We need to apply the same export logic in clang as in llvm for
LLVM_DISTRIBUTION_COMPONENTS, or the clang exports will be invalid
when we use this config.
This makes using distribution components without setting
LLVM_TOOLCHAIN_ONLY=On work correctly.
Sean Callanan [Mon, 7 Nov 2016 20:42:25 +0000 (20:42 +0000)]
When the ASTImporter imports a source location, it avoids importing macro
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.
Alexey Bataev [Mon, 7 Nov 2016 18:15:02 +0000 (18:15 +0000)]
[OPENMP] Fixed codegen for __real/__imag expressions in atomic
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.
Jordan Rose [Mon, 7 Nov 2016 17:28:04 +0000 (17:28 +0000)]
Fix use-of-temporary with StringRef in code coverage
The fixed code is basically identical to the same loop below, which
might indicate an opportunity for refactoring. I just wanted to fix
the use-of-temporary issue.
Caught by adding a similar check to StringRef as r283798 did for
ArrayRef. I'll be upstreaming that soon.
Reviewed by Vedant Kumar as https://reviews.llvm.org/D26317.
Eric Liu [Mon, 7 Nov 2016 06:08:23 +0000 (06:08 +0000)]
Deduplicate replacements by FileEntry instead of file names.
Summary:
The current version does not deduplicate equivalent file paths correctly.
For example, a relative path and an absolute path are considered inequivalent.
Comparing FileEnry addresses these issues.
Add some more asserts to clearly indicate that there are special cases
which guarantee pointers are not null. These all seem to have useful
properties and correlations to document, in one case we even had it in
a comment but now it will also be an assert.
This should prevent PVS-Studio from incorrectly claiming that there are
a bunch of potential bugs here. But I feel really strongly that the
PVS-Studio warnings that pointed at this code have a far too high
false-positive rate to be entirely useful. These are just places where
there did seem to be a useful invariant to document and verify with an
assert. Several other places in the code were already correct and
already have perfectly clear code documenting and validating their
invariants, but still ran afoul of PVS-Studio.
Delete a trivially true check for a variable 'S' being null.
The exact same test guards entry into the loop in which this test
occurs, and there is nothing inside the loop that assigns to the
variable, so it has already been checked for null.
This was flagged by PVS-Studio as well, but the report is actually wrong
-- this is not a case where we dereference a variable prior to testing
it for null, this is a case where we have a redundant test for null
after we already performed the exact same test.
Add an assert to further check the invariant that a null pointer
corresponds to another argument being valid.
This makes it clear that the code is correct despite the PVS-Studio
report that a pointer might be dereferenced prior to being checked for
whether it is null. It likely is also enough for static analyzers to not
flag the code.
Serge Pavlov [Fri, 4 Nov 2016 06:09:23 +0000 (06:09 +0000)]
Enhancement to test for -ast-print
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.
Remove no-op checks for a null CodeCompleter. We have already
dereferenced the pointer at this point, and these routines are
exclusively called after the parser encounters a code completion token.
Other code completion routines called at that point do not check for
null either, so this is clearly the current invariant expected in the
code.
* 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.
Instead of resetting the pointer, or releasing it which was the previous
code, let's just assert that the DiagonsticEngine doesn't own the client
because our constructor took ownership of it and has a std::unique_ptr
that handles deleting it. This seems much more clear -- the release was
harmless but confusing as if there were some memory there it would have
leaked, and the reset was harmless but confusing as if there were some
memory there it would have been double-freed. But in both cases there
was nothing there.
Malcolm Parsons [Thu, 3 Nov 2016 16:57:30 +0000 (16:57 +0000)]
Fixed column shift when formatting line containing bit shift operators
Summary:
During clang-format source lexing >> and << operators are split and
treated as two less/greater operators but column position of following
tokens was not adjusted accordingly.
Akira Hatanaka [Thu, 3 Nov 2016 15:04:58 +0000 (15:04 +0000)]
[Sema] Avoid instantiating templates only when UncompilableErrorOccurred
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.
Olivier Goffart [Thu, 3 Nov 2016 07:36:17 +0000 (07:36 +0000)]
Fix heuristics skipping invalid ctor-initializers with C++11
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.
Serge Pavlov [Thu, 3 Nov 2016 07:32:02 +0000 (07:32 +0000)]
Enhancement to test for -ast-print
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.
Looks like CurFn's name outlives FunctionName, so we can just pass
StringRefs around rather than going from a StringRef to a std::string
to a const char* to a StringRef.
Eric Fiselier [Thu, 3 Nov 2016 02:13:17 +0000 (02:13 +0000)]
[Sema] Allow static_cast<T&&>(e) to check explicit conversions for 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.
Jordan Rose [Wed, 2 Nov 2016 20:44:07 +0000 (20:44 +0000)]
Don't require nullability on template parameters in typedefs.
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.
Artem Dergachev [Wed, 2 Nov 2016 19:35:20 +0000 (19:35 +0000)]
[analyzer] StdLibraryFunctions: provide platform-specific function summaries.
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.
Erich Keane [Wed, 2 Nov 2016 18:29:35 +0000 (18:29 +0000)]
regcall: Implement regcall Calling Conv in clang
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.
Alex Lorenz [Wed, 2 Nov 2016 15:46:34 +0000 (15:46 +0000)]
Add a note that points to the linkage specifier for the C++ linkage errors
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.
Richard Smith [Wed, 2 Nov 2016 00:47:52 +0000 (00:47 +0000)]
More forcibly resolve exception specifications when checking a function
redeclaration in C++1z mode. We need the exception specification in order for
the function's type to be complete.
Bitcode: Change reader interface to take memory buffers.
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html
This change also fixes an API oddity where BitstreamCursor::Read() would
return zero for the first read past the end of the bitstream, but would
report_fatal_error for subsequent reads. Now we always report_fatal_error
for all reads past the end. Updated clients to check for the end of the
bitstream before reading from it.
I also needed to add padding to the invalid bitcode tests in
test/Bitcode/. This is because the streaming interface was not checking that
the file size is a multiple of 4.
Michal Gorny [Tue, 1 Nov 2016 20:31:52 +0000 (20:31 +0000)]
[test] Fix detecting LLVM zlib support in stand-alone builds
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.
Yaxun Liu [Tue, 1 Nov 2016 18:45:32 +0000 (18:45 +0000)]
[OpenCL] Mark group functions as convergent in opencl-c.h
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.
Alexey Bader [Tue, 1 Nov 2016 15:50:52 +0000 (15:50 +0000)]
[OpenCL] Override supported OpenCL extensions with -cl-ext option
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
[x86][inline-asm][clang] accept 'v' constraint
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
Craig Topper [Tue, 1 Nov 2016 05:47:56 +0000 (05:47 +0000)]
[AVX-512] Remove masked vector insert builtins and replace with native 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.
Richard Smith [Tue, 1 Nov 2016 01:34:46 +0000 (01:34 +0000)]
Implement ABI proposal for throwing noexcept function pointers, per discussion
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.
Richard Smith [Tue, 1 Nov 2016 01:31:23 +0000 (01:31 +0000)]
p0012: Teach resolving address of overloaded function with dependent exception
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.
projects / clang / log