wrong source line indication for instructions in some loops

[eoseret]

Hello,

Contrary to gcc and icc 11.1, I encounter wrong source line number indication for instructions in some loops.

I can reproduce the problem if I compile the following function (alone in a C file) using the latest version of icc (12.1.0) with flags "-g -S -fno-inline-functions":

void foo (int n, double *t) {
int i;

for (i=0; i t = 1.0;
}

Instructions corresponding to t = 1.0 are labeled as source line 1 instead of 5.

Other strange facts:
* the loop is unrolled (-g implies -O0 and I don't think loop unrolling should occur at O0...)
* removing -fno-inline-functions or replacing "double *t" with "double t" makes the problem disappear
* removing -fno-inline-functions prevents icc from unrolling

What do you think ?

Thank you in advance

[Mark_S_Intel1]

I can reproduce the issue. I will look further and get back to you.

Thanks,
--mark

[eoseret]

On my side, I tried the code:
double *foo (int n, double *t) {
int i;

double *u = malloc (n * sizeof *u);

for (i=0; i t = u + 1.0;
}

return u;
}

* The instruction loading u is labelled as line 4 (line where u is declared)
* The instruction adding 1.0 is correctly labelled (as line 7)
* The instruction storing to t is labelled as line 1 (line where t is declared)

Consequently, when line is not correctly labelled, the reported line is the line where the corresponding array is declared (and not always the line where the definition of the function containing the loop)

[Mark_S_Intel1]

Thanks for the update. I filed a report on this issue and will let you know when I get an update from the development team.

--mark

[Mark_S_Intel1]

Just one clarification that -g does not imply -O0. The debug level and optimization level should be independent.

--mark

[eoseret]

According to man icc: "These options [-g (Linux* OS and Mac OS* X) and /Z7 (Windows*)] turn off O2 and make O0 (Linux OS and Mac OS X) or Od (Windows) the default unless O2 (or higher) is explicitly specified in the same command line."

And I made this experience to confirm (O2 is the default optimization level):
$ icc -c -g test_loop_line.c -o test_loop_line_g.o
$ icc -c -g -O0 test_loop_line.c -o test_loop_line_g_O0.o
$ icc -c -g -O1 test_loop_line.c -o test_loop_line_g_O1.o
$ icc -c -g -O2 test_loop_line.c -o test_loop_line_g_O2.o
$ ll test_loop_line_g*.o
-rw-r--r-- 1 eoseret permanents 2808 2011-09-15 08:58 test_loop_line_g.o
-rw-r--r-- 1 eoseret permanents 2808 2011-09-15 08:59 test_loop_line_g_O0.o
-rw-r--r-- 1 eoseret permanents 2560 2011-09-15 08:59 test_loop_line_g_O1.o
-rw-r--r-- 1 eoseret permanents 2920 2011-09-15 08:59 test_loop_line_g_O2.o
$ diff test_loop_line_g.o test_loop_line_g_O0.o => no diff

[Mark_S_Intel1]

This issue has been resolved in Intel(R) C++ Composer XE 13.0 update available for download at registrationcenter.intel.com Thanks, --mark