__builtin_mul_overflow_p support with llvm 5.0

[Pádraig Brady]

Forwarding patch to gnulib where it would be adjusted/applied.

cheers,
Pádraig

[Paul Eggert]

Sorry, what's the context here?

In the past we've avoided having intprops.h depend on configure-time
checks and to some extent I suppose I'd rather continue in that
tradition, if only because that'll make it easier to fold into glibc one
of these days. Can you reformulate the patch so that it just uses
__has_attribute or __clang_major__ or whatever?

[Paul Eggert]

Post by Paul Eggert
Sorry, what's the context here?

Ah, I see it now, here:

https://github.com/coreutils/coreutils/issues/11

where Bernhard Rosenkränzer wrote:

"Our clang package is (intentionally) patched to return GNUC == 7 because clang
5.0 is closer to gcc 7.x than to any other version of gcc"

That's the problem. A goodly amount of GNU code assumes that if __GNUC__ is 5
then your compiler supports the features of GCC 5 or later, and similarly for
other values of __GNUC__. Since your implementation of Clang does not support
all relevant GCC 7 features, it should not define __GNUC__ to 7. So I suggest
reverting the patch that you mentioned.

This problem is not limited to the two Gnulib modules that you mention: it's in
several other places in GNU code. If you can't fix your compiler, you can work
around the problem by running 'configure' with something like the following command:

./configure CC=clang CFLAGS='-U__GNUC__ -D__GNUC__=4'

Since you already are invoking 'configure' with special options, it shouldn't be
much trouble to add another option to work around this problem with your compiler.