[bug report] some bug in loop unroll ?

[Yu_Chih]

I do not know how to explain this bug with my poor English.

Here is the section where I think the bug occured.

##########################################
int lv = 0;
int SonPID0 = 183;
int GrandPID0 = 160;

if ( GrandPID0 != -1 )
{
patch->ptr[0][lv+1][SonPID]->son = GrandPID0;

for (int GrandPID=GrandPID0; GrandPID patch->ptr[0][lv+2][GrandPID]->father = SonPID;

}
#########################################

if there is no bug, the code will excute

patch->ptr[0][1][183]->son = 160;

patch->ptr[0][2][160]->father = 183;
patch->ptr[0][2][161]->father = 183;
patch->ptr[0][2][162]->father = 183;
patch->ptr[0][2][163]->father = 183;
patch->ptr[0][2][164]->father = 183;
patch->ptr[0][2][165]->father = 183;
patch->ptr[0][2][166]->father = 183;
patch->ptr[0][2][167]->father = 183;

but acutully the following was done

patch->ptr[0][1][183]->son = 160;

patch->ptr[0][2][161]->father = 183;
patch->ptr[0][2][162]->father = 183;
patch->ptr[0][2][163]->father = 183;
patch->ptr[0][2][164]->father = 183;
patch->ptr[0][2][165]->father = 183;
patch->ptr[0][2][166]->father = 183;
patch->ptr[0][2][167]->father = 183;
patch->ptr[0][2][168]->father = 183;

It left"patch->ptr[0][2][160]->father" behind, but write to the wrong place "patch->ptr[0][2][160]->father"


I checked my code several times, until I used the Intel Debugger which printed the value of these variable.

So I think it may have a bug in the loop unrolling.

Is there any way by which I can upload my whole code to be analize?

But the whole program contains about ten thousand lines.

What should I do to report this bug officially?

Thank you.

[TimP]

You could submit your problem report at https://premier.intel.com. If you didn't set up a support account, you can do that at https://registrationcenter.intel.com.

[Yu_Chih]

[cpp]
[/cpp]
[cpp]aa
I took a lot of effort to minimize the code, and now there are only tens of line in this  
code.

The result should be
1
1
0
0

but Intel C Compiler (11.1.069) give
0
0
1
0

with the commannd line
icpc Main.cpp Refine_Buffer.cpp && ./a.out

OS : CentOS 5.4 with kernel 2.6.18-164.11.1.el5 
 

#############################  GAMER.h  ###################################   
#include    
using namespace std;   
  
struct patch_t   
{   
    int corner[3];   
    int father;   
};   
  
struct AMR_t   
{   
    patch_t *ptr[2][4];   
};   
##########################  End of GAMER.h  #################################   
  
    
#############################  Main.cpp  ###################################   
#include "GAMER.h"   
  
AMR_t *patch;   
int abc[3];   
  
void Refine_Buffer(const int lv);   
  
int main()   
{   
    patch = (AMR_t*) calloc( 1, sizeof(AMR_t) );   
  
    for( int i = 0; i < 2; i++ )   
    for( int j = 0; j < 4; j++ )   
        patch->ptr = (patch_t*) calloc( 1, sizeof(patch_t) );   
  
    for( int i = 0; i < 3; i++ )   
        abc = i;   
  
    patch->ptr[0][1]->father = 1;   
  
    Refine_Buffer(0);   
  
    for( int i = 0; i < 4; i++ )   
        cout << patch->ptr[1]->father << endl;   
  
    return 0;   
}   
##########################  End of Main.cpp  ##################################   
  
    
########################  Refine_Buffer.cpp  ##################################   
#include "GAMER.h"   
  
extern AMR_t *patch;   
extern int abc[3];   
  
void Refine_Buffer( const int lv )   
{   
    for (int s=0; s<2; s++)   
    {   
        for (int SonPID=abc; SonPIDptr[lv][SonPID]->father == 1 )   
            {   
                for (int GrandPID=0; GrandPID<2; GrandPID++)   
                    patch->ptr[1][GrandPID]->father = SonPID;   
            }   
        }   
    }   
}   
#####################  End of Refine_Buffer.cpp  ##############################[/cpp]

[Yu_Chih]

I use theNon-Commercial C Compiler for linux, so I can't register the premier support.

May somebody help me to report this bug to engineers of intel, or test the bug to see if itis really from the Compiler ?

Thanks very much.

[TimP]

You're entitled to submit a bug report in the same way as with a paid license.

[Yu_Chih]

I have tried, but it responses

"You are attempting to access Intel Premier Support but you do not have a user account."


Is there anythingI missed so that I didn't register the account?

Thank you for your reply.

[Yu_Chih]

I have tried it again, but I can't still access the Intel Premier Support.

I have only this account to visit the forum and knowledge base.

Can Non-Commercial Key get the premier support ?

Thanks.

[TimP]

Yes, if you didn't already register your non-commercial key, you can use it at registrationcenter to create a support account.

[JenniferJ]

I'll file a bug repor when I duplicate this issue here.

Yes, you can create a Premier Support account when you sign-up for eval or NCOM. There is a check-box for creating a Premier Support account.

Thanks for cutting down the testcase. It's usually very time consuming.

Jennifer

[JenniferJ]

could you let me know your compile options?

On Linux, ic 11.1.069, even I turned off unroll, it still gives me wrong result except using -O0.

[JenniferJ · Accepted solution]

I did find a work-around. Building "buffer.cpp" with -O1 works.

I'll file a bug to the compiler team to fix. But for now please use the work-around.

Thanks for reporting!
Jennifer

[TimP]

If -O1 works, perhaps /fp:source will work at -O2. The default options intentionally break some code. As far as I know, the reason for that is mostly historical. However, the idea of providing a set of options which allows full vectorization without breaking correct code was rejected in favor of the /fp:source recommendation.

[Yu_Chih]

Inthe original case, turn off the optimization option will fix the bug, and the idb gives the value of variables intended to be changed with an offset so I thought it's unroll bug at that time.

After cutting the code down, some properties changed, so the -unroll0 optionmakes no difference.

In the original case, there are a lot of trick to suppress the bugfor examplecout the loop counter or the value of variable which is changed in the loop.

I am deeply grateful that you have paid attention to this bug.


best regards,

Yu-Chih

[Yu_Chih]

I have no idea that how could floating point model affect a loop which deal with integer value assigning?

But I will try the suggestion and try to understand it.

Thanks for the new knowledge providing.

[TimP]

Well, you're right, fp-model should have an effect only when there is floating point code in or neighboring the loop in question.

[kfsone]

What result do you get if you try the following:

int lv = 0;
int SonPID0 = 183;
int GrandPID0 = 160;

if ( GrandPID0 != -1 )
{
patch->ptr[0][lv+1][SonPID]->son = GrandPID0;

for (int GrandPID=GrandPID0; GrandPID++GrandPID)
patch->ptr[0][lv+2][GrandPID]->father = SonPID;

}

Also, you might want to consider helping the compiler with some aliasing and some additional value markup, something like:

const int lv = 0;
static const unsigned intSonPID0 = 183;
static const unsigned int GrandPID0 = 160;

if ( GrandPID0 != -1 )
{

patch->ptr[0][lv+1][SonPID]->son = GrandPID0;

for (unsigned int GrandPID=GrandPID0; GrandPID

patch->ptr[0][lv+2][GrandPID]->father = SonPID;

}

Little hints like these can often be a huge help to getting the results you expect :)

[JenniferJ]

Our report shows this issue in the original posting has been fixed in the latest 11.1 update 8 and 12.0 compiler update2.

Regards,
Jennifer