[GSoC 2026][libc] Enable float80 and float128 Math Support on Unsupported Targets for LLVM libc

Community GSoC
,
1

Description: The LLVM libc project aims to provide a complete, correct, and high-performance C23 standard library. A key differentiator is its focus on correctly rounded math functions for all floating-point types, including float, double, long double, and float128 (IEEE 754 quad precision).

However, not all compilers or architectures support these types natively. For example:

  • MSVC on Windows treats long double as 64-bit double and lacks a native __float128 type.
  • AArch64 targets typically use 128-bit long double, but lack the 80-bit extended precision format.
  • Clang on certain non-x86 targets may not enable __float128 by default.

This lack of host compiler support prevents LLVM libc from building and testing its high-precision math routines on these platforms.

The Goal: The goal of this project is to implement standalone C++ classes (e.g., within LIBC_NAMESPACE::fputil) that emulate float80 and float128 semantics in software. These classes should provide the necessary operator overloads and storage (using UInt<128> or similar) to allow the existing templated math implementations to compile and run even when the host compiler does not support the native types.

Proposed Solution:

  1. Type Abstraction: Create wrapper classes that mimic the behavior of native floating-point types.
  2. Soft-Float Arithmetic: Implement or connect these classes to soft-float arithmetic routines (add, sub, mul, div) so that math algorithms (like polynomial evaluation) can be executed.
  3. Integration: Refactor the math function entry points to instantiate templates with these emulated types when native support is missing.

Expected Results:

  • A header-only C++ implementation of float80 and float128 types that can be used where native support is missing.
  • Basic arithmetic operations (+, -, *, /) implemented for these types.
  • Demonstration of LLVM libc math functions compiling and passing tests using these emulated types on a target that lacks native support (e.g., building float80 math on Mac arm64, float128 math with MSVC).

Project Size: Medium or Large

Difficulty: Medium

Requirements:

  • Basic C++ skills.
  • Interest in understanding the intricacies of floating-point formats (IEEE 754 and extended precision).

Mentors: Tue Ly, Nicolas Celik, Krishna Pandey.

5 Likes
Fortnightly LLVM libc math library meeting
Libquadmath in LLVM?
Fortnightly LLVM libc math library meeting
2

Greetings

I am considering this as one of my proposals for this year gsoc.

About the float80 part, how would I test it on macs if I dont’t have mac hardware?

Also, will these new float types support native hardware float operations in any way? To AArch64 80float for example?

Will this project need modifications of other parts of LLVM-libc that is not related to the new float80 and float128? Like implement some methods using them?

3

Hi,

I’m planning to draft a proposal for this project and would really value early feedback.

As a mentor, would you prefer that draft proposals be shared via email, Discourse DM, or discussed on this thread first?

Thanks!

4

Greetings, I’m new to GSoC and very interested in this project. Are there any existing PRs, issues, or specific parts of LLVM libc that you’d suggest looking at first to get familiar with the current float80/float128 work? I’d also appreciate any pointers to resources for building a stronger understanding of floating-point formats and extended precision.

5

Hello, my name is Nuraly. I am very interested in the float 80/128 emulation for LLVM libc, and I have studied the IEEE 754 standard basics and rounding methods before.

I would like to know if there are any specific parts of LIBC_NAMESPACE::fputil that I should pay close attention to, for a better understanding of the floating-point utilities.

Also, are there any preferred resources related to floating-point format or arithmetic that will help me improve my foundation?

6

Hello,

My name is Shashank, and I recently went through the project idea on enabling float80 and float128 math support on unsupported targets for LLVM libc. I am very interested in contributing to this project.

From my understanding, the core challenge is to implement software-emulated floating-point types (likely within LIBC_NAMESPACE::fputil) that preserve IEEE 754 extended and quad precision semantics, allowing the existing templated math implementations to compile and run even when the host compiler lacks native support for long double (80-bit) or __float128.

I have started reviewing the libc/src/__support/FPUtil directory and am currently studying IEEE 754 extended precision and quad precision formats to better understand the required abstractions.

