pragma float_control

[stephan_]

Hi,

I just noticed that the Intel C++ compiler doesn't honor a #pragma float_control(precise, on) request when it's not in the global namespace. For example, the following code triggers the

"warning #1670: this pragma may only appear between declarations in the global scope or before any statements or declarations in a block scope"

for both pragma declarations and the compiler ignores the pragma (I've tested this).

[cpp]namespace myname {

#pragma float_control(precise, on, push)

double test(double x) {
  // do some computation where float associativity matters and return result 
}

#pragma float_control(pop)

} // namespace 
 [/cpp]

I wonder:

1. Are namespaces no block scopes?
2. Is this an Intel bug, since Visual Studio doesn't have a problem with this pragma inside a namespace?
3. Can the optimizer be trusted to honor the float_control(precise) request if a function gets inlined?

Thanks in advance for any hint.

BTW, I find the documentation of the floating-point optimization levels somewhat lacking. For example, describing the value safety of the fast=1,2 modes as "unsafe" and "very unsafe" isn't really informative. More details about the kind of optimizations that are applied on the different levels would be really helpful.

Stephan

[TimP]

Quoting - stephan_

describing the value safety of the fast=1,2 modes as "unsafe" and "very unsafe" isn't really informative. More details about the kind of optimizations that are applied on the different levels would be really helpful.

In addition to setting /Qprec-div- /Qprec-sqrt- /Qftz and K&R style handling of parentheses, in comparison with /fp:source, /fp:fast=1 allows vectorized sum reductions and math functions. fast=2 may set restricted range validity of complex divide and sqrt. So, ICL /fp:source, possibly followed by /Qftz, seems to be the closest equivalent to the Microsoft /fp:fast.

[stephan_]

Thanks for the info, Tim.

I'm still hoping someone from Intel might comment on the main questions of my post.

[KitturGanesh]

Quoting - stephan_

Thanks for the info, Tim.

I'm still hoping someone from Intel might comment on the main questions of my post.

Hi Stephan,
To your questions:

1. Are namespaces no block scopes?
Namespaces are not block scopes as you cannot put a statement in a namespace that you can ina block scope.

2. Is this an Intel bug, since Visual Studio doesn't have a problem with this pragma inside a namespace?
Looks like this is an Intel bug, as the warning coming out is appropriate for C (no namespace), but not for C++.
I'll file a tracker on this with the developers.

3. Can the optimizer be trusted to honor the float_control(precise) request if a function gets inlined?
I'll get back to you on this one after some investigation, thanks.

-regards,
Kittur

[KitturGanesh]

Quoting - Kittur Ganesh (Intel)

Hi Stephan,
To your questions:

1. Are namespaces no block scopes?
Namespaces are not block scopes as you cannot put a statement in a namespace that you can ina block scope.

2. Is this an Intel bug, since Visual Studio doesn't have a problem with this pragma inside a namespace?
Looks like this is an Intel bug, as the warning coming out is appropriate for C (no namespace), but not for C++.
I'll file a tracker on this with the developers.

3. Can the optimizer be trusted to honor the float_control(precise) request if a function gets inlined?
I'll get back to you on this one after some investigation, thanks.

-regards,
Kittur

Hi Stephan,
I did verify with our key developers on the last question. The answer is yes. You can trust the optimizer to honor the float_control(precise) request if the function gets inlined.Hope that helps.
-regards,
Kittur

[stephan_]

Kittur, thanks a lot for answering all my questions!

Stephan

[KitturGanesh]

Quoting - stephan_

Kittur, thanks a lot for answering all my questions!

Stephan

Pleasure Stephan. I'll also upate you as soon as a fix is in for that warning message/C++, appreciate much.
-regards,
Kittur

[stephan_]

Kittur, you are probably aware of this, but maybe not every reader: It's not just a spurious warning, the compiler actually won't honor the float_control(precise) request if it is in a namespace scope. One might argue that this warning message should better be an error message, in particular because the miscompiled code can be hard to detect.

[KitturGanesh]

Quoting - stephan_

Kittur, you are probably aware of this, but maybe not every reader: It's not just a spurious warning, the compiler actually won't honor the float_control(precise) request if it is in a namespace scope. One might argue that this warning message should better be an error message, in particular because the miscompiled code can be hard to detect.

Yes I agree Stephan, thanks. Appreciate the clarification, so readers can now understand that it's just not the warning that needs to be fixed.
-regards,
Kittur

[Denis_E_]

Kittur Ganesh (Intel) wrote:
Quoting - Kittur Ganesh (Intel)

2. Is this an Intel bug, since Visual Studio doesn't have a problem with this pragma inside a namespace?
Looks like this is an Intel bug, as the warning coming out is appropriate for C (no namespace), but not for C++.
I'll file a tracker on this with the developers.

I'm using Composer XE 2013 and I still have this issue. The main problem is that this code is located in a 3rd party library, thus I can't really change it. Is it safe to ignore this warning ?

[SergeyKostrov]

>>...3.Can the optimizer be trusted to honor the float_control(precise) request if a function gets inlined? I'd like to make a comment related to a change of a Floating Point Model. The #pragma directive 'float_control(...)' controls the Floating Point Model at a compile time and it affects calculations at run-time. My question is: Wouldn't be better to control the Floating Point Model at run-time only using a set of CRT-functions, like _control87 or _controlfp? >>...Is it safe to ignore this warning? You need to verify results of your calculations for all cases.

[TimP]

The original post referred to use of #pragma float_control to turn on and off observance of language rules on associativity at compile time. This choice could not be made at run time unless both versions of the code were present. Besides, changing x87 run-time settings doesn't solve many problems in the present day when most applications are built with SSE instructions. In my experience, the only reason for returning to the default non-enforcement of associativity is to gain the reduction optimizations, which can also be done in the majority of cases by #pragma simd reduction(). I recognize that from time to time there is a desire to have the compiler ignore parentheses and perform algebraic simplification to speed up execution. The compiler tends not to do this consistently; to me it is also a problem that it is inconsistent with the Microsoft and gnu compilers. In the gnu compilers, there are separate options for associative math and observance of parentheses.

[SergeyKostrov]

>>...Intel C++ compiler doesn't honor a #pragma float_control(precise, on) request when it's not in the global namespace... MSDN doesn't say anything about namespaces but says that 'float_control' pragma 'Specifies floating-point behavior for a function'