| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
| |
allow escaped octal character sequences.
The patch was discussed in Phabricator. See:
http://llvm-reviews.chandlerc.com/D1289
llvm-svn: 190089
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a debug build) with this buggy .indirect_symbol directive usage:
% cat test.s
x: .indirect_symbol _y
The assertion is because it is trying to get the symbol index for the
symbol _y when it is writing out the indirect symbol table. This line of
code in MachObjectWriter::WriteObject() :
Write32(Asm.getSymbolData(*it->Symbol).getIndex());
And while there is a symbol _y it does not have any getSymbolData set which
is only done in MachObjectWriter::BindIndirectSymbols() for pointer sections
or stub sections. I added a check and an error in there to catch this in case
something slips through.
But to get a better error the parser should detect when a .indirect_symbol
directive is used and it is not in a pointer section or stub section. To make
that work I moved the handling of the indirect symbol out of the target
independent AsmParser code into the DarwinAsmParser code that can check
for the proper Mach-O section types.
rdar://14825505
llvm-svn: 189497
|
| |
|
|
|
|
|
| |
first. Use this to turn the PPC modifiers into PPC specific expressions,
allowing them to work on constants.
llvm-svn: 189400
|
| |
|
|
| |
llvm-svn: 188798
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently, when an invalid attribute is encountered on processing a .s file,
clang will abort due to llvm_unreachable. Invalid user input should not cause
an abnormal termination of the compiler. Change the interface to return a
boolean to indicate the failure as a first step towards improving hanlding of
malformed user input to clang.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 188047
|
| |
|
|
| |
llvm-svn: 187702
|
| |
|
|
|
|
|
|
| |
This is dead code since PIC16 was removed in 2010. The result was an odd mix,
where some parts would carefully pass it along and others would assert it was
zero (most of the object streamer for example).
llvm-svn: 185436
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that have been run through the 'C' pre-processor.
The implementation of SrcMgr.FindLineNumber() is slow but OK if
it uses its cache when called multiple times with an SMLoc that is
forward of the previous call.
In the case of generating dwarf for assembly source files that have
been run through the 'C' pre-processor we need to calculate the
logical line number based on the last parsed cpp hash file line
comment. And the current code calls SrcMgr.FindLineNumber()
twice to do this causing its cache not to work and results in very
slow compile times:
% time /Volumes/SandBox/build-llvm/Debug+Asserts/bin/llvm-mc -triple thumbv7-apple-ios -filetype=obj -o /tmp/x.o mscorlib.dll.E -g
672.542u 0.299s 11:13.15 99.9% 0+0k 0+2io 2106pf+0w
So we save the info from the last parsed cpp hash file line comment
to avoid making the second call to SrcMgr.FindLineNumber() most times
and end up with compile times like:
% time /Volumes/SandBox/build-llvm/Debug+Asserts/bin/llvm-mc -triple thumbv7-apple-ios -filetype=obj -o /tmp/x.o mscorlib.dll.E -g
3.404u 0.104s 0:03.80 92.1% 0+0k 0+3io 2105pf+0w
rdar://14156934
llvm-svn: 184592
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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: 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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: 172777
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
// FIXME: Constraints are hard coded to 'm', but we need an 'r'
// constraint for addressof. This needs to be cleaned up!
Test cases are already in place. Specifically,
clang/test/CodeGen/ms-inline-asm.c t15(), t16(), and t24().
llvm-svn: 172569
|