<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:ndesaulniers@google.com" title="Nick Desaulniers <ndesaulniers@google.com>"> <span class="fn">Nick Desaulniers</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - __int128_t multiply with -fsanitize=undefined fails to link (undefined reference to __muloti4)"
href="https://bugs.llvm.org/show_bug.cgi?id=16404">bug 16404</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>craig.topper@gmail.com, ndesaulniers@google.com
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>REOPENED
</td>
<td>RESOLVED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - __int128_t multiply with -fsanitize=undefined fails to link (undefined reference to __muloti4)"
href="https://bugs.llvm.org/show_bug.cgi?id=16404#c30">Comment # 30</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - __int128_t multiply with -fsanitize=undefined fails to link (undefined reference to __muloti4)"
href="https://bugs.llvm.org/show_bug.cgi?id=16404">bug 16404</a>
from <span class="vcard"><a class="email" href="mailto:ndesaulniers@google.com" title="Nick Desaulniers <ndesaulniers@google.com>"> <span class="fn">Nick Desaulniers</span></a>
</span></b>
<pre>I fixed the bug in the initial report in
d0eeb64be5848a7832d13db9d69904db281d02e8 / <a href="https://reviews.llvm.org/D108928">https://reviews.llvm.org/D108928</a> in
clang-14. So closing this as resolved/fixed.
That said, it's kind of tragic from a code size perspective that we can't use
these compiler-rt-only symbols.
It's also tragic IMO that clang doesn't use LLVM's own compiler runtime (or
linker for that matter) by default. And because it doesn't, there's less
incentive to ever get those working for a platform; if we can just depend on
libgcc (or ld64), why put any effort into compiler-rt (or LLD) for those
platforms?
Part of me thinks it would be nice to still emit libcalls to mulodi/muloti and
friends for platforms that do currently link against compiler-rt. To do that,
LLVM would need knowledge of which compiler runtime was being linked against.
Clang knows this (ToolChain::GetRuntimeLibType and
ToolChain::GetDefaultRuntimeLibType are used to make code gen decisions in
clang), but LLVM doesn't AFAICT. Perhaps we should have module level IR for
this that clang can set? Then LLVM can make better code gen decisions? The one
thing I haven't checked yet is whether one can specify something like `clang
-rtlib=compiler-rc -c foo.c` but then invoke the linker with a different
compiler library? I assume that that's possible; otherwise I don't see how you
could build a shared object that could work with either runtimes. So is clang
wrong to make such checks?
Should muloti/mulodi just be deleted from compiler-rt? At the least, we should
file a feature request for libgcc to add these.
Another part of me thinks it would be nice to switch the default compiler
runtime to compiler-rt for clang, and encourage platforms to get their compiler
runtimes working with compiler-rt. Is having the compiler builtins separated
from the reset of compiler-rt interesting? Perhaps. That feels orthogonal to
the above point about module level IR, and not a yak I intend to shave.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>