summaryrefslogtreecommitdiff
path: root/llvm/lib/Bitstream
AgeCommit message (Collapse)Author
2024-11-27[BitstreamReader] Fix 32-bit overflow (#117363)Pranav Kant
This got exposed when processing large LTO-generated files leading to crashes.
2024-05-15[nfc] Allow forwarding `Error` returns from `Expected` callers (#92208)Mircea Trofin
On a few compilers (clang 11/12 for example [1]), the following does not result in a copy elision, and since `Error`'s copy dtor is elided, results in a compile error: ``` Expect<Something> foobar() { ... if (Error E = aCallReturningError()) return E; ... } ``` Moving `E` would, conversely, result in the pessimizing-move warning on more recent clangs ("moving a local object in a return statement prevents copy elision") We just need to make the `Expected` ctor taking an `Error` take it as a r-value reference. [1] https://lab.llvm.org/buildbot/#/builders/54/builds/10505
2022-12-07[Bitcode(Reader|Writer)] Convert Optional to std::optionalKrzysztof Parzyszek
2022-12-02[llvm] Use std::nullopt instead of None (NFC)Kazu Hirata
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-02-16[Bitstream] Remove pessimizing moveJan Svoboda
Commit 4a794d848ce81f41c6e23a4d3d3f70c2d7d1baa4 caused build failure with -Werror -Wpessimizing-move on the clang-ppc64-aix buildbot. This patch applies Clang's suggestion to remove `std::move`.
2022-02-15[Bitstream] Improve error propagation from ReadVBRJan Korous
Differential Revision: https://reviews.llvm.org/D119307
2022-02-07[Bitstream] Check that there is enough space for blobNikita Popov
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.
2022-02-07[Bitstream] Reject implausibly large reservationsNikita Popov
If we're trying to reserve more memory than bits in the stream, reject this early to avoid OOM.
2022-02-07[Bitcode] Handle invalid abbrev number error more gracefullyNikita Popov
Avoid report_fatal_error(), propagate the error upwards instead.
2022-02-04[BitstreamReader] Fix incorrect error forwardingNikita Popov
This code clearly intended to forward the error, but instead returned the non-error result.
2022-02-04[BitstreamReader] Handle errors more gracefullyNikita Popov
Use proper error reporting instead of report_fatal_error().
2021-01-06[llvm] Use llvm::append_range (NFC)Kazu Hirata
2020-11-13llvmbuildectomy - replace llvm-build by plain cmakeserge-sans-paille
No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-09-01[Bitstream] Use alignTo to make code more readable. NFCCraig Topper
I was recently debugging a similar issue to https://reviews.llvm.org/D86500 only with a large metadata section. Only after I finished debugging it did I discover it was fixed very recently. My version of the fix was going to alignTo since that uses uint64_t and improves the readability of the code. So I though I would go ahead and share it. Differential Revision: https://reviews.llvm.org/D86957
2020-08-26Fix a 32-bit overflow issue when reading LTO-generated bitcode files whose ↵Jianzhou Zhao
strtab are of size > 2^29 This happens when using -flto and -Wl,--plugin-opt=emit-llvm to create a linked LTO bitcode file, and the bitcode file has a strtab with size > 2^29. All the issues relate to a pattern like this size_t x64 = y64 + z32 * C When z32 is >= (2^32)/C, z32 * C overflows. Reviewed-by: MaskRay Differential Revision: https://reviews.llvm.org/D86500
2020-05-01[Bitcode] reserve in front of push_back loops. NFCI.Benjamin Kramer
2020-02-10Revert "Remove redundant "std::move"s in return statements"Bill Wendling
The build failed with error: call to deleted constructor of 'llvm::Error' errors. This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
2020-02-10Remove redundant "std::move"s in return statementsBill Wendling
2019-12-25[Bitstream] Delete skipAbbreviatedField which duplicates readAbbreviatedFieldFangrui Song
2019-11-21[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard
Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
2019-07-03[Bitcode] Move Bitstream to a separate libraryFrancis Visoiu Mistrih
This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/. This is needed to avoid a circular dependency when using the bitstream code for parsing optimization remarks. Since Bitcode uses Core for the IR part: libLLVMRemarks -> Bitcode -> Core and Core uses libLLVMRemarks to generate remarks (see IR/RemarkStreamer.cpp): Core -> libLLVMRemarks we need to separate the Bitstream and Bitcode part. For clang-doc, it seems that it doesn't need the whole bitcode layer, so I updated the CMake to only use the bitstream part. Differential Revision: https://reviews.llvm.org/D63899 llvm-svn: 365091