From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA31AC64E8A for ; Mon, 30 Nov 2020 10:26:18 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 53816206C1 for ; Mon, 30 Nov 2020 10:26:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mTQ0PXqN"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="PRbkhnQn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 53816206C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1mcUZAQetDIPOI92khNyeHrbS2Rk3fMyeX0ql6l/goA=; b=mTQ0PXqNC2qV0WMsKvTUlAjP2 HcR+ErEcfnMgCVnwj7ffv15yNy08lAa0HT26253ES5YzP7mh7/GNml8ezv+ltHxieeQotixr7Dzk7 Cp19zmIKJIpexGhfDgF2U/QDOeq2pt/Wj5p+0feAwAoq1KHQaKZAIzXtIM/NeQLh8akhHMJa1+b4p pzG/D33qKkLVnlMz+95dB4s2MzNvkwEQCzquoahiVI1VGTaeggQYH9xuFIVnptaNaPIJviUpunoGs UiK/0OV/0DQ9K/8G8PWmwsrL3WeGhnRqawyNHPrsx+EDSoHUdCYz3I7T5S42GkLU6V46QiYrhvt7I NpXaBlLxA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjgMJ-0005Dp-5T; Mon, 30 Nov 2020 10:24:39 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjgMG-0004v9-Fn for linux-arm-kernel@lists.infradead.org; Mon, 30 Nov 2020 10:24:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MLqKD3jRFo8FpPzkYIL73PYY1dH6RWPaiQHEkCwMjmw=; b=PRbkhnQnLbD5w0tItqIG+1cs/ 9wtc5J6Y29JJXqj2WLEGdA0qV6LmRqH/7qKynykIU2JloqSEhNh4DuC1uqaAtEC+rtJeONqpB2O1e lYdsRwUHa3bvQT/sUBLnItmFFDUC4/MqnzhAvoXV+KSeHWhLAm3ZIH98sje6B2AGg8ojrY2hDw7Mk I1RMFroF3oobZ/pX551OsZam9tyzJ02L/DAJxwoF/2ZMX0MsqRLmRZzLud33WnINyjgMJ5S+nHpMJ Hd6YstL8zS1hxisfqedfHbLsMZEpBycp+uRZ5vruCCYrbuLi7FAu1Nz9r7s6Cj0MiAYcRKpwGWkNo NQaMdLH4w==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:37940) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjgJA-0006Yt-SU; Mon, 30 Nov 2020 10:21:24 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1kjgJ8-0004vR-V5; Mon, 30 Nov 2020 10:21:22 +0000 Date: Mon, 30 Nov 2020 10:21:22 +0000 From: Russell King - ARM Linux admin To: Ard Biesheuvel Subject: Re: [RESEND,PATCH] ARM: fix __div64_32() error when compiling with clang Message-ID: <20201130102122.GT1551@shell.armlinux.org.uk> References: <20201123073634.6854-1-swpenim@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201130_052436_538310_F438F81E X-CRM114-Status: GOOD ( 26.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nicolas Pitre , Antony Yu , Nick Desaulniers , Linux Kernel Mailing List , clang-built-linux , Nathan Chancellor , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 30, 2020 at 11:12:33AM +0100, Ard Biesheuvel wrote: > (+ Nico) > > On Mon, 30 Nov 2020 at 11:11, Ard Biesheuvel wrote: > > > > On Mon, 23 Nov 2020 at 08:39, Antony Yu wrote: > > > > > > __do_div64 clobbers the input register r0 in little endian system. > > > According to the inline assembly document, if an input operand is > > > modified, it should be tied to a output operand. This patch can > > > prevent compilers from reusing r0 register after asm statements. > > > > > > Signed-off-by: Antony Yu > > > --- > > > arch/arm/include/asm/div64.h | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h > > > index 898e9c78a7e7..809efc51e90f 100644 > > > --- a/arch/arm/include/asm/div64.h > > > +++ b/arch/arm/include/asm/div64.h > > > @@ -39,9 +39,10 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base) > > > asm( __asmeq("%0", __xh) > > > __asmeq("%1", "r2") > > > __asmeq("%2", "r0") > > > - __asmeq("%3", "r4") > > > + __asmeq("%3", "r0") > > > + __asmeq("%4", "r4") > > > "bl __do_div64" > > > - : "=r" (__rem), "=r" (__res) > > > + : "=r" (__rem), "=r" (__res), "=r" (__n) > > > : "r" (__n), "r" (__base) > > > : "ip", "lr", "cc"); > > > *n = __res; > > > -- > > > 2.23.0 > > > > > > > Agree that using r0 as an input operand only is incorrect, and not > > only on Clang. The compiler might assume that r0 will retain its value > > across the asm() block, which is obviously not the case. However, you can _not_ have an asm block that names two outputs using the same physical register - that's why both the original patch and the posted v2 will fail. You also can't mark r0 as clobbered because it's used as an operand and that is not allowed by gcc. The fact is, we have two register variables occupying the same register, which are __n and __rem. It doesn't matter which endian-ness __rem is, r0 will be used for both __n (input) and __rem (output). If the compiler can't work out that if a physical register used as an output operand will be written by the assembler, then the compiler is quite simply buggy. The code is correct as it stands; Clang is buggy. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel