[bug report] some bug in loop unroll ?

[bug report] some bug in loop unroll ?

Yu Chih's picture

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.

17 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Tim Prince's picture

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's picture
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[i][j] = (patch_t*) calloc( 1, sizeof(patch_t) );   
  
    for( int i = 0; i < 3; i++ )   
        abc[i] = i;   
  
    patch->ptr[0][1]->father = 1;   
  
    Refine_Buffer(0);   
  
    for( int i = 0; i < 4; i++ )   
        cout << patch->ptr[1][i]->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[s]; SonPIDptr[lv][SonPID]->father == 1 )   
            {   
                for (int GrandPID=0; GrandPID<2; GrandPID++)   
                    patch->ptr[1][GrandPID]->father = SonPID;   
            }   
        }   
    }   
}   
#####################  End of Refine_Buffer.cpp  ##############################
Yu Chih's picture

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.

Tim Prince's picture

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

Yu Chih's picture

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's picture

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.

Tim Prince's picture

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

Jennifer J. (Intel)'s picture

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

Jennifer J. (Intel)'s picture

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.

Jennifer J. (Intel)'s picture
Best Reply

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

Tim Prince's picture

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's picture

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's picture

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.

Tim Prince's picture

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's picture

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 :)
Oliver 'kfs1' Smith, Lead Server Programmer, Cornered Rat Software / Battleground Europe
Jennifer J. (Intel)'s picture

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

Login to leave a comment.