icpc optimization generates incorrect code

[szaboall_mit_edu]

Compiling with -O0 generates correct code; however, compiling with -O1 or -O2 or -O3 generates incorrect code. This is on RHEL 5.3 (x86_64) using icpc 11.0.083; gcc generates correct code in all cases. Something's not configured right or I'm missing a key compiler flag -- any ideas? Thanks in advance for any help!

Alex.

[TimP]

Is it an issue which would be addressed by -fp-model source, for example?

[JD_Patel · Accepted solution]

Could you please share specific details about the issue you're experiencing?
If you can attach a little test-case that demonstrate this issue would work the best.

Thanks.
- J.D. Patel

[aazue]

Quoting - J.D. Patel (Intel)

Could you please share specific details about the issue you're experiencing?
If you can attach a little test-case that demonstrate this issue would work the best.

Thanks.
- J.D. Patel

Hi all

If you can attach a little test-case that demonstrate this issue would work the best.

Sorry J.D. Patel
To recreate sample problem with an error that you having not find can
be impossible ..

Observed same problem (icc64 only,not with 32) with -O3 some source no for all ,but with -O2 true result for all.
Problem is some (char[]) are not correctly reinitialized after multiple use;
With C++ string object class problem solve
observed exactly same problem or greater with g++
Trace with debug this side to observe if eventual leak
produced.

O/S is Debian 5 (64)

Best regard

[szaboall_mit_edu]

Quoting - tim18

Is it an issue which would be addressed by -fp-model source, for example?

Probably not since the applications which fail use essentially no floating point.

In any case, testing is problematic since this is what I get when I add "-fp-model source":

icpc -I. -DTECHMATE_ICC_OPT -strict-ansi -xHost -O1 -fp-model source main.cc -lrt -o techmate
icpc: command line error: use of '-fp-model ' option along with a floating point precision option not supported

Am I missing something?

Alex.

[szaboall_mit_edu]

Quoting - J.D. Patel (Intel)

Could you please share specific details about the issue you're experiencing?
If you can attach a little test-case that demonstrate this issue would work the best.

Thanks.
- J.D. Patel

The problem was first noted in a large code set (>200,000 lines) that was never compiled with icc before. It would fail in some CORBA code when compiled with -O2 but when compiled with -O0 appear to work correctly. This code works correctly compiled with gcc (4.1.2 or 4.3.2) and -O2.

The problem has also been noted in a smaller code set (~5,000 lines). This code, about 5 years ago, was compiled successfully with icc (& gcc & with optimizations).

The issue is that the compiled code -- the executable -- does not generate the correct output when optimization is used. In the first case there's a segmentation fault; in the seconds case the output -- the generated chess move -- is wrong.

My working assumption is that I'm misusing the [icpc] compiler in some way.

My platform is a Dell T7400 with dual Intel X5482s and RHEL 5.3. I have both gcc 4.1.2 and gcc 4.3.2 installed.

I'm working on isolating the fault with a smaller piece of code.

Alex.

[aazue]

Quoting - szaboall.mit.edu

Quoting - J.D. Patel (Intel)

Could you please share specific details about the issue you're experiencing?
If you can attach a little test-case that demonstrate this issue would work the best.

Thanks.
- J.D. Patel

The problem was first noted in a large code set (>200,000 lines) that was never compiled with icc before. It would fail in some CORBA code when compiled with -O2 but when compiled with -O0 appear to work correctly. This code works correctly compiled with gcc (4.1.2 or 4.3.2) and -O2.

The problem has also been noted in a smaller code set (~5,000 lines). This code, about 5 years ago, was compiled successfully with icc (& gcc & with optimizations).

The issue is that the compiled code -- the executable -- does not generate the correct output when optimization is used. In the first case there's a segmentation fault; in the seconds case the output -- the generated chess move -- is wrong.

My working assumption is that I'm misusing the [icpc] compiler in some way.

My platform is a Dell T7400 with dual Intel X5482s and RHEL 5.3. I have both gcc 4.1.2 and gcc 4.3.2 installed.

I'm working on isolating the fault with a smaller piece of code.

Alex.

Hi
This code, about 5 years ago, was compiled successfully with icc (& gcc & with optimizations).

