- 26 Nov, 2020 8 commits
-
-
Aaron Puchert authored
Currently the tarballs contain superfluous metadata, like the user name of the packager and via Pax headers even the PID of the tar process that packaged the files. We build the monorepo projects directly from the git repo using "git archive" and for the test-suite we add some flags as recommended by https://reproducible-builds.org/docs/archives/. We don't use numeric owners though to be compatible with "git archive". The advantage of "git archive" is that the releaser doesn't have to download the tar ball and extract it, rather the archive is built directly from the repository. This is probably what GitHub uses internally to produce the tarballs, so I wouldn't expect a difference. Reviewed By: tstellar Differential Revision: https://reviews.llvm.org/D91494 (cherry picked from commit 1a009296)
-
Jorge Gorbe Moya authored
In the current state, if getFromHash(0) is called and there's no CU with dwo_id=0, the lookup will stop at an empty slot, then the check `Rows[H].getSignature() != S` won't cause the lookup to fail and return a nullptr (as it should), because the empty slot has a 0 in the signature field, and a pointer to the empty slot will be incorrectly returned. This patch fixes this by using the index field in the hash entry to check for empty slots: signature = 0 can match a valid hash but according to the spec the index for an occupied slot will always be non-zero. Differential Revision: https://reviews.llvm.org/D91670 (cherry picked from commit 314a0d73)
-
Sylvestre Ledru authored
This reverts commit b2eb4393. Caused the regression: https://bugs.llvm.org/show_bug.cgi?id=47589 Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D89464 (cherry picked from commit b9e78944)
-
Joachim Meyer authored
This is very similar to 7f1e6fcf, just fixing a left-over. With this, it should be possible to use both, -x cuda and -fopenmp in the same invocation, enabling to use both OpenMP, targeting CPU, and CUDA, targeting the GPU. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D90415 (cherry picked from commit eaee6084)
-
Valentin Churavy authored
These appear in some sections, such as DWARF tables, since RuntimeDyldELF explicitly maps to this as a sentinel value: https://github.com/llvm/llvm-project/blob/29d1fba7b5335d969e3e5daa84b7a25cd1fa75ef/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp#L1199 That could then be a source of problems if it tried to examine these sections (for example, with either setProcessAllSections(true) or ORCv2 on i686). Replaces https://reviews.llvm.org/D89241 Reviewed By: lhames, vchuravy Differential Revision: https://reviews.llvm.org/D90722 (cherry picked from commit 85f4be09)
-
Tom Stellard authored
This reverts commit 8ac70957. This commit changes the public API of clang, so it needs to be reworked.
-
Raul Tambre authored
[AArch64][GlobalISel] Handle rtcGPR64RegClassID in AArch64RegisterBankInfo::getRegBankFromRegClass() TargetRegisterInfo::getMinimalPhysRegClass() returns rtcGPR64RegClassID for X16 and X17, as it's the last matching class. This in turn gets passed to AArch64RegisterBankInfo::getRegBankFromRegClass(), which hits an unreachable. It seems sensible to handle this case, so copies from X16 and X17 work. Copying from X17 is used in inline assembly in libunwind for pointer authentication. Differential Revision: https://reviews.llvm.org/D85720 (cherry picked from commit e887d0e8)
-
Raul Tambre authored
It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead. Simply don't mark the file as C and CMake will recognize the rest. This was attempted earlier in https://reviews.llvm.org/D85706, but reverted due to architecture issues on Apple. Subsequent digging revealed a similar change was done earlier for libunwind in https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09. Afterwards workarounds were added for MinGW and Apple: * https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09 * https://reviews.llvm.org/rGd4ded05ba851304b26a437896bc3962ef56f62cb The workarounds in libunwind and compiler-rt are unified and comments added pointing to each other. The workaround is updated to only be used for MinGW for CMake versions before 3.17, which fixed the issue (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4287). Additionally fixed Clang not being passed as the assembly compiler for compiler-rt runtime build. Example error: [525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o /opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '(' .section .text ^ 1 error generated. Differential Revision: https://reviews.llvm.org/D86308 (cherry picked from commit 45344cf7)
-
- 25 Nov, 2020 5 commits
-
-
Bruno Cardoso Lopes authored
They can get stale at use time because of updates from other recursive specializations. Instead, rely on the existence of previous declarations to add the specialization. Differential Revision: https://reviews.llvm.org/D87853 (cherry picked from commit cffb0dd5)
-
serge-sans-paille authored
- Perform the probing in the correct direction. Related to https://github.com/rust-lang/rust/pull/77885#issuecomment-711062924 - The first touch on a dynamic alloca cannot use a mov because it clobbers existing space. Use a xor 0 instead Differential Revision: https://reviews.llvm.org/D90216 (cherry picked from commit 0f60bcc3)
-
serge-sans-paille authored
As reported in https://github.com/rust-lang/rust/issues/70143 alignment is not taken into account when doing the probing. Fix that by adjusting the first probe if the stack align is small, or by extending the dynamic probing if the alignment is large. Differential Revision: https://reviews.llvm.org/D84419 (cherry picked from commit f2c6bfa3)
-
serge-sans-paille authored
When the allocation size is 0, we shouldn't probe. Within [1, PAGE_SIZE], we should probe once etc. This fixes https://bugs.llvm.org/show_bug.cgi?id=47657 Differential Revision: https://reviews.llvm.org/D88548 (cherry picked from commit 9573c9f2)
-
Keno Fischer authored
In D85499, I attempted to fix this same issue by canonicalizing andnp for i1 vectors, but since there was some opposition to such a change, this commit just fixes the bug by using two different forms depending on which kind of vector type is in use. We can then always decide to switch the canonical forms later. Description of the original bug: We have a DAG combine that tries to fold (vselect cond, 0000..., X) -> (andnp cond, x). However, it does so by attempting to create an i64 vector with the number of elements obtained by truncating division by 64 from the bitwidth. This is bad for mask vectors like v8i1, since that division is just zero. Besides, we don't want i64 vectors anyway. For i1 vectors, switch the pattern to (andnp (not cond), x), which is the canonical form for `kandn` on mask registers. Fixes https://github.com/JuliaLang/julia/issues/36955. Differential Revision: https://reviews.llvm.org/D85553 (cherry picked from commit c58674df)
-
- 21 Nov, 2020 3 commits
-
-
Andrea Di Biagio authored
This is likely to be a regressigion introduced by my last refactoring of the LSUnit (commit 5578ec32). Before this patch, the "CurrentStoreBarrierGroupID" index was not correctly reset on store barrier executions. This was leading to unexpected crashes like the one reported as PR48024. (cherry picked from commit 0e20666d)
-
Artem Belevich authored
If CUDA version can not be determined based on version.txt file, attempt to find CUDA_VERSION macro in cuda.h. This is a follow-up to D89752, Differntial Revision: https://reviews.llvm.org/D89832 (cherry picked from commit e7fe125b)
-
Artem Belevich authored
CUDA-11.1 does not carry version.txt which causes clang to assume that it's CUDA-7.0, which used to be the only CUDA version w/o version.txt. In order to tell CUDA-7.0 apart from the new versions, clang now probes for the presence of libdevice.10.bc which is not present in the old CUDA versions. This should keep Clang working for CUDA-11.1. PR47332: https://bugs.llvm.org/show_bug.cgi?id=47332 Differential Revision: https://reviews.llvm.org/D89752 (cherry picked from commit 65d20648)
-
- 12 Nov, 2020 3 commits
-
-
Aaron Ballman authored
This also adds some bare-bones documentation for the attribute rather than leaving it undocumented. (cherry picked from commit af1d3e65)
-
Adam Balogh authored
The `Root` member of `ImmutableMapRef` was changed recently from a plain pointer to `IntrusiveRefCntPtr`. However, the `Profile` member function was not adjusted. This results in comilation error whenever the `Profile` method is used on an `ImmutableMapRef`. This patch fixes this issue and also adds unit tests for `ImmutableMapRef`. Differential Revision: https://reviews.llvm.org/D89486 (cherry picked from commit 184eb4fa)
-
Kristina Bessonova authored
Seems '${cmake_2_8_12_PRIVATE}' was removed a long time ago, so it should be just PRIVATE keyword here. Reviewed By: john.brawn Differential Revision: https://reviews.llvm.org/D86091 (cherry picked from commit 04ea680a)
-
- 03 Nov, 2020 4 commits
-
-
Arthur Eubanks authored
While looping through all args or all return values, we may mark a use of a later iteration as live. Previously when we got to that later value it would ignore that and continue adding to Uses instead of marking it live. For example, when looping through arg#0 and arg#1, MarkValue(arg#0, Live) may cause some use of arg#1 to be live, but MarkValue(arg#1, MaybeLive) will not notice that and continue adding into Uses. Now MarkValue(RA, MaybeLive) will MarkLive(RA) if any use is live. Fixes PR47444. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D88529 (cherry picked from commit 7468afe9)
-
Geoff Levner authored
Patch VisitCXXDeleteExpr() in clang::UsedDeclVisitor to avoid it crashing when the expression's destroyed type is null. According to the comments in CXXDeleteExpr::getDestroyedType(), this can happen when the type to delete is a dependent type. Patch by Geoff Levner. Differential Revision: https://reviews.llvm.org/D88949 (cherry picked from commit b9225543)
-
Hubert Tong authored
Fix premature decision in the presence of type-dependent expression operands on whether AltiVec vector initializations from single expressions are "splat" operations. Verify that the instantiation is able to determine the correct cast semantics for both the scalar type and the vector type case. Note that, because the change only affects the single-expression case (and the target type is an AltiVec-style vector type), the replacement of a parenthesized list with a parenthesized expression does not change the semantics of the program in a program-observable manner. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D88526 (cherry picked from commit 35ecc7fe)
-
Simon Pilgrim authored
As discussed on PR26418 rGea84dc95 incorrectly set the knl cpuname to tremont (and missed out the tremont cpuname entirely). (cherry picked from commit 0d17dc2e)
-
- 31 Oct, 2020 4 commits
-
-
Aaron Puchert authored
Fixes PR47917. Reviewed By: tstellar Differential Revision: https://reviews.llvm.org/D90100 (cherry picked from commit 139785dc)
-
Fangrui Song authored
Fixes https://github.com/ClangBuiltLinux/linux/issues/1186 If a non-SHF_LINK_ORDER orphan is added first, `firstIsec->flags & SHF_LINK_ORDER` will be zero and we currently assert when calling `getLinkOrderDep`. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D90200 (cherry picked from commit ae73091f)
-
Yonghong Song authored
Currently, bpf backend Instruction section DAG2DAG phase has an optimization to replace loading constant struct memeber or array element with direct values. The reason is that these locally defined struct or array variables may have their initial values stored in a readonly section and early bpf ecosystem is not able to handle such cases. Bpf ecosystem now can not only handle readonly sections, but also global variables. global variable can also have initialized data and global variable may or may not be constant, i.e., global variable data can be put in .data section or .rodata section. This exposed a bug in DAG2DAG Load optimization as it did not check whether the global variable is constant or not. This patch fixed the bug by checking whether global variable, representing the initial data, is constant or not and will not do optimization if it is not a constant. Another bug is also fixed in this patch to check whether the load is simple (not volatile/atomic) or not. If it is not simple, we will not do optimization. To summary for globals: - struct t var = { ... } ; // no load optimization - const struct t var = { ... }; // load optimization is possible - volatile const struct t var = { ... }; // no load optimization Differential Revision: https://reviews.llvm.org/D89021 (cherry picked from commit 31611721) -
Eli Friedman authored
In particular, we shouldn't make assumptions about globals which are unnamed_addr: we can fold them together with other globals. Also while I'm here, use isInterposable() instead of trying to explicitly name all the different kinds of weak linkage. Fixes https://bugs.llvm.org/show_bug.cgi?id=47090 Differential Revision: https://reviews.llvm.org/D87123 (cherry picked from commit d751f861)
-
- 26 Oct, 2020 1 commit
-
-
Tom Stellard authored
-
- 23 Oct, 2020 1 commit
-
-
Tom Stellard authored
-
- 07 Oct, 2020 2 commits
-
-
Bill Wendling authored
Tail duplication of a block with an INLINEASM_BR may result in a PHI node on the indirect branch. This is okay, but it also introduces a copy for that PHI node *after* the INLINEASM_BR, which is not okay. See: https://github.com/ClangBuiltLinux/linux/issues/1125 Differential Revision: https://reviews.llvm.org/D88823 (cherry picked from commit d2c61d2b)
-
Shivanshu Goyal authored
A lot of our code building with clang-cl.exe using Clang 11 was failing with the following 2 type of errors: 1. explicit specialization of 'foo' after instantiation 2. no matching function for call to 'bar' Note that we also use -fdelayed-template-parsing in our builds. I tried pretty hard to get a small repro for these failures, but couldn't. So there is some subtle edge case in the -fpch-instantiate-templates feature introduced by this change: https://reviews.llvm.org/D69585 When I tried turning this off using -fno-pch-instantiate-templates, builds would silently fail with the same error without any indication that -fno-pch-instantiate-templates was being ignored by the compiler. Then I realized this "no" option wasn't actually working when I ran Clang under a debugger. Differential revision: https://reviews.llvm.org/D88680 (cherry picked from commit 66e4f071)
-
- 06 Oct, 2020 1 commit
-
-
Qiu Chaofan authored
This reverts partial of a2fb5446 (actually, 2508ef01) about removing negated FP constant immediately if it has no uses. However, as discussed in bug 47517, there're cases when NegX is folded into constant from other places while NegY is removed by that line of code and NegX is equal to NegY. In these cases, NegX is deleted before used and crash happens. So revert the code and add necessary test case. (cherry picked from commit b326d4ff)
-
- 05 Oct, 2020 1 commit
-
-
Hans Wennborg authored
As suggested by Yvan.
-
- 01 Oct, 2020 2 commits
-
-
Ahsan Saghir authored
-
Hans Wennborg authored
By Lang Hames!
-
- 30 Sep, 2020 2 commits
-
-
Sanjay Patel authored
We shift the significand right on a truncation, but that needs to be made NaN-safe: always set at least 1 bit in the significand. https://llvm.org/PR43907 See D88238 for the likely follow-up (but needs some plumbing fixes before it can proceed). Differential Revision: https://reviews.llvm.org/D87835 (cherry picked from commit e34bd1e0)
-
Amara Emerson authored
During lowering of G_UMULO and friends, the previous code moved the builder's insertion point to be after the legalizing instruction. When that happened, if there happened to be a "G_CONSTANT i32 0" immediately after, the CSEMIRBuilder would try to find that constant during the buildConstant(zero) call, and since it dominates itself would return the iterator unchanged, even though the def of the constant was *after* the current insertion point. This resulted in the compare being generated *before* the constant which it was using. There's no need to modify the insertion point before building the mul-hi or constant. Delaying moving the insert point ensures those are built/CSEd before the G_ICMP is built. Fixes PR47679 Differential Revision: https://reviews.llvm.org/D88514 (cherry picked from commit 1d54e75c)
-
- 29 Sep, 2020 1 commit
-
-
Ulrich Weigand authored
Differential Revision: https://reviews.llvm.org/D88479
-
- 28 Sep, 2020 2 commits
-
-
Hans Wennborg authored
The test would fail in no-asserts release builds using MSVC for 64-bit Windows: Unexpected error message: TestBuffer:1:1: error: implicit format conflict between 'FOO' (%u) and '18\0' (%x), need an explicit format specifier Error message(s) not found: {implicit format conflict between 'FOO' (%u) and 'BAZ' (%x), need an explicit format specifier} It seems a string from a previous test case is finding its way into the latter one. This doesn't reproduce on master anymore after 998709b7, so let's just hack around it here for the branch. -
Robert Widmann authored
It is not a good idea to expose raw constants in the LLVM C API. Replace this with an explicit getter. Differential Revision: https://reviews.llvm.org/D88367 (cherry picked from commit 55f72730)
-