bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: __builtin_add_overflow on clang


From: Mattias Engdegård
Subject: Re: __builtin_add_overflow on clang
Date: Tue, 27 Aug 2019 12:33:10 +0200

26 aug. 2019 kl. 04.40 skrev Paul Eggert <address@hidden>:
> 
> The reason I patched Gnulib in 2017 to work around the Clang bug:
> 
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=04441fd8156978cfc51d6c203fd43c23b64f95df
> 
> was in response to a private bug report for GNU 'sed' builds from Nelson H.F. 
> Beebe, who reported finding the Clang bug on these platforms:
> [...]
> These failures occurred with ordinary integer types, as sed doesn't use 
> 128-bit types.

__builtin_mul_overflow(long long) does expand to a call to __mulodi4 when 
building for 32-bit x86 even with current Clang; either this function is absent 
from libgcc and these platforms do not link to compiler-rt, or their 
compiler-rt is somehow built without it. The former seems more likely.
Did the bug report include any Clang/LLVM version information?

> Given the prevalence of this Clang bug, and the iffiness of whether the bug 
> might occur on macOS or FreeBSD, I was cautious and stuck with the fallback 
> code for Clang. However, now that you mention it this problem seems limited 
> to multiplication and it's easy to change intprops.h to use Clang's 
> __builtin_add_overflow and __builtin_sub_overflow even if its 
> __builtin_mul_overflow is buggy. So I installed the attached patch into 
> Gnulib to do that.

Thank you very much, and I can confirm that it builds and links with Apple 
Clang 10.0.1 for x86-64, which is the most recent standard macOS compiler.

(For some reason, this compiler generates less efficient code for 
__builtin_mul_overflow(__uint128_t), including a call to __udivti3, than 
vanilla clang ≥ 8.0 which produces fairly short branchless code. It does seem 
to be correct, though.)

> If we definitely know that this bug cannot occur on FreeBSD and/or macOS, I 
> suppose we could add further tests on the appropriate preprocessor macros. 
> But that would require further investigation as to what packages are 
> available in these platforms and whether the relevant clang runtimes can be 
> installed separately.

We can safely assume that macOS will use compiler-rt by default rather than 
libgcc; it seems likely that FreeBSD would do that as well but it would have to 
be verified.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]