summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstCombine] Add test for -expensive-combines option; NFCNikita Popov2020-02-101-0/+28
| | | | | | This shows that -expensive-combines=0 is ignored. (cherry picked from commit 2d0d4235a282e0f900d31ac1054aafc0c526245c)
* [InstCombine] Fix infinite loop in min/max load/store bitcast combine (PR44835)Nikita Popov2020-02-102-0/+34
| | | | | | | | | | | | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=44835. Skip the transform if it wouldn't actually do anything (apart from removing and reinserting the same instructions). Note that the test case doesn't loop on current master anymore, only on the LLVM 10 release branch. The issue is already mitigated on master due to worklist order fixes, but we should fix the root cause there as well. As a side note, we should probably assert in combineLoadToNewType() that it does not combine to the same type. Not doing this here, because this assertion would also be triggered in another place right now. Differential Revision: https://reviews.llvm.org/D74278 (cherry picked from commit 23db9724d0e5490fa5a2a726acf015f84e2c87cf)
* Revert "[ARM] Improve codegen of volatile load/store of i64"Victor Campos2020-02-087-342/+6
| | | | This reverts commit 60e0120c913dd1d4bfe33769e1f000a076249a42.
* StringRef.h: __builtin_strlen seems to exist in VS 2017 MSVC 19.16 or laterHans Wennborg2020-02-071-1/+1
| | | | | | | This is a follow-up to ff837aa63cd, as discussed on the llvm-commits thread for that one. (cherry picked from commit 1b3d1661bbeb2c90f8f3ef6e2b77a70bc148731e)
* [Concepts] Fix incorrect check when instantiating abbreviated template ↵Saar Raz2020-02-063-9/+47
| | | | | | | | | | | | | type-constraints We would incorrectly check whether the type-constraint had already been initialized, causing us to ignore the invented template type constraints entirely. Also, TemplateParameterList would store incorrect information about invented type parameters when it observed them before their type-constraint was initialized, so we recreate it after initializing the function type of an abbreviated template. (cherry picked from commit 38fd69995fc5a6f16e0aa132a46e5ccdbc2eebb3)
* [LV] Fix predication for branches with matching true and false succs.Florian Hahn2020-02-062-1/+80
| | | | | | | | | | | | | | | | | | | | | Currently due to the edge caching, we create wrong predicates for branches with matching true and false successors. We will cache the condition for the edge from the true successor, and then lookup the same edge (src and dst are the same) for the edge to the false successor. If both successors match, the condition should always be true. At the moment, we cannot really create constant VPValues, but we can just create a true condition as X | !X. Later passes will clean that up. Fixes PR44488. Reviewers: rengolin, hsaito, fhahn, Ayal, dorit, gilr Reviewed By: Ayal Differential Revision: https://reviews.llvm.org/D73079 (cherry picked from commit f14f2a856802e086662d919e2ead641718b27555)
* Fix x86 32bits MLIR build (NFC)Dimitry Andric2020-02-061-1/+1
| | | | | | | | | | This is fixing a build error: error: non-constant-expression cannot be narrowed from type 'unsigned int' to 'Region::iterator::difference_type' (aka 'int') in initializer list Fix pr44767 (cherry picked from commit 31fd112eb4a90600e0f340f19053e5715e92ec4c)
* [LLDB] Fix compilation with GCC 5Martin Storsjö2020-02-064-3/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D74084 (cherry picked from commit 5bbaf543585c54868f8a2bdd9e74edcf395b24b3)
* [clangd] Add workaround for GCC5 host compilers. NFC.Michael Liao2020-02-061-1/+7
| | | | (cherry picked from commit 40514a7d7a3b745ba43c2d014e54a0d78d65d957)
* Make llvm::crc32() work also for input sizes larger than 32 bits.Hans Wennborg2020-02-062-1/+29
| | | | | | | | | | | | The problem was noticed by the Chrome OS toolchain folks (crbug.com/1048445) because llvm-objcopy --add-gnu-debuglink would insert the wrong checksum when processing a binary larger than 4 GB. That use case regressed in 1e1e3ba2526 when we started using llvm::crc32() in more places. Differential revision: https://reviews.llvm.org/D74039 (cherry picked from commit 6c4a8bc0a9f6a466d90d542bef66d69550c1b041)
* [TSan] Ensure we can compile the runtime with older SDKsJulian Lettner2020-02-051-1/+8
| | | | | | | | | | | | | | | | | | | | | One of my changes [1] included in this release silently bumped the minimal macOS SDK required for building the TSan runtime to SDK 10.12. Let's ensure release 10 does not unexpectedly break builders with old SDKs and add proper minimal SDK checking in CMake for subsequent releases. This fix `#ifdef`s out interceptors for newer APIs. Note that the resulting TSan runtime is less complete: when these newer APIs are used TSan will report false positives. Fixes llvm 10 release blocker: #44682 https://bugs.llvm.org/show_bug.cgi?id=44682 [1] 894abb46f891cba2e0ef581650f27f512a7824b4 Reviewed By: dmajor Differential Revision: https://reviews.llvm.org/D74059
* [libcxx] Add release notes for the 10.x branch for things I've doneMartin Storsjö2020-02-051-0/+5
| | | | Differential Revision: https://reviews.llvm.org/D74029
* [clang] Add release notes for the 10.x branch for things I've doneMartin Storsjö2020-02-051-0/+6
| | | | Differential Revision: https://reviews.llvm.org/D74028
* [docs] Add LLVM/LLDB release notes for the 10.x branch for things I've doneMartin Storsjö2020-02-051-0/+9
| | | | Differential Revision: https://reviews.llvm.org/D74027
* [LLD] Add release notes for MinGW for the 10.x branchMartin Storsjö2020-02-051-1/+27
| | | | Differential Revision: https://reviews.llvm.org/D74026
* [OpenMP][OMPT] fix reduction test for 32-bit x86protze@itc.rwth-aachen.de2020-02-051-3/+7
| | | | | | | | | | | | | | Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44733 | TEST 'libomp :: ompt/synchronization/reduction/tree_reduce.c' FAILED on 32-bit x86 ]] For 32-bit we need at least 3 variables to avoid atomic reduction to be choosen by runtime function `__kmp_determine_reduction_method`. This patch adds reduction variables to the testcase. Reviewers: mgorny, Hahnfeld Differential Revision: https://reviews.llvm.org/D73850 (cherry picked from commit 90e4ebdce55fd3c1f8877f19784a5339b9890f98)
* Don't warn about missing declarations for partial template specializationsAaron Puchert2020-02-052-0/+3
| | | | | | | | | | Summary: Just like templates, they are excepted from the ODR rule. Reviewed By: aaron.ballman, rsmith Differential Revision: https://reviews.llvm.org/D68923 (cherry picked from commit 27684ae66d5545f211c0ac4393d0ba2bf3b5b47c)
* [X86] -fpatchable-function-entry=N,0: place patch label after ENDBR{32,64}Fangrui Song2020-02-053-16/+77
| | | | | | | | | | | | | | | | Similar to D73680 (AArch64 BTI). A local linkage function whose address is not taken does not need ENDBR32/ENDBR64. Placing the patch label after ENDBR32/ENDBR64 has the advantage that code does not need to differentiate whether the function has an initial ENDBR. Also, add 32-bit tests and test that .cfi_startproc is at the function entry. The line information has a general implementation and is tested by AArch64/patchable-function-entry-empty.mir Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D73760 (cherry picked from commit 8ff86fcf4c038c7156ed4f01e7ed35cae49489e2)
* Update for Clang 10 release notes in order to have reference to D66404.Andi-Bogdan Postelnicu2020-02-051-1/+18
| | | | | | | | | | | | Summary: Since `D66404` adds some significat modifications to the `CFG` we should include it in the release notes. Reviewers: hans Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D74031
* [ARM][VecReduce] Force expand vector_reduce_fminDavid Green2020-02-054-6/+2273
| | | | | | | | | | | | | | Under MVE, we do not have any lowering for fminimum, which a vector_reduce_fmin without NoNan will be expanded into. As with the other recent patches, force this to expand in the pre-isel pass. Note that Neon lowering would be OK because the scalar fminimum uses the vector VMIN instruction, but is probably better to just rely on the scalar operations, which is what is done here. Also fixes what appears to be the reversal of INF vs -INF in the vector_reduce_fmin widening code. (cherry picked from commit 362d00e0510ee75750499e2993a782428e377215)
* [ARM] Expand vector reduction intrinsics on soft floatNikita Popov2020-02-052-1/+71
| | | | | | | | | | | | Followup to D73135. If the target doesn't have hard float (default for ARM), then we assert when trying to soften the result of vector reduction intrinsics. This patch marks these for expansion as well. (A bit odd to use vectors on a target without hard float ... but that's where you end up if you expose target-independent vector types.) Differential Revision: https://reviews.llvm.org/D73854 (cherry picked from commit 1cc4f8d17247cd9be88addd75d060f9321b6f8b0)
* [AArch64][ARM] Always expand ordered vector reductions (PR44600)Nikita Popov2020-02-057-2/+687
| | | | | | | | | | | | | | | | | | fadd/fmul reductions without reassoc are lowered to VECREDUCE_STRICT_FADD/FMUL nodes, which don't have legalization support. Until that is in place, expand these intrinsics on ARM and AArch64. Other targets always expand the vector reduction intrinsics. Additionally expand fmax/fmin reductions without nonan flag on AArch64, as the backend asserts that the flag is present when lowering VECREDUCE_FMIN/FMAX. This fixes https://bugs.llvm.org/show_bug.cgi?id=44600. Differential Revision: https://reviews.llvm.org/D73135 (cherry picked from commit 70d345e687caba4ac1f95655c6924dfa91e0083f)
* [mlir] Mark the MLIR tools for installation in CMakeKern Handa2020-02-053-3/+3
| | | | | | | | This binplaces `mlir-translate`, `mlir-cuda-runner`, and `mlir-cpu-runner` when building the CMake install target. Differential Revision: https://reviews.llvm.org/D73986 (cherry picked from commit b8004b7308b490b93231789cd05f86294a77d663)
* PR44786: Don't assert when profiling <=> expressions.Richard Smith2020-02-042-2/+11
| | | | (cherry picked from commit b96c6b65b93f7b3878bced2374bef747a4c3b690)
* [Concepts] Add missing CXXThisScope to function template constraint substitutionSaar Raz2020-02-053-2/+24
| | | | | | | | | | We did not have a CXXThisScope around constraint checking of functions and function template specializations, causing a crash when checking a constraint that had a 'this' (bug 44689). Recommit after fixing test. (cherry picked from commit 6c232441564f8934477e418347bf0c217abb0a00)
* PR44721: Don't consider overloaded operators for built-in comparisonsRichard Smith2020-02-042-7/+34
| | | | | | | | | | | | | | | | | | | | when building a defaulted comparison. As a convenient way of asking whether `x @ y` is valid and building it, we previouly always performed overload resolution and built an overloaded expression, which would both end up picking a builtin operator candidate when given a non-overloadable type. But that's not quite right, because it can result in our finding a user-declared operator overload, which we should never do when applying operators non-overloadable types. Handle this more correctly: skip overload resolution when building `x @ y` if the operands are not overloadable. But still perform overload resolution (considering only builtin candidates) when checking validity, as we don't have any other good way to ask whether a binary operator expression would be valid. (cherry picked from commit 1f3f8c369a5067a132c871f33a955a7feaea8534)
* PR44761: Fix fallback to later tiebreakers if two non-template functionsRichard Smith2020-02-042-8/+22
| | | | | | are equally constrained. (cherry picked from commit cfacf9ae20b8c97a428f118a2720bc109ba6a143)
* Add -Wrange-loop-analysis changes to ReleaseNotesMark de Wever2020-02-041-1/+3
| | | | | | This reflects the recent changes done. Differential Revision: https://reviews.llvm.org/D73834
* [libcxx] [Windows] Store the lconv struct returned from localeconv in locale_tMartin Storsjö2020-02-042-7/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes using non-default locales, which currently can crash when e.g. formatting numbers. Within the localeconv_l function, the per-thread locale is temporarily changed with __libcpp_locale_guard, then localeconv() is called, returning an lconv * struct pointer. When localeconv_l returns, the __libcpp_locale_guard dtor restores the per-thread locale back to the original. This invalidates the contents of the earlier returned lconv struct, and all C strings that are pointed to within it are also invalidated. Thus, to have an actually working localeconv_l function, the function needs to allocate some sort of storage for the returned contents, that stays valid for as long as the caller needs to use the returned struct. Extend the libcxx/win32 specific locale_t class with storage for a deep copy of a lconv struct, and change localeconv_l to take a reference to the locale_t, to allow it to store the returned lconv struct there. This works fine for libcxx itself, but wouldn't necessarily be right for a caller that uses libcxx's localeconv_l function. This fixes around 11 of libcxx's currently failing tests on windows. Differential Revision: https://reviews.llvm.org/D69505 (cherry picked from commit 7db4f2c6945a24a7d81dad3362700353e2ec369e)
* AMDGPU: Fix handling of infinite loops in fragment shadersConnor Abbott2020-02-042-6/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Due to the fact that kill is just a normal intrinsic, even though it's supposed to terminate the thread, we can end up with provably infinite loops that are actually supposed to end successfully. The AMDGPUUnifyDivergentExitNodes pass breaks up these loops, but because there's no obvious place to make the loop branch to, it just makes it return immediately, which skips the exports that are supposed to happen at the end and hangs the GPU if all the threads end up being killed. While it would be nice if the fact that kill terminates the thread were modeled in the IR, I think that the structurizer as-is would make a mess if we did that when the kill is inside control flow. For now, we just add a null export at the end to make sure that it always exports something, which fixes the immediate problem without penalizing the more common case. This means that we sometimes do two "done" exports when only some of the threads enter the discard loop, but from tests the hardware seems ok with that. This fixes dEQP-VK.graphicsfuzz.while-inside-switch with radv. Reviewers: arsenm, nhaehnle Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70781 (cherry picked from commit 87d98c149504f9b0751189744472d7cc94883960)
* [LLD][ELF][ARM][AArch64] Only round up ThunkSection Size when large OS.Peter Smith2020-02-047-23/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In D71281 a fix was put in to round up the size of a ThunkSection to the nearest 4KiB when performing errata patching. This fixed a problem with a very large instrumented program that had thunks and patches mutually trigger each other. Unfortunately it triggers an assertion failure in an AArch64 allyesconfig build of the kernel. There is a specific assertion preventing an InputSectionDescription being larger than 4KiB. This will always trigger if there is at least one Thunk needed in that InputSectionDescription, which is possible for an allyesconfig build. Abstractly the problem case is: .text : { *(.text) ; ... . = ALIGN(SZ_4K); __idmap_text_start = .; *(.idmap.text) __idmap_text_end = .; ... } The assertion checks that __idmap_text_end - __idmap_start is < 4 KiB. Note that there is more than one InputSectionDescription in the OutputSection so we can't just restrict the fix to OutputSections smaller than 4 KiB. The fix presented here limits the D71281 to InputSectionDescriptions that meet the following conditions: 1.) The OutputSection is bigger than the thunkSectionSpacing so adding thunks will affect the addresses of following code. 2.) The InputSectionDescription is larger than 4 KiB. This will prevent any assertion failures that an InputSectionDescription is < 4 KiB in size. We do this at ThunkSection creation time as at this point we know that the addresses are stable and up to date prior to adding the thunks as assignAddresses() will have been called immediately prior to thunk generation. The fix reverts the two tests affected by D71281 to their original state as they no longer need the 4KiB size roundup. I've added simpler tests to check for D71281 when the OutputSection size is larger than the ThunkSection spacing. Fixes https://github.com/ClangBuiltLinux/linux/issues/812 Differential Revision: https://reviews.llvm.org/D72344 (cherry picked from commit 01ad4c838466bd5db180608050ed8ccb3b62d136)
* [ELF] Decrease alignment of ThunkSection on 64-bit targets from 8 to 4Fangrui Song2020-02-0411-58/+58
| | | | | | | | | | | | | ThunkSection contains 4-byte instructions on all targets that use thunks. Thunks should not be used in any performance sensitive places, and locality/cache line/instruction fetching arguments should not apply. We use 16 bytes as preferred function alignments for modern PowerPC cores. In any case, 8 is not optimal. Differential Revision: https://reviews.llvm.org/D72819 (cherry picked from commit 870094decfc9fe80c8e0a6405421b7d09b97b02b)
* [libcxxabi] Fix layout of __cxa_exception for win64Martin Storsjö2020-02-041-5/+5
| | | | | | | | | | | | Win64 isn't LP64, it's LLP64, but there's no __LLP64__ predefined - just check _WIN64 in addition to __LP64__. This fixes compilation after static asserts about the struct layout were added in f2a436058fcbc11291e73badb44e243f61046183. Differential Revision: https://reviews.llvm.org/D73838 (cherry picked from commit 09dc884eb2e4a433eb8c5ed20a17108091279295)
* Actually, don't try to use __builtin_strlen in StringRef.h before VS 2019Hans Wennborg2020-02-031-2/+3
| | | | | | | | | The fix in b3d7d1061dc375bb5ea725e6597382fcd37f41d6 compiled nicely, but didn't link because at least the VS 2017 version I use doesn't have the builtin yet. Instead, make use of the builtin with MSVC conditional on VS 2019 or later. (cherry picked from commit ff837aa63cdfadb58f387ca77785ca3ca51c6976)
* Declare __builtin_strlen in StringRef.h as constexprHans Wennborg2020-02-031-1/+1
| | | | | | | | | | Otherwise Visual Studio 2017 will complain about llvm::StringRef::strlen not being constexpr: StringRef.h(80): error C3615: constexpr function 'llvm::StringRef::strLen' cannot result in a constant expression StringRef.h(84): note: failure was caused by call of undefined function or one not declared 'constexpr' (cherry picked from commit b3d7d1061dc375bb5ea725e6597382fcd37f41d6)
* [clang-tidy] Fixed crash 44745 in readability-else-after-returnNathan James2020-02-032-0/+17
| | | | | | | | | | | | | | | | Summary: Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=44745 | readability-else-after-return crashes ]] Reviewers: aaron.ballman, alexfh, hokein, JonasToth, gribozavr2 Reviewed By: alexfh Subscribers: merge_guards_bot, xazax.hun, cfe-commits Tags: #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D73841 (cherry picked from commit d591bdce6d623208d4aeb335a762d839f0f8f0f7)
* R600: Fix failing testcaseMatt Arsenault2020-02-031-3/+3
| | | | (cherry picked from commit 7dc49f77ee508b4152f9291c8e804e4eda3653d3)
* AMDGPU/R600: Emit rodata in text segmentJan Vesely2020-02-032-1/+7
| | | | | | | | | | R600 relies on this behaviour. Fixes: 6e18266aa4dd78953557b8614cb9ff260bad7c65 ('Partially revert D61491 "AMDGPU: Be explicit about whether the high-word in SI_PC_ADD_REL_OFFSET is 0"') Fixes ~100 piglit regressions since 6e18266 Differential Revision: https://reviews.llvm.org/D72991 (cherry picked from commit 1b8eab179db46f25a267bb73c657009c0bb542cc)
* [BPF] fix a bug in BPFMISimplifyPatchable pass with -O0Yonghong Song2020-02-032-3/+56
| | | | | | | | | | | | | | | | | | | | The recommended optimization level for BPF programs is O2 since (1). BPF is running inside the kernel and linux kernel won't work at -O0 level, and (2). Verifier is not able to handle O0 code properly, e.g., potential large stack size and a lot of spills. But we should keep -O0 at least compiling. This patch fixed a bug in BPFMISimplifyPatchable phase where with -O0, a segmentation fault will happen for a simple program like: int test(int a, int b) { return a + b; } A test case is added to capture such a case. Differential Revision: https://reviews.llvm.org/D73681 (cherry picked from commit 795bbb366266e83d2bea8dc04c19919b52ab3a2a)
* Revert "[AMDGPU] Invert the handling of skip insertion."Nicolai Hähnle2020-02-0340-390/+380
| | | | | | | | | This reverts commit 0dc6c249bffac9f23a605ce4e42a84341da3ddbd. The commit is reported to cause a regression in piglit/bin/glsl-vs-loop for Mesa. (cherry picked from commit a80291ce10ba9667352adcc895f9668144f5f616)
* [RISCV] Scheduler description for the Rocket coreKai Wang2020-02-0311-186/+900
| | | | | | | | | | Pipeline scheduler model for the RISC-V Rocket micro-architecture using the MIScheduler interface. Support for both 32 and 64-bit Rocket cores is implemented. Differential revision: https://reviews.llvm.org/D68685 (cherry picked from commit 838a28e234e098bfc073a45f37a4dd3bb5b45eab)
* [Concepts] Instantiate invented template type parameter type-constraint ↵Saar Raz2020-02-033-20/+184
| | | | | | | | | | | | | | | | | along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint a second time. (cherry picked from commit 84959ae47f447fca9d56a9c61e8c46e993d0387a)
* Revert "[Concepts] Instantiate invented template type parameter ↵Saar Raz2020-02-033-179/+20
| | | | | | type-constraint along with function parameters" This temporarily reverts commit 2b54b8b994b45d4e0a72f36dfb91dc9662543234 which caused some test failures.
* [Concepts] Instantiate invented template type parameter type-constraint ↵Saar Raz2020-02-033-20/+179
| | | | | | | | | | | | | | along with function parameters We previously instantiated type-constraints of template type parameters along with the type parameter itself, this caused problems when the type-constraints created by abbreviated templates refreneced other parameters in the abbreviated templates. When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of the type-constraint until the function parameter which created the invented template type parameter is instantiated. (cherry picked from commit eacca4824463d8b96e2e1c9f8bbf886055218a16)
* [libcxxabi] Insert padding in __cxa_exception struct for compatibilitySteven Wu2020-02-031-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Preserve the old ABI for __cxa_exception and __cxa_dependent_exception on 64 bit platforms or ARM_EHABI platforms. After r276215, libunwind in llvm-project labels _Unwind_Exception to be double word aligned. That change implictly adds a padding before unwindHeader field in __cxa_exception and __cxa_dependent_exception. Preserve the same negative offsets in those struct by moving the padding to the beginning of the field. The assumption here is that if the ABI is not aware of the padding before unwindHeader and put the referenceCount/primaryException in there, no padding should exist before unwindHeader. Reviewers: EricWF, mclow.lists, ldionne, jroelofs, dexonsmith, rjmccall, compnerd, phosek, ahatanak Reviewed By: rjmccall Subscribers: hans, smeenai, kristof.beyls, christof, jkorous, ributzka, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D72543 (cherry picked from commit f2a436058fcbc11291e73badb44e243f61046183)
* [AArch64] -fpatchable-function-entry=N,0: place patch label after BTIFangrui Song2020-02-034-4/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For -fpatchable-function-entry=N,0 -mbranch-protection=bti, after 9a24488cb67a90f889529987275c5e411ce01dda, we place the NOP sled after the initial BTI. ``` .Lfunc_begin0: bti c nop nop .section __patchable_function_entries,"awo",@progbits,f,unique,0 .p2align 3 .xword .Lfunc_begin0 ``` This patch adds a label after the initial BTI and changes the __patchable_function_entries entry to reference the label: ``` .Lfunc_begin0: bti c .Lpatch0: nop nop .section __patchable_function_entries,"awo",@progbits,f,unique,0 .p2align 3 .xword .Lpatch0 ``` This placement is compatible with the resolution in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424 . A local linkage function whose address is not taken does not need a BTI. Placing the patch label after BTI has the advantage that code does not need to differentiate whether the function has an initial BTI. Reviewers: mrutland, nickdesaulniers, nsz, ostannard Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73680 (cherry picked from commit 06b8e32d4fd3f634f793e3bc0bc4fdb885e7a3ac)
* MSVC Buggy version detection: turn pre-processor error into CMake ↵Mehdi Amini2020-02-031-0/+14
| | | | | | | | | | | | | | | | | configuration time check This allows consumer to override in a cleaner way while still prevent them from hitting bug without knowing they run an unsupported configuration. Recommit after fix by Christopher Tetreault to add parens and ${} to cmake check to work around CMake configure time "unknown arguments specified" issue Differential Revision: https://reviews.llvm.org/D73677 Differential Revision: https://reviews.llvm.org/D73751 (cherry picked from commit 5f940220bf9438e95ffa4a627ac1591be1e1ba6e)
* [Sema] Remove a -Wrange warning from -WallMark de Wever2020-02-034-9/+12
| | | | | | | | | | | | | | | | | | | | | | | During the review of D73007 Aaron Puchert mentioned `warn_for_range_variable_always_copy` shouldn't be part of -Wall since some coding styles require `for(const auto &bar : bars)`. This warning would cause false positives for these users. Based on Aaron's proposal refactored the warnings: * -Wrange-loop-construct warns about possibly unintended constructor calls. This is part of -Wall. It contains * warn_for_range_copy: loop variable A of type B creates a copy from type C * warn_for_range_const_reference_copy: loop variable A is initialized with a value of a different type resulting in a copy * -Wrange-loop-bind-reference warns about misleading use of reference types. This is not part of -Wall. It contains * warn_for_range_variable_always_copy: loop variable A is always a copy because the range of type B does not return a reference Differential Revision: https://reviews.llvm.org/D73434 (cherry picked from commit c03349e40f21f0375278138992a32694a99c830e)
* Make quick-append.test resilient to running in paths with '1.o' in the nameHans Wennborg2020-02-031-9/+9
| | | | (cherry picked from commit f00ab188f4e4214dfbecfdd8968a183e9363cefa)
* Fix wrong devirtualization when the final overrider in one base classRichard Smith2020-01-313-4/+73
| | | | | | overrides the final overrider in a different base class. (cherry picked from commit aade5fbbfef3e8555df202082bea905deebc2ca5)
OpenPOWER on IntegriCloud