I had a few questions:

  1. Should the emulated types primarily wrap existing utilities like UInt<128> for storage and build arithmetic on top of them, or is there an expectation to integrate a more complete soft-float implementation?

  2. Would it be preferable to start with float128 support first (for MSVC-like targets), or with float80 emulation?

I would greatly appreciate guidance on how to begin contributing and which areas of the codebase would be most helpful to explore initially.

Thank you for your time.

7

I’m interested in working on this . I have previously contributed to issues related to float16, float128, bfloat16 and adding math support for some functions . will look more into this .

8

I am interested to work on this.

I have relevant experience from my prior and ongoing contributions to llvm-projects

(6 Merged PR’s and 4 to be Merged).

Will research more about these and draft a proposal.

9

Hi everyone, I’m sorry for replying so late! Thank you for your interest in this project.

@manueldun You could test it on any non-x86 hardware, like an AArch64 smartphone. You could also test it with QEMU. Once you open a pull request, our CI will test your code on an AArch64 macOS machine.

We could investigate making use of hardware support (when available) for arithmetic operations, if we have enough time.

Some math function implementations will need to be refactored once the new types are implemented:

@sohail103 Please send us your draft proposal by email. Thanks.

@shuklaveeresh You can take a look at the work that was done for BFloat16 last year, e.g.,

There are also various issues you could work on (please ask to have them assigned to you beforehand) to gain experience with relevant areas of LLVM-libc:

As for resources to build a stronger understanding of floating-point formats and arithmetic, I recommend the following books:

  • Handbook of Floating-Point Arithmetic by Jean-Michel Muller et al.
  • Elementary Functions: Algorithms and Implementation by Jean-Michel Muller

@nyr1k I recommend you take a look at the following files:

  • libc/src/__support/FPUtil/bfloat16.h
  • libc/src/__support/FPUtil/FPBits.h
  • Everything under libc/src/__support/FPUtil/generic
  • libc/src/__support/FPUtil/BasicOperations.h
  • libc/src/__support/FPUtil/comparison_operations.h
  • libc/src/__support/FPUtil/DivisonAndRemainderOperations.h
  • libc/src/__support/FPUtil/ManipulationFunctions.h
  • libc/src/__support/FPUtil/NearestIntegerFunctions.h

See the two books I mentioned earlier.

@Sxashank Correct.

The former: they should wrap around integer types for storage and reuse fputil::generic:* functions for arithmetic.

I don’t think we have a preference. CC @lntue.

See the PRs, issues, and files I mentioned earlier.

Please let us know if you have any further questions. We are also available on Discord (#libc channel on the LLVM Discord server: LLVM).

1 Like
10

Greetings,

This project interests me a lot and I would like to contribute to it for Google Summer of Code. I have read rigorously on methods to implement floating point arithmetic along with several research papers. May I share a rough draft proposal for an evaluation to get feedback?? Thanks and Regards

11

I was looking at the FPRepSem<FPType::X86_Binary80> in FPBits.h, and I noticed that the integer bit of the significand is stored explicitly as should be.

For the float80 emulation part of this project, should we preserve that explicit-bit layout exactly, or is the main goal to match numerical behavior regardless of encoding details?

12

@KartikDua1504 Sure, you can email us your draft proposal.

@Joker96 We should preserve the exact encoding/layout.

14

@overmighty Any specific resources to study about Tests to be added?

15

Hi, I’ve submitted my GSoC proposal on enabling software-emulated float80/float128 support in LLVM libc.

I would appreciate any feedback on whether this integration approach aligns with the current libc design, particularly regarding interaction with existing math templates.

16

Hi @overmighty

I have sent you an email for GSoC proposal review. Could you please review it whenever you get the time?

Thank you!

17

@overmighty Hi, thank you for proposing this exciting project! I have just sent an email with my GSoC proposal draft regarding the header-only SoftFloat implementation (leveraging UInt<128>). I would be incredibly grateful for any feedback on the technical approach or the project size when you have a moment. Looking forward to your thoughts!

18

Hey,

I am Supus. I will be drafting a proposal for this idea. It definitely stood out to me because I like Maths and I love low level programming such as C++.

What resources would you suggest to prepare for the draft and get started on it?

20

The deadline is in a few hours. You can’t write a proposal in so little time :confused: