the Mips16 port. A few of the psuedos could either take signed
or unsigned arguments and I did not distinguish the case and improperly
rejected some valid cases that the assembler had previously accepted
when they were pure pseudos that expanded as assembly instructions.

llvm-svn: 183633

Also move CGCleanup.h to the top of CGCleanup.cpp to verify that
CGCleanup.h really includes what it needs.

llvm-svn: 183632

No functionality change.  CGCleanup.cpp provides the implementation for
EHScopeStack, so it seems more consistent to place the class definition
in CGCleanup.h.

This should also help solve a header ordering problem that I have.

llvm-svn: 183631

PR16281.

llvm-svn: 183630

PR16283.

llvm-svn: 183629

Since we have ARM unwind directive parser and assembler, we
can check the correctness in two stages:

1. From LLVM assembly (.ll) to ARM assembly (.s)
2. From ARM assembly (.s) to ELF object file (.o)

We already have several "*.s to *.o" test cases.  This CL adds
some "*.ll to *.s" test cases and removes the redundant "*.ll to *.o"
test cases.

New test cases to check "*.ll to *.s" code generator:

- ehabi.ll: Check the correctness of the generated unwind directives.
- section-name.ll: Check the section name of functions.

Removed test cases:

- ehabi-mc-cantunwind.ll
  (Covered by ehabi-cantunwind.ll, and eh-directive-cantunwind.s)
- ehabi-mc-compact-pr0.ll
  (Covered by ehabi.ll, eh-compact-pr0.s, eh-directive-save.s, and
   eh-directive-setfp.s)
- ehabi-mc-compact-pr1.ll
  (Covered by ehabi.ll, eh-compact-pr1.s, eh-directive-save.s, and
   eh-directive-setfp.s)
- ehabi-mc.ll
  (Covered by ehabi.ll, and eh-directive-integrated-test.s)
- ehabi-mc-section-group.ll
  (Covered by section-name.ll, and eh-directive-section-comdat.s)
- ehabi-mc-section.ll
  (Covered by section-name.ll, and eh-directive-section.s)
- ehabi-mc-sh_link.ll
  (Covered by eh-directive-text-section.s, and eh-directive-section.s)

llvm-svn: 183628

Changes to ARM unwind opcode assembler:

* Fix multiple .save or .vsave directives.  Besides, the
  order is preserved now.

* For the directives which will generate multiple opcodes,
  such as ".save {r0-r11}", the order of the unwind opcode
  is fixed now, i.e. the registers with less encoding value
  are popped first.

* Fix the $sp offset calculation.  Now, we can use the
  .setfp, .pad, .save, and .vsave directives at any order.

Changes to test cases:

* Add test cases to check the order of multiple opcodes
  for the .save directive.

* Fix the incorrect $sp offset in the test case.  The
  stack pointer offset specified in the test case was
  incorrect.  (Changed test cases: ehabi-mc-section.ll and
  ehabi-mc.ll)

* The opcode to restore $sp are slightly reordered.  The
  behavior are not changed, and the new output is same
  as the output of GNU as.  (Changed test cases:
  eh-directive-pad.s and eh-directive-setfp.s)

llvm-svn: 183627

llvm-svn: 183626

Variadic functions are particularly fragile in the face of ABI changes, so this
limits how much the pass changes them

llvm-svn: 183625

The register classes when emitting loads weren't quite restricting enough, leading to MI verification failure on the result register.

These are new failures that weren't there the first time I tried enabling ARM FastISel for new targets.

llvm-svn: 183624

llvm-svn: 183623

llvm-svn: 183622

sys::process::get_id() now returns the process ID instead of a process handle on Windows.  Patch thanks to Kim Gräsman!

llvm-svn: 183621

Fix the parser's updating of the template depth when parsing local templates and late-parsed templates. 
This is a slight tweak of r180708; It avoids incrementing depth when non-template local classes nested within member templates of local classes are encountered.  
This patch was LGTM'd by Doug http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130506/079656.html and passed the regression tests that normally pass (i.e. excluding many Module and Index tests on Windows that fail regardless)

llvm-svn: 183620

