summaryrefslogtreecommitdiffstats
path: root/llvm/test/Bitcode/invalid.test
Commit message (Collapse)AuthorAgeFilesLines
...
* Error out of ParseBitcodeInto(Module*) if we haven't read a ModuleFilipe Cabecinhas2015-04-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | 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
* Add testing for mismatched explicit type on a gep operator when loading from ↵David Blaikie2015-03-161-0/+3
| | | | | | bitcode llvm-svn: 232427
* Add testing for mismatched explicit type on a load instruction when loading ↵David Blaikie2015-03-161-0/+3
| | | | | | from bitcode llvm-svn: 232424
* Test bitcode parsing error-handling for incorrect explicit typeDavid Blaikie2015-03-161-0/+3
| | | | | | | | (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
* Use common parse routine to read alignment values from bitcodeJF Bastien2015-02-221-0/+3
| | | | | | | | | | 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
* [Bitcode reader] Fix a few assertions when reading invalid filesFilipe Cabecinhas2015-02-161-0/+21
| | | | | | | | | | | | | | | | 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
* Check bit widths before trying to get a type.Filipe Cabecinhas2015-01-301-0/+6
| | | | | | | | | Added a test case for it. Also added run lines for the test case in r227566. Bugs found with afl-fuzz llvm-svn: 227589
* [Bitcode] Diagnose errors instead of asserting from bad inputFilipe Cabecinhas2015-01-241-1/+13
| | | | | | | | | | | | | | | Eventually we can make some of these pass the error along to the caller. Reports a fatal error if: We find an invalid abbrev record We try to get an invalid abbrev number We can't fill the current word due to an EOF Fixed an invalid bitcode test to check for output with FileCheck Bugs found with afl-fuzz llvm-svn: 226986
* Use report_fatal_error instead of llvm_unreachable, so we don't crash on ↵Filipe Cabecinhas2015-01-161-0/+1
user input llvm-svn: 226248
OpenPOWER on IntegriCloud