wrong source line indication for instructions in some loops

wrong source line indication for instructions in some loops

Ritratto di 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[i] = 1.0;
}

Instructions corresponding to t[i] = 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[n]" makes the problem disappear
* removing -fno-inline-functions prevents icc from unrolling

What do you think ?

Thank you in advance

7 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di mark-sabahi (Intel)

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

Thanks,
--mark

Ritratto di 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[i] = u[i] + 1.0;
}

return u;
}

* The instruction loading u[i] 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[i] 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)

Ritratto di mark-sabahi (Intel)

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

Ritratto di mark-sabahi (Intel)

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

--mark

Ritratto di 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

Ritratto di mark-sabahi (Intel)

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

Thanks,
--mark

Accedere per lasciare un commento.