From 13064fe5db237872fcb9dfafb05cbdf2ddd07e07 Mon Sep 17 00:00:00 2001 From: 卜部昌平 Date: Thu, 9 Jan 2020 16:50:59 +0900 Subject: 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 --- configure.ac | 1 + 1 file changed, 1 insertion(+) (limited to 'configure.ac') 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], -- cgit v1.2.3