"remark #981: operands are evaluated in unspecified order" for floating point

"remark #981: operands are evaluated in unspecified order" for floating point

Hi !

Using the Intel compiler for Linux, version 8.1, I try to enable the -Wall option, just to make sure that all potential problems are addressed.

The problem is that I get the remark from subject where I think it is not the case. I attached a very simple test case. Here is the result of compilation:

>icc -Wall t.c -o t
t.c(8): remark #981: operands are evaluated in unspecified order
printf("a=%f b=%f
", a, b);
^

If I change the a and b from float to int and the %f to %d then everything is ok.

Is there a way to disable this output? I don't want to disable all the remarks about the evaluation order for the operands, as it matters in other cases.

The exact version of the intel compiler is:
Intel C++ Compiler for 32-bit applications, Version 8.1 Build 20041019Z Package ID: l_cc_pu_8.1.024

Regards,
-Iulian

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You might want to file a problem report on your premier.intel.com, as this certainly looks like an annoying and useless warning. The only "evaluation" I see there is a promotion from float to double. It might be interest whether there is a warning when the arguments are doubles, and whether gcc -O -Wall produces the warning.

I got the same i C++

cout <<"Glunk " << func() << endl;

also get a warning for unspecified order :-)

You can disable with -wd981 (on Linux)

/Tommy

Thank you !

You are right, this is what happens: for functions without prototype or with variable number of parameters the floating point arguments are promoted to double (I think that is ANSI C - to keep it compatible with old K&R C routines where the promotion applies for all float variables involved on any numerical expression). If I change the type of variables from float to double there are no warnings.

gcc -Wall doesn't issue this kind of warning though.

-Iulian

Thanks for the tip!

The problem is that I want this type of warning enabled on different situations where it may be relevant. Other than that it is working :-)

Oh, by the way, do you know by any chance if there is a "pragma" I can use to disable it just locally?

-Iulian

#pragma warning (disable:193)

#pragma warning (default:193)

seems to work, can't find anything about it in the documentation though :-(

/Tommy

Thanks !

For now it seems to be an acceptable workaround.

Again thank you all for the help.

-iulian

Why is this still not fixed ?

Thanks.

Leave a Comment

Please sign in to add a comment. Not a member? Join today