Severe bug in VC5 compiler : Bad code generation 
Author Message
 Severe bug in VC5 compiler : Bad code generation

Hi !

VC5 generated the foolowing bug this morning. It is not registered in
Microsoft bug list, and is the most severe I've ever seen :

The following code :

 for( i = 0; i < iCount; i++ )
  {
        [ ... zip .... ]

    int iRc = SetVarValue( strVarName, Variant );

    if( iRc )       <======== BUG HERE
    {
      ASSERT_FAILURE;
      RetCode = SQL_ERROR;   <===== JUMP HERE
    }                        <===== INSTEAD OF HERE
  }
  return RetCode;

Quote:
}

generates this machine code :

973:      int iRc = SetVarValue( strVarName, Variant );
09577B3F   lea         ecx,dword ptr [Variant]
09577B42   push        ecx
09577B43   lea         ecx,dword ptr [strVarName]

09577B4B   push        eax
09577B4C   mov         ecx,dword ptr [this]
09577B4F   add         ecx,20h

09577B57   mov         dword ptr [iRc],eax
974:
975:      if( iRc )
09577B5A   cmp         dword ptr [iRc],0
 ********** BUG in the following line ******************
09577B5E   je        
COdbcStmtAccessorQuery::ReadParams(0x09577b7c)+14Fh
976:      {
977:        ASSERT_FAILURE;
09577B60   push        3D1h
09577B65   push        offset

09577B6A   push        1

09577B71   test        eax,eax
09577B73   je        
COdbcStmtAccessorQuery::ReadParams(0x09577b76)+149h
09577B75   int         3
978:        RetCode = SQL_ERROR;   // Return only the last error ?
09577B76   mov         word ptr
[RetCode],offset                        
COdbcStmtAccessorQuery::ReadParams(0x09577b7a)+14Dh
09577B7C   lea         ecx,dword ptr [strVarName]

09577B84   lea         ecx,dword ptr [Variant]

979:      }
980:    }
09577B8C   jmp        
COdbcStmtAccessorQuery::ReadParams(0x09577ab2)+85h
981:    return RetCode;
09577B91   mov         ax,word ptr [RetCode]
982:  }

The calculated offset is wrong (0x09577b7c) instead of (0x9577b8c).
It is certainly not a hardware problem, since it is reproductible
on different boxes.

        Does somebody have seen it, and found a solution ?
SP3 didn't fix it for a friend (was with an "if" in a "switch"...).
        Compiler is VC 5.0.

                Thanks for your help
                                        Bye !
--
Eric



Sun, 21 Jan 2001 03:00:00 GMT  
 Severe bug in VC5 compiler : Bad code generation

Quote:
>VC5 generated the foolowing bug this morning. It is not registered in
>Microsoft bug list, and is the most severe I've ever seen :

Eric,

Can you reproduce this code generation problem is a simple stand-alone
example?

The chances are that it's a peculiar combination of things in your
specific code that gives rise to this. Without a simple independent
piece of code that reproduces this problem, it'll be difficult to
test.

Dave
----
Address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow up email copies.



Mon, 22 Jan 2001 03:00:00 GMT  
 Severe bug in VC5 compiler : Bad code generation

Quote:

> Hi !

> VC5 generated the foolowing bug this morning. It is not registered in
> Microsoft bug list, and is the most severe I've ever seen :

        Well, after an in-depth analysis, it seems that only the debugging
infos are bad, and the code is ok. I saw that when I added an __asm nop
just after the jump :

Quote:
>     if( iRc )       <======== BUG HERE
>     {
>       ASSERT_FAILURE;
>       RetCode = SQL_ERROR;   <===== JUMP HERE
>     }                        <===== INSTEAD OF HERE
>   }

    __asm nop;  <-- here

Quote:
>   return RetCode;
> }

The machine code was ok, but it was exactly the same than the previous
one

Quote:
> 975:      if( iRc )
> 09577B5A   cmp         dword ptr [iRc],0
>  ********** BUG in the following line ******************
> 09577B5E   je
> COdbcStmtAccessorQuery::ReadParams(0x09577b7c)+14Fh
> 976:      {
> 977:        ASSERT_FAILURE;
> 09577B60   push        3D1h
> 09577B65   push        offset

> 09577B6A   push        1

> 09577B71   test        eax,eax
> 09577B73   je
> COdbcStmtAccessorQuery::ReadParams(0x09577b76)+149h
> 09577B75   int         3
> 978:        RetCode = SQL_ERROR;   // Return only the last error ?
> 09577B76   mov         word ptr
> [RetCode],offset
> COdbcStmtAccessorQuery::ReadParams(0x09577b7a)+14Dh

  979:      }     <== brace at the good place
  980:      __asm nop;
  09577B7C  nop

