GCC declares __clear_cache in the gnu modes (-std=gnu++98,
-std=gnu++11), but not in the strict modes (-std=c++98, -std=c++11). This patch
declares it and therefore fixes the build when using one of the strict modes.

llvm-svn: 181785

Current gcc's produce an error if __clear_cache is anything but

__clear_cache(char *a, char *b);

It looks like we had just implemented a gcc bug that is now fixed.

llvm-svn: 181784

llvm-svn: 181783

llvm-svn: 181782

There is no clangRewrite.a.

llvm-svn: 181781

llvm-svn: 181780

llvm-svn: 181779

We have been assuming that CharSourceRange::getTokenRange() by itself
expands a range until the end of a token, but in fact it only sets
IsTokenRange to true. Thus, we have so far only considered the first
character of the last token to belong to an unwrapped line. This
did not really manifest in symptoms as all edit integrations
expand ranges to fully lines.

llvm-svn: 181778

llvm-svn: 181777

Reviewed-by: Christian König <christian.koenig@amd.com>
llvm-svn: 181775

Forgot to svn add these...

llvm-svn: 181774

The GNU assembler treats things like:

        brasl   %r14, 100

in the same way as:

        brasl   %r14, .+100

rather than as a branch to absolute address 100.  We implemented this in
LLVM by creating an immediate operand rather than the usual expr operand,
and by handling immediate operands specially in the code emitter.
This was undesirable for (at least) three reasons:

- the specialness of immediate operands was exposed to the backend MC code,
  rather than being limited to the assembler parser.

- in disassembly, an immediate operand really is an absolute address.
  (Note that this means reassembling printed disassembly can't recreate
  the original code.)

- it would interfere with any assembly manipulation that we might
  try in future.  E.g. operations like branch shortening can change
  the relative position of instructions, but any code that updates
  sym+offset addresses wouldn't update an immediate "100" operand
  in the same way as an explicit ".+100" operand.

This patch changes the implementation so that the assembler creates
a "." label for immediate PC-relative operands, so that the operand
to the MCInst is always the absolute address.  The patch also adds
some error checking of the offset.

llvm-svn: 181773

Marking instructions as isAsmParserOnly stops them from being disassembled.
However, in cases where separate asm and codegen versions exist, we actually
want to disassemble to the asm ones.

No functional change intended.

llvm-svn: 181772

The SystemZ port currently relies on the order of the instruction operands
matching the order of the instruction field lists.  This isn't desirable
for disassembly, where the two are matched only by name.  E.g. the R1 and R2
fields of an RR instruction should have corresponding R1 and R2 operands.

The main complication is that addresses are compound operands,
and as far as I know there is no mechanism to allow individual
suboperands to be selected by name in "let Inst{...} = ..." assignments.
Luckily it doesn't really matter though.  The SystemZ instruction
encoding groups all address fields together in a predictable order,
so it's just as valid to see the entire compound address operand as
a single field.  That's the approach taken in this patch.

Matching by name in turn means that the operands to COPY SIGN and
CONVERT TO FIXED instructions can be given in natural order.
(It was easier to do this at the same time as the rename,
since otherwise the intermediate step was too confusing.)

No functional change intended.

llvm-svn: 181771

Before (in styles that allow it), clang-format would not merge an
if statement onto a single line, if only the second line was format
(e.g. in an editor integration):

if (a)
  return; // clang-format invoked on this line.

With this patch, this gets properly merged to:

if (a) return; // ...

llvm-svn: 181770

The SystemZ port currently relies on the order of the instruction operands
matching the order of the instruction field lists.  This isn't desirable
for disassembly, where the two are matched only by name.  E.g. the R1 and R2
fields of an RR instruction should have corresponding R1 and R2 operands.

The main complication is that addresses are compound operands,
and as far as I know there is no mechanism to allow individual
suboperands to be selected by name in "let Inst{...} = ..." assignments.
Luckily it doesn't really matter though.  The SystemZ instruction
encoding groups all address fields together in a predictable order,
so it's just as valid to see the entire compound address operand as
a single field.  That's the approach taken in this patch.

Matching by name in turn means that the operands to COPY SIGN and
CONVERT TO FIXED instructions can be given in natural order.
(It was easier to do this at the same time as the rename,
since otherwise the intermediate step was too confusing.)

