[Responding to https://github.com/coreutils/coreutils/issues/11 and
CC'ing to bug-coreutils.]
Thanks for the heads-up. That's odd, as I just looked at the LLVM source
code, and cfe-5.0.0.src/lib/Frontend/InitPreprocessor.cpp defines
__GNUC__ to 4, whereas Coreutils (via Gnulib) doesn't use
__builtin_mul_overflow_p unless __GNUC__ is at least 7.
To help debug this, what is the value of __GNUC__ on your platform? For
example, what is the output of the following shell command?
echo __GNUC__ | /usr/bin/clang -E -
and what happens if you append this line to lib/mbsstr.c
"__GNUC__" __GNUC__
and then run this (long, one-line) command:
/usr/bin/clang -E -I. -I./lib -Ilib -I./lib -Isrc -I./src -Os -gdwarf-4
-Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
-fstack-protector --param=ssp-buffer-size=4 -fPIC -flto -fPIC -D_GNU_SOURCE=1
lib/mbsstr.c >lib/mbsstr.i
and look at the last few lines of lib/mbsttr.i?
On Fedora 26, which has clang version 4.0.1 (tags/RELEASE_401/final), these
commands say that __GNUC__ is 4, which is what I would expect.
Also, does the attached patch to lib/intprops.h work around the problem?
diff --git a/lib/intprops.h b/lib/intprops.h
index 2052ceec0..6099664e3 100644
--- a/lib/intprops.h
+++ b/lib/intprops.h
@@ -226,7 +226,7 @@
#endif
/* True if __builtin_add_overflow_p (A, B, C) works. */
-#define _GL_HAS_BUILTIN_OVERFLOW_P (7 <= __GNUC__)
+#define _GL_HAS_BUILTIN_OVERFLOW_P (7 <= __GNUC__ && !defined __clang__)
/* The _GL*_OVERFLOW macros have the same restrictions as the
*_RANGE_OVERFLOW macros, except that they do not assume that operands
