[cfp-interest 3927] Re: Setting the Dynamic Rounding Direction

[Trevor Gross]

On 2026-05-06 23:56, Damian McGuckin wrote:
> In the great "rounding" discussion, ....
> 
> Investigations by someone (far smarter than me) a while ago showed that
> aggressive optimization by at least one main-stream compiler resulted 
> in code
> like
> 
> 	old_rounding_direction_mode = fegetround();
> 	fesetround(new_rounding_direction_mode);
> 	{
> 		multiple statements;
> 	}
> 	fesetround(old_rounding_direction_mode);
> 
> not always guaranteeing that the new_rounding_direction_mode is set 
> before any
> of those "multiple statements" are executed and likewise the last of 
> the
> fesetround() statements might not always be done immediately those same
> "multiple statements".
> 
> Recent re-investigations seem to show this problem has now been 
> addressed by a
> workaround. Sadly, its downside is that it no longer yields quite so 
> optimal
> code within the block. Ideally what the compiler should have done 
> instead is
> model the dependencies between rounding modes and instructions. 
> Sub-optimal.
> Undesirable.

What would the alternative be? In practice any access to the dynamic 
floating
point environment needs to act as a fence for relevant floating point
operations, so the original situation feels like a miscompilation or 
missing
barrier in libc.

- Trevor

> Does demanding that this block structure is honored by the optimizer in 
> terms of
> the execution sequence a topic that either ourselves or even the WG14 
> itself can
> raise?
> 
> I am curious - Damian
> 
> P.S. I will investigate what happens with static rounding #pragmas in 
> my (ha-ha)
spare time.