Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7942 Discussions

Optimization does not account for gentlemen's agreement

yuriisig
Beginner
392 Views
Question on Intel C++ 64 compiler (version 11.1.065). In some cases the order of evaluation is very important and are rescued by placement of brackets. With -O2 option program considers wrong (apart brackets!), with the option -Od believes correctly. Microsoft compiler always creates a correct program.
0 Kudos
9 Replies
Milind_Kulkarni__Int
New Contributor II
392 Views
Can you state examples of expressions that have different results with -O2 & -Od . This could be due to some optimization in intel compiler. If you provide small example, we can escalate the issue, provided the expression is unambiguous and aesthetic.
Something like the below should not suffice:--

printf("%d\n", i++ * i++);

i++ + j++ * k++

i++ + (j++ * k++)

0 Kudos
yuriisig
Beginner
392 Views
Can you state examples of expressions that have different results with -O2 & -Od . This could be due to some optimization in intel compiler. If you provide small example, we can escalate the issue, provided the expression is unambiguous and aesthetic.
Something like the below should not suffice:--

printf("%d\n", i++ * i++);

i++ + j++ * k++

i++ + (j++ * k++)

I do not do such masochism. I figured out: besides the option -O2 is necessary to specify the option -fp: double (not everyone thought of this before!). Previously, this was not. Perhaps the developers overheated in the sun.

0 Kudos
TimP
Honored Contributor III
392 Views
Several icc/icpc options in the /fp: category require observance of parentheses in accordance with the standard. In particular, -fp:source observes parentheses and also evaluates expressions in source defined precision. Its effect of disabling vectorized math functions may be over-ridden by -fast-transcendentals, and its effect of setting gradual underflow may be over-ridden by a subsequent -Qftz. This leaves vectorized sum and dot products as perhaps the most important optimizations enabled only by -fp:fast.
So, icpc option combination -fp:source -O1 has closest effect to Microsoft option -fp:fast. If you don't use float data types, -fp:double would have identical effect.
In case it's of interest, several C and C++ compilers in common use still have options which imply K&R treatment of parentheses, such as gcc -ffast-math, which by design allow the compiler to perform algebraic simplifications by disregarding parentheses.
0 Kudos
yuriisig
Beginner
392 Views

Not everyone has such deep knowledge as you. Previous versions did not require the option -fp:double. Microsoft's compiler option -fp: fast is working correctly, and Intel's compiler - no. Previous versions of the Intel's compiler work correctly with only one option -O2. I think that developers are too hasty.

0 Kudos
TimP
Honored Contributor III
392 Views
No, icc/icpc have always included aggressive optimizations which may violate the standards, as part of the default selection. You might reasonably argue that these defaults have become less tolerable, as hardware has improved so as to nearly remove the incentive for several of those defaults. Or, you might argue that choosing different meanings from Microsoft for /fp:fast, as well as making it the default, was not your favorite decision. Speaking for myself, I favor keeping vector sum reduction and vector math functions available under default, although I don't like the barriers against using those options without breaking correct code.
0 Kudos
yuriisig
Beginner
392 Views
Thank you: I am in favor of brackets will never break. Makes sense to introduce the parameter translator, who warned that the brackets can not be taken into account.
0 Kudos
JenniferJ
Moderator
392 Views
could you paste the code snipet here so we can take a look to see what can be done?

Thanks,
Jennifer
0 Kudos
yuriisig
Beginner
392 Views
could you paste the code snipet here so we can take a look to see what can be done?

I already wrote above that the option -fp: double corrects the situation.

Best regards,
Yurii

0 Kudos
yuriisig
Beginner
392 Views
Quoting yuriisig
could you paste the code snipet here so we can take a look to see what can be done?

I already wrote above that the option -fp: double corrects the situation.

I was very optimistic.
Here's the code snippet:
x=f1(a,b,c,...);
x=f2(x,f,g,...);
where f1 and f2 - arithmetic expressions (+,-,*,/,brackets).
The program works for such fragments in some cases incorrect.
Am submitting changes:
y=f1(a,b,c,...);
x=f2(y,f,g,...);
The program considers correct.
Interestingly, developers heard something about the IEEE?
0 Kudos
Reply