Ard:
There is no objection to merge this change into the stable tag 202005. I see
this patch has Reviewed-by and Tested-by. Can you update this patch and merge
it today?
The stable tag will be created on 2020-06-03 (tomorrow).
Thanks
Liming
-----Original Message-----
From: Ard Biesheuvel <ard.biesheu...@arm.com>
Sent: 2020年5月22日 21:27
To: Leif Lindholm <l...@nuviainc.com>; Laszlo Ersek <ler...@redhat.com>
Cc: devel@edk2.groups.io; g...@suse.com; Gao, Liming <liming....@intel.com>
Subject: Re: [edk2-devel] [PATCH v2] ArmPkg/CompilerIntrinsicsLib: provide
atomics intrinsics
On 5/22/20 12:54 PM, Leif Lindholm wrote:
> On Thu, May 21, 2020 at 22:22:58 +0200, Laszlo Ersek wrote:
>> On 05/21/20 16:16, Leif Lindholm wrote:
>>
>>> OK, then I would vote *for* merging the patch regardless. We know
>>> how long some toolchain versions can stick around simply because
>>> they were mentioned in some blog post somewhere that ended up high
>>> in search rankings.
>>>
>>> Once gcc 10.2 is released (and we have verified the problem can be
>>> worked around elsewhere), I guess we could add a note saying "once
>>> all gcc 10.0 and 10.1 toolchains are considered obsolete, this file
>>> can be deleted".
>>
>> I think we can expect all distros that ship gcc-10 to eventually
>> migrate to gcc-10.2+. Until then, this patch should hopefully work.
>> (I'm quite annoyed by having to call the patch "temporary", as it
>> feels very technically impressive.)
>>
>> So I think I agree with Leif, with a small modification to the idea:
>> rather than a *note* saying "back this out once 10.0 and 10.1 have
>> been replaced by 10.2+ in all 'large' distros"
>
> That isn't actually exatly what I meant - I meant properly obsolete as
> in "we are now reasonably certain no one is still using some silly
> ancient cross compiler they checked into their build infrastructure
> years ago".
>
>> , I would suggest filing a *BZ*
>> for the same. And I recommend making the new BZ dependent on
>> TianoCore#2723 (i.e. the present BZ).
>
> But I don't object to that approach.
>
OK, so i will leave it up to Liming and the stewards to decide whether this
gets incorporated ino the stable tag or not. If it is, I would like to fold in
the fixup below
--- a/ArmPkg/Library/CompilerIntrinsicsLib/AArch64/Atomics.S
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/AArch64/Atomics.S
@@ -53,10 +53,10 @@
0: ld\a\()xr\s r0_\sz, [x1]
.ifnc \insn, swp
\opc tmp1_\sz, r0_\sz, tmp0_\sz
+ st\l\()xr\s w15, tmp1_\sz, [x1]
.else
- \opc tmp1_\sz, tmp0_\sz
+ st\l\()xr\s w15, tmp0_\sz, [x1]
.endif
- st\l\()xr\s w15, tmp1_\sz, [x1]
cbnz w15, 0b
ret
fn_end __aarch64_\insn\()\sz\()\model
to get rid of the redundant 'mov' for the SWP flavor of the atomics helpers.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#60552): https://edk2.groups.io/g/devel/message/60552
Mute This Topic: https://groups.io/mt/74347980/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
