bitops.h: correctly handle rol32 with 0 byte shift
authorSasha Levin <sasha.levin@oracle.com>
Fri, 4 Dec 2015 03:04:01 +0000 (22:04 -0500)
committerSeung-Woo Kim <sw0312.kim@samsung.com>
Wed, 14 Dec 2016 04:50:55 +0000 (13:50 +0900)
commit409516a92418169e30e8f65ea71c9c6fba5e86fd
tree44c6563c516d81dcb48186eb39c126bf93460559
parenta3291e7200f9deab6ca77f44e89d279292a2a7c6
bitops.h: correctly handle rol32 with 0 byte shift

ROL on a 32 bit integer with a shift of 32 or more is undefined and the
result is arch-dependent. Avoid this by handling the trivial case of
roling by 0 correctly.

The trivial solution of checking if shift is 0 breaks gcc's detection
of this code as a ROL instruction, which is unacceptable.

This bug was reported and fixed in GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157):

The standard rotate idiom,

  (x << n) | (x >> (32 - n))

is recognized by gcc (for concreteness, I discuss only the case that x
is an uint32_t here).

However, this is portable C only for n in the range 0 < n < 32. For n
== 0, we get x >> 32 which gives undefined behaviour according to the
C standard (6.5.7, Bitwise shift operators). To portably support n ==
0, one has to write the rotate as something like

  (x << n) | (x >> ((-n) & 31))

And this is apparently not recognized by gcc.

Note that this is broken on older GCCs and will result in slower ROL.

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Backport from mainline to fix ubsan report]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I47fcb9807778615fff4972fa92dc7b3143e0ef3d
include/linux/bitops.h