| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 219933
|
| |
|
|
|
|
| |
The test is a C++ semantic analysis test, move it to SemaCXX from Sema. NFC.
llvm-svn: 219932
|
| |
|
|
| |
llvm-svn: 219929
|
| |
|
|
|
|
| |
The ensures there is an explicit address space id in the output.
llvm-svn: 219928
|
| |
|
|
| |
llvm-svn: 219901
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference-ness, etc) for non-type template parameters
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
llvm-svn: 219900
|
| |
|
|
|
|
|
| |
Fix for clang crash when instantiating a template with qualified lookup for members in non-class types.
Differential Revision: http://reviews.llvm.org/D5769
llvm-svn: 219897
|
| |
|
|
|
|
|
|
|
|
| |
Separate out the non-nullable parameters from the nullable ones
(currently only the template template parameter) and demonstrate that
cv-qualifiers aren't preserved for non-null parameters (but are
preserved for null parameters) by adding 'const' to an int* non-type
template parameter.
llvm-svn: 219883
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.
Even if the definition was already emitted, it would never mark the
alias as thread_local.
This fixes PR21288.
llvm-svn: 219859
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When performing a type deduction from the return type, the FunctionDecl may be
attributed with a calling convention. In such a case, the retrieved type
location may be an AttributedTypeLoc. Performing a castAs<FunctionProtoTypeLoc>
on such a type loc would result in an assertion as they are not derived types.
Ensure that we correctly handle the attributed type location by looking through
it to the modified type loc.
Fixes an assertion triggered in C++14 mode.
llvm-svn: 219851
|
| |
|
|
|
|
| |
Remove the use of an unnecessary function. NFC.
llvm-svn: 219850
|
| |
|
|
|
|
| |
PPC64/NetBSD.
llvm-svn: 219839
|
| |
|
|
|
|
| |
struct/union fields. This fixes PR20930.
llvm-svn: 219807
|
| |
|
|
|
|
|
|
| |
In particular, if you have two identical templates in different TUs in
anonymous namespaces, we would use the same global_ctors comdat key for
both. As a result, only one would be run.
llvm-svn: 219806
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The size of the ID field in CommandInfo was narrow, leading to potential
wrap-around of command IDs, causing misinterpretation later on.
The patch does the following:
- It extends the ID bitfield from 8 to 20 bits.
- It provides a DRY definition of the number of bits for the field to
avoid using literal numbers in different files.
- It introduces a new assertion that checks for the wrap-around.
- It adds the testcase from PR21254.
llvm-svn: 219802
|
| |
|
|
| |
llvm-svn: 219797
|
| |
|
|
|
|
|
|
|
|
| |
Unions are initialized with the default initialization of their first
named member. If that member is not zero initialized, then we should
prefer that member's type. Otherwise, we might try to make an otherwise
unsuitable type (like an array) which we cannot easily initialize with a
pointer to member.
llvm-svn: 219781
|
| |
|
|
|
|
|
| |
We assumed the last argument of the copy constructor was the this
pointer. However, this is not the case under the MS ABI.
llvm-svn: 219775
|
| |
|
|
|
|
|
|
|
| |
Split logic to separate checking function
Refine the macro checking
Catch nullptr->bool conversions
Add some explanatory comments
llvm-svn: 219774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AddressSanitizer currently doesn't support this configuration, and binaries
built with it will just get into an infinite loop during startup.
Test Plan: Includes an automated test.
Reviewers: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5764
llvm-svn: 219744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
canonical declaration for line/file information.
When lazily constructing static member variable declarations (when
the vtable optimization fires and the definition of the type is omitted
(or built later, lazily), but the out of line definition of the static
member is provided and must be described in debug info) ensure we use
the canonical declaration when computing the file, line, etc for that
declaration (rather than the definition, which is also a declaration,
but not the canonical one).
llvm-svn: 219736
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Thumb1 has legitimate reasons for preferring 32-bit alignment of types
i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be
a multiple of 4. However, this is a trade-off betweem code size and RAM usage;
the DataLayout string is not the best place to represent it even if desired.
So this patch removes the extra Thumb requirements, hopefully making ARM and
Thumb completely compatible in this respect.
llvm-svn: 219735
|
| |
|
|
|
|
|
|
|
| |
Specifically, avoid typo-correcting the variable name into a type before
typo-correcting the actual type name in the declaration. Doing so
results in a very unpleasant cascade of errors, with the typo correction
of the actual type name being buried in the middle.
llvm-svn: 219732
|
| |
|
|
|
|
|
|
|
|
|
| |
Before, ARM and Thumb mode code had different preferred alignments, which could
lead to some rather unexpected results. There's justification for reducing it
from the default 64-bits (wasted space), but I don't think there is for going
below 32-bits.
There's no actual ABI change here, just to reassure people.
llvm-svn: 219720
|
| |
|
|
|
|
|
| |
implicit casts. Reviewed by Reid Kleckner.
rdar://18405357
llvm-svn: 219712
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Mangling for blocks defined within blocks in an ObjectiveC context were also
broken by SVN r219393. Because the code in mangleName assumed that the code was
either C or C++, we would trigger assertions when trying to mangle the inner
blocks in an ObjectiveC context.
Add a test and use the ObjectiveC specific mangling when dealing with an
ObjectiveC method declaration.
llvm-svn: 219697
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses a regression introduced with SVN r219393. A block may be
contained within another block. In such a scenario, we would end up within a
BlockDecl, which is not a NamedDecl (as the names are synthesised). The cast to
a NamedDecl of the DeclContext would then assert as the types are unrelated.
Restore the mangling behaviour to that prior to SVN r219393. If the current
block is contained within a BlockDecl, walk up to the parent DeclContext,
recursively, until we have a non-BlockDecl. This is expected to be a NamedDecl.
Add in a couple of asserts to ensure that the assumption that we only encounter
a block within a NamedDecl or a BlockDecl.
llvm-svn: 219696
|
| |
|
|
| |
llvm-svn: 219691
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
prologue of the next function.
CodeGenFunction objects aren't really designed to be reused for more
than one function, and doing so can leak debug info location information
from one function into the prologue of the next.
Add an assertion in to catch reuses of CodeGenFunction, which
surprisingly only caught the ObjC atomic getter/setter cases. Fix those
and add a test to demonstrate the issue.
The test is a bit slim, because we're just testing for the absence of a
debug location on the prologue instructions, which by itself probably
wouldn't be the end of the world - but the particular debug location
that was ending up there was for the previous function's last
instruction. This produced debug info for another function within this
function, which is something I'm trying to remove all cases of as its a
substantial source of bugs, especially around inlining (see r219215).
llvm-svn: 219690
|
| |
|
|
| |
llvm-svn: 219679
|
| |
|
|
|
|
|
| |
In cases of nested module builds, or when you care how long module builds take,
this information was not previously easily available / obvious.
llvm-svn: 219658
|
| |
|
|
| |
llvm-svn: 219657
|
| |
|
|
|
|
|
|
|
|
|
| |
This change adds UBSan check to upcasts. Namely, when we
perform derived-to-base conversion, we:
1) check that the pointer-to-derived has suitable alignment
and underlying storage, if this pointer is non-null.
2) if vptr-sanitizer is enabled, and we perform conversion to
virtual base, we check that pointer-to-derived has a matching vptr.
llvm-svn: 219642
|
| |
|
|
|
|
|
|
| |
Objective-C pointer types. In this case, checker incorrectly
claims incompatible pointer types if redundant protocol conformance
is specified. rdar://18491222
llvm-svn: 219630
|
| |
|
|
|
|
| |
Patch by Daniel Fahlgren!
llvm-svn: 219625
|
| |
|
|
|
|
|
| |
Allow "signext" in a couple of more places in recently
added test cases to fix failures on SystemZ.
llvm-svn: 219615
|
| |
|
|
|
|
| |
Don't include stdint.h directly, instead typedef int64_t which is all we need.
llvm-svn: 219608
|
| |
|
|
|
|
| |
Patch by Matthew Wahab.
llvm-svn: 219607
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some early revisions of the Cortex-A53 have an erratum (835769) whereby it is
possible for a 64-bit multiply-accumulate instruction in AArch64 state to
generate an incorrect result. The details are quite complex and hard to
determine statically, since branches in the code may exist in some
circumstances, but all cases end with a memory (load, store, or prefetch)
instruction followed immediately by the multiply-accumulate operation.
The safest work-around for this issue is to make the compiler avoid emitting
multiply-accumulate instructions immediately after memory instructions and the
simplest way to do this is to insert a NOP.
This patch implements clang options to enable this workaround in the backend.
The work-around code generation is not enabled by default.
llvm-svn: 219604
|
| |
|
|
| |
llvm-svn: 219601
|
| |
|
|
|
|
|
| |
This patch generates call to "kmpc_push_num_threads(ident_t *loc, kmp_int32 global_tid, kmp_int32 num_threads);" library function before calling "kmpc_fork_call" each time there is an associated "num_threads" clause in the "omp parallel" directive.
Differential Revision: http://reviews.llvm.org/D5145
llvm-svn: 219599
|
| |
|
|
| |
llvm-svn: 219598
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds codegen for 'if' clause. Currently only for 'if' clause used with the 'parallel' directive.
If condition evaluates to true, the code executes parallel version of the code by calling __kmpc_fork_call(loc, 1, microtask, captured_struct/*context*/), where loc - debug location, 1 - number of additional parameters after "microtask" argument, microtask - is outlined finction for the code associated with the 'parallel' directive, captured_struct - list of variables captured in this outlined function.
If condition evaluates to false, the code executes serial version of the code by executing the following code:
global_thread_id.addr = alloca i32
store i32 global_thread_id, global_thread_id.addr
zero.addr = alloca i32
store i32 0, zero.addr
kmpc_serialized_parallel(loc, global_thread_id);
microtask(global_thread_id.addr, zero.addr, captured_struct/*context*/);
kmpc_end_serialized_parallel(loc, global_thread_id);
Where loc - debug location, global_thread_id - global thread id, returned by __kmpc_global_thread_num() call or passed as a first parameter in microtask() call, global_thread_id.addr - address of the variable, where stored global_thread_id value, zero.addr - implicit bound thread id (should be set to 0 for serial call), microtask() and captured_struct are the same as in parallel call.
Also this patch checks if the condition is constant and if it is constant it evaluates its value and then generates either parallel version of the code (if the condition evaluates to true), or the serial version of the code (if the condition evaluates to false).
Differential Revision: http://reviews.llvm.org/D4716
llvm-svn: 219597
|
| |
|
|
|
|
| |
For commit r219561 - Fix deserialization of PredefinedExpr in dependent context.
llvm-svn: 219594
|
| |
|
|
|
|
|
|
| |
Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).
Reviewed by Richard Smith
llvm-svn: 219589
|
| |
|
|
|
|
|
|
|
| |
While we ran getUnqualifiedType over the catch type,
it isn't enough for array types. Use getUnqualifiedArrayType instead.
This fixes PR21252.
llvm-svn: 219582
|
| |
|
|
| |
llvm-svn: 219580
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and !=) to support mixed complex and real operand types.
This requires removing an assert from SemaChecking, and adding support
both to the constant evaluator and the code generator to synthesize the
imaginary part when needed. This seemed somewhat cleaner than having
just the comparison operators force real-to-complex conversions.
I've added test cases for these operations. I'm really terrified that
there were *no* tests in-tree which exercised this.
This turned up when trying to build R after my change to the complex
type lowering.
llvm-svn: 219570
|
| |
|
|
|
|
| |
Patch by Charlie Turner.
llvm-svn: 219569
|
| |
|
|
|
|
|
|
|
|
|
| |
for complex math.
This should fix the windows build bots that started having trouble here
and generally fix complex libcall emission on targets which use sret for
complex data types. It also makes the code a bit simpler (despite
calling into a much more complex bucket of code).
llvm-svn: 219565
|