lkml.org 
[lkml]   [2020]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] x86: bitops: fix build regression
    From
    On May 7, 2020 6:32:24 AM PDT, Brian Gerst <brgerst@gmail.com> wrote:
    >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

    The compiler is free to do that, including for legit reasons (common subexpression elimination, especially.) So yes.
    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.

    \
     
     \ /
      Last update: 2020-05-07 21:31    [W:3.764 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site