Optimization does not account for gentlemen's agreement

[yuriisig]

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.

[Milind_Kulkarni__Int]

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++)

[yuriisig]

Quoting Milind Kulkarni (Intel)

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.

[TimP]

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.

[yuriisig]

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.

[TimP]

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.

[yuriisig]

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.

[JenniferJ]

could you paste the code snipet here so we can take a look to see what can be done?

Thanks,
Jennifer

[yuriisig]

Quoting Jennifer Jiang (Intel)

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

[yuriisig]

Quoting yuriisig

Quoting Jennifer Jiang (Intel)

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?