lkml.org 
[lkml]   [2016]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: linux/bitops.h
    From
    On Wed, May 4, 2016 at 5:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
    >
    > Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, and the
    > description even says so.
    >
    > As I said, gcc has treated the former code as idiomatic since gcc 2, so that
    > support is beyond ancient.

    Well, we're *trying* to get clang supported, so the argument that gcc
    has always supported it and compiles correct code for it is not
    necessarily the whole story yet.

    The problem with "32 - shift" is that it really could generate garbage
    in situations where shift ends up being a constant zero..

    That said, the fact that the other cases weren't changed
    (rol64/ror64/ror32) does make that argument less interesting. Unless
    there was some particular code that actively ended up using
    "rol32(..0)" but not the other cases.

    (And yes, rol32(x,0) is obviously nonsense, but it could easily happen
    with inline functions or macros that end up generating that).

    Note that there may be 8 "rol/ror" functions, but the 16-bit and 8-bit
    ones don't have the undefined semantics. So there are only four that
    had _that_ problem, although I agree that changing just one out of
    four is wrong.

    Linus

    \
     
     \ /
      Last update: 2016-05-05 03:01    [W:4.120 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site