Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp967058ybj; Tue, 5 May 2020 10:31:21 -0700 (PDT) X-Google-Smtp-Source: APiQypIyj5PQs0cmA+Hd7YoPNC92+kvqeZ9ltwFStQU76wVaMa0P8z8iemFwhpTKGPoVLXBJ/RCy X-Received: by 2002:a05:6402:1773:: with SMTP id da19mr3621235edb.2.1588699881751; Tue, 05 May 2020 10:31:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588699881; cv=none; d=google.com; s=arc-20160816; b=Qm89Qdk/MjH+a/uanWjW2WdHeJPpcUyWvbeVAzCNSUcsqCnurVC7UfVLWD7VrZuhrK Z/UN3phz7NDkzq+hwuUj+N2dljyS+sgD6CEElS02uJulLEK027mUdSkHpFORxdArAEm9 h3PU23+tAeNVqaiEq8J72QiGW/Ves5SP8Pit5JJlry2MS9x8bnJJ3ZtD4i9NetYIW/j0 9Rf5n3Q3CQTc6U2vi3CjVZYcrANSzGKh8Meq22jzaiavH2oUk0pqvcRbkbgIItOEPXFA RgKXYByexONsemJ3thkCjJngE7hiQAojryhRk2QHrmhWzrvFpagGEjauOWRcNapv7C7i /srA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kHcXHJ8ma+wHdOnq6wbVgZKgLxUnEELMmnMVXInJOCs=; b=FAtWX1LyyH+dGefQc38ajGNAiTeRC6UapMgzV5ZzGHdVoHq+lm7O0c/pcmYHoChJiI gqqunpaMAUUgjtHhX5QOY56r8SCNROla7JnjZYJh9CBFF26rHBfGIA+Ybx2uJacZ0MIY vaoaQOlEBw+uaWaTfVjATz2sS97rdiy43xcH3kLADQfyGO/pGrC1Ms1tzeIp0hui/clY gFITsmpFUfvZzSyavJ9wOxdx0t+E+9GSZEARq7YKJ9QECpGb4Xn21ph4KjEiaKNzrYyc XUYwovFFwdmzV889iAenyVV9K5vM5gcyrBMPdK5o1S+ntQyj1H6w7uThs2sQ0kyoCiar TU+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QFxgVVwU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id e8si1548093ejd.76.2020.05.05.10.30.57; Tue, 05 May 2020 10:31:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QFxgVVwU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1730215AbgEER3N (ORCPT + 99 others); Tue, 5 May 2020 13:29:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726350AbgEER3N (ORCPT ); Tue, 5 May 2020 13:29:13 -0400 Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D250C061A0F for ; Tue, 5 May 2020 10:29:13 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id z6so1088433plk.10 for ; Tue, 05 May 2020 10:29:13 -0700 (PDT) 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; bh=kHcXHJ8ma+wHdOnq6wbVgZKgLxUnEELMmnMVXInJOCs=; b=QFxgVVwUcZjMbp8kD9oXT7EVHZUxsKuReDdqqKCVYXKWf2hOOValeougGSA5KojQjm HnYyb3Tyc3cKTJWNmy0j/kkImorKLiZ2MATkWbxwum7sPvSyLLDLWXSV9xQBRsjNhvCk nkO8uDEhaLjHQ2jYdj9Am4WKZdnV2O0cGHsVVzWetCni3Oe/GE+9Fc6IZOR+fAwGiq6U S3ex4fNAZ9fTplxoRFobYUBamjeiU+5zOMzEOz32x9o4k1kmvdKS6T8bSAtvyUcKDSr5 2cQWBcNp6g4IBkT4d1XhVdhUf5o0mHUAnJLqxH2kl/V9Rm4RZ0YBzMz8uGcP2/Jmx231 RfvQ== 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; bh=kHcXHJ8ma+wHdOnq6wbVgZKgLxUnEELMmnMVXInJOCs=; b=ZvrmCKOWZU5NTOYXOJneSLziTTIYQwMglVVFz6kQXihbS50bNR8ScWSTTXzm47cmER 7ZDgUR8vq2k2Hm7twfod4gWp3Z19DkbTD+7X0Qh+jfEazwlcjGHvNIVW+JCD7KWx1IDY rHi9Ghwi3ovl9OgAa8tt33owQfU1e17TLjlcsZ7o76uJNn+s6tXaVDMZJbHQcAZkyFCF a0gVTBD6iWR7G5VRFB/1FJROUKAnxfXkyeSmbFbK9lVC+qnMU7q58vjuAyyx8XwOW4yb JH80hGwHMPZ2+NKBbVrmLLaIy2WCRpNcbV51fa2FvfpEvlnuR/QFwf52H3Nw4awdxVcF FqfQ== X-Gm-Message-State: AGi0PubQ8H6dXK2fMINMMKW9G0W3GsF2yVhA7F6uqUL6A2w6CY+jcD2U 9SfP67Yf9PbCKf80wY8DM2OSHH3EyUHZ0UK1jW/sCw== X-Received: by 2002:a17:90a:6488:: with SMTP id h8mr4415749pjj.51.1588699752126; Tue, 05 May 2020 10:29:12 -0700 (PDT) MIME-Version: 1.0 References: <20200310221747.2848474-1-jesse.brandeburg@intel.com> <20200504193524.GA221287@google.com> <20200504181443.00007a3d@intel.com> <20200505151438.GP185537@smile.fi.intel.com> In-Reply-To: <20200505151438.GP185537@smile.fi.intel.com> From: Nick Desaulniers Date: Tue, 5 May 2020 10:29:01 -0700 Message-ID: Subject: Re: [PATCH v6 1/2] x86: fix bitops.h warning with a moved cast To: Andy Shevchenko Cc: Jesse Brandeburg , clang-built-linux , Borislav Petkov , Dan Williams , LKML , Rasmus Villemoes , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Ilie Halip , Nathan Chancellor , Sedat Dilek Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 5, 2020 at 8:14 AM Andy Shevchenko wrote: > > On Mon, May 04, 2020 at 06:14:43PM -0700, Jesse Brandeburg wrote: > > On Mon, 4 May 2020 12:51:12 -0700 > > Nick Desaulniers wrote: > > > > > Sorry for the very late report. It turns out that if your config > > > tickles __builtin_constant_p just right, this now produces invalid > > > assembly: > > > > > > $ cat foo.c > > > long a(long b, long c) { > > > asm("orb\t%1, %0" : "+q"(c): "r"(b)); > > > return c; > > > } > > > $ gcc foo.c > > > foo.c: Assembler messages: > > > foo.c:2: Error: `%rax' not allowed with `orb' > > > > > > The "q" constraint only has meanting on -m32 otherwise is treated as > > > "r". > > > > > > Since we have the mask (& 0xff), can we drop the `b` suffix from the > > > instruction? Or is a revert more appropriate? Or maybe another way to > > > skin this cat? > > > > Figures that such a small change can create problems :-( Sorry for the > > thrash! > > > > The patches in the link below basically add back the cast, but I'm > > interested to see if any others can come up with a better fix that > > a) passes the above code generation test > > b) still keeps sparse happy > > c) passes the test module and the code inspection > > > > If need be I'm OK with a revert of the original patch to fix the issue > > in the short term, but it seems to me there must be a way to satisfy > > both tools. We went through several iterations on the way to the final > > patch that we might be able to pluck something useful from. > > For me the below seems to work: Yep: https://github.com/ClangBuiltLinux/linux/issues/961#issuecomment-623785987 https://github.com/ClangBuiltLinux/linux/issues/961#issuecomment-624162497 Sedat wrote the same patch 22 days ago; I didn't notice before starting this thread. I will sign off on his patch, add your Suggested by tag, and send shortly. > > > diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h > index b392571c1f1d1..139122e5b25b1 100644 > --- a/arch/x86/include/asm/bitops.h > +++ b/arch/x86/include/asm/bitops.h > @@ -54,7 +54,7 @@ arch_set_bit(long nr, volatile unsigned long *addr) > if (__builtin_constant_p(nr)) { > asm volatile(LOCK_PREFIX "orb %1,%0" > : CONST_MASK_ADDR(nr, addr) > - : "iq" (CONST_MASK(nr) & 0xff) > + : "iq" ((u8)(CONST_MASK(nr) & 0xff)) > : "memory"); > } else { > asm volatile(LOCK_PREFIX __ASM_SIZE(bts) " %1,%0" > @@ -74,7 +74,7 @@ arch_clear_bit(long nr, volatile unsigned long *addr) > if (__builtin_constant_p(nr)) { > asm volatile(LOCK_PREFIX "andb %1,%0" > : CONST_MASK_ADDR(nr, addr) > - : "iq" (CONST_MASK(nr) ^ 0xff)); > + : "iq" ((u8)(CONST_MASK(nr) ^ 0xff))); > } else { > asm volatile(LOCK_PREFIX __ASM_SIZE(btr) " %1,%0" > : : RLONG_ADDR(addr), "Ir" (nr) : "memory"); > > > -- > With Best Regards, > Andy Shevchenko > > -- Thanks, ~Nick Desaulniers