Add a workaround to prevent endless recursion in compiler-rt.

SPARC and MIPS CPUs don't have special instructions to count
leading/trailing zeroes. The compiler-rt library provides fallback
rountines for these. The 64-bit routines, __clzdi2 and __ctzdi2, are
implemented as simple wrappers around the compiler built-in
__builtin_clz(), assuming these will expand to either 32-bit
CPU instructions or calls to __clzsi2 and __ctzsi2.

Unfortunately, our GCC 4.2 probably thinks that because the operand is
stored in a 64-bit register, it might just be a better idea to invoke
its 64-bit equivalent, simply resulting into endless recursion. Fix this
by defining __builtin_clz and __builtin_ctz to __clzsi2 and __ctzsi2
explicitly.

1 files changed, 20 insertions, 0 deletions

diff --git a/contrib/compiler-rt/lib/int_lib.h b/contrib/compiler-rt/lib/int_lib.h
index a87426c..2328a1d 100644
--- a/contrib/compiler-rt/lib/int_lib.h
+++ b/contrib/compiler-rt/lib/int_lib.h
@@ -43,4 +43,24 @@
 /* Include internal utility function declarations. */
 #include "int_util.h"
 
+/*
+ * Workaround for LLVM bug 11663.  Prevent endless recursion in
+ * __c?zdi2(), where calls to __builtin_c?z() are expanded to
+ * __c?zdi2() instead of __c?zsi2().
+ *
+ * Instead of placing this workaround in c?zdi2.c, put it in this
+ * global header to prevent other C files from making the detour
+ * through __c?zdi2() as well.
+ *
+ * This problem has only been observed on FreeBSD for sparc64 and
+ * mips64 with GCC 4.2.1.
+ */
+#if defined(__FreeBSD__) && (defined(__sparc64__) || \
+    defined(__mips_n64) || defined(__mips_o64))
+si_int __clzsi2(si_int);
+si_int __ctzsi2(si_int);
+#define	__builtin_clz	__clzsi2
+#define	__builtin_ctz	__ctzsi2
+#endif
+
 #endif /* INT_LIB_H */