Skip to content

[compiler-rt][PowerPC] missing IEEE long double emulation functions #89054

Description

@pkubaj

Currently when building LLVM on ppc64le with IEEE long double, LLVM tries to use emulation functions listed in https://gcc.gnu.org/wiki/Ieee128PowerPC (table in 2.3 Emulation functions). However, compiler-rt has no implementation of those functions leading to a build failure when there's no libgcc installed (e.g. on LLVM-only system).

Activity

  1. llvmbot commented on Apr 17, 2024

    @llvmbot
    Member

    @llvm/issue-subscribers-backend-powerpc

    Author: Piotr Kubaj (pkubaj)

    Details Currently when building LLVM on ppc64le with IEEE long double, LLVM tries to use emulation functions listed in https://gcc.gnu.org/wiki/Ieee128PowerPC (table in 2.3 Emulation functions). However, compiler-rt has no implementation of those functions leading to a build failure when there's no libgcc installed (e.g. on LLVM-only system).
  2. chenzheng1030 commented on Apr 18, 2024

    @chenzheng1030

    Could you share your usage for LLVM-only system? It it a Linux system? Why do you want to try with LLVM-only system? Thank you!

  3. ecnelises commented on Apr 18, 2024

    @ecnelises
    Member

    From the table, following supplementary functions are for __float128 (LLVM does not support decimal so they are excluded):

    • __extendsfkf2
    • __extenddfkf2
    • __trunckfsf2
    • __trunckfdf2
    • __extendkftf2
    • __trunctfkf2
    • __floatsikf
    • __floatdikf
    • __floatdikf
    • __floattikf
    • __floatunsikf
    • __floatundikf
    • __floatundikf
    • __floatuntikf
    • __addkf3
    • __subkf3
    • __mulkf3
    • __divkf3
    • __cmpukf2
    • __cmpokf2

    Except __cmpukf2 and __cmpokf2 are not found inside llvm subdirectory, the rest libcalls may be generated by LLVM backend but compiler-rt does not have implementations.

  4. pkubaj commented on Apr 18, 2024

    @pkubaj
    ContributorAuthor

    @chenzheng1030
    FreeBSD is LLVM-only. We use clang as C compiler, clang++ as C++ compiler, lld as linker and libc++ as a C++ standard library. Our C library is our own (no glibc nor musl).

  5. pkubaj commented on Jun 22, 2026

    @pkubaj
    ContributorAuthor

    While I succeeded in creating a workaround on FreeBSD's side, this issue came up while upstreaming at #201298. What would be the preferred way of adding this support? I can see two ways:
    a) small per-symbol wrappers under lib/builtins/ppc/ that #define the tf entry point to the kf name and #include the existing binary128 source with the working type forced to __float128/_Float128; or
    b) a dedicated PPC kf build of the binary128 builtins, closer to libgcc's t-float128.

  6. brad0 commented on Oct 9, 2026