All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Gerst <brgerst@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Sedat Dilek <sedat.dilek@gmail.com>,
	stable <stable@vger.kernel.org>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	"kernelci . org bot" <bot@kernelci.org>,
	Andy Shevchenko <andriy.shevchenko@intel.com>,
	Ilie Halip <ilie.halip@gmail.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Marco Elver <elver@google.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Daniel Axtens <dja@axtens.net>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	clang-built-linux@googlegroups.com
Subject: Re: [PATCH] x86: bitops: fix build regression
Date: Thu, 7 May 2020 09:32:24 -0400	[thread overview]
Message-ID: <CAMzpN2iCgr0rb=MCYPGMx8tcfLq2qdzv0h7YnX5hkzBB+O7JJQ@mail.gmail.com> (raw)
In-Reply-To: <6A99766A-59FB-42DF-9350-80EA671A42B0@zytor.com>

On Thu, May 7, 2020 at 3:02 AM <hpa@zytor.com> wrote:
>
> On May 6, 2020 11:18:09 PM PDT, Brian Gerst <brgerst@gmail.com> wrote:
> >On Tue, May 5, 2020 at 1:47 PM Nick Desaulniers
> ><ndesaulniers@google.com> wrote:
> >>
> >> From: Sedat Dilek <sedat.dilek@gmail.com>
> >>
> >> It turns out that if your config tickles __builtin_constant_p via
> >> differences in choices to inline or not, 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".
> >>
> >> This is easily reproducible via
> >Clang+CONFIG_STAGING=y+CONFIG_VT6656=m,
> >> or Clang+allyesconfig.
> >>
> >> Keep the masking operation to appease sparse (`make C=1`), add back
> >the
> >> cast in order to properly select the proper 8b register alias.
> >>
> >>  [Nick: reworded]
> >>
> >> Cc: stable@vger.kernel.org
> >> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> >> Link: https://github.com/ClangBuiltLinux/linux/issues/961
> >> Link:
> >https://lore.kernel.org/lkml/20200504193524.GA221287@google.com/
> >> Fixes: 1651e700664b4 ("x86: Fix bitops.h warning with a moved cast")
> >> Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
> >> Reported-by: kernelci.org bot <bot@kernelci.org>
> >> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> >> Suggested-by: Ilie Halip <ilie.halip@gmail.com>
> >> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> >> Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
> >> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> >> ---
> >>  arch/x86/include/asm/bitops.h | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/bitops.h
> >b/arch/x86/include/asm/bitops.h
> >> index b392571c1f1d..139122e5b25b 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))
> >
> >I think a better fix would be to make CONST_MASK() return a u8 value
> >rather than have to cast on every use.
> >
> >Also I question the need for the "q" constraint.  It was added in
> >commit 437a0a54 as a workaround for GCC 3.4.4.  Now that the minimum
> >GCC version is 4.6, is this still necessary?
> >
> >--
> >Brian Gerst
>
> Yes, "q" is needed on i386.

I think the bug this worked around was that the compiler didn't detect
that CONST_MASK(nr) was also constant and doesn't need to be put into
a register.  The question is does that bug still exist on compiler
versions we care about?

--
Brian Gerst

  reply	other threads:[~2020-05-07 13:32 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 17:44 [PATCH] x86: bitops: fix build regression Nick Desaulniers
2020-05-05 18:07 ` hpa
2020-05-05 18:22   ` Nick Desaulniers
2020-05-07 11:34   ` Peter Zijlstra
2020-05-07 14:00     ` Brian Gerst
2020-05-07 19:19       ` Nick Desaulniers
2020-05-07 22:29         ` Nick Desaulniers
2020-05-08  1:57           ` Brian Gerst
2020-05-08 17:21             ` Nick Desaulniers
2020-05-08 17:31               ` H. Peter Anvin
2020-05-08 18:05                 ` [PATCH v3] " Nick Desaulniers
2020-05-08 18:08                   ` Nick Desaulniers
2020-05-08 18:22                   ` Brian Gerst
2020-05-08 18:28                     ` [PATCH v4] " Nick Desaulniers
2020-05-08 18:32                       ` [PATCH v5] " Nick Desaulniers
2020-05-08 20:28                         ` Nathan Chancellor
2020-05-08 23:47                           ` Jesse Brandeburg
2020-05-09  4:44                             ` Sedat Dilek
2020-05-09 12:20                         ` Andy Shevchenko
2020-05-09 15:43                           ` Brian Gerst
2020-05-11 17:22                           ` Nick Desaulniers
2020-05-10 13:54                         ` David Laight
2020-05-11 18:52                         ` Brian Gerst
2020-05-14 23:47                           ` Nick Desaulniers
2020-05-10 11:59                 ` [PATCH] " David Laight
2020-05-10 12:33                   ` hpa
2020-05-07 19:29     ` hpa
2020-05-06  4:30 ` Nathan Chancellor
2020-05-06  9:22   ` Sedat Dilek
2020-05-06 15:41   ` Nathan Chancellor
2020-05-06 16:37   ` Nick Desaulniers
2020-05-06 16:55     ` Ilie Halip
2020-05-06 17:05       ` [PATCH v2] " Nick Desaulniers
2020-05-07  6:18 ` [PATCH] " Brian Gerst
2020-05-07  7:02   ` hpa
2020-05-07 13:32     ` Brian Gerst [this message]
2020-05-07 15:09       ` David Laight
2020-05-07 19:31         ` hpa
2020-05-07 19:29       ` hpa
2020-05-07  7:44   ` David Laight
2020-05-07  7:59     ` hpa
2020-05-07  8:35       ` David Laight
2020-05-07  8:38         ` hpa
2020-05-07  9:17     ` Andy Shevchenko
2020-05-07 19:22   ` Nick Desaulniers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMzpN2iCgr0rb=MCYPGMx8tcfLq2qdzv0h7YnX5hkzBB+O7JJQ@mail.gmail.com' \
    --to=brgerst@gmail.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=bot@kernelci.org \
    --cc=bp@alien8.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dja@axtens.net \
    --cc=elver@google.com \
    --cc=hpa@zytor.com \
    --cc=ilie.halip@gmail.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=mingo@redhat.com \
    --cc=ndesaulniers@google.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sedat.dilek@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.