Merge tag 'llvmorg-11.0.0-rc3' into rustc/11.0-2020-08-20 #75
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
D80298 made Timer::total atomic, but this requires linking libatomic on some targets. Reviewed By: aaronpuchert Differential Revision: https://reviews.llvm.org/D85691 (cherry picked from commit b26b32b)
The global variable outputSections in the COFF writer was not cleared between runs which caused successive calls to lld::coff::link to generate invalid binaries. These binaries when loaded would result in "invalid win32 applications" and/or "bad image" errors. Differential Revision: https://reviews.llvm.org/D86401 (cherry picked from commit 54f5a4e)
We're (temporarily) disabling ExtInt for the '__atomic' builtins so we can better design their behavior later. The idea is until we do an audit/design for the way atomic builtins are supposed to work with _ExtInt, we should leave them restricted so they don't limit our future options, such as by binding us to a sub-optimal implementation via ABI.
Example after this change:
$ cat test.c
void f(_ExtInt(64) *ptr) {
__atomic_fetch_add(ptr, 1, 0);
}
$ clang -c test.c
test.c:2:22: error: argument to atomic builtin of type '_ExtInt' is not supported
__atomic_fetch_add(ptr, 1, 0);
^
1 error generated.
Differential Revision: https://reviews.llvm.org/D84049
(cherry picked from commit ca77ab4)
D77531 has a type for mfsprg, it should be mtsprg. This patch is to fix this typo. (cherry picked from commit 95e18b2)
… anything (cherry picked from commit ac46bc3)
PR46970: for `alias = aliasee`, the alias can be used in relocation processing and on ARM st_type does affect Thumb interworking. It is thus desirable for the alias to get the same st_type. Note that the st_size field should not be inherited because some tools use st_size=0 as a heuristic to detect aliases. Retaining st_size can thwart such heuristics and cause aliases to be preferred over the original symbols. Differential Revision: https://reviews.llvm.org/D86263 (cherry picked from commit 9670029) The test symbol-assign-type.s was rewritten to not depend on 'split-file'.
When `Target::GetEntryPointAddress()` calls `exe_module->GetObjectFile()->GetEntryPointAddress()`, and the returned `entry_addr` is valid, it can immediately be returned. However, just before that, an `llvm::Error` value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: ``` * thread llvm#1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 llvm#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 llvm#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 llvm#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 llvm#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 llvm#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 llvm#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 llvm#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 llvm#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 llvm#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 llvm#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 llvm#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 llvm#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 llvm#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 llvm#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 llvm#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 llvm#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 llvm#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 llvm#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 llvm#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 llvm#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 llvm#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 llvm#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 llvm#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 llvm#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 llvm#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890``` Fix the incorrect error catch by only instantiating an `Error` object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 (cherry picked from commit 1ce07cd)
…Support for the OpenBSD clang driver. If not overridden, AddClangSystemIncludeArgs's implementation is empty, so by default, no system include args are added to the Clang driver. This means that invoking Clang without the frontend must include a manual -I/usr/include flag, which is inconsistent behavior. Therefore, override and implement this method to match. Some boilerplate is also borrowed for handling of the other driver flags. While we are here, also override and enable HasNativeLLVMSupport. Patch by: 3405691582 (dana koch) Differential Revision: https://reviews.llvm.org/D86412 (cherry picked from commit 2b37174)
… the OpenBSD clang driver. (cherry picked from commit bf3577e)
Currently, this function is present in the dynsym table of libunwind.so (on ELF targets). Make the function static instead. In the previous release (LLVM 10.x), this function was instead a lambda function inside LocalAddressSpace::findUnwindSections, and because LocalAddressSpace was marked with _LIBUNWIND_HIDDEN, the lambda function was also a hidden symbol. Differential Revision: https://reviews.llvm.org/D86372 (cherry picked from commit 3c1b2e3)
friend declarations and declarations found in inline namespaces within the target context. (cherry picked from commit 04ba185)
Replace the `ident_t` handling in Clang with the methods offered by the OMPIRBuilder. This cuts down on the clang code as well as the differences between the two, making further transitions easier. Tests have changed but there should not be a real functional change. The most interesting difference is probably that we stop generating local ident_t allocations for now and just use globals. Given that this happens only with debug info, the location part of the `ident_t` is probably bigger than the test anyway. As the location part is already a global, we can avoid the allocation, memcpy, and store in favor of a constant global that is slightly bigger. This can be revisited if there are complications. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D80735
When we implement OpenMP GPU reductions we use type punning a lot during the shuffle and reduce operations. This is not always compatible with language rules on aliasing. So far we generated TBAA which later allowed to remove some of the reduce code as accesses and initialization were "known to not alias". With this patch we avoid TBAA in this step, hopefully for all accesses that we need to. Verified on the reproducer of PR46156 and QMCPack. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D86037
We hit the compiling time reported by https://bugs.llvm.org/show_bug.cgi?id=46877 and the reason is the same as D77319. So we need to remove the dead node we created to avoid increase the problem size of DAGCombiner. Reviewed By: Spatel Differential Revision: https://reviews.llvm.org/D86183 (cherry picked from commit 960cbc5)
-gdwarf-5 -fdebug-types-section may produce multiple .debug_info sections. All except one are type units (.debug_types before DWARF v5). When constructing .gdb_index, we should ignore these type units. We use a simple heuristic: the compile unit does not have the SHF_GROUP flag. (This needs to be revisited if people place compile unit .debug_info in COMDAT groups.) This issue manifests as a data race: because an object file may have multiple .debug_info sections, we may concurrently construct `LLDDwarfObj` for the same file in multiple threads. The threads may access `InputSectionBase::data()` concurrently on the same input section. `InputSectionBase::data()` does a lazy uncompress() and rewrites the member variable `rawData`. A thread running zlib `inflate()` (transitively called by uncompress()) on a buffer with `rawData` tampered by another thread may fail with `uncompress failed: zlib error: Z_DATA_ERROR`. Even if no data race occurred in an optimistic run, if there are N .debug_info, one CU entry and its address ranges will be replicated N times. The result .gdb_index can be much larger than a correct one. The new test gdb-index-dwarf5-type-unit.s actually has two compile units. This cannot be produced with regular approaches (it can be produced with -r --unique). This is used to demonstrate that the .gdb_index construction code only considers the last non-SHF_GROUP .debug_info Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D85579 (cherry picked from commit fb14129)
Summary: Documents interaction of linker option added in D71913 with LTO visibility. Reviewers: pcc Subscribers: inglorion, hiraditya, steven_wu, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75655 (cherry picked from commit 72bdb41)
to make the test more stable, as suggested by mmoroz. (cherry picked from commit 8421503)
* For .cfi_*, GCC/GNU as emits SHT_PROGBITS type .eh_frame sections.
* Since rL252300, clang emits SHT_X86_64_UNWIND type .eh_frame sections
(originated from Solaris, documented in the x86-64 psABI).
* Some assembly use `.section .eh_frame,"a",@unwind` to generate
SHT_X86_64_UNWIND .eh_frame sections.
In a non-relocatable link, input .eh_frame are combined and there is
only one SyntheticSection .eh_frame in the output section, so the
"section type mismatch" diagnostic does not fire.
In a relocatable link, there is no SyntheticSection .eh_frame. .eh_frame of
mixed types can trigger the diagnostic. This patch fixes it by adding another
special case 0x70000001 (= SHT_X86_64_UNWIND) to canMergeToProgbits().
ld.lld -r gcc.o clang.o => error: section type mismatch for .eh_frame
There was a discussion "RFC: Usefulness of SHT_X86_64_UNWIND" on the x86-64-abi
mailing list. Folks are not wild about making the psABI value 0x70000001 into
gABI, but a few think defining 0x70000001 for .eh_frame may be a good idea for a
new architecture.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D85785
(cherry picked from commit 88498f4)
…ProcessorTypeAndSubtype to do a proper bit test. Instead of ANDing with a one hot mask representing the bit to be tested, we were ANDing with just the bit number. This tests multiple bits none of them the correct one. This caused skylake-avx512, cascadelake and cooperlake to all be misdetected. Based on experiments with the Intel SDE, it seems that all of these CPUs are being detected as being cooperlake. This is bad since its the newest CPU of the 3. (cherry picked from commit df9a9bb)
Text by Saleem!
The version of `st1d` that operates with vector plus immediate
addressing mode uses the alias `st1d { <Zn>.d }, <Pg>, [<Za>.d]` for
rendering `st1d { <Zn>.d }, <Pg>, [<Za>.d, #0]`. The disassembler was
generating `<Zn>.s` instead of `<Zn>.d>`.
Differential Revision: https://reviews.llvm.org/D86633
(cherry picked from commit a45ccc9)
Patch by mati865@gmail.com Differential Revision: https://reviews.llvm.org/D86552 (cherry picked from commit 1596ea8)
…n-clang-tidy.py The action='store_true' option of argparse.add_argument implicitly generates a default value of False if the argument is not specified. Thus, the allow_enabling_alpha_checkers argument of get_tidy_invocation is never None.
By Alexey Bataev! Differential revision: https://reviews.llvm.org/D86562
This seems to have caused incorrect register allocation in some cases, breaking tests in the Zig standard library (PR47278). As discussed on the bug, revert back to green for now. > Record internal state based on register units. This is often more > efficient as there are typically fewer register units to update > compared to iterating over all the aliases of a register. > > Original patch by Matthias Braun, but I've been rebasing and fixing it > for almost 2 years and fixed a few bugs causing intermediate failures > to make this patch independent of the changes in > https://reviews.llvm.org/D52010. This reverts commit 66251f7, and follow-ups 931a68f and 0671a4c. It also adjust some test expectations. (cherry picked from commit a21387c)
By Ahsan Saghir!
Apply a local fix to an issue with recommonmark's AutoStructify extension when used with certain versions of sphinx. See readthedocs/recommonmark#93 Reviewed By: hans Differential Revision: https://reviews.llvm.org/D87714 (cherry picked from commit af56be3)
This fixes a bug in dbf486c, which introduced the Index section of the config, but did not register the parse method, so it didn't work in a YAML file (but did in a test). Differential Revision: https://reviews.llvm.org/D87710 (cherry picked from commit 7029e5d)
…or STV_DEFAULT only This patch restricts the behaviour of referencing via .Lfoo$local local aliases, introduced in https://reviews.llvm.org/D73230, to STV_DEFAULT globals only. Hidden symbols via --fvisiblity=hidden (https://gcc.gnu.org/wiki/Visibility) is an important scenario. Benefits: - Improves the size of object files by using fewer STT_SECTION symbols. - The code reads a bit better (it was not obvious to me without going back to the code reviews why the canBenefitFromLocalAlias function currently doesn't consider visibility). - There is also a side benefit in restoring the effectiveness of the --wrap linker option and making the behavior of --wrap consistent between LTO and normal builds for references within a translation-unit. Note: this --wrap behavior (which is specific to LLD) should not be considered reliable. See comments on https://reviews.llvm.org/D73230 for more. Differential Revision: https://reviews.llvm.org/D85782 (cherry picked from commit 4cb016c)
Adds a new GettingInvolved page to documentation which provides details about mailing list, chats and calls. Adds a sidebar page which provides common links on all documentation pages. The links include: - Getting Started - Getting Involved - Github Repository - Bug Reports - Code Review Depends on https://reviews.llvm.org/D87242 Reviewed By: richard.barton.arm Differential Revision: https://reviews.llvm.org/D87270 (cherry picked from commit fe395ae)
2508ef0 fixed a bug about constant removal in negation. But after sanitizing check I found there's still some issue about it so it's reverted. Temporary nodes will be removed if useless in negation. Before the removal, they'd be checked if any other nodes used it. So the removal was moved after getNode. However in rare cases the node to be removed is the same as result of getNode. We missed that and will be fixed by this patch. Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D87614 (cherry picked from commit a2fb544)
Matches C++20 API addition. Differential Revision: https://reviews.llvm.org/D83449 (cherry picked from commit a0385bd)
…y inserted after an INLINEASM_BR. findPHICopyInsertPoint special cases placement in a block with a callbr or invoke in it. In that case, we must ensure that the copy is placed before the INLINEASM_BR or call instruction, if the register is defined prior to that instruction, because it may jump out of the block. Previously, the code placed it immediately after the last def _or use_. This is wrong, if the use is the instruction which may jump. We could correctly place it immediately after the last def (ignoring uses), but that is non-optimal for register pressure. Instead, place the copy after the last def, or before the call/inlineasm_br, whichever is later. Differential Revision: https://reviews.llvm.org/D87865 (cherry picked from commit f7a53d8)
…uilder SelectionDAGBuilder was inconsistently mangling values based on ABI Calling Conventions when getting them through copyFromRegs in SelectionDAGBuilder, causing duplicate value type convertions for function arguments. The checking for the mangling requirement was based on the value's originating instruction and was performed outside of, and inspite of, the regular Calling Convention Lowering. The issue could be observed in a scenario such as: ``` %arg1 = load half, half* %const, align 2 %arg2 = call fastcc half @someFunc() call fastcc void @otherFunc(half %arg1, half %arg2) ; Here, %arg2 was incorrectly mangled twice, as the CallConv data from ; the call to @someFunc() was taken into consideration for the check ; when getting the value for processing the call to @otherFunc(...), ; after the proper convertion had taken place when lowering the return ; value of the first call. ``` This patch fixes the issue by disregarding the Calling Convention information for such copyFromRegs, making sure the ABI mangling is properly contanined in the Calling Convention Lowering. This fixes Bugzilla llvm#47454. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D87844 (cherry picked from commit 53d238a)
D79916 changed the behaviour from -O2 to -O1 but the documentation was not updated to reflect this. (cherry picked from commit 788c7d2)
|
I think it would be better to create a new branch instead. |
|
I thought our process was to merge RCs, then rebase on the final release. But if you want a new rebased branch now, I can. |
Tag 11.0.0-rc3
cuviper
force-pushed
the
rust-llvm-11.0.0-rc3
branch
from
ed1ad1f to
d5e220f
Compare
|
Replaced by the new |
vext01
pushed a commit
to vext01/llvm-project
that referenced
this pull request
Jul 18, 2023
75: Allow programs without a control point to be compiled. r=ptersilie a=ltratt Co-authored-by: Laurence Tratt <laurie@tratt.net>
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.
No description provided.