Hello, The Intel compiler syntactically allowsthe fenv_access pragmato appear within a compound statement.However,the current implementation still appliesthe pragmato the entire function. Likewise for the other floating-point pragmas. If there are multiple pragmas, the most restrictive is applied to the entire function. Perhaps this might change in the future, but it's a challenge to implement these pragmas effectively, safely and locally in the presence of optimization.
The pragmas apply only to the function that contains them, it makes no difference who calls who. The pragmas influence how code is compiled, but there is no dynamic state that can be passed from caller to callee at run time.
In principle, (i.e. semantically), this remains true when one function is inlined into another. But in practice, for the current implementation, just as for pragmas contained inside compound statements, the whole function including inlined code is compiled according to the most restrictive pragma in either the host or the inlined functions. Conceivably, this could change in a future implementation.
The floating-point environment is a global item that changes during runtime, so it is a dynamic state. The control part is the current rounding mode (trap enable is outside the scope of the C standard). The status part is the floating-point exception flags.
When the user does: #pragma STDC FENV_ACCESS ON the compiler must assume that the rounding mode may be anything, and the FP flags will be tested. In that case, the compiler is limited in the "optimizations" that can be done.
When the user does: #pragma STDC FENV_ACCESS OFF then the compiler can assume that default modes (round to nearest) are in effect and that the FP flags will not be tested. Then the compiler can do "optimizations" .
When code goes from a block with FENV_ACCESS OFF to FENV_ACCESS ON, the FP flags are unspecfied, and the rounding mode is assumed to be round to nearest.