Clang-cl generates a call to an undefined symbol __udivti3

[llvmbot]

Bugzilla Link	25305
Version	trunk
OS	Windows NT
Blocks	#48113
Attachments	Build with: clang-cl main.c
Reporter	LLVM Bugzilla Contributor
CC	@amccarth-google,@asl,@compnerd,@topperc,@RKSimon,@nickdesaulniers,@rengolin,@rnk,@stbergmann,@yurybura

Extended Description

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.

[llvmbot]

assigned to @amccarth-google

[asl]

mode(TI) is a gcc extension. Therefore you need to link with libgcc / compiler_rt.

[llvmbot]

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.

[rnk]

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.

[stbergmann]

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

[llvmbot]

I'm currently hitting this exact same bug while compiling the a project that makes use of libTomMath v0.41

[llvmbot]

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

[amccarth-google]

Per conversation with @​rnk, I'll see if the driver can be convinced to include the right compiler-rt files.

[nickdesaulniers]

This has come up again in llvm/llvm-bugzilla-archive#28629 . I think Renato's comment here is highly relevant: ClangBuiltLinux/linux#1438 (comment).

[nickdesaulniers]

We'll want to do something similar to this list of commits: llvm/llvm-bugzilla-archive#28629 #c23.

[topperc]

We'll want to do something similar to this list of commits:
llvm/llvm-bugzilla-archive#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.

[GabrielRavier]

mentioned in issue #48113

[h-vetinari]

Looking at the status of this, I think it's worth noting that the last update was actually in #26142 (Should clang-cl require compiler-rt?), where @rnk said:

This continues to come up, and I think we want the answer to be yes, we just need to make it happen.

Let's say this is a Duplicate of #25679.

Any update on this effort? I'm hitting this issue while trying to build flang on windows.

[rnk]

Specifically, I think we ought to implement this by emitting /defaultlib:clang_rt.builtins.${arch}.lib directives in the object file, so that we auto-link compiler-rt transparently. Bonus points if we only emit the directive when we need these runtime functions.

Separately, folks have been talking about teaching lld-link to find clang runtime libraries by searching relative to argv[0]. That would make this more seamless.

[zmodem]

Separately, folks have been talking about teaching lld-link to find clang runtime libraries by searching relative to argv[0]. That would make this more seamless.

+@tru for that.

It would be amazing to finally get this fixed.

[tru]

Yes - I have started working on this! Stay tuned.

[h-vetinari]

Yes - I have started working on this! Stay tuned.

Hey @tru, just a gentle question about the status of this. I'm hitting some likely related issues about the different runtime-libraries when test-driving flang on windows.

[flriancu]

Hi @tru @h-vetinari, are there any updates on this issue? I encountered it when attempting to build flang for windows x86_64 using the latest commit on main at the time of writing: 79682c4

[h-vetinari]

For flang specifically, it should be fixed by #110217, see here. For the general case, there was some discussion on discourse here and here, though I'm not aware that anything else happened since then.

[flriancu]

@h-vetinari It appears it's not yet fixed as of commit cfc6dbe9. I'm using the following commands, though I pieced them together from various Github comments so they might not be correct:

cmake -S llvm -B build-release -G Ninja -DLLVM_ENABLE_PROJECTS="clang;flang" -DLLVM_TARGETS_TO_BUILD=Native -DCMAKE_BUILD_TYPE=Release -DLLVM_INSTALL_TOOLCHAIN_ONLY=ON -DLLVM_HOST_TRIPLE=x86_64
cmake --build build-release --target flang

The very last ninja task fails:

[3881/3881] Linking CXX executable bin\flang.exe
FAILED: bin/flang.exe
[...]
lld-link: error: undefined symbol: __udivti3

On my machine, cmake is using Clang 19.1.3 with GNU-like command-line.

Edit: If my understanding is correct, I've just realized this might not apply to this ticket, as it's not about clang-cl (which has MSVC-like command-line syntax)

Edit 2: All good with clang-cl. the #110217 branch builds without any issues.

[rnk]

I believe we haven't done anything systematic to simplify linking clang_rt.builtins into applications build with clang-cl, so I believe this issue is still open and active. I may find time to work on this in the new year.