Merge ^/vendor/llvm/dist up to its last change, and resolve conflicts.
Merge commit 894f742acb from llvm git (by me): [MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel |
Merge commit 894f742acb from llvm git (by me): [MIPS][ELF] Use PC-relative relocations in .eh_frame when possible When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228Merge commit 8e8ccf47 from llvm git (by me) [MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols The R_(MICRO)MIPS_JALR optimization only works when used against functions. Using the relocation against a data symbol (e.g. function pointer) will cause some linkers that don't ignore the hint in this case (e.g. LLD prior to commit 5bab291) to generate a relative branch to the data symbol which crashes at run time. Before this patch, LLVM was erroneously emitting these relocations against local-dynamic TLS function pointers and global function pointers with internal visibility. Reviewers: atanasyan, jrtc27, vstefanovic Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72571These two changes should allow using lld for MIPS64 (and maybe also MIPS32)by default.The second commit is not strictly necessary for clang+lld since LLD9 willnot perform the R_MIPS_JALR optimization (it was only added for 10) but itis probably required in order to use recent ld.bfd.Reviewed By: dim, emasteMFC after: 1 weekDifferential Revision: https://reviews.freebsd.org/D23203
show more ...
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05.Release notes for llvm, clang, lld and libc++ 9.0.1 will become
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05.Release notes for llvm, clang, lld and libc++ 9.0.1 will becomeavailable here:https://releases.llvm.org/9.0.1/docs/ReleaseNotes.htmlhttps://releases.llvm.org/9.0.1/tools/clang/docs/ReleaseNotes.htmlhttps://releases.llvm.org/9.0.1/tools/lld/docs/ReleaseNotes.htmlhttps://releases.llvm.org/9.0.1/projects/libcxx/docs/ReleaseNotes.htmlPR: 240629MFC after: 1 month
Move all sources from the llvm project into contrib/llvm-project.This uses the new layout of the upstream repository, which was recentlymigrated to GitHub, and converted into a "monorepo". That i
Move all sources from the llvm project into contrib/llvm-project.This uses the new layout of the upstream repository, which was recentlymigrated to GitHub, and converted into a "monorepo". That is, most ofthe earlier separate sub-projects with their own branches and tags wereconsolidated into one top-level directory, and are now branched andtagged together.Updating the vendor area to match this layout is next.
12