llvm-svn: 197335

llvm-svn: 197332

The warning for backslash and newline separated by whitespace was missed in
this code path.

backslash<whitespace><newline> is handled differently from compiler to compiler
so it's important to warn consistently where there's ambiguity.

Matches similar handling of block comments and non-comment lines.

llvm-svn: 197331

This was silently accepted by clang without warning due to a lexer bug.

llvm-svn: 197330

llvm-svn: 197329

llvm-svn: 197327

I don't think we should need a triple, but this allows us to run the test
until we fix it (PR18251).

llvm-svn: 197326

This is a base implementation of the powerpc-apple-darwin asm parser dialect.

* Enables infrastructure (essentially isDarwin()) and fixes up the parsing of asm directives to separate out ELF and MachO/Darwin additions.
* Enables parsing of {r,f,v}XX as register identifiers.
* Enables parsing of lo16() hi16() and ha16() as modifiers.

The changes to the test case are from David Fang (fangism).

llvm-svn: 197324

llvm-svn: 197323

Comment indicates where linux x86_64 lldb-gdbserver
will soon be added to Makefile builds.

llvm-svn: 197318

This optional register liveness analysis pass can be enabled with either
-enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass
traverses each basic block in a machine function. For each basic block the
instructions are processed in reversed order and if a patchpoint or stackmap
instruction is encountered the current live-out register set is encoded as a
register mask and attached to the instruction.

Later on during stackmap generation the live-out register mask is processed and
also emitted as part of the stackmap.

This information is optional and intended for optimization purposes only. This
will enable a client of the stackmap to reason about the registers it can use
and which registers need to be preserved.

Reviewed by Andy

llvm-svn: 197317

llvm-svn: 197316

Reviewed by Andy

llvm-svn: 197315

We should check defined(__clang__) before the usage of the
clang diagnostic pragmas.

The [-Wswitch] warning in src/future.cpp should be ignored.
As the result, the equivalent GCC pragma is added.

llvm-svn: 197314

GCC does not support strong enum if -std=c++0x is not used.
Without the strong enum, we will see following error:

  In file included from libcxx/include/ostream:131:0,
                   from libcxx/include/sstream:174,
                   from libcxx/include/complex:247,
                   from cpp03-headers.cpp:11:
  libcxx/include/ios:419:68: error: 'io_errc' is not a class or namespace
  libcxx/include/ios:420:66: error: 'io_errc' is not a class or namespace

To workaround this issue, this commit will define
_LIBCPP_HAS_NO_STRONG_ENUMS when we are compiling with
g++ without c++0x.

llvm-svn: 197313

No functionality change.

llvm-svn: 197312

No functionality change.

llvm-svn: 197311

No functionality change.

llvm-svn: 197310

CompilationDatabase.cpp:stripPositionalArgs(): Match not "no-integrated-as" but "-no-integrated-as", it really fixes r197229.

llvm-svn: 197309

These were just missing an expected-no-diagnostics directive.

Also add -std=c++11 to a test warning noisly about extensions.

llvm-svn: 197308

Symbol names exported from a DLL should be undecorated, not prefixed by
an underscore ones.

llvm-svn: 197307

llvm-svn: 197306

is specialized by an explicit specialization, start from the first declaration
in case we've got a member of a class template (redeclarations might not number
the template parameters the same way).

Our recover here is still far from ideal.

llvm-svn: 197305

[block-freq] Rename getEntryFrequency() -> getEntryFreq() to match getBlockFreq() in all *BlockFrequencyInfo*.

llvm-svn: 197304

[block-freq] Teach branch probability how to return the edge weight in between a BasicBlock and one of its successors.

IMHO At some point BasicBlock should be refactored along the lines of
MachineBasicBlock so that successors/weights are actually embedded within the
block. Now is not that time though.

llvm-svn: 197303

llvm-svn: 197302

and still inherit the designated initializers of its super class.

llvm-svn: 197301

change SBQueue to have a shared pointer to its corresponding
QueueImpl object for binary compatibility.
<rdar://problem/15657926> 

llvm-svn: 197300

This patch was submitted to the list for review and didn't receive a LGTM.

(In fact one explicit objection and one query were raised.)

This reverts commit r197295.

llvm-svn: 197299

class templates (a Microsoft extension).

llvm-svn: 197298

llvm-svn: 197297

[block-freq] Refactor LiveInterals::getSpillWeight to use the new MachineBlockFrequencyInfo methods.

This is slightly more interesting than the previous batch of changes.
Specifically:

1. We refactor getSpillWeight to take a MachineBlockFrequencyInfo (MBFI)
object. This enables us to completely encapsulate the actual manner we
use the MachineBlockFrequencyInfo to get our spill weights. This yields
cleaner code since one does not need to fetch the actual block frequency
before getting the spill weight if all one wants it the spill weight. It
also gives us access to entry frequency which we need for our
computation.

2. Instead of having getSpillWeight take a MachineBasicBlock (as one
might think) to look up the block frequency via the MBFI object, we
instead take in a MachineInstr object. The reason for this is that the
method is supposed to return the spill weight for an instruction
according to the comments around the function.

llvm-svn: 197296

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

llvm-svn: 197295

clang still doesn't emit the right llvm code when initializing multi-D arrays it seems.

For e.g. the following code would still crash for me on Windows 7, 64 bit:

auto f4 = new int[100][200][300]{{{1,2,3}, {4, 5, 6}}, {{10, 20, 30}}};

It seems that the final new loop that iterates through each outermost array and memsets it to zero gets confused with its final ptr arithmetic.

This patch ensures that it converts the pointer to the allocated type (int [200][300]) before incrementing it (instead of using the base type: 'int').

Richard somewhat squeamishly approved the patch (as a quick fix to potentially make it into 3.4) - while exhorting for a more optimized fix in the future. http://llvm-reviews.chandlerc.com/D2398
 
Thanks Richard!

llvm-svn: 197294

Use CHECK-LABEL, add an i64 version, check store instructions.

llvm-svn: 197293

llvm-svn: 197292

[block-freq] Store MBFI as a field on SpillPlacement so we can access it to get the entry frequency while processing data.

llvm-svn: 197291

[block-freq] Update MachineBlockPlacement and RegAllocGreedy to use the new MachineBlockFrequencyInfo methods.

llvm-svn: 197290

llvm-svn: 197289

llvm-svn: 197288