# Compiler guarantees for floating-point rounding modes
**URL:** https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808
**Category:** Internals & Design
**Created:** [February 24, 2026, 9:18am UTC](https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808 "2026-02-24T09:18:24Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@OlivierHnt](https://discourse.julialang.org/u/OlivierHnt)
#### Post date: [February 24, 2026, 9:18am UTC](https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808/1 "2026-02-24T09:18:24Z")
One of the recurring roadblocks in improving [IntervalArithmetic.jl](https://github.com/JuliaIntervals/IntervalArithmetic.jl) is the lack of support for changing the floating-point rounding mode ([R.I.P. `setrounding`](https://github.com/JuliaLang/julia/pull/27166)).
LLVM supports changing rounding modes (see also: [Setting Floating Point Rounding Mode through LLVM intrinsics · Issue #48812 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/48812)), but, as I understand it, Julia’s optimizer may still violate a user-selected rounding mode.
So changing the rounding mode is currently not much of an option for [validated numerics](https://en.wikipedia.org/wiki/Validated_numerics), and computer-assisted proofs.
At the moment, our strategy is a mix of RoundingEmulator + CRlibm + MPFR. Sadly, the more modern alternative [CORE-MATH](https://core-math.gitlabpages.inria.fr) relies on `fesetround` for rounding up or down, and is thus incompatible with Julia 🤦.
Now,
1. Can the Julia compiler’s behavior regarding directed rounding modes be made predictable?
For instance, there is [one piece of code](https://github.com/JuliaIntervals/IntervalArithmetic.jl/blob/b3f27567fb270aa13b1258536c01c73a651709c6/ext/IntervalArithmeticLinearAlgebraExt.jl#L593-L647) in IntervalArithmetic that changes the rounding mode to implement a fast interval matrix multiplication algorithm; the logic of the function is
```Julia
function foo(r::RoundingMode)
old = getroundingmode()
setrounding(r)
# `ccall` to the library OpenBLASConsistentFPCSR_jll
setrounding(old)
end
```
Tests seem to indicate that it works as expected, but what guarantees do we really have that Julia respects the rounding mode and does not silently override it during optimization?
1. Is it possible to have some sort of mechanism that prevents the compiler from assuming round-to-nearest within a given function?
For instance some sort of macro `Base.@consistent_fpcsr` that can preface a function, like `foo` above. In a very different context, there is `Base.@assume_effects` that somehow talks to the compiler…
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [February 24, 2026, 1:31pm UTC](https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808/2 "2026-02-24T13:31:40Z")
> [@OlivierHnt](#):
>
> as I understand it, Julia’s optimizer may still violate a user-selected rounding mode.
My understanding is that the violations occur for arithmetic that occurs at compile-time, i.e. for constant-folding. So it wouldn’t apply to a `ccall`?
---
### Author:  [@Keno](https://discourse.julialang.org/u/Keno)
#### Post date: [February 24, 2026, 6:46pm UTC](https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808/3 "2026-02-24T18:46:21Z")
I don’t think we want to model the rounding mode as implicit dynamic state. Instead, there should be explicit selection, either at the type or operation level to opt into different rounding modes. For ISAs that do not have instruction-level rounding mode control, there’ll need to be a compiler pass to explicitly schedule rounding mode transitions, which doesn’t exist, but that’s a much saner design model than implicit global state.
---
### Author:  [@Keno](https://discourse.julialang.org/u/Keno)
#### Post date: [February 24, 2026, 7:00pm UTC](https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808/4 "2026-02-24T19:00:12Z")
You may also be interested in following this upstream discussion: [Static rounding mode in IR - IR & Optimizations - LLVM Discussion Forums](https://discourse.llvm.org/t/static-rounding-mode-in-ir/80621)
---
### Author:  [@OlivierHnt](https://discourse.julialang.org/u/OlivierHnt)
#### Post date: [February 25, 2026, 1:58am UTC](https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808/5 "2026-02-25T01:58:41Z")
As I understand it, Julia might optimise
```Julia
setrounding(r) # call `fesetround` under the hood
x+y
```
such that `x+y` is performed before the `setrounding` call.
My intuition is that this would not happen for `ccall`; but I could not find anything explicitly written about this.
---
### Author:  [@OlivierHnt](https://discourse.julialang.org/u/OlivierHnt)
#### Post date: [February 25, 2026, 2:39am UTC](https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808/6 "2026-02-25T02:39:47Z")
Static semantics for rounding modes sound really great; the linked discussion is insightful.
If implemented in LLVM, is that straightforward to port the feature in Julia?
This function prefix `Base.@consistent_fpcsr` macro suggestion was also trying to make the FP environment more of an explicit effect.
I do not know how `Base.assume_effects` works, but couldn’t `Base.@consistent_fpcsr` also communicates some info about the function to the compiler?
Instructing that the function modifies the FP register, and to get a guarantee that nothing spooky (since it feels like magic from my point of view 😅) occurs. In my example where the function is essentially just doing a call to `fesetround` and `ccall`, you just want to make sure that the specified temporal execution order is respected.
Though maybe implementing such a macro is just asking for static semantics?
---
### Author:  [@Keno](https://discourse.julialang.org/u/Keno)
#### Post date: [February 26, 2026, 10:54pm UTC](https://discourse.julialang.org/t/compiler-guarantees-for-floating-point-rounding-modes/135808/7 "2026-02-26T22:54:10Z")
> [@OlivierHnt](#):
>
> If implemented in LLVM, is that straightforward to port the feature in Julia?
Yes