Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: MSVC code gen bug?

Author: Vincent Diepeveen

Date: 04:49:03 01/01/02

Go up one level in this thread


On December 31, 2001 at 15:47:25, Scott Gasch wrote:

>Hi all,
>
>I'm pulling my hair out right now with what looks like an MSVC code gen bug.
>Would someone please sanity check the following code?  Maybe I'm missing
>something?
>
>    j = 1;
>    do
>    {
>	ASSERT(j > 0);
>	ASSERT(j < 9);
>
>        if (pHash->iFiles[WHITE][j] != 0)
>        {
>            //
>            // Look for White doubled and tripled (etc...) pawns.
>            //
>            ASSERT(pHash->iFiles[WHITE][j] >= 0);
>            ASSERT(pHash->iFiles[WHITE][j] <= 8);
>            if (pHash->iFiles[WHITE][j] > 1)
>            {
>                iDoubled[WHITE] += pHash->iFiles[WHITE][j];
>            }
>
>            //
>            // We can detect White isolated pawns by looking at files.
>            //
>            if ((pHash->iFiles[WHITE][j - 1] == 0) &&
>                (pHash->iFiles[WHITE][j + 1] == 0))
>            {
>                //
>                // It's isolated, see if it's exposed.
>                //
>                if (pHash->iFiles[BLACK][j] == 0)
>                {
>#ifdef DEVAL
>                    EvalTrace(WHITE, PAWN, 0, g_iIsolatedExposedPawn,
>                              "isolated exp file %c",
>                              'A' + j - 1);
>#endif
>                    iScore[WHITE] += g_iIsolatedExposedPawn;
>                }
>                iIsolated[WHITE] += pHash->iFiles[WHITE][j];
>                ASSERT(iScore[WHITE] < 1500);
>            }
>
>            //
>            // Look for passed pawns...
>            //
>            i = pHash->iRanks[WHITE][j];

Is i signed or unsigned and iDoubled[2] is that signed or unsigned
and what datatypes is it?

I got so sick combining 8 bits and 32 bits code some years ago
because of all the suffering that i rewrote it all to 32 bits 'int'.

Now there are rumours that P4 is faster in unsigned arithmetic than
it is in signed :)

>            ASSERT(i > 1);
>            ASSERT(i < 8);
>
>This last bit (i = pHash->iRanks[WHITE][j]) is causing an access violation.  The
>problem is the code that MSVC generates for this seems to be wrong.  It's got
>the address of pHash in esi and the loop counter in ecx.  So when it accesses
>the pHash->iFiles[WHITE][j] array it uses code like this:
>
>100236F1   mov         al,byte ptr [esi+ecx+16h] // esi = &pHash, ecx = loop var
>
>This code is right.  Offset 16h in pHash is the start of the iFiles[WHITE] and
>it's a byte array.
>
>Meanwhile it has never put &pHash on the stack and in the offending line above
>it generates this code:
>
>1002374A   mov         edi,dword ptr [esp+24h]   // get pHash? pHash+20h? what?
>1002374E   xor         edx,edx
>10023750   mov         dl,byte ptr [edi+ecx+0Ah] // boom
>
>The address of pHash is still sitting in esi at this point.  It could very well
>have generated code that looked like this:
>
>xor edx,edx
>mov edx,byte ptr [esi+ecx+20h]
>
>What it instead reads from the stack into edi is NULL.  The address of pHash is
>nowhere on the stack as it has never been written there.  Even if the address of
>pHash magically somehow got into edi, the expression [edi+ecx+0Ah] would not
>equate to pHash->iRanks[WHITE][j].  For that to work edi needs to be the address
>of the start of the iRanks array in pHash... or &pHash + 20h.
>
>This goes away when I turn off global optimizations.  I'm working with MSVC6.0
>sp5.  Any clue what's going on here?  Eugene?  Anyone?  Help!
>
>Scott



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.