Intel 64 mode: 0.0/0.0 sometimes accepted, sometimes rejected

[tydeman]

Hardware: Centrino 2 vPro (Core2Duo) in 64-bit mode
O.S.: Linux Fedora Core 10 in 64-bit mode
Compiler: Intel icc 11.1, 072 in Intel64 mode
Command line options: "-std=c99 -msse3 -O0 -fmath-errno -fp-model strict -fp-speculation=strict -H ${INCS}"

The expressions 0.0/0.0 and 1.0/0.0 are sometimes accepted and sometimes rejected.
They should all be accepted.

Program:

int main(void){
static float fs = 0.f / 0.f; /* Bad */
static double ds = 1.0 / 0.0; /* Bad */
auto float fa = 0.f / 0.f; /* OK */
auto double da = 1.0 / 0.0; /* OK */
auto float fa2[1] = {0.f / 0.f}; /* OK */
auto double da2[1] = {1.0 / 0.0}; /* OK */
return 0;
}

[Milind_Kulkarni__Int]

I could not reproduce your case.

Do you seem to find out which compiler option is causing this to happen for you.
I tested with 11.1 072 in intel64 , and got only warnings all the time. like below:--

div0.cpp(9): warning #265: floating-point operation result is out of range

auto double da2[1] = {1.0 / 0.0}; /* OK */

Which error does the compiler throw for you.

As for the output I get consistent results.

0.0/0.0 = nan
1.0/0.0 - inf

Regards

[tydeman]

icc -std=c99 test74.c

test74.c(2): error: floating-point operation result is out of range
static float fs = 0.f / 0.f; /* Bad */
^

test74.c(3): error: floating-point operation result is out of range
static double ds = 1.0 / 0.0; /* Bad */
^

compilation aborted for test74.c (code 2)

[Milind_Kulkarni__Int]

I used the .cpp extension, that was converting error to warning.
The static is needed to get this error, while auto / locals do not display this error.

gcc I tried, and it gives correct results.

I have escalated this issue to the compiler team, and will let you know of the updates.

[Milind_Kulkarni__Int]

Though its already escalated as a bug,I thought if you could give this a try:-- (using icpc , )

icpc -std=c99 test.c

-- this gives correct result.

icc -std=c99 test.c

-- Bad result for static

Please let me know if it workarounds your code.

The thread id which shares this issue is:-- 74369 , which is already escalated a bug.

Probably, the reason that icc gives error when the vars are outside of the function, it's because the compiler has to evaluate them at compile time. When it's within a function, compiler do not do that.

So, this example works perfectly, even with statics:--

[bash]  static float  fs;    
  static double ds;  


int main(void){
    fs = 0.0f / 0.0f;    /* Now good */
    ds = 1.0 / 0.0;    /* Now good */
[/bash]

Regards

[Milind_Kulkarni__Int]

The developer replied in this way:--

The situation described (i.e. that the compiler works differently between C and C++) is not a bug. It reflects the fact that run-time initialization of static objects is allowed in C++, but not in C. However, though we reject it while GCC accepts it without a quiver, EVEN IN C.

It shouldn't be hard to drop divide-by-zero from the list of floating-point errors, provided it does not have any side-effects, and it could include other OS/environments.

I will keep you updated on the decision, and the progress.

[tydeman]

I tried using icpc (in place of icc) and my C99 application will not compile.
It appears that, while is includable, one cannot call any of
the math functions.

#include
int main(void){
float f = ldexp(1.f, 3);
return 0;
}

Also, FLT_EVAL_METHOD is not defined.

[Milind_Kulkarni__Int]

I am sorry in case I was not clear on the 0.0/0.0 issue . Its accounted for as a bug and would be fixed in later release.

For ldexp() , is this another issue or related to former issue?

As for this tgmath.h, its a c99 C header file . In a lot of ways, that should not conflict with c++ usage.

icc supports -std=c99, but icpc does not. So, icc works, but only with the flag c99, which enforces that its a c99 hdr file.

For a more lengthy and useful discussion, you may refer to this thread in the forum:--

http://software.intel.com/en-us/forums/showthread.php?t=64021

[tydeman]

I was asked to try icpc. I did and got many errors.
I reported those errors. I am not surprised that
using a C++ compiler on C99 code would fail.
So, the not working (and no ldexp)
is a side effect of trying to use C++ compiler with
C99 features. So, is FLT_EVAL_METHOD. Both
of those are not issues.

[Milind_Kulkarni__Int]

yesmost ofcases, c99 code is not compatible with c++, as many data-types & headers are not defined for C++. So you could not apply the workaround. I understood your situation that you need to use c99 features , along with your program-implicit features (like statics initialization of constants at runtime), which is actually a C++ feature , and C language enforces it to compile-time, though gccis immune to the enforcement.
-- Though I much hope you already know that assigning the static (nan, inf)after declaring them, instead of initializing them in declaration will solve your purpose with icc, and let you have c99 as well. I hoped you already tried that out, and then you need not use icpc ..
Please let me know of any further questions..

Also, I will keep you posted on the progress of this bug-fix.

[Milind_Kulkarni__Int]

Following from above , you still have a better workaround (by using builtins with static initialization) works, and then you do not need even the bug to be fixed. It is like:--

And using these builtins should be a good workaround for this problem. And it serves as good as the original sample code you gave that contained the bug.

[bash]static double nan = ((__builtin_nanl("")));
static double plus_in = ((__builtin_huge_vall()));
static double minus_in = ((-__builtin_huge_vall()));

printf(%g %g %gn, nan, plus_in, minus_in)   //// seems to fix this problem.














[/bash]