Created attachment 15150 [details] Build with: clang-cl main.c While attempting to build a (very) old version of libtomcrypt with Clang-cl (64-bit r250698), it appears a call to an undefined function is being generated: main-ff9827.obj : error LNK2019: unresolved external symbol __udivti3 referenced in function main I've attached a minimal reproduce case. This appears to be due to the "__attribute__((mode(TI)))" on the typedef.
mode(TI) is a gcc extension. Therefore you need to link with libgcc / compiler_rt.
Is this true under Windows as well? The default installation of LLVM (through the installer provided at llvm.org/builds) doesn't seem to supply either libgcc or compiler_rt. From a user standpoint there doesn't seem to be anything I can link against under Windows to resolve this.
Very rarely do you need compiler-rt. I think you can trigger the reference a different way, something like this with -fms-extensions: __int128 mydiv(__int128 a, __int128 b) { return a / b; } I bet we still generate the call to compiler-rt. If the MSVC CRT has a reliably available libcall (going back to VC 6.0 in MSVCRT.dll), then we could call it instead of the libgcc version. If not, I'd recommend building compiler-rt. It isn't normally required.
(In reply to Reid Kleckner from comment #3) > If the MSVC CRT has a reliably available libcall (going back to VC 6.0 in > MSVCRT.dll), then we could call it instead of the libgcc version. If not, > I'd recommend building compiler-rt. It isn't normally required. But even with projects/compiler-rt built (alongside llvm itself and tools/clang), `clang-cl main.c` still cannot resolve __udivti3, and I cannot spot any .lib in the installation tree that would provide it. (On recent trunk towards LLVM 6.)
I'm currently hitting this exact same bug while compiling the a project that makes use of libTomMath v0.41
Hello there, As far as I can tell, running strings on "C:\Program Files\LLVM\lib\clang\6.0.1\lib\windows\clang_rt.builtins-x86_64.lib" seems to indicate udivti3 should be linked in from udivti3.c.obj. However, running DUMPBIN /SYMBOLS on the said file only lists the udivsi3 function. What's the proper way to request the 128b variants are linked are not optimized out or compiled out of clang_rt.builtins-x86_64.lib ? Thank you
Per conversation with @rnk, I'll see if the driver can be convinced to include the right compiler-rt files.
This has come up again in https://bugs.llvm.org/show_bug.cgi?id=28629. I think Renato's comment here is highly relevant: https://github.com/ClangBuiltLinux/linux/issues/1438#issuecomment-907689836.
We'll want to do something similar to this list of commits: https://bugs.llvm.org/show_bug.cgi?id=28629#c23.
(In reply to Nick Desaulniers from comment #9) > We'll want to do something similar to this list of commits: > https://bugs.llvm.org/show_bug.cgi?id=28629#c23. Its a quite a bit more complicated than that. We need to generate a inline division implementation, but that requires loops that SelectionDAG can't create. We likely need a pre-SelectionDAG IR pass that expands the unsupported division.