David Majnemer [Tue, 21 Jun 2016 03:40:16 +0000 (03:40 +0000)]
[CodeGen] Do not run initializers for imported variables
The export side is responsible for running any initializers, they are
run when the module is first loaded. Attempting to run an initializer
for the import side is not possible.
[Docs] More warning fixes to unbreak the docs buildbot.
A number of warnings still remain, but these were the last of the
"unlexable code"-related ones (AFAICT).
I changed a few examples in docs/UsersManual.rst to showcase
-Wextra-tokens because it's already documented (-Wmultichar isn't), and
the sphinx C lexer apparently can't handle char literals like 'ab'. It
seemed like a better overall approach than just marking the code blocks
as none or console.
Zvi Rackover [Sat, 18 Jun 2016 20:01:07 +0000 (20:01 +0000)]
[X86] _MM_ALIGN16 attribute support for non-windows targets
Summary:
This patch adds support for the _MM_ALIGN16 attribute on non-windows targets. This aligns Clang with ICC which supports the attribute on all targets.
David Majnemer [Fri, 17 Jun 2016 17:47:24 +0000 (17:47 +0000)]
[CodeGen] Use pointer-sized integers for ptrtoint sources
Given something like:
void *v = (void *)100;
We need to synthesize a ptrtoint operation from 100. During constant
emission, we choose i64 as the type for our constant because it
guaranteed not to drop any bits from our CharUnits representation of the
value. However, this is suboptimal for 32-bit targets: LLVM passes like
GlobalOpt will get confused by these sorts of casts resulting in
pessimization.
Instead, make sure the ptrtoint operand has a pointer-sized integer
type.
Driver: introduce and use `-isystem-after` for cross-windows
This mirrors the many other -i*after options to insert a new system search
directory at the end of the search path. This makes it possible to actually
inject a search path after the resource dir. This option is similar in spirit
to the /imsvc option in the clang-cl driver. This is needed to properly use the
driver for Windows targets where the clang headers wrap some of the system
headers.
This concept is actually useful on other targets (e.g. Linux) and would be
really easy to support on the core toolchain.
Ranjeet Singh [Fri, 17 Jun 2016 00:59:41 +0000 (00:59 +0000)]
[ARM] Add mrrc/mrrc2 intrinsics and update existing mcrr/mcrr2 intrinsics.
Reapplying patch in r272777 which was reverted
because the llvm patch which added support
for generating the mcrr/mcrr2 instructions
from the intrinsic was causing an assertion
failure. This has now been fixed in llvm.
Olivier Goffart [Thu, 16 Jun 2016 21:39:46 +0000 (21:39 +0000)]
Functions declared in a scope should not hide previous declaration in earlier scopes
This code should be an error:
void foo(int);
void f3() {
int foo(float);
{
float foo(int); // expected-error {{functions that differ only in their return type cannot be overloaded}}
}
}
the foo(float) function declared at function scope should not hide the float(int)
while trying to redeclare functions.
Samuel Antao [Thu, 16 Jun 2016 15:09:31 +0000 (15:09 +0000)]
[OpenMP] Cast captures by copy when passed to fork call so that they are compatible to what the runtime library expects.
Summary:
This patch fixes an issue detected when firstprivate variables are passed to an OpenMP outlined function vararg list. Currently they are not compatible with what the runtime library expects causing malfunction in some targets.
This patch fixes the issue by moving the casting logic already in place for offloading to the common code that creates the outline function and arguments and updates the regression tests accordingly.
Andrey Turetskiy [Thu, 16 Jun 2016 12:26:20 +0000 (12:26 +0000)]
Patch "Compilation for Intel MCU (Part 2/3)" caused the clang-x64-ninja-win7
buildbot to fail because of inaccurate CHECK in the test. This is a quick fix
for the test to make it platform independent.
Andrey Turetskiy [Thu, 16 Jun 2016 10:36:09 +0000 (10:36 +0000)]
Compilation for Intel MCU (Part 2/3)
This is the second patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
* Recognize and use IAMCU GCC toolchain
* Set up include paths
* Forbid C++
Sanjay Patel [Wed, 15 Jun 2016 21:20:04 +0000 (21:20 +0000)]
[x86] translate SSE packed FP comparison builtins to IR
As noted in the code comment, a potential follow-on would be to remove
the builtins themselves. Other than ord/unord, this already works as
expected. Eg:
typedef float v4sf __attribute__((__vector_size__(16)));
v4sf fcmpgt(v4sf a, v4sf b) { return a > b; }
Matthias Braun [Wed, 15 Jun 2016 19:24:55 +0000 (19:24 +0000)]
cc1_main: Do not print statistics twice in -disable_free mode.
llvm statistics are currently printed when the destructor of a "static
ManagedStatic<StatisticInfo> StatInfo" in llvm runs. This destructor
currently runs in each case as part of llvm_shutdown() which is run even
in disable_free mode as part of main(). I assume that this hasn't always
been the case.
Removing the special code here avoids the statistics getting printed
twice.
John Brawn [Wed, 15 Jun 2016 14:14:51 +0000 (14:14 +0000)]
Don't use static variables in LambdaCapture
When static variables are used in inline functions in header files anything that
uses that function ends up with a reference to the variable. Because
RecursiveASTVisitor uses the inline functions in LambdaCapture that use static
variables any AST plugin that uses RecursiveASTVisitor, such as the
PrintFunctionNames example, ends up with a reference to these variables. This is
bad on Windows when building with MSVC with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON
as variables used across a DLL boundary need to be explicitly dllimported in
the DLL using them.
This patch avoids that by adjusting LambdaCapture to be similar to before
r263921, with a capture of either 'this' or a VLA represented by a null Decl
pointer in DeclAndBits with an extra flag added to the bits to distinguish
between the two. This requires the use of an extra bit, and while Decl does
happen to be sufficiently aligned to allow this it's done in a way that means
PointerIntPair doesn't realise it and gives an assertion failure. Therefore I
also adjust Decl slightly to use LLVM_ALIGNAS to allow this.
Alexey Bataev [Wed, 15 Jun 2016 11:19:39 +0000 (11:19 +0000)]
[MSVC] Late parsing of in-class defined member functions in template
classes.
MSVC actively uses unqualified lookup in dependent bases, lookup at the
instantiation point (non-dependent names may be resolved on things
declared later) etc. and all this stuff is the main cause of
incompatibility between clang and MSVC.
Clang tries to emulate MSVC behavior but it may fail in many cases.
clang could store lexed tokens for member functions definitions within
ClassTemplateDecl for later parsing during template instantiation.
It will allow resolving many possible issues with lookup in dependent
base classes and removing many already existing MSVC-specific
hacks/workarounds from the clang code.
The reason is that this (a) seems to work just fine and (b) useful when building stuff with
sanitizer+coverage, but need to exclude the sanitizer for a particular source file.
Vedant Kumar [Tue, 14 Jun 2016 19:06:48 +0000 (19:06 +0000)]
[perf-training] Ignore 'Profile Note' warnings from the runtime
After r272599, -DLLVM_BUILD_INSTRUMENTED passes a default argument to
-fprofile-instr-generate. This confuses the perf-helper script because
the runtime emits a note stating that the default is overridden by the
LLVM_PROFILE_FILE environment variable.
Change the perf-helper script s.t it does not treat these notes as
failures.
This isn't a strictly NFC change, but I don't see a simple way to add a
test for it.
Rafael Espindola [Tue, 14 Jun 2016 12:47:24 +0000 (12:47 +0000)]
Start adding support for Musl.
The two patches together enable clang to support targets like
"x86_64-pc-linux-musl" and build binaries against musl-libc instead of
glibc. This make it easy for clang to work on some musl-based systems
like Alpine Linux and certain flavors of Gentoo.
Adam Nemet [Tue, 14 Jun 2016 12:04:26 +0000 (12:04 +0000)]
Add loop pragma for Loop Distribution
Summary:
This is similar to other loop pragmas like 'vectorize'. Currently it
only has state values: distribute(enable) and distribute(disable). When
one of these is specified the corresponding loop metadata is generated:
!{!"llvm.loop.distribute.enable", i1 true/false}
As a result, loop distribution will be attempted on the loop even if
Loop Distribution in not enabled globally. Analogously, with 'disable'
distribution can be turned off for an individual loop even when the pass
is otherwise enabled.
There are some slight differences compared to the existing loop pragmas.
1. There is no 'assume_safety' variant which makes its handling slightly
different from 'vectorize'/'interleave'.
2. Unlike the existing loop pragmas, it does not have a corresponding
numeric pragma like 'vectorize' -> 'vectorize_width'. So for the
consistency checks in CheckForIncompatibleAttributes we don't need to
check it against other pragmas. We just need to check for duplicates of
the same pragma.
Daniel Sanders [Tue, 14 Jun 2016 08:58:50 +0000 (08:58 +0000)]
[mips] Defer validity check for CPU/ABI pairs and improve error message for invalid cases.
Summary:
The validity of ABI/CPU pairs is no longer checked on the fly but is
instead checked after initialization. As a result, invalid CPU/ABI pairs
can be reported as being known but invalid instead of being unknown. For
example, we now emit:
error: ABI 'n32' is not supported on CPU 'mips32r2'
instead of:
error: unknown target ABI 'n64'
Faisal Vali [Tue, 14 Jun 2016 03:23:15 +0000 (03:23 +0000)]
Fix PR28100 - Allow redeclarations of deleted explicit specializations.
See https://llvm.org/bugs/show_bug.cgi?id=28100.
In r266561 when I implemented allowing explicit specializations of function templates to override deleted status, I mistakenly assumed (and hence introduced a violable assertion) that when an explicit specialization was being declared, the corresponding specialization of the most specialized function template that it would get linked to would always be the one that was implicitly generated - and so if it was marked as 'deleted' it must have inherited it from the primary template and so should be safe to reset its deleted status, and set it to being an explicit specialization. Obviously during redeclaration of a deleted explicit specialization, in order to avoid a recursive reset, we need to check that the previous specialization is not an explicit specialization (instead of assuming and asserting it) and that it hasn't been referenced, and so only then is it safe to reset its 'deleted' status.
All regression tests pass.
Thanks to Zhendong Su for reporting the bug and David Majnemer for tracking it to my commit r266561, and promptly bringing it to my attention.