Fixes pr18508.

llvm-svn: 199843

The CF stack can be corrupted if you use CF_ALU_PUSH_BEFORE,
CF_ALU_ELSE_AFTER, CF_ALU_BREAK, or CF_ALU_CONTINUE when the number of
sub-entries on the stack is greater than or equal to the stack entry
size and sub-entries modulo 4 is either 0 or 3 (on cedar the bug is
present when number of sub-entries module 8 is either 7 or 0)

We choose to be conservative and always apply the work-around when the
number of sub-enries is greater than or equal to the stack entry size,
so that we can safely over-allocate the stack when we are unsure of the
stack allocation rules.

reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 199842

reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 199841

reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 199840

reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 199839

v2:
  - Initialize wavefront size to 0

reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 199838

reviewed-by: Vincent Lejeune <vljn at ovi.com>
llvm-svn: 199837

llvm-svn: 199836

llvm-svn: 199835

If an attribute has a semantically meaningful spelling (such as ArgumentWithTypeTagAttr or MSInheritanceAttr), display the spelling used for the attribute as part of the AST dump. This should ease debugging the AST for these attributes. Attributes without semantically meaningful spelling variations are not affected.

llvm-svn: 199834

llvm-svn: 199833

My understanding (from reading just the llvm code) is that
* most ppc cpus have a "sync n" instruction and an msync alias that is "sync 0".
* "book e" cpus instead have a msync instruction and not the more
general "sync n"

This patch reflects that in the .td files, allowing a single codepath for
asm ond obj streamer and incidentelly fixes a crash when EmitRawText was
called on a obj streamer.

llvm-svn: 199832

llvm-svn: 199831

PNaCl and Emscripten can both handle va_arg IR instructions with
struct type.

Also add a test to cover generating a va_arg IR instruction from
va_arg in C on le32 (as already handled by VisitVAArgExpr() in
CGExprScalar.cpp), which was not covered by a test before.

(This fixes https://code.google.com/p/nativeclient/issues/detail?id=2381)

Differential Revision: http://llvm-reviews.chandlerc.com/D2539

llvm-svn: 199830

the defaulting because it would delete the member, produce additional notes
explaining why the member is implicitly deleted.

llvm-svn: 199829

llvm-svn: 199828

llvm-svn: 199827

llvm-svn: 199826

llvm-svn: 199825

This way private memory does not over-write work group information
stored in GPRs 0 and 1.

llvm-svn: 199824

llvm-svn: 199823

(to go with existing suppression of -Wa,-compress-debug-sections)

llvm-svn: 199822

different number of elements.

Bitcasts were passing with vectors of pointers with different number of
elements since the number of elements was checking
SrcTy->getVectorNumElements() == SrcTy->getVectorNumElements() which
isn't helpful. The addrspacecast was also wrong, but that case at least
is caught by the verifier. Refactor bitcast and addrspacecast handling
in castIsValid to be more readable and fix this problem.

llvm-svn: 199821

not using backing ivar warning, ignore when
property is not being synthesized (user declared its
implementation @dynamic). // rdar://1583425

llvm-svn: 199820

currently, for thumbv8, two predefined macros are missing:
 define __THUMB_INTERWORK__ 1
 define __THUMB_INTERWORK__ 1

This patch adds them for thumbv8.

llvm-svn: 199819

This patch restores the ARM mode if the user's inline assembly
does not.  In the object streamer, it ensures that instructions
following the inline assembly are encoded correctly and that
correct mapping symbols are emitted.  For the asm streamer, it
emits a .arm or .thumb directive.

This patch does not ensure that the inline assembly contains
the ADR instruction to switch modes at runtime.

The problem we need to solve is code like this:

  int foo(int a, int b) {
    int r = a + b;
    asm volatile(
        ".align 2     \n"
        ".arm         \n"
        "add r0,r0,r0 \n"
    : : "r"(r));
    return r+1;
  }

If we compile this function in thumb mode then the inline assembly
will switch to arm mode. We need to make sure that we switch back to
thumb mode after emitting the inline assembly or we will incorrectly
encode the instructions that follow (i.e. the assembly instructions
for return r+1).

Based on patch by David Peixotto

Change-Id: Ib57f6d2d78a22afad5de8693fba6230ff56ba48b
llvm-svn: 199818

Before:
  std::unique_ptr<int[]> foo() {}

After:
  std::unique_ptr<int []> foo() {}

Also, the formatting could go severely wrong after such a function
before.

llvm-svn: 199817

We still read/mmap them twice, but the fix for that is a bit more complex.

llvm-svn: 199815

Found by -Wdocumentation.

llvm-svn: 199814

identify_magic is not free, so we should avoid calling it twice. The argument
also makes it cheap for createBinary to just forward to createObjectFile.

llvm-svn: 199813

llvm-svn: 199812

llvm-svn: 199811

llvm-svn: 199810

llvm-svn: 199809

llvm-svn: 199808

llvm-svn: 199807

llvm-svn: 199806

llvm-svn: 199805

llvm-svn: 199804

llvm-svn: 199803