No functional change intended.

llvm-svn: 181769

This library supports all the features of the compile-time based ASTMatcher
library, but allows the user to specify and construct the matchers at runtime.
It contains the following modules:
 - A variant type, to be used by the matcher factory.
 - A registry, where the matchers are indexed by name and have a factory method
   with a generic signature.
 - A simple matcher expression parser, that can be used to convert a matcher
   expression string into actual matchers that can be used with the AST at
   runtime.

Many features where omitted from this first revision to simplify this code
review. The main ideas are still represented in this change and it already has
support working use cases.
Things that are missing:
 - Support for polymorphic matchers. These requires supporting code in the
   registry, the marshallers and the variant type.
 - Support for numbers, char and bool arguments to the matchers. This requires
   supporting code in the parser and the variant type.
 - A command line program putting everything together and providing an already
   functional tool.

Patch by Samuel Benzaquen.

llvm-svn: 181768

This fixes indentation where there are for example multiple closing
parentheses after a string literal, and where those parentheses
run over the end of the line.

During testing this revealed a bug in the implementation of
breakProtrudingToken: we don't want to change the state if we didn't
actually do anything.

llvm-svn: 181767

- Remove free variables
- Add function clang-format-buffer, e.g. for before-save-hooks
- Wrap restoring windows in an unwind-protect

Patch by Stephen Gildea!

llvm-svn: 181766

llvm-svn: 181765

Before: A<sizeof (*x)> a;
After:  A<sizeof(*x)> a;
llvm-svn: 181764

llvm-svn: 181763

According to libgcc document __clear_cache takes two char*
pointers. I suspect GCC's actual behaviour is more subtle than that,
but char* should clearly be preferred to void*.

llvm-svn: 181762

[-Wconversion-null], introduced in r181326.

llvm-svn: 181761

llvm-svn: 181760

llvm-svn: 181759

was erroneous and got discarded.

llvm-svn: 181758

Most importantly, have DoReadGPR/DoReadFPU/DoReadEXC return -1
to indicate failure if they're called.  Else these could override
the Error setting for the relevant thread state -- if the core file
didn't include a floating point thread state, for instance, these
functions would clear the Error setting for that register set and 
lldb would display random bytes as those registers' contents.
<rdar://problem/13665075> 

llvm-svn: 181757

in one large block - and be sure toget the fpscr value as well when
processing a core file.

llvm-svn: 181756

of arm Mach-O core files.
<rdar://problem/13665075>

llvm-svn: 181755

"static".

llvm-svn: 181754

Mips16/32 floating point interoperability.

When Mips16 code calls external functions that would normally have some
of its parameters or return values passed in floating point registers,
it needs (Mips32) helper functions to do this because while in Mips16 mode
there is no ability to access the floating point registers.

In Pic mode, this is done with a set of predefined functions in libc.
This case is already handled in llvm for Mips16.

In static relocation mode, for efficiency reasons, the compiler generates
stubs that the linker will use if it turns out that the external function
is a Mips32 function. (If it's Mips16, then it does not need the helper
stubs).

These stubs are identically named and the linker knows about these tricks
and will not create multiple copies and will delete them if they are not
needed.

llvm-svn: 181753

llvm-svn: 181752

object is a PseudoSourceValue and PseudoSourceValue::isConstant returns true (i.e.,
points to memory that has a constant value).

llvm-svn: 181751

This matches gcc's behaviour. The patch also explicitly parses the version so
that this keeps working when we add support for v8.

llvm-svn: 181750

Summary:
Split buildFollowOnTable to small functions to improve
code readability and remove code duplication. No change
in functionality.

CC: llvm-commits

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

llvm-svn: 181749

This just brings a crash a little further forward from DWARF emission to
DIE construction to make errors easier to diagnose.

llvm-svn: 181748

PR15956: Debug Info: Include the appropriate file location in types created due to using declarations

We might benefit from API refactoring here (why pass in a value that's
derived from another parameter?) but this is the immediate issue.

llvm-svn: 181747

We used to give up if we saw two integer inductions. After this patch, we base
further induction variables on the chosen one like we do in the reverse
induction and pointer induction case.

Fixes PR15720.

radar://13851975

llvm-svn: 181746

llvm-svn: 181745