| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Implement getLazyBitcodeModule() and parseBitcodeFile() in terms of it.
Differential Revision: https://reviews.llvm.org/D26719
llvm-svn: 287156
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26430
llvm-svn: 286323
|
|
|
|
|
|
|
|
| |
Should unbreak ocaml binding tests.
Also added an llvm-dis test that checks for the same thing.
llvm-svn: 285777
|
|
|
|
| |
llvm-svn: 271851
|
|
|
|
| |
llvm-svn: 271850
|
|
|
|
| |
llvm-svn: 271849
|
|
|
|
| |
llvm-svn: 271848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation is fairly obvious. This is preparation for using
some blobs in bitcode.
For clarity (and perhaps future-proofing?), I moved the call to
JumpToBit in BitstreamCursor::readRecord ahead of calling
MemoryObject::getPointer, since JumpToBit can theoretically (a) read
bytes, which (b) invalidates the blob pointer.
This isn't strictly necessary the two memory objects we have:
- The return of RawMemoryObject::getPointer is valid until the memory
object is destroyed.
- StreamingMemoryObject::getPointer is valid until the next chunk is
read from the stream. Since the JumpToBit call is only going ahead
to a word boundary, we'll never load another chunk.
However, reordering makes it clear by inspection that the blob returned
by BitstreamCursor::readRecord will be valid.
I added some tests for StreamingMemoryObject::getPointer and
BitstreamCursor::readRecord.
llvm-svn: 264549
|
|
|
|
|
|
|
| |
This reverts commit r264409 since it failed to bootstrap:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/
llvm-svn: 264410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optimize output of MDStrings in bitcode. This emits them in big blocks
(currently 1024) in a pair of records:
- BULK_STRING_SIZES: the sizes of the strings in the block, and
- BULK_STRING_DATA: a single blob, which is the concatenation of all
the strings.
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
I needed to add support for blobs to streaming input to get the test
suite passing.
- StreamingMemoryObject::getPointer reads ahead and returns the
address of the blob.
- To avoid a possible reallocation of StreamingMemoryObject::Bytes,
BitstreamCursor::readRecord needs to move the call to JumpToEnd
forward so that getPointer is the last bitstream operation.
llvm-svn: 264409
|
|
|
|
|
|
| |
Bug found with afl-fuzz.
llvm-svn: 252048
|
|
|
|
|
|
|
|
|
| |
This assert was reachable from user input. A minimized test case (no
FUNCTION_BLOCK_ID record) is attached.
Bug found with afl-fuzz
llvm-svn: 251910
|
|
|
|
|
|
| |
This reverts r251667 since it broke the bots.
llvm-svn: 251671
|
|
|
|
|
|
|
|
|
| |
This assert was reachable from user input. A minimized test case (no
FUNCTION_BLOCK_ID record) is attached.
Bug found with afl-fuzz
llvm-svn: 251667
|
|
|
|
|
|
| |
Bug found with afl-fuzz.
llvm-svn: 249396
|
|
|
|
|
|
| |
Bug found with AFL fuzz.
llvm-svn: 238895
|
|
|
|
|
|
| |
Bug found with AFL fuzz
llvm-svn: 238891
|
|
|
|
|
|
|
|
| |
It's reachable from user input.
Bug found with AFL fuzz.
llvm-svn: 238633
|
|
|
|
|
|
|
|
| |
It can be triggered by user input.
Bug found with AFL fuzz.
llvm-svn: 238272
|
|
|
|
|
|
| |
Bug found with AFL fuzz.
llvm-svn: 238269
|
|
|
|
|
|
| |
Bug found with AFL fuzz.
llvm-svn: 238265
|
|
|
|
|
|
|
|
| |
Shouldn't be an assert, since user input can trigger it.
Bug found with AFL fuzz.
llvm-svn: 238261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also tagged a FIXME comment, and added information about why it breaks.
Bug found using AFL fuzz.
Reviewers: rafael, craig.topper
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9729
llvm-svn: 237709
|
|
|
|
|
|
| |
Bug found with AFL fuzz.
llvm-svn: 237650
|
|
|
|
|
|
| |
Bug found with AFL fuzz.
llvm-svn: 237646
|
|
|
|
|
|
|
|
| |
the aggregate at those indices
Bug found with AFL-fuzz.
llvm-svn: 237628
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added isLoadableOrStorableType to PointerType.
We were doing some checks in some places, occasionally assert()ing instead
of telling the caller. With this patch, I'm putting all type checking in
the same place for load/store type instructions, and verifying the same
thing every time.
I also added a check for load/store of a function type.
Applied extracted check to Load, Store, and Cmpxcg.
I don't have exhaustive tests for all of these, but all Error() calls in
TypeCheckLoadStoreInst are being tested (in invalid.test).
Reviewers: dblaikie, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9785
llvm-svn: 237619
|
|
|
|
|
|
|
|
| |
This would trigger an assertion later.
Bug found with AFL fuzz.
llvm-svn: 237494
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Bug found with AFL fuzz.
Reviewers: rafael, dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9361
llvm-svn: 236200
|
|
|
|
|
|
| |
Bug found with AFL fuzz.
llvm-svn: 236193
|
|
|
|
|
|
|
|
| |
Make it an error instead.
Bug found with AFL fuzz.
llvm-svn: 236190
|
|
|
|
|
|
|
|
| |
Same as r236073 but for PointerType.
Bug found with AFL fuzz.
llvm-svn: 236079
|
|
|
|
|
|
| |
Bug found with AFL fuzz.
llvm-svn: 236076
|
|
|
|
|
|
|
|
| |
{Array,Struct}Type::get(Type)
Bug found with AFL fuzz.
llvm-svn: 236073
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We don't seem to need to assert here, since this function's callers expect
to get a nullptr on error. This way we don't assert on user input.
Bug found with AFL fuzz.
Reviewers: rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9308
llvm-svn: 236027
|
|
|
|
| |
llvm-svn: 235735
|
|
|
|
|
|
|
|
|
|
| |
insert/extract/shuffle
Added some additional checking for vector types + tests.
Bug found with AFL fuzz.
llvm-svn: 235710
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Bug found with AFL fuzz.
Reviewers: rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9016
llvm-svn: 235596
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Make sure the abbrev operands are valid and that we can read/skip them
afterwards.
Bug found with AFL fuzz.
Reviewers: rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9030
llvm-svn: 235595
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Bug found with AFL.
Reviewers: rafael, bkramer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9015
llvm-svn: 235489
|
|
|
|
|
|
|
|
|
|
| |
Use an extra bit in the CCInfo to flag the newer version of the
instructiont hat includes the type explicitly.
Tested the newer error cases I added, but didn't add tests for the finer
granularity improvements to existing error paths.
llvm-svn: 235160
|
|
|
|
|
|
|
| |
This reverts r234984 since it seems to break some bots (most of them
seemed arm*-selfhost).
llvm-svn: 234998
|
|
|
|
|
|
| |
Also added an assert to ReadVBR64.
llvm-svn: 234984
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without this check the following case failed:
Skip a SubBlock which is not a MODULE_BLOCK_ID nor a BLOCKINFO_BLOCK_ID
Got to end of file
TheModule would still be == nullptr, and we would subsequentially fail
when materializing the Module (assert at the start of
BitcodeReader::MaterializeModule).
Bug found with AFL.
Reviewers: dexonsmith, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9014
llvm-svn: 234887
|
|
|
|
|
|
| |
bitcode
llvm-svn: 232427
|
|
|
|
|
|
| |
from bitcode
llvm-svn: 232424
|
|
|
|
|
|
|
|
| |
(turns out I had regressed this when sinking handling of this type down
into GetElementPtrInst::Create - since that asserted before the error
handling was performed)
llvm-svn: 232420
|
|
|
|
|
|
|
|
|
|
| |
While fuzzing LLVM bitcode files, I discovered that (1) the bitcode reader doesn't check that alignments are no larger than 2**29; (2) downstream code doesn't check the range; and (3) for values out of range, corresponding large memory requests (based on alignment size) will fail. This code fixes the bitcode reader to check for valid alignments, fixing this problem.
This CL fixes alignment value on global variables, functions, and instructions: alloca, load, load atomic, store, store atomic.
Patch by Karl Schimpf (kschimpf@google.com).
llvm-svn: 230180
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When creating {insert,extract}value instructions from a BitcodeReader, we
weren't verifying the fields were valid.
Bugs found with afl-fuzz
Reviewers: rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7325
llvm-svn: 229345
|
|
|
|
|
|
|
|
|
| |
Added a test case for it.
Also added run lines for the test case in r227566.
Bugs found with afl-fuzz
llvm-svn: 227589
|