I need clarifications concerning fenv_access

[Andreas_Fabri__Geome]

Hello,

It seems that the Intel compiler has implemented the enclosing compound statement as scope for the pragma fenv_access, whereas Visual C++ only allows the pragma in the global or a namespace scope.

Can anybody confirm this?
Is there a manual page from Intel clearly stating this?
Is there a minimal piece of code which allows to verify it on 64 bit Windows?

And I have kind of the same question for #pragma fp_contract
and for #pragma float_control(precise, on) push

Best regards,

andreas

[Martyn_C_Intel]

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.

[Andreas_Fabri__Geome]

Thank you for the quick reply. I still have some follow up questions.

What about a function foo calling a function bar, the two having different pragmas?

What about inlined functions, or are they not inlined if they use different pragmas?

Is all this documented somehere?

Best regards,

Andreas

[Martyn_C_Intel]

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.

I don't know of any documentation that goes into this amount of detail. There's an article that discusses floating-point arithmetic for the Intel compiler attached at http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/ .

This contains a reference to a Microsoft article on floating-point optimization at http://msdn2.microsoft.com/en-us/library/aa289157(vs.71).aspx .

[tydeman]

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.