| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
The assembler parser common code supports recognizing symbol variants
using the @ modifer. On PowerPC, it should also be possible to use
(some of) those modifiers with directional labels, like "1f@l".
This patch adds support for accepting symbol variants on directional
labels as well.
llvm-svn: 184437
|
|
|
|
|
|
|
|
|
| |
Someone may want to do something crazy, like replace these objects if they
change or something.
No functionality change intended.
llvm-svn: 184175
|
|
|
|
| |
llvm-svn: 181848
|
|
|
|
|
|
|
|
|
| |
A = 9
B = 3 * A - 2 * A + 1 as B = 3 * A - (2 * A + 1)
rdar://13816516
llvm-svn: 181366
|
|
|
|
|
|
|
|
| |
constructor enables
Patch by Robert Wilhelm.
llvm-svn: 181138
|
|
|
|
|
|
| |
Part of rdar://13663589
llvm-svn: 180057
|
|
|
|
|
|
|
| |
change indended.
Part of rdar://13663589
llvm-svn: 180028
|
|
|
|
| |
llvm-svn: 179994
|
|
|
|
|
|
| |
functional change.
llvm-svn: 179993
|
|
|
|
| |
llvm-svn: 179991
|
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D598
llvm-svn: 179725
|
|
|
|
|
|
|
| |
in r179325. Test case coming shortly on the clang side.
Part of rdar://13453209
llvm-svn: 179383
|
|
|
|
|
|
|
|
| |
specific logic. This makes the code much less fragile. Test case coming on the
clang side in a moment.
rdar://13634327
llvm-svn: 179323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test cases that regressed due to r179115, plus a few more, were added in
r179182. Original commit message below:
[ms-inline asm] Use parsePrimaryExpr in lieu of parseExpression if we need to
parse an identifier. Otherwise, parseExpression may parse multiple tokens,
which makes it impossible to properly compute an immediate displacement.
An example of such a case is the source operand (i.e., [Symbol + ImmDisp]) in
the below example:
__asm mov eax, [Symbol + ImmDisp]
Part of rdar://13611297
llvm-svn: 179187
|
|
|
|
| |
llvm-svn: 179120
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parse an identifier. Otherwise, parseExpression may parse multiple tokens,
which makes it impossible to properly compute an immediate displacement.
An example of such a case is the source operand (i.e., [Symbol + ImmDisp]) in
the below example:
__asm mov eax, [Symbol + ImmDisp]
The existing test cases exercise this patch.
rdar://13611297
llvm-svn: 179115
|
|
|
|
|
|
|
|
|
|
|
| |
rather than deriving the StringRef from the Start and End SMLocs.
Using the Start and End SMLocs works fine for operands such as [Symbol], but
not for operands such as [Symbol + ImmDisp]. All existing test cases that
reference a variable exercise this patch.
rdar://13602265
llvm-svn: 179109
|
|
|
|
|
|
| |
rdar://13521249
llvm-svn: 179030
|
|
|
|
| |
llvm-svn: 177451
|
|
|
|
|
|
|
| |
logic as a QOI cleanup. No functional change. Tests already in place.
rdar://13456414
llvm-svn: 177446
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added back in by X86AsmPrinter::printIntelMemReference() during codegen.
Previously, this following example
void t() {
int i;
__asm mov eax, [i]
}
would generate the below assembly
mov eax, dword ptr [[eax]]
which resulted in a fatal error when compiling. Test case coming on the
clang side.
rdar://13444264
llvm-svn: 177440
|
|
|
|
|
|
|
| |
logic as a QOI cleanup.
rdar://13445327
llvm-svn: 177413
|
|
|
|
|
|
| |
MCDwarfFilesCUMap
llvm-svn: 176893
|
|
|
|
|
|
|
|
|
|
| |
For integer constants, allow 'L', 'UL' as well as 'ULL' and 'LL'. This provides
better support for shared headers between .s and .c files that define bunches
of constant values.
rdar://9321056
llvm-svn: 176118
|
|
|
|
| |
llvm-svn: 176031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
s/AddDirectiveHandler/addDirectiveHandler/
s/ParseMSInlineAsm/parseMSInlineAsm/
s/ParseIdentifier/parseIdentifier/
s/ParseStringToEndOfStatement/parseStringToEndOfStatement/
s/ParseEscapedString/parseEscapedString/
s/EatToEndOfStatement/eatToEndOfStatement/
s/ParseExpression/parseExpression/
s/ParseParenExpression/parseParenExpression/
s/ParseAbsoluteExpression/parseAbsoluteExpression/
s/CheckForValidSection/checkForValidSection/
http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
No functional change intended.
llvm-svn: 175675
|
|
|
|
|
|
|
|
| |
GNU as rejects them and there are configure scripts in the wild that check if
the assembler rejects ".align 3" to determine whether the alignment is in bytes
or powers of two.
llvm-svn: 175360
|
|
|
|
|
|
| |
so.
llvm-svn: 175327
|
|
|
|
|
|
|
| |
Input/Output rewrite to the same location. Make sure the SizeDirective rewrite
is performed first. This also ensure the sort algorithm is stable.
llvm-svn: 175317
|
|
|
|
|
|
|
| |
While there postpone register name printing after uniquing.
No intended functionality change.
llvm-svn: 175292
|
|
|
|
| |
llvm-svn: 175173
|
|
|
|
| |
llvm-svn: 175082
|
|
|
|
| |
llvm-svn: 175063
|
|
|
|
|
|
| |
rdar://13202662
llvm-svn: 175021
|
|
|
|
|
|
|
|
|
|
| |
.align).
Also, allow _EMIT and __EMIT for the emit directive. We already do the same
for TYPE, SIZE, and LENGTH.
rdar://13200215
llvm-svn: 175008
|
|
|
|
|
|
| |
function is called with a signed char argument, in order to avoid assertions in Windows Debug configuration.
llvm-svn: 175006
|
|
|
|
| |
llvm-svn: 174999
|
|
|
|
| |
llvm-svn: 174998
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is complicated by backward labels (e.g., 0b can be both a backward label
and a binary zero). The current implementation assumes [0-9]b is always a
label and thus it's possible for 0b and 1b to not be interpreted correctly for
ms-style inline assembly. However, this is relatively simple to fix in the
inline assembly (i.e., drop the [bB]).
This patch also limits backward labels to [0-9]b, so that only 0b and 1b are
ambiguous.
Part of rdar://12470373
llvm-svn: 174983
|
|
|
|
| |
llvm-svn: 174927
|
|
|
|
|
|
| |
Part of rdar://12470373
llvm-svn: 174926
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the body does not use them and it appears the body has positional parameters.
This can cause unexpected results as in the added test case. As the darwin
version of gas(1) which only supported positional parameters, happened to
ignore the named parameters. Now that we want to support both styles of
macros we issue a warning in this specific case.
rdar://12861644
llvm-svn: 173199
|
|
|
|
|
|
|
|
|
| |
an expression. Currently this bug causes the line to be ignored in a
release build and an assert in a debug build.
rdar://13062484
llvm-svn: 173195
|
|
|
|
| |
llvm-svn: 172778
|
|
|
|
| |
llvm-svn: 172777
|
|
|
|
| |
llvm-svn: 172776
|
|
|
|
|
|
| |
Part of rdar://12576868
llvm-svn: 172743
|
|
|
|
| |
llvm-svn: 172640
|
|
|
|
|
|
| |
return into the safe harbor of AsmParser's private areas.
llvm-svn: 172637
|
|
|
|
|
|
|
| |
Since we already have this type it's a shame to keep dragging a pair of object
and method around explicitly.
llvm-svn: 172584
|