| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 162055
|
|
|
|
|
|
| |
tokens we don't know how to handle; this should aid when debugging.
llvm-svn: 162053
|
|
|
|
|
|
| |
simple asm.
llvm-svn: 162051
|
|
|
|
|
|
|
|
| |
These require special handling, which we don't currently handle. This is being
put in place to ensure we don't do invalid symbol table lookups or try to parse
invalid assembly. The test cases just makes sure the latter isn't happening.
llvm-svn: 162050
|
|
|
|
| |
llvm-svn: 162048
|
|
|
|
|
|
|
| |
this information to determine valid MC operands. This will also be used for
semantic analysis.
llvm-svn: 162043
|
|
|
|
|
|
|
|
| |
variables, function or label references. The former is a potential clobber.
The latter is either an input or an output. Unfortunately, it's difficult to
test this patch at the moment, but the added test case will eventually do so.
llvm-svn: 162026
|
|
|
|
| |
llvm-svn: 162000
|
|
|
|
| |
llvm-svn: 161991
|
|
|
|
|
|
| |
building the AsmString.
llvm-svn: 161988
|
|
|
|
|
|
|
|
|
|
|
|
| |
statement. For example,
if (x)
__asm out dx, ax __asm out dx, ax
results in a single inline asm statement (i.e., both "out dx, ax" statements are
predicated on if(x)).
llvm-svn: 161986
|
|
|
|
|
|
| |
anyways. Also, simplify some conditional logic.
llvm-svn: 161977
|
|
|
|
| |
llvm-svn: 161966
|
|
|
|
|
|
| |
printer. Patch by Enea Zaffanella <zaffanella@cs.unipr.it>.
llvm-svn: 161958
|
|
|
|
|
|
| |
llvm::AsmToken.
llvm-svn: 161927
|
|
|
|
| |
llvm-svn: 161913
|
|
|
|
| |
llvm-svn: 161904
|
|
|
|
|
|
| |
Token::isAtStartOfLine() APIs.
llvm-svn: 161898
|
|
|
|
| |
llvm-svn: 161896
|
|
|
|
|
|
| |
track the LineEnds now that single line asm statments aren't merged.
llvm-svn: 161893
|
|
|
|
| |
llvm-svn: 161796
|
|
|
|
| |
llvm-svn: 161793
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AsmParser expects a single asm instruction, but valid ms-style inline asm
statements may contain multiple instructions.
This happens with asm blocks
__asm {
mov ebx, eax
mov ecx, ebx
}
or when multiple asm statements are adjacent to one another
__asm mov ebx, eax
__asm mov ecx, ebx
and
__asm mov ebx, eax __asm mov ecx, ebx
Currently, asm blocks are not properly handled.
llvm-svn: 161780
|
|
|
|
|
|
|
| |
statements. Therefore, we can't pass the PatchedAsmString to the AsmParser
and expect things to work.
llvm-svn: 161701
|
|
|
|
| |
llvm-svn: 161698
|
|
|
|
| |
llvm-svn: 161686
|
|
|
|
| |
llvm-svn: 161676
|
|
|
|
| |
llvm-svn: 161673
|
|
|
|
| |
llvm-svn: 161622
|
|
|
|
| |
llvm-svn: 161619
|
|
|
|
| |
llvm-svn: 161615
|
|
|
|
| |
llvm-svn: 161614
|
|
|
|
| |
llvm-svn: 161595
|
|
|
|
| |
llvm-svn: 161526
|
|
|
|
| |
llvm-svn: 161522
|
|
|
|
| |
llvm-svn: 161521
|
|
|
|
|
|
| |
crashers at the moment (and coincidentally this case was causing a crash).
llvm-svn: 161520
|
|
|
|
|
|
| |
functional change intended.
llvm-svn: 161518
|
|
|
|
|
|
|
|
|
|
|
| |
asm statements are those that don't reference variable names, function names,
and labels.
Add logic to generate a patched AsmString that will eventually be consumed by
the AsmParser. No functional change at this point, so unfortunately no test
case.
llvm-svn: 161508
|
|
|
|
| |
llvm-svn: 161503
|
|
|
|
|
|
| |
the ASTContext BumpPtr. Also use the preferred llvm::ArrayRef interface.
llvm-svn: 161373
|
|
|
|
|
|
| |
change intended. No test case as there's no real way to test at this time.
llvm-svn: 161342
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.
Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.
llvm-svn: 160885
|
|
|
|
|
|
|
| |
Due to performance cost, this is an opt-in option placed
under -Wassign-enum. // rdar://11824807
llvm-svn: 160382
|
|
|
|
|
|
|
| |
Fixes PR13314, clang crashing on blocks refering to an enclosing local
when the enclosing function returns void.
llvm-svn: 160089
|
|
|
|
| |
llvm-svn: 159925
|
|
|
|
|
|
| |
over objective-c container collection. // rdar://9293227
llvm-svn: 159847
|
|
|
|
|
|
|
| |
objective-c's fast enumeration statement,
for more work to come.
llvm-svn: 159689
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) Thus, when a
block's return type is inferred from an enum constant, it is incompatible
with expressions that return the enum type.
In r158899, I told block returns to pretend that enum constants have enum
type, like in C++. Doug Gregor pointed out that this can break existing code.
Now, we don't check the types of return statements until the end of the block.
This lets us go back and add implicit casts in blocks with mixed enum
constants and enum-typed expressions.
<rdar://problem/11662489> (again)
llvm-svn: 159591
|
|
|
|
|
|
|
|
|
|
|
|
| |
In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) This leads to
odd warnings when returning enum constants directly in blocks with inferred
return types. The easiest way out of this is to pretend that, like C++, enum
constants have enum type when being returned from a block.
<rdar://problem/11662489>
llvm-svn: 158899
|