I ran clang-format on my patch but it seemed to have wreaked havoc with new lines  - might have to do with using it on windows :( will resubmit once i've cleaned this issue up. sorry.

llvm-svn: 183619

Fix the parser's updating of the template depth when parsing local templates and late-parsed templates. This is a slight tweak of r180708; It avoids incrementing depth when non-template local classes nested within member templates of local classes are encountered.  
This patch was LGTM'd by Doug http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130506/079656.html and passed the regression tests that normally pass (i.e. excluding many Module and Index tests on Windows that fail regardless)

llvm-svn: 183618

r183614 was failing because va_list on some platforms is defined in a
similar manner.  This test fails on Windows with r183614 applied.

llvm-svn: 183617

This reverts commit r183614.

It broke test/Sema/block-printf-attribute-1.c on non-Windows platforms,
and the fix is not trivial.

llvm-svn: 183616

This helps preserve the type-as-written in the AST, which we need for
MSVC mangling.  In particular, we need to preserve the types of array
parameters in function pointer types.

The essence of this change is:
-  QualType ArgTy = Param->getType();
+  QualType ArgTy = Param->getTypeSourceInfo()->getType();

... followed by the adjustment in ActOnFunctionDeclarator().

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

llvm-svn: 183614

llvm-svn: 183613

Enforce Table A7-15 (op=1, cmode=0b111) -> UNDEF

llvm-svn: 183612

llvm-svn: 183611

Handle the case when the disassembler table can't tell
the difference between some encodings of QADD and CPS.

Add some necessary safe guards in CPS decoding as well.

llvm-svn: 183610

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

llvm-svn: 183609

UNPRED was reported instead of UNDEF

llvm-svn: 183608

Several LLVM headers are moved.  The code listings in
LLVM tutorial are not updated yet.

This CL removes the code replica in the .rst, and replace
them with a literalinclude directive, so that sphinx can
include the latest code automatically.

llvm-svn: 183607

  r183584 tries to derive some info from the code *AFTER* a call and apply
these derived info to the code *BEFORE* the call, which is not always safe
as the call in question may never return, and in this case, the derived
info is invalid.
  
  Thank Duncan for pointing out this potential bug.

rdar://14073661 

llvm-svn: 183606

sys::IdentifyFileType is already conscious of the length, and
object_error::invalid_file_type is returned below anyway if
sys::IdentifyFileType doesn't recognize the file.

llvm-svn: 183605

llvm-svn: 183604

llvm-svn: 183603

llvm-svn: 183602

llvm-svn: 183601

Based on feedback from Jordan.

llvm-svn: 183600

We drew the diagnostic edges to wrong statements in cases the note was on a macro.
The fix is simple, but seems to work just fine for a whole bunch of test cases (plist-macros.cpp).

Also, removes an unnecessary edge in edges-new.mm, when function signature starts with a macro.

llvm-svn: 183599

llvm-svn: 183598

Two variables with the same name declared in two if conditions in the same
scope are no longer coalesced into one.

rdar://problem/14024005

llvm-svn: 183597

destination operands of an instruction.

No functionality changes.

llvm-svn: 183596

instantiation issue with non-standard type.

Add a backend option to warn on a given stack size limit.
Option: -mllvm -warn-stack-size=<limit>
Output (if limit is exceeded):
warning: Stack size limit exceeded (<actual size>) in <functionName>.

The longer term plan is to hook that to a clang warning.
PR:4072
<rdar://problem/13987214>.

llvm-svn: 183595

created through binding a reference-to-array to an initializer list.

llvm-svn: 183594

This is using a hint from AMD APP OpenCL Programming Guide with
empirically tweaked parameters.
I used Unigine Heaven 3.0 to determine best parameters on my system
(i7 2600/Radeon 6950/Kernel 3.9.4) the benchmark :
it went from 38.8 average fps to 39.6, which is ~3% gain.
(Lightmark 2008.2 gain is much more marginal: from 537 to 539)

There is no lit test provided as the parameter were determined
empirically and it it would be nearly impossiblet to find a test
program that check for optimal behavior.

llvm-svn: 183593