5 years ago,i think now that compiler GCC or ICC have changed and not relation with the old.
Can you test you small source((~5,000 lines) with last GCC 4.3.3 with flag -Wall to observe all warning.
My experience...
When i have upgrade compiler GNU 3.XXX to 4.XXX I have rewrite and modify several part all my sources
for resulting it work without problem ..
Exactly same task modification (G++) with Solaris,Aix and Linux, (Operating system 32 or 64 used).
Observed with Linux and Icc, less problem number occured that with Gcc in the upgrade..

If you having result ok without problem with last version GCC problem can be ICC or wrong flag ???..
Best regards

[szaboall_mit_edu]

Quoting - bustaf

Hi
This code, about 5 years ago, was compiled successfully with icc (& gcc & with optimizations).

5 years ago,i think now that compiler GCC or ICC have changed and not relation with the old.
Can you test you small source((~5,000 lines) with last GCC 4.3.3 with flag -Wall to observe all warning.
My experience...
When i have upgrade compiler GNU 3.XXX to 4.XXX I have rewrite and modify several part all my sources
for resulting it work without problem ..
Exactly same task modification (G++) with Solaris,Aix and Linux, (Operating system 32 or 64 used).
Observed with Linux and Icc, less problem number occured that with Gcc in the upgrade..

If you having result ok without problem with last version GCC problem can be ICC or wrong flag ???..
Best regards

I added -Wall and fixed the warnings -- all minor and of no consequence. The code still behaves the same: g++ & g++43 with & without optimization generate good results as does icpc without optimization (-O0), but icpc with optimization generates bad results.

Alex.

[TimP]

Quoting - szaboall.mit.edu

In any case, testing is problematic since this is what I get when I add "-fp-model source":


-strict-ansi -xHost -O1 -fp-model source main.cc main.cc -lrt -o techmate
icpc: command line error: use of '-fp-model ' option along with a floating point precision option not supported

This is a mighty strange remark. I don't see which options it could be complaining about, and I can't provoke anything like this.

It may be worth while to invoke source verifier, e.g.
icpc -I. -DTECHMATE_ICC_OPT -diag-enable sc main.cc

so as to see if the compiler has any complaints, or may be misinterpreting a scope.

[szaboall_mit_edu]

Quoting - szaboall.mit.edu

The problem was first noted in a large code set (>200,000 lines) that was never compiled with icc before. It would fail in some CORBA code when compiled with -O2 but when compiled with -O0 appear to work correctly. This code works correctly compiled with gcc (4.1.2 or 4.3.2) and -O2.

The problem has also been noted in a smaller code set (~5,000 lines). This code, about 5 years ago, was compiled successfully with icc (& gcc & with optimizations).

The issue is that the compiled code -- the executable -- does not generate the correct output when optimization is used. In the first case there's a segmentation fault; in the seconds case the output -- the generated chess move -- is wrong.

My working assumption is that I'm misusing the [icpc] compiler in some way.

My platform is a Dell T7400 with dual Intel X5482s and RHEL 5.3. I have both gcc 4.1.2 and gcc 4.3.2 installed.

I'm working on isolating the fault with a smaller piece of code.

Alex.

Here's the smaller piece of code that isolates the fault:

//
// $Id$
//
// Author:
// Alex Szabo -- szaboa@ll.mit.edu
//
// Purpose:
// Demonstrate icpc optimization bug.
//
// Usage:
// When compiled "icpc -O0 main.cc" resulting executable, when run,
// generates the correct result "x[0]=1";
// however, when compiled "icpc -O1 main.cc" resulting executable,
// when run, generates the incorrect result "x[0]=0".
//
// Notes:
// g++ & g++43 generate correct results in all cases (-O0,-O1,-O2,-O3).
//
// icpc versions 11.0.083, 11.1.038, & 11.1.046 are all broken with -O1;
// with -O0, -O2, or -O3 correct results are generated.
//

#include

int
main (int argc, char ** argv)
{
int x[2] = {0};
for (int i = -2; i < 0; i++)
if (i % -1 == 0)
x[i + 2] = 1;
printf ("x[0]=%dn", x[0]);
}

That's it! -- Alex.

[JD_Patel]

Hello Alex,

I have verified the issue and submitted to our engineering team for resolution.
I'll update you when progress is made.

Thanks for the test-case and your patience!
- J.D. Patel

[aazue]

Quoting - J.D. Patel (Intel)

Hello Alex,

I have verified the issue and submitted to our engineering team for resolution.
I'll update you when progress is made.

Thanks for the test-case and your patience!
- J.D. Patel

Hi J.D. Patel

I have verified the issue and submitted to our engineering team for resolution.

If you receive as response physical shoe don't be surprised....
probability to find same wrote in reality is same you find
an dog optimized with five foot or greater...

But ...., congratulation for your diplomacy.

Best regards