26 aug. 2019 kl. 04.40 skrev Paul Eggert <[email protected]>: > > 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.