Quote:
> 09577B7D   lea         ecx,dword ptr [strVarName]

> 09577B85   lea         ecx,dword ptr [Variant]

> 981:    }
> 09577B8D   jmp
> COdbcStmtAccessorQuery::ReadParams(0x09577ab2)+85h
> 982:    return RetCode;
> 09577B92   mov         ax,word ptr [RetCode]
> 983:  }

        So the code is good, but it is difficult to believe it when the
debugging infos are wrong and the de{*filter*} jumps to an unexpected line.

        Dmitry as also another explanation and solution for this bug
(I quoted his message, since it can be interesting for a lot of people)

Quote:
>   Date: Thu, 6 Aug 1998 08:38:25 -0500


> Hello Eric,

>     I've had alike problem with the VC5 compiler. In that case the cause was
> the precompiled header. After I rebuilt it everything went fine.

> Cheers,
> Dmitry

                Bye !

                        Eric



Mon, 22 Jan 2001 03:00:00 GMT  
 Severe bug in VC5 compiler : Bad code generation

Quote:

> Hi !

> VC5 generated the foolowing bug this morning. It is not registered in
> Microsoft bug list, and is the most severe I've ever seen :

        Well, after an in-depth analysis, it seems that only the debugging
infos are bad, and the code is ok. I saw that when I added an __asm nop
just after the jump :

Quote:
>     if( iRc )       <======== BUG HERE
>     {
>       ASSERT_FAILURE;
>       RetCode = SQL_ERROR;   <===== JUMP HERE
>     }                        <===== INSTEAD OF HERE
>   }

    __asm nop;  <-- here

Quote:
>   return RetCode;
> }

The machine code was ok, but it was exactly the same than the previous
one

Quote:
> 975:      if( iRc )
> 09577B5A   cmp         dword ptr [iRc],0
>  ********** BUG in the following line ******************
> 09577B5E   je
> COdbcStmtAccessorQuery::ReadParams(0x09577b7c)+14Fh
> 976:      {
> 977:        ASSERT_FAILURE;
> 09577B60   push        3D1h
> 09577B65   push        offset

> 09577B6A   push        1

> 09577B71   test        eax,eax
> 09577B73   je
> COdbcStmtAccessorQuery::ReadParams(0x09577b76)+149h
> 09577B75   int         3
> 978:        RetCode = SQL_ERROR;   // Return only the last error ?
> 09577B76   mov         word ptr
> [RetCode],offset
> COdbcStmtAccessorQuery::ReadParams(0x09577b7a)+14Dh

  979:      }     <== brace at the good place
  980:      __asm nop;
  09577B7C  nop

Quote:
> 09577B7D   lea         ecx,dword ptr [strVarName]

> 09577B85   lea         ecx,dword ptr [Variant]

> 981:    }
> 09577B8D   jmp
> COdbcStmtAccessorQuery::ReadParams(0x09577ab2)+85h
> 982:    return RetCode;
> 09577B92   mov         ax,word ptr [RetCode]
> 983:  }

        So the code is good, but it is difficult to believe it when the
debugging infos are wrong and the de{*filter*} jumps to an unexpected line.

        Dmitry as also another explanation and solution for this bug
(I quoted his message, since it can be interesting for a lot of people)

Quote:
>   Date: Thu, 6 Aug 1998 08:38:25 -0500


> Hello Eric,

>     I've had alike problem with the VC5 compiler. In that case the cause was
> the precompiled header. After I rebuilt it everything went fine.

> Cheers,
> Dmitry

                Bye !

                        Eric



Mon, 22 Jan 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. BUG: bad code generation with if statements

2. Compiler Code Generation Bug with /O2 optimization

3. Microsoft C 6.0 BAD code generation

4. VC++ 5.0 bad code generation - memory leaks

5. VC++ 6 SP5 - bad code generation with intrinsics

6. compiler bug visual c++ 4.0 4.2 bad cast

7. VC7 code generation bug?

8. code generation bug

9. C7 code generation bug

10. Code generation bug in Microsoft C 5.1

11. Severe MIDL Bug

12. Stack checking code generation bug in VC .net

 

 
Powered by phpBB® Forum Software