Hans Wennborg [Tue, 10 Jun 2014 00:55:51 +0000 (00:55 +0000)]
Improve checking for dynamic initializers of dllimport fields in template instantiation
We would previously assert if the initializer was dependent. I also think that
checking isConstantInitializer is more correct here than checkInitIsICE.
Richard Trieu [Mon, 9 Jun 2014 22:53:25 +0000 (22:53 +0000)]
Removing an "if (this == nullptr)" check from two print methods. The condition
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.
Objective-C. Consider block pointer as NSObject as well as conforming to
'NSCopying' protocol when diagnosing block to ObjC pointer conversion.
// rdar://16739120
Fix line numbers for code inlined from __nodebug__ functions.
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.
Bill Schmidt [Mon, 9 Jun 2014 03:31:47 +0000 (03:31 +0000)]
[PPC64LE] Implement little-endian semantics for vec_sums
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.
David Majnemer [Sun, 8 Jun 2014 04:51:13 +0000 (04:51 +0000)]
MS ABI: Simplify microsoft mangling of template instantiations
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.
Alp Toker [Sat, 7 Jun 2014 23:30:53 +0000 (23:30 +0000)]
Avoid dubious IdentifierInfo::getNameStart() uses
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.
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.
Bill Schmidt [Sat, 7 Jun 2014 02:20:52 +0000 (02:20 +0000)]
[PPC64LE] Implement little-endian semantics for vec_unpack[hl]
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.
Bill Schmidt [Sat, 7 Jun 2014 01:47:42 +0000 (01:47 +0000)]
[PPC64LE] Update test for vec_sum2s interface
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.
Bill Schmidt [Fri, 6 Jun 2014 23:12:00 +0000 (23:12 +0000)]
[PPC64LE] Update builtins-ppc-altivec.c for PPC64 and PPC64LE
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.
Warren Hunt [Fri, 6 Jun 2014 22:12:37 +0000 (22:12 +0000)]
[MS-ABI] Implement dynamic_cast
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.
Hans Wennborg [Fri, 6 Jun 2014 20:04:01 +0000 (20:04 +0000)]
MS ABI: Update the thunk linkage computation
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.
Hans Wennborg [Fri, 6 Jun 2014 17:36:17 +0000 (17:36 +0000)]
Defer codegen of inline method definitions to the end of current top level declaration
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.
Richard Smith [Fri, 6 Jun 2014 16:00:50 +0000 (16:00 +0000)]
PR14841: If partial substitution of explicitly-specified template arguments
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.
Bill Schmidt [Fri, 6 Jun 2014 15:10:47 +0000 (15:10 +0000)]
[PPC64LE] Implement little-endian semantics for vec_pack family
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.
Bill Schmidt [Fri, 6 Jun 2014 14:45:06 +0000 (14:45 +0000)]
[PPC64LE] Implement little-endian semantics for vec_mul[eo]
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.
Alp Toker [Fri, 6 Jun 2014 06:58:25 +0000 (06:58 +0000)]
Devise a package-private means to determine the LLVM version string
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.
Alp Toker [Thu, 5 Jun 2014 22:11:12 +0000 (22:11 +0000)]
Provide fallback locations for backend remarks
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).
Alp Toker [Thu, 5 Jun 2014 22:10:59 +0000 (22:10 +0000)]
Implement -Wframe-larger-than backend diagnostic
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.
Alexey Samsonov [Thu, 5 Jun 2014 20:53:34 +0000 (20:53 +0000)]
Mangle predefined string constants names to merge them at link-time
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.
Richard Smith [Thu, 5 Jun 2014 20:13:13 +0000 (20:13 +0000)]
Cleanup, and always create a DecltypeType for a decltype expression, rather
than omitting it the first time we see a decltype type with a particular
expression.
Bill Schmidt [Thu, 5 Jun 2014 19:07:40 +0000 (19:07 +0000)]
[PPC64LE] Implement little-endian semantics for vec_perm
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.
Renato Golin [Thu, 5 Jun 2014 16:45:22 +0000 (16:45 +0000)]
Add pointer types to global named register
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.
Fix equalsNode() to accept pointers to derived types.
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*'.
Puyan Lotfi [Thu, 5 Jun 2014 04:29:21 +0000 (04:29 +0000)]
Changing this line of code back to the way it was before Alp's config.h clean up changes.
I've already spoken to Alp and he signed off on making this one change, so that our buildbots
go green in the short term.
Reid Kleckner [Thu, 5 Jun 2014 00:13:43 +0000 (00:13 +0000)]
Flush C stdio streams upon process termination
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:
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.
Richard Smith [Wed, 4 Jun 2014 23:28:46 +0000 (23:28 +0000)]
[ubsan] Don't add a --dynamic-list for ubsan symbols when building a shared
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).
Alexey Samsonov [Wed, 4 Jun 2014 19:56:57 +0000 (19:56 +0000)]
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral.
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).
Daniel Jasper [Wed, 4 Jun 2014 12:40:57 +0000 (12:40 +0000)]
clang-format: Leave empty lines within UnwrappedLines.
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.
Richard Smith [Tue, 3 Jun 2014 23:27:44 +0000 (23:27 +0000)]
Add __builtin_operator_new and __builtin_operator_delete, which act like calls
to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.
projects / clang / log