Community
cancel
Showing results for 
Search instead for 
Did you mean: 
201 Views

I need clarifications concerning fenv_access

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
0 Kudos
4 Replies
Martyn_C_Intel
Employee
201 Views

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.
201 Views

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
Employee
201 Views

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-compi... .

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
Beginner
201 Views

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.
Reply