Now starting from the first use of pragma FENV_ROUND rounding mode
becomes user-defined and there is no way to return back to initial
state. Default rounding mode and the same explicitly defined one result
in different AST. For example, the code:
float func_04(float x, float y) { return x + y; }
produces AST where the FP operation is represented with the node:
`-BinaryOperator 0x25d6e2cecb8 <col:10, col:14> 'float' '+'
The same code with #pragma STDC FENV_ROUND FE_TONEAREST before the
function definition produces slightly different representation:
`-BinaryOperator 0x1832c1a4ce8 <col:10, col:14> 'float' '+' ConstRoundingMode=tonearest
Code generation is not changed in this case because tonearest is the
rounding mode in default FP environment. However if an AST object has
an override for a FP property, it considered as explicitly specified
and is preserved in some cases where default property may be overridden.
Default rounding mode is dynamic according to the C2x standard
draft (7.6.2p3):
... If no FENV_ROUND pragma is in effect, or the specified constant rounding mode is FE_DYNAMIC, rounding is according to the mode specified by the dynamic floating-point environment ...
So pragma FENV_ROUND FE_DYNAMIC must reset rounding to default state,
but now it only adds related override:
`-BinaryOperator 0x1cb8cfaaec8 <col:10, col:14> 'float' '+' ConstRoundingMode=dynamic
This change fixes the pragma behavior. If FENV_ROUND FE_DYNAMIC is
specified without FENV_ACCESS ON, the rounding mode override is
removed, which effectively establish default rounding mode state.
I'm not really happy with the way this is written... like I mentioned in the other patch, keep the state transitions simple, and put the logic into the code that computes the derived properties.