From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.19766.1590174304864679640 for ; Fri, 22 May 2020 12:05:05 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JO68vF1j; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590174304; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z7+/quB+BjNqj8giJnX11P6cg1Fy8SpIoK2qoioKRMo=; b=JO68vF1jtW8xZ8u3hS4KkEK5tPUDmI6W72Fd4CzKcXGjnxc1p4hWeUqjlTR05X4uqUr/Yh zxPvy12BnwsJMqUznIK16aXP2EVKJOA78SIHKMY2CcRKXU8uZAQIgal09rTJVmU9LkmyAt hGTdVz/TuV3k/IDxoiAktk7Qf+ZuYCA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-40-vUjyzL0oNgmeZa1vkvEgRw-1; Fri, 22 May 2020 15:05:02 -0400 X-MC-Unique: vUjyzL0oNgmeZa1vkvEgRw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C91E5108BD11; Fri, 22 May 2020 19:05:00 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-40.ams2.redhat.com [10.36.112.40]) by smtp.corp.redhat.com (Postfix) with ESMTP id 88A6F54FF1; Fri, 22 May 2020 19:04:59 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2] ArmPkg/CompilerIntrinsicsLib: provide atomics intrinsics To: Ard Biesheuvel , Leif Lindholm Cc: devel@edk2.groups.io, glin@suse.com, liming.gao@intel.com References: <20200520114448.26104-1-ard.biesheuvel@arm.com> <20200521112353.GS1923@vanye> <20200521131644.GT1923@vanye> <059e1db5-8228-63a8-09ab-bb0efcd95176@arm.com> <20200521141615.GU1923@vanye> <036f7682-0903-40aa-3743-6a383b742b88@redhat.com> <20200522105435.GY1923@vanye> From: "Laszlo Ersek" Message-ID: Date: Fri, 22 May 2020 21:04:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 05/22/20 15:27, Ard Biesheuvel wrote: > 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. I'd delay it -- first, maybe have some more discussion around it, second, we can consider this "GCC10 feature enablement". IMO anyway. Thanks Laszlo > 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. > >