[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.