| Age | Commit message (Collapse) | Author |
|---|
|
Unfortunately all the nice error messages get lost because we
don't forward errors from lazy value materialization.
Fixes https://github.com/llvm/llvm-project/issues/117707.
|
|
Opaque pointers mode is enabled by default, no need to explicitly
enable it.
|
|
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D145727
|
|
Always read bitcode according to the -opaque-pointers mode. Do not
perform auto-detection to implicitly switch to typed pointers.
This is a step towards removing typed pointer support, and also
eliminates the class of problems where linking may fail if a typed
pointer module is loaded before an opaque pointer module. (The
latest place where this was encountered is D139924, but this has
previously been fixed in other places doing bitcode linking as well.)
Differential Revision: https://reviews.llvm.org/D139940
|
|
We should not be using APIs here that try to fetch the attribute
from both the call attributes and the function attributes. Otherwise
we'll try to upgrade a non-existent sret attribute on the call using
the attribute on the function.
|
|
If the value is forward-declared, then the type must match,
otherwise we can't RAUW.
|
|
Otherwise this is going to crash either the TypeFinder or the
Verifier.
|
|
Differential Revision: https://reviews.llvm.org/D119307
|
|
This was using && instead of ||.
|
|
Checking this early, because we may end up reading up to two
records before the operands.
|
|
We only support chunks <= 32 bits regardless of whether we're
running on a 64-bit platform or not. Chunk size > 32 <= 64 would
cause UB in the reading code.
|
|
|
|
This avoid shift larger than bitwidth UB.
|
|
failing sanitizer buildbots.
Tests added by
https://github.com/llvm/llvm-project/commit/3c86642edd28f1ce970882edaba8dce468ec7401
https://github.com/llvm/llvm-project/commit/f4fca0fbb052e55935b483c8955c440b59511ce8
cause existing code to exhibit UB:
https://github.com/llvm/llvm-project/blob/b4c6d1bb379192cb5b712fda9f60cd105f21194f/llvm/include/llvm/Bitstream/BitstreamReader.h#L244
llvm/include/llvm/Bitstream/BitstreamReader.h:244:51:
runtime error: shift exponent 35 is too large for 32-bit type 'unsigned int'
Hitting the UBSan error before the expected error causes the test to fail under UBSan:
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D119182
|
|
|
|
We should make sure that the value ID is in bounds, otherwise
we will assert / read out of bounds.
|
|
Instead of simply assuming that it will be zero. I double checked
that the bitstream reader doesn't have any special handling for
all-zero blobs, it will always write out the full contents.
|
|
Report an error instead.
|
|
If we're trying to reserve more memory than bits in the stream,
reject this early to avoid OOM.
|
|
Avoid report_fatal_error(), propagate the error upwards instead.
|
|
Use proper error reporting instead of report_fatal_error().
|
|
These checks already exist as asserts when creating the corresponding
instruction. Anybody creating these instructions already need to take
care to not break these checks.
Move the checks for success/failure ordering in cmpxchg from the
verifier to the LLParser and BitcodeReader plus an assert.
Add some tests for cmpxchg ordering. The .bc files are created from the
.ll files with an llvm-as with these checks disabled.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D102803
|
|
`exit`"""
This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes.
Previously, since bots turning on EXPENSIVE_CHECKS are essentially turning on
MachineVerifierPass by default on X86 and the fact that
inline-asm-avx-v-constraint-32bit.ll and inline-asm-avx512vl-v-constraint-32bit.ll
are not expected to generate functioning machine code, this would go
down to `report_fatal_error` in MachineVerifierPass. Here passing
`-verify-machineinstrs=0` to make the intent explicit.
|
|
instead of `exit`""""
This reverts commit bb51d243308dbcc9a8c73180ae7b9e47b98e68fb.
|
|
`exit`"""
This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes.
On bots llvm-clang-x86_64-expensive-checks-ubuntu and
llvm-clang-x86_64-expensive-checks-debian only,
llc returns 0 for these two tests unexpectedly. I tweaked the RUN line a little
bit in the hope that LIT is the culprit since this change is not in the
codepath these tests are testing.
llvm\test\CodeGen\X86\inline-asm-avx-v-constraint-32bit.ll
llvm\test\CodeGen\X86\inline-asm-avx512vl-v-constraint-32bit.ll
|
|
This reverts commit rGcd5b308b828e, rGcd5b308b828e, rG8cedf0e2994c.
There are issues to be investigated for polly bots and bots turning on
EXPENSIVE_CHECKS.
|
|
Summary:
Reland D67847 after D73742 is committed. Replace `sys::Process::Exit(1)`
with `abort` in `report_fatal_error`.
After this patch, for tools turning on `CrashRecoveryContext`,
crash handler installed by `CrashRecoveryContext` is called unless
they installed a non-returning handler using `llvm::install_fatal_error_handler`
like `cc1_main` currently does.
Reviewers: rnk, MaskRay, aganea, hans, espindola, jhenderson
Subscribers: jholewinski, qcolombet, dschuff, jyknight, emaste, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, rupprecht, jocewei, jsji, Jim, dmgreen, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, kerbowa, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D74456
|
|
This reverts commit 647c3f4e47de8a850ffcaa897db68702d8d2459a.
Got bots failure from sanitizer-windows and maybe others.
|
|
Summary:
This patch could be treated as a rebase of D33960. It also fixes PR35547.
A fix for `llvm/test/Other/close-stderr.ll` is proposed in D68164. Seems
the consensus is that the test is passing by chance and I'm not
sure how important it is for us. So it is removed like in D33960 for now.
The rest of the test fixes are just adding `--crash` flag to `not` tool.
** The reason it fixes PR35547 is
`exit` does cleanup including calling class destructor whereas `abort`
does not do any cleanup. In multithreading environment such as ThinLTO or JIT,
threads may share states which mostly are ManagedStatic<>. If faulting thread
tearing down a class when another thread is using it, there are chances of
memory corruption. This is bad 1. It will stop error reporting like pretty
stack printer; 2. The memory corruption is distracting and nondeterministic in
terms of error message, and corruption type (depending one the timing, it
could be double free, heap free after use, etc.).
Reviewers: rnk, chandlerc, zturner, sepavloff, MaskRay, espindola
Reviewed By: rnk, MaskRay
Subscribers: wuzish, jholewinski, qcolombet, dschuff, jyknight, emaste, sdardis, nemanjai, jvesely, nhaehnle, sbc100, arichardson, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, lenary, s.egerton, pzheng, cfe-commits, MaskRay, filcab, davide, MatzeB, mehdi_amini, hiraditya, steven_wu, dexonsmith, rupprecht, seiya, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D67847
|
|
Summary:
This change allows llvm-dis to disassemble multi-module bitcode
files, including the associated module summary.
Reviewers: tejohnson, pcc, mehdi_amini
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70153
|
|
This recommits r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164)
Original message:
Currently invalid bitcode files can cause a crash, when OpNum exceeds
the number of elements in Record, like in the attached bitcode file.
The test case was generated by clusterfuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15698
Reviewers: t.p.northover, thegameg, jfb
Reviewed By: jfb
Differential Revision: https://reviews.llvm.org/D64507
llvm-svn: 365750jkkkk
llvm-svn: 366018
|
|
This reverts r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164)
llvm-dis runs out of memory while opening invalid-fcmp-opnum.bc on
llvm-hexagon-elf, probably because the bitcode file contains other
suspicious values.
http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/21949
llvm-svn: 365757
|
|
Currently invalid bitcode files can cause a crash, when OpNum exceeds
the number of elements in Record, like in the attached bitcode file.
The test case was generated by clusterfuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15698
Reviewers: t.p.northover, thegameg, jfb
Reviewed By: jfb
Differential Revision: https://reviews.llvm.org/D64507
llvm-svn: 365750
|
|
There is existing bitcode that we need to support where the structured nature
of pointer types is used to derive the result type of some operation. For
example a GEP's operation and result will be based on its input Type.
When pointers become opaque, the BitcodeReader will still have access to this
information because it's explicitly told how to construct the more complex
types used, but this information will not be attached to any Value that gets
looked up. This changes BitcodeReader so that in all places which use type
information in this manner, it's derived from a side-table rather than from the
Value in question.
llvm-svn: 364550
|
|
On the armv8 bot the failure is slightly different in the number it prints. Don't check the numbers. This was caused by r364464.
llvm-svn: 364488
|
|
The bitstream reader handles errors poorly. This has two effects:
* Bugs in file handling (especially modules) manifest as an "unexpected end of
file" crash
* Users of clang as a library end up aborting because the code unconditionally
calls `report_fatal_error`
The bitstream reader should be more resilient and return Expected / Error as
soon as an error is encountered, not way late like it does now. This patch
starts doing so and adopting the error handling where I think it makes sense.
There's plenty more to do: this patch propagates errors to be minimally useful,
and follow-ups will propagate them further and improve diagnostics.
https://bugs.llvm.org/show_bug.cgi?id=42311
<rdar://problem/33159405>
Differential Revision: https://reviews.llvm.org/D63518
llvm-svn: 364464
|
|
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
|
