Patch warning that causes oa-selftest to fail #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For the LLVM 14 release, don't ship incomplete features (currently ranges and format) by default. If some vendors want to ship those features, they can override the CMake option manually. This is consistent with what we did for LLVM 13. Note that this patch is only aimed towards the release/14.x branch. Differential Revision: https://reviews.llvm.org/D118901
…omplete type. var-const points out that `ranges::begin` is (non-normatively but explicitly) always supposed to return a `std::input_or_output_iterator`, and `Incomplete*` is not a `std::input_or_output_iterator` because it has no `operator++`. Therefore, we should never return `Incomplete*` from `ranges::begin(x)`, even when `x` is `Incomplete(&)[]`. Instead, just SFINAE away. Differential Revision: https://reviews.llvm.org/D118963 (cherry picked from commit cc1d02b)
Fix build for Linux musl. Reviewed By: #sanitizers, dvyukov Differential Revision: https://reviews.llvm.org/D118970 (cherry picked from commit 9d1857f)
-fprofile-use=/-fprofile-sample-use= compiles may produce REL-format .rel.llvm.call-graph-profile even if the prevailing format is RELA on AArch64. Add R_AARCH64_NONE to getImplicitAddend to fix this linker error: ``` ld.lld: error: internal linker error: cannot read addend for relocation R_AARCH64_NONE PLEASE submit a bug report to https://crbug.com and run tools/clang/scripts/process_crashreports.py (only works inside Google) which will upload a report and include the crash backtrace. ``` (cherry picked from commit f457863)
(cherry picked from commit c161b30)
… after D112753 (cherry picked from commit 3dd2d4c)
…on after D112759 (cherry picked from commit 42f9ca5)
musl does not set errno in math functions: https://wiki.musl-libc.org/mathematical-library.html, https://git.musl-libc.org/cgit/musl/tree/include/math.h?id=cfdfd5ea3ce14c6abf7fb22a531f3d99518b5a1b#n26. Reviewed By: srhines, MaskRay Differential Revision: https://reviews.llvm.org/D116753 (cherry picked from commit 38449c9)
The diagnostic is concise. It is ok because the case is rare. (cherry picked from commit bad1b7f)
…on for Microsoft CXX ABI was added. This mentions the change in the release notes. Differential revision: https://reviews.llvm.org/D117500
This issue is an oversight in D108621. Literals in HIP are emitted as global constant variables with default address space which maps to Generic address space for HIPSPV. In SPIR-V such variables translate to OpVariable instructions with Generic storage class which are not legal. Fix by mapping literals to CrossWorkGroup address space. The literals are not mapped to UniformConstant because the “flat” pointers in HIP may reference them and “flat” pointers are modeled as Generic pointers in SPIR-V. In SPIR-V/OpenCL UniformConstant pointers may not be casted to Generic. Patch by: Henry Linjamäki Reviewed by: Yaxun Liu Differential Revision: https://reviews.llvm.org/D118876
lld/ELF/OutputSections.cpp includes llvm/Config/config.h for LLVM_ENABLE_ZLIB definition, but llvm/Config/config.h doesn't exist in standalone build. To fix this, this patch moves LLVM_ENABLE_ZLIB from config.h to llvm-config.h and updates OutputSections.cpp to include llvm-config.h instead of config.h Reviewed By: MaskRay, mgorny Differential Revision: https://reviews.llvm.org/D119058 (cherry picked from commit e8bff9a)
Add SPARC to the list of platforms for which we provide a full unwind implementation which leads to _Unwind_Backtrace being defined within libunwind.so. Likewise for PPC (see D118320 for background). Reviewed By: #libunwind, MaskRay, Arfrever Differential Revision: https://reviews.llvm.org/D119068 (cherry picked from commit 0220110)
Similar to D116843 for Gnu.cpp Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119071 (cherry picked from commit 1831cbd)
Adds libunwind support for SPARCv9 (aka sparc64). This is a rebase of @kettenis' patch D32450, which I created (with his permission) because the original review has become inactive. The changes are of a cosmetic nature to make it fit better with the new code style, and to reuse the existing SPARCv8 code, whenever possible. Please let me know if I posted this on the wrong place. Also, the summary of the original review is reproduced below: > This adds unwinder support for 64-bit SPARC (aka SPARCv9). The implementation was done on OpenBSD/sparc64, so it takes StackGhost into account: > > https://www.usenix.org/legacy/publications/library/proceedings/sec01/full_papers/frantzen/frantzen_html/index.html > > Since StackGhost xor's return addresses with a random cookie before storing them on the stack, the unwinder has to do some extra work to recover those. This is done by introducing a new kRegisterInCFADecrypt "location" type that is used to implement the DW_CFA_GNU_window_save opcode. That implementation is SPARC-specific, but should work for 32-bit SPARC as well. DW_CFA_GNU_window_save is only ever generated on SPARC as far as I know. Co-authored-by: Mark Kettenis Reviewed By: #libunwind, thesamesam, MaskRay, Arfrever Differential Revision: https://reviews.llvm.org/D116857 (cherry picked from commit 2b9554b)
llvm#53567 The following source ``` namespace A { template <int N> struct Foo<char[N]> { void foo() { std::cout << "Bar"; } }; // namespace A ``` is incorrectly formatted as: ``` namespace A { template <int N> struct Foo<char[N]>{void foo(){std::cout << "Bar"; } } ; // namespace A ``` This looks to be caused by llvm@5c2e7c9 Reviewed By: curdeius Differential Revision: https://reviews.llvm.org/D118911 (cherry picked from commit 23fc20e)
Was reverted in 1c1b670 as it broke all non-x86 bots. Original commit message: [DebugInfo][InstrRef] Add a max-stack-slots-to-track cut-out In certain circumstances with things like autogenerated code and asan, you can end up with thousands of Values live at the same time, causing a large working set and a lot of information spilled to the stack. Unfortunately InstrRefBasedLDV doesn't cope well with this and consumes a lot of memory when there are many many stack slots. See the reproducer in D116821. It seems very unlikely that a developer would be able to reason about hundreds of live named local variables at the same time, so a huge working set and many stack slots is an indicator that we're likely analysing autogenerated or instrumented code. In those cases: gracefully degrade by setting an upper bound on the amount of stack slots to track. This limits peak memory consumption, at the cost of dropping some variable locations, but in a rare scenario where it's unlikely someone is actually going to use them. In terms of the patch, this adds a cl::opt for max number of stack slots to track, and has the stack-slot-numbering code optionally return None. That then filters through a number of code paths, which can then chose to not track a spill / restore if it touches an untracked spill slot. The added test checks that we drop variable locations that are on the stack, if we set the limit to zero. Differential Revision: https://reviews.llvm.org/D118601 (cherry picked from commit 14aaaa1)
Install a cache of DBG_INSTR_REF -> ValueIDNum resolutions, for scenarios where the value has to be reconstructed from several DBG_PHIs. Whenever this happens, it's because branch folding + tail duplication has messed with the SSA form of the program, and we have to solve a mini SSA problem to find the variable value. This is always called twice, so it makes sense to cache the value. This gives a ~0.5% geomean compile-time-performance improvement on CTMark. Differential Revision: https://reviews.llvm.org/D118455 (cherry picked from commit d556eb7)
This patch releases some memory from InstrRefBasedLDV earlier that it would otherwise. The underlying problem is: * We store a big table of "live in values for each block", * We translate that into DBG_VALUE instructions in each block, And both exist in memory at the same time, which needlessly doubles that information. The most of what this patch does is: as we progressively translate live-in information into DBG_VALUEs, we free the variable-value / machine-value tracking information as we go, which significantly reduces peak memory. While I'm here, also add a clear method to wipe variable assignments that have been accumulated into VLocTracker objects, and turn a DenseMap into a SmallDenseMap to avoid an initial allocation. Differential Revision: https://reviews.llvm.org/D118453 (cherry picked from commit a80181a)
…locs This patch aims to reduce max-rss from instruction referencing, by avoiding keeping variable value information in memory for too long. Instead of computing all the variable values then emitting them to DBG_VALUE instructions, this patch tries to stream the information out through a depth first search: * Make use of the fact LexicalScopes gives a depth-number to each lexical scope, * Produce a map that identifies the last lexical scope to make use of a block, * Enumerate each scope in LexicalScopes' DFS order, solving the variable value problem, * After each scope is processed, look for any blocks that won't be used by any other scope, and emit all the variable information to DBG_VALUE instructions. Differential Revision: https://reviews.llvm.org/D118460 (cherry picked from commit 9fd9d56)
Gaps in the basic block number range (from blocks being deleted or folded) get block-value-tables allocated but never ejected, leading to a memory leak, currently tripping up the asan buildbots. Fix this up by manually freeing that memory. As suggested elsewhere, if these things were owned by a unique_ptr then cleanup would happen automagically. D118774 should eliminate the need for this dance. (cherry picked from commit 206cafb)
This is a follow-up to D117877: variable assignments of DBG_VALUE $noreg, or DBG_INSTR_REFs where no value can be found, are represented by a DbgValue object with Kind "Undef", explicitly meaning "there is no value". In D117877 I added a special-case to some assignment accounting faster, without considering this scenario. It causes variables to be given the value ValueIDNum::EmptyValue, which then ends up being a DenseMap key. The DenseMap asserts, because EmptyValue is the tombstone key. Fix this by handling the assign-undef scenario in the special case, to match what happens in the general case: the variable has no value if it's only ever assigned $noreg / undef. Differential Revision: https://reviews.llvm.org/D118715 (cherry picked from commit 43de305)
Clang-format LLVM style has a custom include category for gtest/ and gmock/ headers between regular includes and angled includes. Do the same here. Fixes llvm#53525. Differential Revision: https://reviews.llvm.org/D118913 (cherry picked from commit 0447ec2)
Similar to 60cc1d3 for NetBSD, add aliases and interceptors for the following pthread related functions: - pthread_cond_init(3) - pthread_cond_destroy(3) - pthread_cond_signal(3) - pthread_cond_broadcast(3) - pthread_cond_wait(3) - pthread_mutex_init(3) - pthread_mutex_destroy(3) - pthread_mutex_lock(3) - pthread_mutex_trylock(3) - pthread_mutex_unlock(3) - pthread_rwlock_init(3) - pthread_rwlock_destroy(3) - pthread_rwlock_rdlock(3) - pthread_rwlock_tryrdlock(3) - pthread_rwlock_wrlock(3) - pthread_rwlock_trywrlock(3) - pthread_rwlock_unlock(3) - pthread_once(3) - pthread_sigmask(3) In FreeBSD's libc, a number of internal aliases of the pthread functions are invoked, typically with an additional prefixed underscore, e.g. _pthread_cond_init() and so on. ThreadSanitizer needs to intercept these aliases too, otherwise some false positive reports about data races might be produced. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D119034 (cherry picked from commit 28fb22c)
- If not using `llvm-config`, `LLVM_MAIN_SRC_DIR` now has a sane default - `LLVM_CONFIG_PATH` will continue to work for LLD for back compat. - More quoting of paths in an abundance of caution. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D118792 (cherry picked from commit e0eeae9)
When the main loop is e.g. VF=vscale x 1 and the epilogue VF cannot be any smaller, the vectorizer should try to estimate how many lanes are executed at runtime and allow a suitable fixed-width VF to be chosen. It can use VScaleForTuning to figure out what a suitable fixed-width VF could be. For the case where the main loop VF is VF=vscale x 1, and VScaleForTuning=8, it could still choose an epilogue VF upto VF=4. This was a bit tricky to test, so this patch also introduces a wrapper function to get 'VScaleForTuning' by also considering vscale_range. If min and max are equal, then that will be the vscale we compile for. It makes little sense to tune for a different width if the code will not be portable for other widths. Reviewed By: david-arm Differential Revision: https://reviews.llvm.org/D118709 (cherry picked from commit eaee477)
Based on original tests from D119839. See llvm#53853
…nge comparison and branch until after at least the IPSCCP That transformation is lossy, as discussed in llvm#53853 and rust-lang/rust#85133 (comment) This is an alternative to D119839, which would add a limited IPSCCP into SimplifyCFG. Unlike lowering switch to lookup, we still want this transformation to happen relatively early, but after giving a chance for the things like CVP to do their thing. It seems like deferring it just until the IPSCCP is enough for the tests at hand, but perhaps we need to be more aggressive and disable it until CVP. Fixes llvm#53853 Refs. rust-lang/rust#85133 Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D119854
Fix checking for an unsupported stdlib++. Differential Revision: https://reviews.llvm.org/D121209 (cherry picked from commit 5b7941a)
…ses" This reverts commit c8bb177 to fix llvm#54154 on the release branch. Differential Revision: https://reviews.llvm.org/D121258
Differential Revision: https://reviews.llvm.org/D99134 (cherry picked from commit 0bff3a9)
We were using: armv8-linux-gnueabihf But for a native clang build the default target is: armv8l-linux-gnueabihf (ditto for v7) Add the "l" to the target triples and update the one test that is unsupported to look for the various possible names. armv(7 or 8)(m or l, optionally) The UNSUPPORTED does not include aarch64 because aarch64 Linux (and others that follow Arm's AAPCS64) use quad precision for long double where arm64 (darwin) does not: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#811arithmetic-types Reviewed By: rovka Differential Revision: https://reviews.llvm.org/D119948
When building libcxxabi via LLVM_ENABLE_RUNTIMES=libcxxabi the CMake invocation fails because of missing "unwind" target. However, if the extraneous dependency is removed, the library builds just fine against installed libunwind and tests work fine. To fix this, add the dependency only if the target actually exists. Differential Revision: https://reviews.llvm.org/D119538 (cherry picked from commit 5244ef0)
Prior to this change, we would make check-all depend on check-runtimes which is a target that runs tests in the runtimes build. This means that the runtimes tests are going to run prior to other test suites in check-all, and if one of them fails, we won't run the other test suites at all. To address this issue, we instead collect the list of test suites and their dependencies from the runtimes subbuild, and include them in check-all, so a failure of runtimes test suite doesn't prevent other test suites from being executed. This addresses llvm#54154. Differential Revision: https://reviews.llvm.org/D121276 (cherry picked from commit f39a971)
…in packed structs" This reverts commit 2771233. There are still some issues with this change to be worked out, so revert this patch to avoid having to change ABIs from LLVM 13->14 and then again from LLVM 14->15. See discussion in https://reviews.llvm.org/D118511
…lding LLVM releases""" This reverts commit a9415df. There are still bugs reported with the new bootstraping build. See https://reviews.llvm.org/D121276#3375464
This reverts commit e54a7bf. There was a bug reported with this patch, see: https://reviews.llvm.org/D121276#3375464
(cherry picked from commit 7403c02)
…s> are disabled Back in 3a208c6, we implemented the range-based constructor for <span>. However, in doing so, we removed a previous non-standard constructor that we provided before shipping <ranges>. Unfortunately, that breaks code that was relying on a range-based constructor until we ship all of <ranges>. This patch reintroduces the old non-conforming constructors and tests that were removed in 3a208c6 and uses them whenever <ranges> is not provided (e.g. in LLVM 14). This is only a temporary workaround until we enable <ranges> by default in C++20, which should hopefully happen by LLVM 15. The goal is to cherry-pick this workaround back to the LLVM 14 release branch, since I suspect the constructor removal may otherwise cause breakage out there, like the breakage I saw internally. We could have avoided this situation by waiting for C++20 to be finalized before shipping std::span. For example, we could have guarded it with something like _LIBCPP_HAS_NO_INCOMPLETE_RANGES to prevent users from accidentally starting to depend on it before it is stable. We did not have these mechanisms when std::span was first implemented, though. NOTE: This is a pretty modified version of d4c39f1 since that one didn't apply properly onto the release/14.x branch. (cherry picked from commit d4c39f1) Differential Revision: https://reviews.llvm.org/D121739
See https://reviews.llvm.org/D121626 for details -- this re-enables the CTAD we removed, since it does break some stuff as well (even though it's not nearly as bad as the removed constructors fixed by D121626). (cherry picked from commit 6a7f055) Differential Revision: https://reviews.llvm.org/D122201
Merge the llvm, clang, and libclc tests into a single job. This is the most sub-projects we can test at once without running out of disk space on the GitHub runners. Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D120872
This will be used starting from LLVM 11 to avoid the usual annoying conflicts with system/other LLVM, that seem to be hard to avoid with the broken libtool (see Issue llvm#91). We better use this until all patches are upstreamed to avoid troubles.
…f available in the loaded plugins
This fixes a warning that causes oa-selftest to fail. ``` - /home/sec/local/include/llvm/ADT/PointerSumType.h:275:21: warning: expected ‘template’ keyword before dependent template name [-Wmissing-template-keyword] - 275 | return SumType::create<SomeTag>(SomePointerInfo::getEmptyKey()); - | ^~~~~~ - /home/sec/local/include/llvm/ADT/PointerSumType.h: In static member function ‘static llvm::DenseMapInfo<llvm::PointerSumType<TagT, MemberTs ...> >::SumType llvm::DenseMapInfo<llvm::PointerSumType<TagT, MemberTs ...> >::getTombstoneKey()’: - /home/sec/local/include/llvm/ADT/PointerSumType.h:279:21: warning: expected ‘template’ keyword before dependent template name [-Wmissing-template-keyword] - 279 | return SumType::create<SomeTag>(SomePointerInfo::getTombstoneKey()); ```
|
Ugh, I'm not sure why it wants to merge 10k commits. I'll reissue the PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This warning breaks the test: