Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp6137312ybv; Tue, 18 Feb 2020 10:38:00 -0800 (PST) X-Google-Smtp-Source: APXvYqyuAqZTm2Mf0UKJTDp1wx/FsxNF2ApUr+YAfscNpoGaW3qCvjz+dJkb/O5NW7Att6oSo/6m X-Received: by 2002:a9d:7c99:: with SMTP id q25mr17101435otn.105.1582051079862; Tue, 18 Feb 2020 10:37:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582051079; cv=none; d=google.com; s=arc-20160816; b=WUYM1zSRnoL9hVlQ5XLXapa2iPXMkRoWVNBRtMgpDdaAyynPUvhgbtNcejQEmM3TF6 gohyyeY2rVF2j0iccK3G5btfe6TsaSvwzvdmxpfDG3Z4Ou0ZStRDVcVi6svYBLAA9aHg zy06n4DyxmplvoD59f+1qoTc3UJWfeXNokN7TzVDe/ZG1QO/J5kqCh1RPvKxfyIp2IgL wVmNGrTeb99P1meF4YoVSY8a44ST73bKlmFUaFVgQsOuUDVbtucNUnsi5kB2+at782Fj 1FibJV5MPIMPCEVfvfnoEKlPo4yNyfkXMOab6gKPJd4JwSfX/Snrql+cULcaYwywZAN1 1rpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ccXZcPHgblgsQ7szhI146C2Fb020S8Uq8EN9Auab0l4=; b=Z27ea41rm/1z+/77qJ7FveXZY0NsDL4o56ApAijIuUQdco31NoKqA70g/YsnE/h3of rCzqaLbs0goVLqLoGmmpNicfpofwcRZcFpI+jFeG3/hEqK8J9SF7NigMtCy0b2btEwqH 2E1lA3ngSKGF3b9bRA7H5qWfrRxV1h6IyXX36xiqdDDRsi6wfBb7kOrnt4qDmhi7w+uH ddRerPsATgHZ3awvfYlqdjsJHDY19R3bZqlDtjFUuGchpJ+MrqYEguVfUVFADYqsaHGG n9sSn+v0T19bHIfPE3ldIEByvh6x0nzmZ3z6z2stnmZ+aK4YqplMGFEX510iHuDb6up/ bsUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WuPXMTek; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t4si2010695otc.160.2020.02.18.10.37.47; Tue, 18 Feb 2020 10:37:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=WuPXMTek; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726477AbgBRShN (ORCPT + 99 others); Tue, 18 Feb 2020 13:37:13 -0500 Received: from mail-pl1-f193.google.com ([209.85.214.193]:34643 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726296AbgBRShM (ORCPT ); Tue, 18 Feb 2020 13:37:12 -0500 Received: by mail-pl1-f193.google.com with SMTP id j7so8426588plt.1 for ; Tue, 18 Feb 2020 10:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ccXZcPHgblgsQ7szhI146C2Fb020S8Uq8EN9Auab0l4=; b=WuPXMTeklZQs1oW0RE5IlOhPNzD6lbppOClBV6i0Ns8aeFerqCD3HXxAL6SQmOZv5L T1Eztw2uppZlUEDdP+rbVrNRHxUhjrKsSs3AYg+rGVsfuBrs/+X5YDGxx4LHJQzsRqEU FBb/sBVAkLgg1I8GCSI03WSVMahh9xEo0IikKesZX34MbFAvkVxQel80aQeoKFjuo339 hbVA3VFfaCseBdGYbE8pwDZZFc09cCdr7DmcEKrbGhCYfEnjZtWDNRPGSoZ193bniHrY Y81NQnOo5edZ5MgDyG67f51BmuzxhIYka3sK4u0x/GkWRGLkrePBhKz8RLGRvUon9yC9 Yg5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ccXZcPHgblgsQ7szhI146C2Fb020S8Uq8EN9Auab0l4=; b=WsdX+xvQeCzh2t9wg1l8JwKanIOWb/+ie/3Z9iNXo3maK45roxfkETwnw4S0D5Cumx pfMynT47h48g2E2Vydt7eYldDYJ89vNxbBu237mEkwgkY9iC/QZztgWiyaU+VEc8fPGn LLqCCRy89ZccnFHhtvQszHMpXiWk8V3ZyTEIfsOc8+WoHGzC9yutiW0NIzQoPaw3LS1+ yFFHBe0NkwpeoB28YqTqm3f6WfsF2sWsueJXAKF54wUI6W3M1DuyS/+Afe6asikKZMiN 2LubLRBq3ka06n6W78DxleVwTgjgEUngbUB0JAr7cN5z2A0Dqqj2vmdGsAcq/R/VrI9I tB+w== X-Gm-Message-State: APjAAAXa8znb8oPRgoLTVRifr4Y869g8wpn1hB0dVfKTj2OqenQEWqXk zSPsAh9WbLah2uopsmOKUWV9oKqxIWFE5WoWtgXcvfve2Jk= X-Received: by 2002:a17:902:760e:: with SMTP id k14mr20968051pll.119.1582051031642; Tue, 18 Feb 2020 10:37:11 -0800 (PST) MIME-Version: 1.0 References: <20200211212455.3307-1-mark.tomlinson@alliedtelesis.co.nz> <8e852d84c8b0c6b35faa3b3f2a1034d93a6e8967.camel@alliedtelesis.co.nz> <8cb14684e2f774d9573c062f2d82ad5348c5fee7.camel@alliedtelesis.co.nz> In-Reply-To: <8cb14684e2f774d9573c062f2d82ad5348c5fee7.camel@alliedtelesis.co.nz> From: Nick Desaulniers Date: Tue, 18 Feb 2020 10:37:00 -0800 Message-ID: Subject: Re: [PATCH] MIPS: cavium_octeon: Fix syncw generation. To: Chris Packham Cc: Mark Tomlinson , "f4bug@amsat.org" , "linux-kernel@vger.kernel.org" , "clang-built-linux@googlegroups.com" , "paulburton@kernel.org" , "linux-mips@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 17, 2020 at 12:01 PM Chris Packham wrote: > > On Mon, 2020-02-17 at 17:58 +1300, Mark Tomlinson wrote: > > Hi Phil, > > > > On Mon, 2020-02-17 at 01:22 +0100, Philippe Mathieu-Daud=C3=A9 wrote: > > > Hi Mark, > > > > > > On Tue, Feb 11, 2020 at 10:42 PM Mark Tomlinson > > > wrote: > > > > > > > > The Cavium Octeon CPU uses a special sync instruction for implement= ing > > > > wmb, and due to a CPU bug, the instruction must appear twice. A mac= ro > > > > had been defined to hide this: > > > > > > > > #define __SYNC_rpt(type) (1 + (type =3D=3D __SYNC_wmb)) > > > > > > > > which was intended to evaluate to 2 for __SYNC_wmb, and 1 for any o= ther > > > > type of sync. However, this expression is evaluated by the assemble= r, > > > > and not the compiler, and the result of '=3D=3D' in the assembler i= s 0 or > > > > -1, not 0 or 1 as it is in C. The net result was wmb() producing no= code > > > > at all. The simple fix in this patch is to change the '+' to '-'. > > > > > > Isn't this particular to the assembler implementation? > > > Can you explicit the assembler you are using in the commit descriptio= n? > > > Assuming we have to look at your commit in 3 years from now, we'll > > > wonder what assembler you were using. > > > > > > Thanks, > > > > > > Phil. > > > > Yes, it is tied to the assembler. But the Linux kernel is tied to GCC, > > and GCC (I believe) is tied to GNU as. I can't see the specification of > > GNU as changing, since that could break anything written for it. > > > > There is an effort underway to build the kernel with clang[1]. I'm not > sure what that ends up using for an assembler or if it'll even be able > to target mips64 anytime soon. > > For reference the relevant section from the GNU as manual[2] says "A > true results has a value of -1 whereas a false result has a value of > 0". > > [1] - https://clangbuiltlinux.github.io/ > [2] - https://sourceware.org/binutils/docs/as/Infix-Ops.html#Infix-Ops Chris, thanks for CC'ing us. Mark, we're building 32 bit MIPS kernels with Clang under CI (just added big endian builds this morning). We're actively looking into supporting 64b MIPS. The kernel uses GCC by default, but supports using any compiler via `make CC=3D`. There is extensive support in the kernel for building with Clang. GCC and Clang (when doing kernel builds, for clang we set `-no-integrated-as`) will invoke GAS for inline assembly, but you can set `AS=3Dclang` for example for the out of line assembly files. If the C source files don't contain inline assembly (or `-no-integrated-as` wasn't set) then Clang will skip invoking the assembler and stream out an object file. If you're actively supporting 64b mips, and want to give a Clang build a try, we'd appreciate the bug reports: https://github.com/ClangBuiltLinux/linux/issues --=20 Thanks, ~Nick Desaulniers