using multiclass.

llvm-svn: 169432

Fixed arrays with a size of 1 to correctly have 1 member when DW_AT_upper_bound was set to zero and no other attributes were set.

llvm-svn: 169431

and does an '-index-file' for all compile commands in the database.

llvm-svn: 169430

llvm-svn: 169429

llvm-svn: 169428

llvm-svn: 169427

Now that live register units are tracked individually, the code can be simplified.

llvm-svn: 169426

This is much simpler to reason about, more efficient, and
fixes some corner cases involving implicit super-register defs.
Fixed rdar://12797931.

llvm-svn: 169425

Always allows getting builtin types by name even if there is no backing debug information.

llvm-svn: 169424

llvm-svn: 169423

-fasm-blocks flag, not the -fms-extensions flag.
rdar://12808010

llvm-svn: 169422

File contains installation and usage instructions.

llvm-svn: 169421

The encoding of NOP in ARMAsmBackend.cpp is missing a trailing zero, which
causes the emission of a coprocessor instruction rather than "mov r0, r0"
as indicated in the comment.  The test also checks for the wrong encoding.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121203/157919.html

llvm-svn: 169420

llvm-svn: 169419

Patch by Eric Holk

llvm-svn: 169418

llvm-svn: 169417

The new command line option -unwind-info dumps the Win64 EH unwind
data to the console. This is a nice feature if you need to debug
generated EH data (e.g. from LLVM). Includes a test case.

Initial patch by João Matos, extensions and rework by Kai Nacke.

llvm-svn: 169415

Change member types of RuntimeFunction and UnwindInfo from uint64_t to
uint32_t:
These members represent addresses. According to MSDN, they are image
relative, that is, they are 32-bit offsets from the starting address
of the image that contains the function table entry.
See MSDN for more information:
RUNTIME_FUNCTION: http://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx
UNWIND_INFO: http://msdn.microsoft.com/en-us/library/ddssxxy8.aspx

Make Win64.h platform-neutral:
The standard types unit8_t, uint16_t and uint32_t are replaced with
their counterparts from Endian.h. Accessor functions are introduced to
replace bit fields.

Patch by João Matos and Kai Nacke.

llvm-svn: 169414

llvm-svn: 169413

<declaration> tag of Comment XML.
Added DeclPrint support for constructors
and fix tests accordingly.
This is wip. // rdar://12378714

llvm-svn: 169412

llvm-svn: 169411

llvm-svn: 169410

Backed out part of the ABI changes that were checked in because it breaks the i386 test suite as it makes backtraces for the first instruction of a function fail. Stepping relies on backtraces being correct, so I am reverting what is causing the breakage.

I filed this to track the fix:

<rdar://problem/12817918> Recent i386 ABI changes break the i386 test suite because stack backtracing is busted when stopped in trampolines

llvm-svn: 169409

addressing mode and immediate stored value.

llvm-svn: 169408

good for enacpsulation anyway.

llvm-svn: 169407

For OS X builds, we generate one version of config.h but then build for
multiple architectures.  This means that the LLVM_HOSTTRIPLE setting may have
the wrong architecture.  Adjust it dynamically to match the current
architecture.  <rdar://problem/12715470>

llvm-svn: 169405

llvm-svn: 169404

- using "__lambda_node" causes internal compiler error in newer GCC versions

llvm-svn: 169402

llvm-svn: 169401

For most cases where a conversion specifier doesn't match an argument,
we usually guess that the conversion specifier is wrong. However, if
the argument is an integer type and the specifier is %C, it's likely
the user really did mean to print the integer as a character.

(This is more common than %c because there is no way to specify a unichar
literal -- you have to write an integer literal, such as '0x2603',
and then cast it to unichar.)

This does not change the behavior of %S, since there are fewer cases
where printing a literal Unicode *string* is necessary, but this could
easily be changed in the future.

<rdar://problem/11982013>

llvm-svn: 169400

No functionality change (the test change is a comment only, and the new
functionality can't be tested using the current test).

llvm-svn: 169399

The type of a character literal is 'int' in C, but if the user writes a
character /as/ a literal, we should assume they meant it to be a
character and not a numeric value, and thus offer %c as a correction
rather than %d.

There's a special case for multi-character literals (like 'MooV'), which
have implementation-defined value and usually cannot be printed with %c.
These still use %d as the suggestion.

In C++, the type of a character literal is 'char', and so this problem
doesn't exist.

<rdar://problem/12282316>

llvm-svn: 169398

We tried to account for 'uint8_t' by saying that /typedefs/ of 'char'
should be corrected as %hhd rather than %c, but the condition was wrong.

llvm-svn: 169397

Also use the portable (ugly) format string macros, for MSVC compatibility.

llvm-svn: 169396

A MachineInstr can only ever be constructed by CreateMachineInstr() and
CloneMachineInstr(), and those factories don't use the removed
constructors.

llvm-svn: 169395

llvm-svn: 169394

This is for the lldb team so most of but not all of the values are
to be printed as hex with this option.  Some small values like the
scale in an X86 address were requested to printed in decimal
without the leading 0x.

There may be some tweaks need to places that may still be in
decimal that they want in hex.  Specially for arm.  I made my best
guess.  Any tweaks from here should be simple.

I also did the best I know now with help from the C++ gurus
creating the cleanest formatImm() utility function and containing
the changes.  But if someone has a better idea to make something
cleaner I'm all ears and game for changing the implementation.

rdar://8109283

llvm-svn: 169393

llvm-svn: 169392

- Added calls to doInitialization/doFinalization to immutable passes
- fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies
- fixed machine module info to operate in the doInitialization/doFinalization model, also fixes some FIXMEs

reviewed by Evan Cheng <evan.cheng@apple.com>

llvm-svn: 169391

llvm-svn: 169390