float128 builtins are currently not built for x86_64.
This causes linker to complain baout missing symbols when linking
glibc 2.27 with float128 support.
Details
- Reviewers
efriedma joerg manojgupta
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lib/builtins/fp_lib.h | ||
---|---|---|
111 ↗ | (On Diff #170743) | You need to guard this with an ifdef; clang doesn't supports __float128 on every target, even if long double is an 128-bit IEEE float. For reasons I don't really understand, there are apparently two different macros for this; #if defined(__FLOAT128__) || defined(__SIZEOF_FLOAT128__) should do the right thing. |
lib/builtins/fp_lib.h | ||
---|---|---|
111 ↗ | (On Diff #170743) | Thanks Eli. I also found out that GCC 4.9 does not seem to have these defined even though it supports __float128. |
I am also getting these tests failures because of missing trunctfxf2 and extendxftf2. These are provided by libgcc but compiler-rt does not seem to have an implementation for them.
Builtins-x86_64-linux :: compiler_rt_logbl_test.c Builtins-x86_64-linux :: divtc3_test.c Builtins-x86_64-linux :: floattitf_test.c Builtins-x86_64-linux :: floatuntitf_test.c
compiler_rt_logbl_test.c:26: error: undefined reference to 'trunctfxf2'
compiler_rt_logbl_test.c:26: error: undefined reference to 'extendxftf2'
__extendxftf2 and __trunctfxf2 are for conversions between x86 long double and __float128; you'll need to write implementations yourself. (That should be a separate patch.)
Thanks Eli. I also found out that GCC 4.9 does not seem to have these defined even though it supports __float128.
gcc 5 has the define; that's good enough.
Missing changes to run the unittests (test/builtins/Unit/) for the new functions. Unfortunately, it looks like that will be a large patch because they use "long double" and "LDBL_MANT_DIG" explicitly all over the place.
lib/builtins/fp_lib.h | ||
---|---|---|
107 ↗ | (On Diff #170756) | Instead of checking for __x86_64__, this should probably also check for the FLOAT128 defines. |
Took another look and seems like long double is hardcoded in many of the builtins. So I think the current patch needs to rename a lot of places using long double to __float128 type.
Some examples where I think __float128 type (propagating the type in fp_lib.h) should be used instead of long double:
./extenddftf2.c: COMPILER_RT_ABI long double extenddftf2(double a) {
./trunctfsf2.c: COMPILER_RT_ABI float trunctfsf2(long double a) {
./extendsftf2.c: COMPILER_RT_ABI long double __extendsftf2(float a) {
@efriedma what do you think?
Wound up here while trying to use compiler-rt for static linking with our downstream compiler. It seems that compiler-rt's current approach of only providing these routines on certain platforms is problematic because libgcc always provides them, and thus compiler-rt is not a full replacement for libgcc in some cases. I also encountered the same two missing entry points.
Would very much like to see an upstream change to match the libgcc entry points, no matter the platform.
Yes, it makes sense to provide these routines, but someone has to write the code to make it work. This patch is currently incomplete:
Took another look and seems like long double is hardcoded in many of the builtins. So I think the current patch needs to rename a lot of places using long double to __float128 type.
I have tried my best to follow the conversation here and complete this patch. Please let me know if it is missing something, or if I need to assign new reviewers.
From earlier review comment:
Missing changes to run the unittests (test/builtins/Unit/) for the new functions.
That's the most important part, so we have some confidence the code actually works.
Hmm I tried to fiddle around with this but I'm out of my depth here. Pulling in @MaskRay @compnerd @phosek in the hopes that one of you is able to provide some insight or pull in someone else who is able to help.
When building a static compiler-rt with thinlto every downstream target breaks because of the missing __extendxftf2 and __trunctfxf2. AFAIU this blocks everyone from using thinlto with compiler-rt.
ld.lld: error: undefined symbol: __extendxftf2 >>> referenced by extendsftf2.c:18 (./external/llvm-project-overlay~17-init-bcr.0~llvm_project_overlay~llvm-project/compiler-rt/lib/builtins/extendsftf2.c:18) >>> lto.tmp:(__extendsftf2) >>> referenced by extenddftf2.c:18 (./external/llvm-project-overlay~17-init-bcr.0~llvm_project_overlay~llvm-project/compiler-rt/lib/builtins/extenddftf2.c:18) >>> lto.tmp:(__extenddftf2) >>> referenced by floattitf.c:75 (./external/llvm-project-overlay~17-init-bcr.0~llvm_project_overlay~llvm-project/compiler-rt/lib/builtins/floattitf.c:75) >>> lto.tmp:(__floattitf) >>> referenced 1 more times >>> did you mean: __extenddftf2 >>> defined in: lto.tmp ld.lld: error: undefined symbol: __trunctfxf2 >>> referenced by trunctfsf2.c:17 (./external/llvm-project-overlay~17-init-bcr.0~llvm_project_overlay~llvm-project/compiler-rt/lib/builtins/trunctfsf2.c:17) >>> lto.tmp:(__trunctfsf2) >>> referenced by trunctfdf2.c:17 (./external/llvm-project-overlay~17-init-bcr.0~llvm_project_overlay~llvm-project/compiler-rt/lib/builtins/trunctfdf2.c:17) >>> lto.tmp:(__trunctfdf2) bazel-out/k8-fastbuild-ST-1b2103630309/bin/external/llvm-project-overlay~17-init-bcr.0~llvm_project_overlay~llvm-project/clang/clang-linker-wrapper: error: 'ld.lld' failed
I also vaguely remember this leading to issues with static CUDA linking, but I don't have stacktraces for that :/