When I tested gcc's behaviour before, I forgot the extern "C", so it
would warn when the types *did* match.
So in the end
* __clear_cache takes two void pointers.
* aarch64 was correct before.
* libgcc's manual is wrong.
* this patch fixes arm.
llvm-svn: 181810
The "lldb" driver was interfering with STDOUT and STDERR if the output was over 1024 charcters long. The output was grabbing 1024 characters at a time, before it output the characters, it was writing characters to the screen to clear the current line. This has been fixed.
I also fixed the command interpreter from mixing the "(lldb) " prompt in with program output by always manually checking for program output. This was done by having the command interpreter know when it is in the middle of executing a command by setting a bool. This was needed since sometimes when a command would run the target, like with a command like 'expression (int)printf("hello\n")', the process would push a new input reader, and then pop it when it was done. This popping of the input reader would cause the command interpreter to get sent a reactivated message (from the private process state thread) and cause it to ask for another command, even though we were still in the middle of the command ('expression (int)printf("hello\n")'). Now we set a bool to true, run the command and set the bool to false. If we get reactivated while we are in the middle of a command, we don't say we are ready for a new command. This coupled with emitting the STDOUT/STDERR first after each command, followed by the command results, followed by then saying we are ready for a new command, should help cleanup the command line output on all platforms.
llvm-svn: 181807
This commit fixes a "FIXME" in the add-override transform. ' override' was
misplaced when a comment was between the function body and the end of the
'prototype'.
It also remove duplicated check for the main file from the last commit (and
fixes the typo in the comment above).
Author: Guillaume Papin <guillaume.papin@epitech.eu>
llvm-svn: 181806
The personality function is user defined and may have an arbitrary result type.
The code assumes always i8*. This results in an assertion failure if a different
type is used. A bitcast to i8* is added to prevent this failure.
Reviewed by: Renato Golin, Bob Wilson
llvm-svn: 181802
ARM FastISel is currently only enabled for iOS non-Thumb1, and I'm working on
enabling it for other targets. As a first step I've fixed some of the tests.
Changes to ARM FastISel tests:
- Different triples don't generate the same relocations (especially
movw/movt versus constant pool loads). Use a regex to allow either.
- Mangling is different. Use a regex to allow either.
- The reserved registers are sometimes different, so registers get
allocated in a different order. Capture the names only where this
occurs.
- Add -verify-machineinstrs to some tests where it works. It doesn't
work everywhere it should yet.
- Add -fast-isel-abort to many tests that didn't have it before.
- Split out the VarArg test from fast-isel-call.ll into its own
test. This simplifies test setup because of --check-prefix.
Patch by JF Bastien
llvm-svn: 181801
The changes to CR spill handling missed a case for 32-bit PowerPC.
The code in PPCFrameLowering::processFunctionBeforeFrameFinalized()
checks whether CR spill has occurred using a flag in the function
info. This flag is only set by storeRegToStackSlot and
loadRegFromStackSlot. spillCalleeSavedRegisters does not call
storeRegToStackSlot, but instead produces MI directly. Thus we don't
see the CR is spilled when assigning frame offsets, and the CR spill
ends up colliding with some other location (generally the FP slot).
This patch sets the flag in spillCalleeSavedRegisters for PPC32 so
that the CR spill is properly detected and gets its own slot in the
stack frame.
llvm-svn: 181800
- add IsVirtualStep() virtual function to ThreadPlan, and implement it for
ThreadPlanStepInRange
- make GetPrivateStopReason query the current thread plan for a virtual stop to
decide if the current stop reason needs to be preserved
- remove extra check for an existing process in GetPrivateStopReason
llvm-svn: 181795
Patch by: Alex Deucher
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
NOTE: This is a candidate for the 3.3 branch.
llvm-svn: 181792
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
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
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
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
Eric Christopher