Patch by Alexander Zinenko!

llvm-svn: 175890

PR15329.

llvm-svn: 175889

should be unique for each loop.

llvm-svn: 175888

16 more little piglits with radeonsi.

NOTE: This is a candidate for the Mesa stable branch.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 175887

24 more little piglits with radeonsi.

NOTE: This is a candidate for the Mesa stable branch.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 175886

9 more little piglits with radeonsi.

NOTE: This is a candidate for the Mesa stable branch.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 175885

The Printer will now print instructions with the correct alignment specifier syntax, like
    vld1.8  {d16}, [r0:64]

llvm-svn: 175884

MSanDR is a DynamoRio-based tool that handles uninstrumented libraries and
dynamically generated code for MSan.

llvm-svn: 175883

 * Mark attributes as done in SVN.
 * Downgrade alignment support from 'Clang 3.0' to 'SVN', now that we actually implement the rules.
 * Upgrade 'Dynamic initialization with concurrency' from 'No' to 'Clang 2.9' -- all that is required here is the ABI-mandated locking for the initialization of static locals.

llvm-svn: 175882

llvm-svn: 175881

incomplete type.

llvm-svn: 175880

in C++98.

llvm-svn: 175879

Update to use references to attribute groups instead of listing the attributes on the call/invoke instructions.

llvm-svn: 175878

Listing all of the attributes for the callee of a call/invoke instruction is way
too much and makes the IR unreadable. Use references to attributes instead.

llvm-svn: 175877

if it has declarators. We were missing the check for this in a couple of places.

llvm-svn: 175876

llvm-svn: 175875

llvm-svn: 175874

llvm-svn: 175873

llvm-svn: 175872

llvm-svn: 175871

own port namepsace) as the thread identifier to using the system-wide
globally unique thread id as the thread identifier number.

MachThread.cpp keeps both the unique id and the mach port number
for each thread.  All layers outside MachThread class use the unique
id with three exceptions: (1) Mach exceptions come in with the port
number (thread_port) which needs to be translated, (2) any calls to
low-level thread_get_state/thread_set_state/thread_suspend etc need
to use the mach port number, (3) MachThreadList::UpdateThreadList 
which creates the MachThread objects gets the unique id and passes
it to the MachThread ctor as an argument.

In general, any time nub_thread_t is used, it is now referring to a
unique thread id.  Any time a thread_t is used, it is now referring
to a mach port number.  There was some interchangability of these 
types previously.  nub_thread_t has also been changed to a 64-bit
type which necessitated some printf specification string changes.

I haven't been able to test these changes extensively yet but want
to checkpoint the work.  The scenarios I've been testing are all
working correctly so while there may be some corner cases I haven't
hit yet, I think it is substantially correct.

<rdar://problem/12931414> 

llvm-svn: 175870

In LookupResult::resolveKind(), when handling multiple found declarations, ignore invalid declarations.

This reduces the "ambiguous reference" errors (which are rather strange in C/ObjC) and fixes an assertion hit
with an invalid code test case.

llvm-svn: 175869

instead of a non-function type.

llvm-svn: 175868

llvm-svn: 175867

and we used to assert if it did.

llvm-svn: 175866

to the immediate operand of sli or cmp function.

llvm-svn: 175865

llvm-svn: 175864

Fixes <rdar://problem/13236549>

llvm-svn: 175863

llvm-svn: 175862

the normal attribute-merging path, because we can't merge alignment attributes
without knowing the complete set of alignment attributes which apply to a
particular declaration.

llvm-svn: 175861

llvm-svn: 175860

llvm-svn: 175859

accessible in its declaring class;  otherwise we might
fail to apply [class.protected] when considering
accessibility in derived classes.

Noticed by inspection; <rdar://13270329>.

I had an existing test wrong.  Here's why it's wrong:

Follow the rules (and notation) of [class.access]p5.
The naming class (N) is B and the context (R) is D::getX.
- 'x' as a member of B is protected, but R does not occur
  in a member or friend of a class derived from B.
- There does exist a base class of B, A, which is accessible
  from R, and 'x' is accessible at R when named in A because
  'x' as a member of A is protected and R occurs in a member
  of a class, D, that is derived from A;  however, by
  [class.protected], the class of the object expression must
  be equal to or derived from that class, and A does not
  derive from D.

llvm-svn: 175858

Previously, we had the decisions about inlining spread out
over multiple functions.

In addition to the refactor, this commit ensures
that we will always inline BodyFarm functions as long as the Decl
is available. This fixes false positives due to those functions
not being inlined when no or minimal inlining is enabled such (as
shallow mode).

llvm-svn: 175857

Using __package__ and __name__ seems redundant - __name__ should always contain the fully qualified module name

llvm-svn: 175856

to control the check for the C 5.2.4.1 / C++ [implimits] restriction on nesting
levels for parentheses, brackets and braces.

Some code with heavy macro use exceeds the default limit of 256, but we don't
want to increase it generally to avoid stack overflow on stack-constrained
systems.

llvm-svn: 175855

This is a follow-up to r175830, which made sure a temporary object region
created for, say, a struct rvalue matched up with the initial bindings
being stored into it. This does the same for the case in which the AST
actually tells us that we need to create a temporary via a
MaterializeObjectExpr. I've unified the two code paths and moved a static
helper function onto ExprEngine.

This also caused a bit of test churn, causing us to go back to describing
temporary regions without a 'const' qualifier. This seems acceptable; it's
our behavior from a few months ago.

<rdar://problem/13265460> (part 2)

llvm-svn: 175854

It was incorrectly checking a Function* being an IntrinsicInst* which
isn't possible.  It should always have been checking the CallInst* instead.

Added test case for x86 which ensures we only get one constant load.
It was 2 before this change.

rdar://problem/13267920

llvm-svn: 175853

Fix regression in modeling assignments of an address of a variable to itself.  Fixes <rdar://problem/13226577>.

llvm-svn: 175852

if we're compiling.

llvm-svn: 175851