| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Weakly defined symbols should evaluate to 0 if they're undefined at
link-time. This is impossible to do with the usual address generation
patterns, so we should use a literal pool entry to materlialise the
address.
llvm-svn: 174518
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now correctly format:
// Written as a macro, it is reformatted from:
#define foo(a) \
do { \
/* Initialize num to zero. */ \
int num = 10; \
/* This line ensures a is never zero. */ \
int i = a == 0 ? 1 : a; \
i = num / i; /* This division is OK. */ \
return i; \
} while (false)
llvm-svn: 174517
|
|
|
|
| |
llvm-svn: 174516
|
|
|
|
| |
llvm-svn: 174515
|
|
|
|
|
|
|
|
|
| |
We now leave the semicolon in the line of the closing brace in:
namespace {
...
};
llvm-svn: 174514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes llvm.org/PR15165.
We now correctly align:
[image_rep drawInRect:drawRect
fromRect:NSZeroRect
operation:NSCompositeCopy
fraction:1.0
ssssssssdd:NO
hints:nil];
llvm-svn: 174513
|
|
|
|
|
|
|
| |
This is pretty common in macros:
#define A(X, Y) class X##Y {};
llvm-svn: 174512
|
|
|
|
|
|
| |
interposition, we must intercept both siglongjmp and longjmp on Darwin.
llvm-svn: 174510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes llvm.org/PR15162.
Before:
bool aaaaaaaaaaaaa = // comment
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
bool aaaaaaaaaaaaa = // comment
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 174508
|
|
|
|
|
|
|
|
| |
-mmacosx-version-min=10.5, thus the default inode
size is 32 bits. However the supported client code is going to target 10.6 and higher, where 64-bit inodes will be used.
llvm-svn: 174507
|
|
|
|
| |
llvm-svn: 174506
|
|
|
|
| |
llvm-svn: 174505
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, clang-format can analyze the input file for two
properties:
1. Is "int *a" or "int* a" more common.
2. Are non-C++03 constructs used, e.g. A<A<A>>.
With Google-style, clang-format will now use the more common style for
(1) and format C++03 compatible, unless it finds C++11 constructs in the
input.
llvm-svn: 174504
|
|
|
|
|
|
|
|
|
| |
The -invert-pointer-binding option will be superseeded by my next
cfe-commit. Instead of explicitly overwriting this flag, clang-format
can then be configured to auto-detect certain style-options based on the
input file.
llvm-svn: 174503
|
|
|
|
| |
llvm-svn: 174502
|
|
|
|
|
|
| |
Currently, works only if symbolization happens in-process.
llvm-svn: 174501
|
|
|
|
|
|
| |
Before: void f(int *a = d *e, int b = 0);
After: void f(int *a = d * e, int b = 0);
llvm-svn: 174500
|
|
|
|
|
|
|
|
| |
A very common use case is to search for the first occurrence of
a certain node that is a descendant of another node. In that
case, selectFirst significantly simplifies the code at the client side.
llvm-svn: 174499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Properly handle annotation contexts while calculating extra information
for each token. This enable nested ObjC calls and thus solves (most of)
llvm.org/PR15164. E.g., we can now format:
[contentsContainer replaceSubview:[subviews objectAtIndex:0]
with:contentsNativeView];
Also fix a problem with the formatting of types in casts as this was
trivial now.
llvm-svn: 174498
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently the owners of the tools we want to integrate with (eclipse in
this case) don't have JSON parsers.
The output now is:
<replacements>
<replacement offset='2' length='3'> </replacement>
...
</replacements>
Kicking JSON for now - it's easy enough to get back in when we need it.
FIXME: once we find this useful enough, we might want to add it as
free-standing functions to tooling.
llvm-svn: 174497
|
|
|
|
|
|
|
|
| |
These instructions are a late addition to the architecture, and may
yet end up behind an optional attribute, but for now they're available
at all times.
llvm-svn: 174496
|
|
|
|
|
|
|
| |
This adds hints to the various "prfm" instructions so that they can
affect the instruction cache as well as the data cache.
llvm-svn: 174495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attribute groups are of the form:
#0 = attributes { noinline "no-sse" "cpu"="cortex-a8" alignstack=4 }
Target-dependent attributes are represented as strings. Attributes can have
optional values associated with them. E.g., the "cpu" attribute has the value
"cortex-a8".
Target-independent attributes are listed as enums inside the attribute classes.
Multiple attribute groups can be referenced by the same object. In that case,
the attributes are merged together.
llvm-svn: 174493
|
|
|
|
| |
llvm-svn: 174492
|
|
|
|
| |
llvm-svn: 174491
|
|
|
|
| |
llvm-svn: 174490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. let determineStarAmp() check of unary operators before checking for
"is next '['". That check was added in r173150, and the test from that
revision passes either way.
2. change determineStarAmp() to categorize '*' and '&' after '=' as unary
operator.
3. don't let parseSquare() overwrite the type of a '*' or '&' before the start
of an objc message expression if has the role of unary operator.
llvm-svn: 174489
|
|
|
|
|
|
|
|
|
|
|
| |
Use the validateTargetOperandClass() hook to match literal '#0' operands in
InstAlias definitions. Previously this required per-instruction C++ munging of the
operand list, but not is handled as a natural part of the matcher. Much better.
No additional tests are required, as the pre-existing tests for these instructions
exercise the new behaviour as being functionally equivalent to the old.
llvm-svn: 174488
|
|
|
|
|
|
|
|
|
|
| |
For example, ARM has several instructions with a literal '#0' immediate in the syntax
that's not represented as an actual operand. The asm matcher is expected a token
operand, but the parser will have created an immediate operand. This is currently
handled by dedicated per-instruction C++ munging of the ParsedAsmOperand list, but
will be better handled by this hook.
llvm-svn: 174487
|
|
|
|
|
|
| |
we already checked it when parsing.
llvm-svn: 174486
|
|
|
|
|
|
| |
initialization is one of the reasons I consider -werror to be shoddy.
llvm-svn: 174485
|
|
|
|
|
|
|
| |
to move the stack pointer in prologs/epilogs. I will fix the test and add it
back later.
llvm-svn: 174484
|
|
|
|
| |
llvm-svn: 174483
|
|
|
|
| |
llvm-svn: 174482
|
|
|
|
|
|
|
| |
Fix the 'operator==' and 'hasAttributes' queries to take into account
target-dependent attributes.
llvm-svn: 174481
|
|
|
|
|
|
|
|
| |
This is useful when parsing an object that references multiple attribute groups.
N.B. If both builders have alignments specified, then they should match!
llvm-svn: 174480
|
|
|
|
|
|
|
|
|
| |
Failure: undefined symbol 'Lline_table_start0'.
Root-cause: we use a symbol subtraction to calculate at_stmt_list, but
the line table entries are not dumped in the assembly.
Fix: use zero instead of a symbol subtraction for Compile Unit 0.
llvm-svn: 174479
|
|
|
|
|
|
|
| |
- As of this commit, the test suite should now fully pass on both darwin11 and
darwin12 when testing against either a locally built libc++ or the system libc++.
llvm-svn: 174478
|
|
|
|
|
|
| |
rdar://13153516
llvm-svn: 174477
|
|
|
|
|
|
| |
The first part of the fix for having LLDB handle LTO debugging when the DWARF is in the .o files. This part separates the object file's modules into a separate cache map that maps unique C strings for the N_OSO path to the ModuleSP since one object file might be mentioned more than once in LTO binaries.
llvm-svn: 174476
|
|
|
|
|
|
|
| |
- The trickery can confuse more basic source processors, in particular the
Unix conformance tool that wants to scan headers.
llvm-svn: 174475
|
|
|
|
|
|
| |
"list" alias which has now been turned into a regex command that mimics the GDB equivalent. Changed "list" to "source list" to get around this problem.
llvm-svn: 174474
|
|
|
|
| |
llvm-svn: 174473
|
|
|
|
|
|
|
|
| |
ObjC++ alongside ObjC.
\end paranoia.
llvm-svn: 174471
|
|
|
|
|
|
|
| |
- Otherwise, we never were actually linking against the right library when
building the test applications.
llvm-svn: 174470
|
|
|
|
| |
llvm-svn: 174469
|
|
|
|
|
|
|
|
|
|
|
| |
This is a "quick fix".
The underlining issue is that when a const pointer to a struct is passed
into a function, we do not invalidate the pointer fields. This results
in false positives that are common in C++ (since copy constructors are
prevalent). (Silences two llvm false positives.)
llvm-svn: 174468
|
|
|
|
|
|
| |
AttributeSet.
llvm-svn: 174467
|
|
|
|
| |
llvm-svn: 174466
|
|
|
|
| |
llvm-svn: 174465
|