The changes in r204978 broke win32-macho targets. There were checks added for
MSVC and Itanium environments as special cases, and win32-macho needs to be
treated the same way.
llvm-svn: 210584
We would previously end up with an error when instantiating the
following template:
template <typename> struct __declspec(dllimport) S {
void foo() = delete;
};
S<int> s;
error: attribute 'dllimport' cannot be applied to a deleted function
llvm-svn: 210550
Clang's lit cfg already detects the currently selected SDK via
"xcrun --show-sdk-path". The same thing should be done for compiler-rt tests,
to make them work on recent OS X versions. Instead of duplicating the detection
code, this patch extracts the detection function into a lit.util method.
Patch by Kuba Brecka (kuba.brecka@gmail.com),
reviewed at http://reviews.llvm.org/D4072
llvm-svn: 210534
Diagnostic mappings are used to calculate the final severity of diagnostic
instances.
Detangle the implementation to reflect the terminology used in documentation
and bindings.
No change in functionality.
llvm-svn: 210518
Doing so would be inconsistent with the common fallback case where backend
diagnostics without source locations are emitted unconditionally.
llvm-svn: 210515
Anyone enabling this warning would expect to hear about all occurrences
including those in system headers that can cause non-reproducible builds.
To achieve this, rework ShowInSystemHeader to remove broken unused mapping code
that didn't make sense with a simpler and correct scheme.
llvm-svn: 210512
We would previously assert if the initializer was dependent. I also think that
checking isConstantInitializer is more correct here than checkInitIsICE.
llvm-svn: 210505
It turns out the trailing '=' really is part of the option name spelling and
treating it as such gets us compatible with GCC's -Werror= and pragmas.
(GCC doesn't appear to support any -Wno- form for this diagnostic but we do.)
llvm-svn: 210503
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210498
Instructions from __nodebug__ functions don't have file:line
information even when inlined into no-nodebug functions. As a result,
intrinsics (SSE and other) from <*intrin.h> clang headers _never_
have file:line information.
With this change, an instruction without !dbg metadata gets one from
the call instruction when inlined.
Fixes PR19001.
llvm-svn: 210459
The PowerPC vsumsws instruction, accessed via vec_sums, is defined
architecturally with a big-endian bias, in that the second input vector
and the result always reference big-endian element 3 (little-endian
element 0). For ease of porting, the programmer wants elements 3 in
both cases.
To provide this semantics, for little endian we generate a permute for
the second input vector prior to the vsumsws instruction, and generate
a permute for the result vector following the vsumsws instruction.
The correctness of this code is tested by the new sums.c test added in
a previous patch, as well as the modifications to
builtins-ppc-altivec.c in the present patch.
llvm-svn: 210449
This uncovered something strange. Diagnostics for InlineAsm have source locations
that don't really map to where they are within the .c source file.
llvm-svn: 210440
This change isolates various llvm/MC headers from the rest of the parser and
better aligns with the existing SemaStmtAsm.cpp.
No change in functionality, code move only.
llvm-svn: 210420
Use mangled template instantiation name as key for back references.
Templates have their own context for back references, so their mangling
is always the same regardless of context. This avoids mangling template
instantiations twice.
Patch by Agustín Bergé!
llvm-svn: 210416
These cases in particular were incurring an extra strlen() when we already knew
the length. They appear to be leftovers from when the interfaces worked with C
strings that have continued to compile due to the implicit StringRef ctor.
llvm-svn: 210403
This mirrors the GCC option for the ARM backend. This option enables the
backend option "-enable-arm-long-calls". The default behaviour is that this is
disabled due to the slight overhead of the generated calls.
If the target of jumps are greater than 64M range of offset-based jumps, then
the target address must be loaded into a register to make an indirect jump. The
backend support for this has been present, but was not previously controllable
by the proper flag.
llvm-svn: 210398
The PowerPC vector-unpack-high and vector-unpack-low instructions
are defined architecturally with a big-endian bias, in that the vector
element numbering is assumed to be "left to right" regardless of
whether the processor is in big-endian or little-endian mode. This
effectively reverses the meaning of "high" and "low." Such a
definition is unnatural for little-endian code generation.
To facilitate ease of porting, the vec_unpackh and vec_unpackl
interfaces are designed to use natural element ordering, so that
elements are numbered according to little-endian design principles
when code is generated for a little-endian target. The desired
semantics can be achieved by using the opposite instruction for
little-endian mode. That is, when a call to vec_unpackh appears in
the code, a vector-unpack-low is generated, and when a call to
vec_unpackl appears in the code, a vector-unpack-high is generated.
The correctness of this code is tested by the new unpack.c test
added in a previous patch, as well as the modifications to
builtins-ppc-altivec.c in the present patch.
Note that these interfaces were originally incorrectly implemented
when they take a vector pixel argument. This patch corrects this
implementation for both big- and little-endian code generation.
llvm-svn: 210391
Commit r210384 prematurely included changes to the little-endian
implementation of the vec_sum2s interface. This patch modifies
test/CodeGen/builtins-ppc-altivec.c to test those changes.
llvm-svn: 210389
The Altivec builtin test case test/CodeGen/builtins-ppc-altivec.c has
always been executed only for 32-bit PowerPC. These tests are equally
valid for 64-bit PowerPC. This patch updates the test to be run for
three targets: powerpc-unknown-unknown, powerpc64-unknown-unknown,
and powerpc64le-unknown-unknown. The expected code generation changes
for some of the Altivec builtins for little endian, so this patch adds
new CHECK-LE variants to the test for the powerpc64le target.
These tests satisfy the testing requirements for some previous patches
committed over the last couple of days for lib/Headers/altivec.h:
r210279 for vec_perm, r210337 for vec_mul[eo], and r210340 for
vec_pack.
llvm-svn: 210384
MSVC delays parsing of default arguments until instantiation. If the
default argument is never used, it is never parsed. We don't model
this.
Instead, if lookup of a type name fails in a template argument context,
we form a DependentNameType, which will be looked up at instantiation
time.
This fixes errors about 'CControlWinTraits' in atlwin.h.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3995
llvm-svn: 210382
This patch implements call lower from dynamic_cast to __RTDynamicCast
and __RTCastToVoid. Test cases are included. A feature of note is that
helper function getPolymorphicOffset is placed in such a way that it can
be used by EmitTypeid (to be implemented in a later patch) without being
moved. Details are included as comments directly in the code.
llvm-svn: 210377
A previous patch r210330 (and possibly another) introduced DOS-style newlines
into a UNIX newline formatted file.
Patch by Mark Heffernan (http://reviews.llvm.org/D4046)
llvm-svn: 210369
As suggested by Reid:
- class has GVA_Internal linkage -> internal
- thunk has return adjustment -> weak_odr, to handle evil corner case [1]
- all other normal methods -> linkonce_odr
1. Evil corner case:
struct Incomplete;
struct A { int a; virtual A *bar(); };
struct B { int b; virtual B *foo(Incomplete); };
struct C : A, B { int c; virtual C *foo(Incomplete); };
C c;
Here, the thunk for C::foo() will be emitted when C::foo() is defined, which
might be in a different translation unit, so it needs to be weak_odr.
Differential Revision: http://reviews.llvm.org/D3992
llvm-svn: 210368
We would previously fail to emit a definition of bar() for the following code:
struct __declspec(dllexport) S {
void foo() {
t->bar();
}
struct T {
void bar() {}
};
T *t;
};
Note that foo() is an exported method, but bar() is not. However, foo() refers
to bar() so we need to emit its definition. We would previously fail to
realise that bar() is used.
By deferring the method definitions until the end of the top level declaration,
we can simply call EmitTopLevelDecl on them and rely on the usual mechanisms
to decide whether the method should be emitted or not.
Differential Revision: http://reviews.llvm.org/D4038
llvm-svn: 210356
results in a template having too many arguments, but all the trailing arguments
are packs, that's OK if we have a partial pack substitution: the trailing pack
expansions may end up empty.
llvm-svn: 210350
The PowerPC vector-pack instructions are defined architecturally with
a big-endian bias, in that the vector element numbering is assumed to
be "left to right" regardless of whether the processor is in
big-endian or little-endian mode. This definition is unnatural for
little-endian code generation.
To facilitate ease of porting, the vec_pack and related interfaces are
designed to use natural element ordering, so that elements are
numbered according to little-endian design principles when code is
generated for a little-endian target. The vec_pack calls are
implemented as calls to vec_perm, specifying selection of the
odd-numbered vector elements. For little endian, this means the
odd-numbered elements counting from the right end of the register.
Since the underlying instructions count from the left end, we must
instead select the even-numbered vector elements for little endian to
achieve the desired semantics.
The correctness of this code is tested by the new pack.c test added in
a previous patch. I plan to later make the existing ppc32 Altivec
compile-time tests work for ppc64 and ppc64le as well.
llvm-svn: 210340
The PowerPC vector-multiply-even and vector-multiply-odd instructions
are defined architecturally with a big-endian bias, in that the vector
element numbering is assumed to be "left to right" regardless of
whether the processor is in big-endian or little-endian mode. This
definition is unnatural for little-endian code generation.
To facilitate ease of porting, the vec_mule and vec_mulo interfacs are
designed to use natural element ordering, so that elements are
numbered according to little-endian design principles when code is
generated for a little-endian target. The desired semantics can be
achieved by using the opposite instruction for little-endian mode.
That is, when a call to vec_mule appears in the code, a
vector-multiply-odd is generated, and when a call to vec_mulo appears
in the code, a vector-multiply-even is generated.
The correctness of this code is tested by the new mult-even-odd.c test
added in a previous patch. I plan to later make the existing ppc32
Altivec compile-time tests work for ppc64 and ppc64le as well.
llvm-svn: 210337
Before (JavaScript example, but can extend to other languages):
return {
a: 'E',
b: function() {
return function() {
f(); // This is wrong.
};
}
};
After:
return {
a: 'E',
b: function() {
return function() {
f(); // This is better.
};
}
};
llvm-svn: 210334
A leftover -S was generating unwanted output in the source tree overriding
-only flags that normally disable output.
This reverts commit r210323 and implements the proper fix.
Reported by Timur Iskhodzhanov!
llvm-svn: 210326
We probably just need to touch LLVM's configure this time to work around the
totally inadequate Makefile build server integration.
This reverts commit r210314.
llvm-svn: 210320
This will unbreak clang vendor builds as a follow-up to r210238, now that we
can't poke into LLVM's private config.h (nor should the string be exposed by
llvm-config.h).
This hopefully removes for good the last include of LLVM's config.h.
llvm-svn: 210313
Instead of disembodied diagnostics when debug info is disabled it's now
possible to identify the associated function's location in order to provide
some amount of of context.
We use the definition's body right brace location to differentiate the fallback
from diagnostics that genuinely relate to the function declaration itself (a
convention also used by gcc).
llvm-svn: 210294
Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.
This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.
An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.
llvm-svn: 210293
Summary:
This change generalizes the code used to create global LLVM
variables referencing predefined strings (e.g. __FUNCTION__): now it
just calls GetAddrOfConstantStringFromLiteral method. As a result,
global variables for these predefined strings may get mangled names
and linkonce_odr linkage. Fix the test accordingly.
Test Plan: clang regression tests
Reviewers: majnemer
Reviewed By: majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4023
llvm-svn: 210284
The PowerPC vperm (vector permute) instruction is defined
architecturally with a big-endian bias, in that the two input vectors
are assumed to be concatenated "left to right" and the elements of the
combined input vector are assumed to be numbered from "left to right"
(i.e., with element 0 referencing the high-order element). This
definition is unnatural for little-endian code generation.
To facilitate ease of porting, the vec_perm interface is designed to
use natural element ordering, so that elements are numbered according
to little-endian design principles when code is generated for a
little-endian target. The desired semantics can be achieved with the
vperm instruction provided that the two input vector registers are
reversed, and the permute control vector is complemented. The
complementing is performed using an xor with a vector containing all
one bits.
Only the rightmost 5 bits of each element of the permute control
vector are relevant, so it would be possible to complement the vector
with respect to a <16xi8> vector containing all 31s. However, when
the permute control vector is not a constant, using 255 instead has
the advantage that the vec_xor can be recognized during code
generation as a vnor instruction. (Power8 introduces a vnand
instruction which could alternatively be generated.)
The correctness of this code is tested by the new perm.c test added in
a previous patch. I plan to later make the existing ppc32 Altivec
compile-time tests work for ppc64 and ppc64le as well.
llvm-svn: 210279
Summary:
Add hasLocalStorage/hasGlobalStorage matchers for VarDecl nodes.
Update the doc. Also add them to the dynamic registry.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D4034
llvm-svn: 210278
This patch adds support for pointer types in global named registers variables.
It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls.
Also adds some early checks on types on SemaDecl to avoid the assert.
Tests changed accordingly. (PR19837)
llvm-svn: 210274
Summary: The Linux Kernel is one example of a piece of software that relies on them.
Reviewers: atanasyan
Reviewed By: atanasyan
Differential Revision: http://reviews.llvm.org/D3756
llvm-svn: 210270
Summary:
Move the 'const' in the AST_*MATCHER_P* macros to the right of ParamType to
avoiad applying the constness on the wrong level when ParamType is a pointer.
Change equalsNode() to explicitly accept 'const Decl*' or 'const Stmt*'.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D3994
llvm-svn: 210269
Due to what can only be described as a CRT bug, stdout and amazingly
even stderr are not always flushed upon process termination, especially
when the system is under high threading pressure. I have found two
repros for this:
1) In lib\Support\Threading.cpp, change sys::Mutex to an
std::recursive_mutex and run check-clang. Usually between 30 and 40
tests will fail.
2) Add OutputDebugStrings in code that runs during static initialization
and static shutdown. This will sometimes generate similar failures.
After a substantial amount of troubleshooting and debugging, I found
that I could reproduce this from the command line without running
check-clang. Simply make the mutex change described in #1, then
manually run the following command many times by running it once, then
pressing Up -> Enter very quickly:
D:\src\llvm\build\vs2013\Debug\bin\c-index-test.EXE -cursor-at=D:\src\llvm\tools\clang\test\Index\targeted-preamble.h:2:15 D:\src\llvm\tools\clang\test\Index\targeted-cursor.c -include D:\src\llvm\build\vs2013\tools\clang\test\Index\Output\targeted-cursor.c.tmp.h -Xclang -error-on-deserialized-decl=NestedVar1 -Xclang -error-on-deserialized-decl=TopVar | D:\src\llvm\build\vs2013\Debug\bin\FileCheck.EXE D:\src\llvm\tools\clang\test\Index\targeted-cursor.c -check-prefix=PREAMBLE-CURSOR1
Sporadically they will fail, and attaching a debugger to a failed
instance indicates that stdin of FileCheck.exe is empty.
Note that due to the repro in #2, we can rule out a bug in the STL's
mutex implementation, and instead conclude that this is a real flake in
the windows test harness.
Test Plan:
Without patch: Ran check-clang 10 times and saw over 30 Unexpected failures on every run.
With patch: Ran check-clang 10 times and saw 0 unexpected failures across all runs.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4021
Patch by Zachary Turner!
llvm-svn: 210225
library. That results in the linker resolving all references to weak symbols in
the DSO to the definition from within that DSO. Ironically, this rarely causes
observable problems, except that it causes ubsan's own dynamic type check to
spuriously fail (because we fail to properly merge type_info object names).
llvm-svn: 210220
Share mode code between these functions and re-structure them in a way
which shows how similar they actually are. The latter function works well
with literals of multi-byte chars and does a GlobalVariable name mangling
(if global strings are non-writable).
No functionality change.
llvm-svn: 210212
Straightforward implementation of UDLs, it's compatible with VS "14".
This nearly completes our implementation of C++ name mangling for the
MS-ABI.
llvm-svn: 210197
These are commonly used to structure things like enums or long braced
lists. There doesn't seem to be a good reason to have the behavior in
such structures be different from the behavior between statements.
llvm-svn: 210183
Fix post-commit review comments by Carlo Bertolli
for commit r209660 - OMP collapse clause.
Re-formatted TransformOMP* functions in TreeTransform.h with clang-format.
llvm-svn: 210169
This corrects long-standing misuses of LLVM's internal config.h.
In most cases the public llvm-config.h header was intended and we can now
remove the old hacks thanks to LLVM r210144.
The config.h header is private, won't be installed and should no longer be
included by clang or other modules.
llvm-svn: 210145
This allows us to compile the following kind of code, which occurs in MSVC
headers:
template <typename> struct S {
__declspec(dllimport) static int x;
};
template <typename T> int S<T>::x;
The definition works similarly to a dllimport inline function definition and
gets available_externally linkage.
Differential Revision: http://reviews.llvm.org/D3998
llvm-svn: 210141
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.
llvm-svn: 210137
This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form.
This is the form required for 'omp simd', 'omp for' and other loop pragmas.
Differential revision: http://reviews.llvm.org/D3778
llvm-svn: 210095
elements from {}, rather than value-initializing them. This permits calling an
initializer-list constructor or constructing a std::initializer_list object.
(It would also permit initializing a const reference or rvalue reference if
that weren't explicitly prohibited by other rules.)
llvm-svn: 210091
just the extremely specific case of a trailing array element that couldn't be
initialized because the default constructor for the element type is deleted.
Also reword the diagnostic to better match our other context diagnostics and to
prepare for the implementation of core issue 1070.
llvm-svn: 210083
trailing elements as a single loop, rather than sometimes emitting a nest of
several loops. This fixes a bug where CodeGen would sometimes try to emit an
expression with the wrong type for the element being initialized. Plus various
other minor cleanups to the IR produced for array new initialization.
llvm-svn: 210079
The only remaining user didn't actually use the non-dynamic storage facility
this class provides.
The std::string is transitional and likely to be StringRefized shortly.
llvm-svn: 210058
Allow the tests to succeed with tne signext (or other) attribute is present. The attributes
show up for Power, but not for x86*, so need to be appropriately wildcarded.
llvm-svn: 210050
Instrumentation passes now use attributes
address_safety/thread_safety/memory_safety which are added by Clang frontend.
Clang parses the blacklist file and adds the attributes accordingly.
Currently blacklist is still used in ASan module pass to disable instrumentation
for certain global variables. We should fix this as well by collecting the
set of globals we're going to instrument in Clang and passing it to ASan
in metadata (as we already do for dynamically-initialized globals and init-order
checking).
This change also removes -tsan-blacklist and -msan-blacklist LLVM commandline
flags in favor of -fsanitize-blacklist= Clang flag.
llvm-svn: 210037
There is a pattern where evaluation order is used as control flow.
This patch special-cases a commonly occuring version of this pattern.
Before:
Aaaaa *aaa = nullptr;
// ...
aaa &&aaa->f();
After:
Aaaaa *aaa = nullptr;
// ...
aaa && aaa->f();
llvm-svn: 210017
We should treat tentative definitions as undefined for the purpose of
ODR-use linkage checking.
This broke somewhere around r149731 when tests were disabled.
Note that test coverage for these diagnostics is generally lacking due to a
separate issue (PR19910: Don't suppress unused/undefined warnings when there
are errors).
llvm-svn: 209996
http://llvm.org/bugs/show_bug.cgi?id=18498
This code was resulting in a crash:
auto L = [](auto ... v) { };
L.operator()<int>(3);
The reason is that the partially-substituted-pack is incorrectly retained within the current-instantiation-scope during template-argument-finalization, and because lambda's are local, there parent instantiation scopes are merged, which leads to the expansion-pattern being retained in the finalized specialization.
This patch ensures that once we have finalized deduction of a parameter-pack, we remove the partially-substituted-pack so that it doesn't cause CheckParameterPacksForExpansion to incorrectly inform the caller that it needs to retain the expansion pattern.
Thanks to Richard Smith for the review!
http://reviews.llvm.org/D2135
llvm-svn: 209992
Remove redundant -fno-stack-protector run with openbsd.
Add -target to the -fstack-protector tests so they pass on openbsd.
Patch by Brad Smith.
llvm-svn: 209991
With recent changes, this is now a compatible language extension and can be
safely enabled with -ms-extensions instead of requiring the full
-ms-compatibility MSVC drop-in mode. As such we can now also emit an extension
warning under -Wmicrosoft to help users port their code.
llvm-svn: 209978
Zachary Turner