Hi all, I’m investigating the requirements for fenv access in Zig.

My primary goal is to get all the math tests in the libc-test-nsz test suite uncommented, so that the ziglibc project can rely on them to test the compatibility and correctness of libc functions implemented in Zig.

But from what I’ve found researching the state of floating point arithmetic, many platforms and ISAs are moving away from dynamic rounding modes and FPU exception flags, since the use of global dynamic state impedes the ability of the compiler to optimise arithmetic operations and make parallelisation more difficult. A recent RFC for strictfp in LLVM highlighted that the broad consensus is to move away from a dynamic floating point environment, and towards a static floating point environment defined at the function- or instruction-level.

In my opinion, most use cases for dynamically accessing the floating point environment are better served by fine-grained static control over the floating point environment within the language. The rounding mode of an arithmetic computation can be set statically at the level of a code block, like setFloatMode, or even at the level of the indivudal arithmetic expression, which the accepted proposal to incorporate floating point optimisations into the numeric type system would unlock. Floating point exceptions could be implemented by builtin functions similar to {add,sub,mul}WithOverflow that return a tuple of the output value and a bitmask of the FPU exceptions that triggered.

What use cases of floating point environment access, rounding mode, and FPU exception flags should Zig support? How would game developers, maintainers of numeric libaries, scientific users, or any other users benefit from better language support for floating point environment operations? In particular, what use cases specifically require dynamic access of the floating point environment, despite its performance costs?

Lygaen July 27, 2026, 6:32pm 2

Heya !

I’m a student in numerical analysis (I’m starting my specification ;)) and currently using zig to develop a personal library for scientific computing.

I do need in a few places to access the floating point env notably for setting the rounding direction (used once) and checking for exceptions (most of the times). The rounding direction is quite a hack on my end to skip some code but is not that much needed (removing a few seconds of a minute).

In the end, my code mostly checks for floating point exceptions and that’s it.

However, the proposal seems to remove NaN, ±inf, etc. which I do use in my code to both signal values and do computations.

So no real impact on my end for this proposal apart from the removal of these values (which I assume is motivated by making a “protected type” that represents only viable values).

Awesome! Best of luck with your studies.

Where in your code do you need to check for floating point exceptions? How do you currently check for them?

The proposal for new floating point types doesn’t remove those values, rather it changes how certain compiler optimisations which speed up computational code are declared. These optimisations include allowing the compiler to assume that NaNs and infs never occur, so the compiler doesn’t need to check the result of every computation for invalid results. This makes the code faster, but doesn’t guarantee perfectly accurate results. The change would be to improve the expressiveness with which users of Zig can declare which code should focus on correctness and which code should focus on performance.