The order in which operands appear in the encoded instruction is different
to order in which they appear in assembly. This changes the XCore backend to
use the instruction encoding order.
llvm-svn: 173493
politely report it instead of running into llvm_unreachable.
Also patch llvm-dwarfdump to actually check whether the file it's attempting to
dump is a valid object file.
llvm-svn: 173489
- set auto-confirm to false when running TestExprs (avoid hang when using API)
- set prompt-on-quit to false in test helper (avoid timeout when using lldb CLI)
llvm-svn: 173485
- This just scratches the surface, We have pretty horrible test coverage in
this area it seems like, but this at least covers the change in r173410.
llvm-svn: 173464
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
This combines two small changes:
1) Put a penalty on breaking after "<"
2) Only produce a hanging indent when parameters are separated by
commas.
Before:
aaaaaaaaaaaaaaaaaaaaaaaa<
aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa>(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
aaaaaa(new Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa));
After:
aaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa>(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
aaaaaa(new Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa));
This changes one ObjC test, but AFAICT this is not according to any
style guide (neither before nor after). We probably should be aligning
on the ":" there according to:
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Method_Invocations#Method_Invocations
llvm-svn: 173457
This warning fires on:
Operator::~Operator() {
llvm_unreachable("should never destroy an Operator");
}
That seems like a false positive. I don't see any good way to silence
the warning here, so I'm disabling it.
llvm-svn: 173455
Only for integers, pointers, and vectors of those. No floats.
Instrumentation seems very heavy, and may need to be replaced
with some approximation in the future.
llvm-svn: 173452
with an initial number of elements, instead of DenseMap, which has
zero initial elements, in order to avoid the copying of elements
when the size changes and to avoid allocating space every time
LegalizeTypes is run. This patch will not affect the memory footprint,
because DenseMap will increase the element size to 64
when the first element is added.
Patch by Wan Xiaofei.
llvm-svn: 173448
Jakub Staszak