| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This shows that -expensive-combines=0 is ignored.
(cherry picked from commit 2d0d4235a282e0f900d31ac1054aafc0c526245c)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
This reverts commit 60e0120c913dd1d4bfe33769e1f000a076249a42.
|
|
|
|
|
|
|
| |
This is a follow-up to ff837aa63cd, as discussed on the llvm-commits
thread for that one.
(cherry picked from commit 1b3d1661bbeb2c90f8f3ef6e2b77a70bc148731e)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D74084
(cherry picked from commit 5bbaf543585c54868f8a2bdd9e74edcf395b24b3)
|
|
|
|
| |
(cherry picked from commit 40514a7d7a3b745ba43c2d014e54a0d78d65d957)
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D74029
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D74028
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D74027
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D74026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
(cherry picked from commit b96c6b65b93f7b3878bced2374bef747a4c3b690)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
are equally constrained.
(cherry picked from commit cfacf9ae20b8c97a428f118a2720bc109ba6a143)
|
|
|
|
|
|
| |
This reflects the recent changes done.
Differential Revision: https://reviews.llvm.org/D73834
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
(cherry picked from commit 7dc49f77ee508b4152f9291c8e804e4eda3653d3)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
type-constraint along with function parameters"
This temporarily reverts commit 2b54b8b994b45d4e0a72f36dfb91dc9662543234 which caused some test failures.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
(cherry picked from commit f00ab188f4e4214dfbecfdd8968a183e9363cefa)
|
|
|
|
|
|
| |
overrides the final overrider in a different base class.
(cherry picked from commit aade5fbbfef3e8555df202082bea905deebc2ca5)
|