Hi,

There is a fourth option as well: move to a full softfloat
implementation for constant evaluation. This has the added benefit of
making the compiler output more deterministic. It's also how other
compilers handle constant evaluation IIUC.

I have been experimenting with this in the context of enabling compiler
cache sharing between different host architectures. It isn't ready to be
shared yet but if people think this idea has merits, I can clean it up
sooner.

Cheers,
Job

On 08/09/2026 04:02, Timothy Arceri wrote:
> Hi all,
> 
> I'd like to move forward MR 42611 (or its alternate patch) as a real
> game is currently crashing on mesa drivers, but those who have
> commented on the MR are at a deadlock as to what is the best way to
> handle user enabled floating point exception flags inside the compiler.
> 
> The problem with the game is the exception when evaluating a divide by
> zero in the shaders math, as the game has floating point exception
> flags turned on.
> 
> There are currently three options I can see:
> 
> 1. Disable the exceptions whenever the compiler evaluates math from the
> shader (see patch [2]) and then re-enable them afterwards, here we just
> ignore the chance that anything else in mesa generates the exceptions
> which can be possible (but not currently seen) as we enable the build
> flag no-trapping-math
> 
> 2. Apply the above patch and apply the -ftrapping-math flag to builds
> so that clang doesn't default to no-trapping-math
> 
> 3. Use the patch the MR currently carries that just disables the
> exceptions at context and screen creation time, and leave them disabled
> behind the applications back.
> 
> I would be happy enough with 1 landing as it solves the game bug, 2 is
> the most complete solution but means we no longer set no-trapping-math,
> 3 disables floating point exception flags outright, but doesn't cover
> vulkan and can disable the flags for the application, it might also be
> possible the calling application turns them on again later and new
> threads will pick up that change but I'm not 100% sure if that can end
> up happening in mesa.
> 
> I'd appreciate any thoughts on how we should move this forward.
> 
> Thanks,
> Tim
> 
> 
> [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42611
> [2]
> https://gitlab.freedesktop.org/-/project/176/uploads/361c2f02fd14a994e864719ee5a5dfca/0001-nir-temporarily-disable-floating-point-exception-fla.patch

Reply via email to