avoid undefined behaviour when n==0

ISO/IEC 9899:1999 section 6.5.7 states that "If the value of the right
operand is negative or is greater than or equal to the width of the
promoted left operand, the behavior is undefined".  So we have to take
care of such situations.

This has not been a problem because contemporary C compilers are
extraordinary smart to compile the series of shifts into a single
ROTLQ/ROTRQ machine instruction.  In contrast to what C says those
instructions have fully defined behaviour for all possible inputs.
Hence it has been quite difficult to observe the undefined-ness of such
situations.  But undefined is undefined.  We should not rely on such
target-specific assumptions.

We are fixing the situation by carefully avoiding shifts with out-of-
range values.  At least GCC since 4.6.3 and Clang since 8.0 can issue
the exact same instructions like before the changeset.

Also in case of Intel processors, there supposedly be intrinsics named
_rotr/_rotl that do exactly what we need.  They, in practice, are absent
on Clang before 9.x so we cannot blindly use.  But we can at least save
MSVC.

See also:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157
https://bugs.llvm.org/show_bug.cgi?id=17332

1 files changed, 1 insertions, 0 deletions

diff --git a/configure.ac b/configure.ac
index 55b2d93eae..548849d612 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1104,6 +1104,7 @@ AC_CHECK_HEADERS(syscall.h)
 AC_CHECK_HEADERS(time.h)
 AC_CHECK_HEADERS(ucontext.h)
 AC_CHECK_HEADERS(utime.h)
+AC_CHECK_HEADERS(x86intrin.h)
 
 AC_ARG_WITH([gmp],
   [AS_HELP_STRING([--without-gmp],