compiler dependent scores!

Discussion of chess software programming and technical issues.

Moderator: Ras

jswaff

compiler dependent scores!

Post by jswaff »

I noticed during CCT that Prophet was returning some really unusual scores for even positions. Coming out of book in an even position it would be at +1 ish for White or -1 when playing black.

I traced it back to the compiler. When using the Intel compiler I'm having these problems, but not when using gcc. Below is the output from one such position.

Prophet is using YBW, but this is happening even when using a single search thread. Ideas??


Using the Intel compiler:

Code: Select all

 1&   -96      1       123   Nc6
 1.   -96      1       160   Nc6
 2&  -108      1       243   Nc6 Bb5
 2&   -96      3       648   Bg4 d5
 2.   -96      4       737   Bg4 d5
 3&   -92      8      1754   Nc6 Bg5 Be6
 3.   -92      9      2015   Nc6 Bg5 Be6
 4&  -111     27      7527   Nc6 d5 Nb4 Ng5
 4.  -111     33      8901   Nc6 d5 Nb4 Ng5
 5&  -120     49     14581   Nc6 Bb5 exd4 Nxd4 Bd7
 5&  -115     59     18696   exd4 Nxd4 c5 Bb5+ Nb8d7
 5&  -109     82     28113   Nb8d7 Bc4 exd4 Nxd4 Ne5
 5.  -109     82     28177   Nb8d7 Bc4 exd4 Nxd4 Ne5
 6&  -137    110     40703   Nb8d7 Bd3 c5 dxe5 Nxe5 O-O Nxd3 Qxd3
 6&  -113    135     51986   exd4 Nxd4 c5 Nf5 Nxe4 Nxg7+
 6.  -113    179     69200   exd4 Nxd4 c5 Nf5 Nxe4 Nxg7+
 7&  -112    242    105482   exd4 Nxd4 Nb8d7 Bd3 c5 Nf5 Ne5
 7.  -112    287    126301   exd4 Nxd4 Nb8d7 Bd3 c5 Nf5 Ne5
 8&  -106    384    187909   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4b5 Nc6
 8.  -106    472    238191   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4b5 Nc6
 9&  -119    577    302589   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4
 9.  -119    891    493615   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4
10&   -99   2552   1530810   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4e2 Qc6 f3 Nb8d7
10.   -99   2776   1667864   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4e2 Qc6 f3 Nb8d7
11&  -111   3751   2245483   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4 Qe6
11.  -111   4478   2713455   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4 Qe6
12&  -115  15082   9765049   exd4 Nxd4 Be7 Bc4 O-O O-O Nb8d7 Bf4 Ne5 Bb3 c5 Nd4b5
12.  -115  16717  10815991   exd4 Nxd4 Be7 Bc4 O-O O-O Nb8d7 Bf4 Ne5 Bb3 c5 Nd4b5
Using g++:

Code: Select all

 1&    -1      0       123   Nc6
 1.    -1      1       157   Nc6
 2&   -13      1       230   Nc6 Bb5
 2.   -13      2       352   Nc6 Bb5
 3&    -3      4       814   Nc6 Bb5 Bd7
 3.    -3      6      1127   Nc6 Bb5 Bd7
 4&   -21     11      2492   Nc6 d5 Nb4 Be3
 4.   -21     21      4514   Nc6 d5 Nb4 Be3
 5&   -19     46     13127   Nb8d7 Be3 Be7 dxe5 Nxe5 Nxe5 dxe5
 5.   -19     50     14183   Nb8d7 Be3 Be7 dxe5 Nxe5 Nxe5 dxe5
 6&   -48     97     32764   Nb8d7 Bd3 exd4 Nxd4 c5 Nf5
 6&   -28    154     55506   exd4 Nxd4 c5 Nd4b5 Nc6 a4
 6.   -28    195     69070   exd4 Nxd4 c5 Nd4b5 Nc6 a4
 7&   -12    284    105240   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 Bd7
 7.   -12    312    116482   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 Bd7
 8&   -25    394    163498   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 c6 Be2
 8.   -25    561    241059   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 c6 Be2
 9&   -33   1581    608170   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
 9.   -33   1917    785017   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
10&   -33   2742   1246247   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
10.   -33   3227   1515792   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
11&   -29   4677   2348672   exd4 Qxd4 Be7 Bb5+ c6 Bc4 Nb8d7 Bf4 b5 Be2 Qb6
11.   -29   5664   2923281   exd4 Qxd4 Be7 Bb5+ c6 Bc4 Nb8d7 Bf4 b5 Be2 Qb6
12&   -28   9895   5395230   exd4 Qxd4 Nc6 Bb5 Bd7 Qc4 Be7 O-O O-O Nd5 Nxd5 Qxd5
12.   -28  13239   6898899   exd4 Qxd4 Nc6 Bb5 Bd7 Qc4 Be7 O-O O-O Nd5 Nxd5 Qxd5
Karlo Bala
Posts: 373
Joined: Wed Mar 22, 2006 10:17 am
Location: Novi Sad, Serbia
Full name: Karlo Balla

Re: compiler dependent scores!

Post by Karlo Bala »

jswaff wrote:I noticed during CCT that Prophet was returning some really unusual scores for even positions. Coming out of book in an even position it would be at +1 ish for White or -1 when playing black.

I traced it back to the compiler. When using the Intel compiler I'm having these problems, but not when using gcc. Below is the output from one such position.

Prophet is using YBW, but this is happening even when using a single search thread. Ideas??


Using the Intel compiler:

Code: Select all

 1&   -96      1       123   Nc6
 1.   -96      1       160   Nc6
 2&  -108      1       243   Nc6 Bb5
 2&   -96      3       648   Bg4 d5
 2.   -96      4       737   Bg4 d5
 3&   -92      8      1754   Nc6 Bg5 Be6
 3.   -92      9      2015   Nc6 Bg5 Be6
 4&  -111     27      7527   Nc6 d5 Nb4 Ng5
 4.  -111     33      8901   Nc6 d5 Nb4 Ng5
 5&  -120     49     14581   Nc6 Bb5 exd4 Nxd4 Bd7
 5&  -115     59     18696   exd4 Nxd4 c5 Bb5+ Nb8d7
 5&  -109     82     28113   Nb8d7 Bc4 exd4 Nxd4 Ne5
 5.  -109     82     28177   Nb8d7 Bc4 exd4 Nxd4 Ne5
 6&  -137    110     40703   Nb8d7 Bd3 c5 dxe5 Nxe5 O-O Nxd3 Qxd3
 6&  -113    135     51986   exd4 Nxd4 c5 Nf5 Nxe4 Nxg7+
 6.  -113    179     69200   exd4 Nxd4 c5 Nf5 Nxe4 Nxg7+
 7&  -112    242    105482   exd4 Nxd4 Nb8d7 Bd3 c5 Nf5 Ne5
 7.  -112    287    126301   exd4 Nxd4 Nb8d7 Bd3 c5 Nf5 Ne5
 8&  -106    384    187909   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4b5 Nc6
 8.  -106    472    238191   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4b5 Nc6
 9&  -119    577    302589   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4
 9.  -119    891    493615   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4
10&   -99   2552   1530810   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4e2 Qc6 f3 Nb8d7
10.   -99   2776   1667864   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4e2 Qc6 f3 Nb8d7
11&  -111   3751   2245483   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4 Qe6
11.  -111   4478   2713455   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4 Qe6
12&  -115  15082   9765049   exd4 Nxd4 Be7 Bc4 O-O O-O Nb8d7 Bf4 Ne5 Bb3 c5 Nd4b5
12.  -115  16717  10815991   exd4 Nxd4 Be7 Bc4 O-O O-O Nb8d7 Bf4 Ne5 Bb3 c5 Nd4b5
Using g++:

Code: Select all

 1&    -1      0       123   Nc6
 1.    -1      1       157   Nc6
 2&   -13      1       230   Nc6 Bb5
 2.   -13      2       352   Nc6 Bb5
 3&    -3      4       814   Nc6 Bb5 Bd7
 3.    -3      6      1127   Nc6 Bb5 Bd7
 4&   -21     11      2492   Nc6 d5 Nb4 Be3
 4.   -21     21      4514   Nc6 d5 Nb4 Be3
 5&   -19     46     13127   Nb8d7 Be3 Be7 dxe5 Nxe5 Nxe5 dxe5
 5.   -19     50     14183   Nb8d7 Be3 Be7 dxe5 Nxe5 Nxe5 dxe5
 6&   -48     97     32764   Nb8d7 Bd3 exd4 Nxd4 c5 Nf5
 6&   -28    154     55506   exd4 Nxd4 c5 Nd4b5 Nc6 a4
 6.   -28    195     69070   exd4 Nxd4 c5 Nd4b5 Nc6 a4
 7&   -12    284    105240   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 Bd7
 7.   -12    312    116482   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 Bd7
 8&   -25    394    163498   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 c6 Be2
 8.   -25    561    241059   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 c6 Be2
 9&   -33   1581    608170   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
 9.   -33   1917    785017   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
10&   -33   2742   1246247   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
10.   -33   3227   1515792   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
11&   -29   4677   2348672   exd4 Qxd4 Be7 Bb5+ c6 Bc4 Nb8d7 Bf4 b5 Be2 Qb6
11.   -29   5664   2923281   exd4 Qxd4 Be7 Bb5+ c6 Bc4 Nb8d7 Bf4 b5 Be2 Qb6
12&   -28   9895   5395230   exd4 Qxd4 Nc6 Bb5 Bd7 Qc4 Be7 O-O O-O Nd5 Nxd5 Qxd5
12.   -28  13239   6898899   exd4 Qxd4 Nc6 Bb5 Bd7 Qc4 Be7 O-O O-O Nd5 Nxd5 Qxd5
I had similar (but not same) problem with VS. Everything worked fine in debug version but not in release version. Bug was really funny. During eval data initialization I wrote some data out of buffer. In debug version there was enough room between two data block so there was no error. In release version compiler merged two data block and I rewrote already initialized data...
Best Regards,
Karlo Balla Jr.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: compiler dependent scores!

Post by bob »

jswaff wrote:I noticed during CCT that Prophet was returning some really unusual scores for even positions. Coming out of book in an even position it would be at +1 ish for White or -1 when playing black.

I traced it back to the compiler. When using the Intel compiler I'm having these problems, but not when using gcc. Below is the output from one such position.

Prophet is using YBW, but this is happening even when using a single search thread. Ideas??
It is almost guaranteed to be an uninitialized local variable. Since these are allocated on the stack, different compilers will call different things which alter the stack in different ways, giving you different garbage each time you use that value.

If you use gcc with -O2, it will do a dependency analysis and report such potential problems so that you can fix them before they bite...



Using the Intel compiler:

Code: Select all

 1&   -96      1       123   Nc6
 1.   -96      1       160   Nc6
 2&  -108      1       243   Nc6 Bb5
 2&   -96      3       648   Bg4 d5
 2.   -96      4       737   Bg4 d5
 3&   -92      8      1754   Nc6 Bg5 Be6
 3.   -92      9      2015   Nc6 Bg5 Be6
 4&  -111     27      7527   Nc6 d5 Nb4 Ng5
 4.  -111     33      8901   Nc6 d5 Nb4 Ng5
 5&  -120     49     14581   Nc6 Bb5 exd4 Nxd4 Bd7
 5&  -115     59     18696   exd4 Nxd4 c5 Bb5+ Nb8d7
 5&  -109     82     28113   Nb8d7 Bc4 exd4 Nxd4 Ne5
 5.  -109     82     28177   Nb8d7 Bc4 exd4 Nxd4 Ne5
 6&  -137    110     40703   Nb8d7 Bd3 c5 dxe5 Nxe5 O-O Nxd3 Qxd3
 6&  -113    135     51986   exd4 Nxd4 c5 Nf5 Nxe4 Nxg7+
 6.  -113    179     69200   exd4 Nxd4 c5 Nf5 Nxe4 Nxg7+
 7&  -112    242    105482   exd4 Nxd4 Nb8d7 Bd3 c5 Nf5 Ne5
 7.  -112    287    126301   exd4 Nxd4 Nb8d7 Bd3 c5 Nf5 Ne5
 8&  -106    384    187909   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4b5 Nc6
 8.  -106    472    238191   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4b5 Nc6
 9&  -119    577    302589   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4
 9.  -119    891    493615   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4
10&   -99   2552   1530810   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4e2 Qc6 f3 Nb8d7
10.   -99   2776   1667864   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nd4e2 Qc6 f3 Nb8d7
11&  -111   3751   2245483   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4 Qe6
11.  -111   4478   2713455   exd4 Nxd4 c5 Bb5+ Bd7 Bxd7+ Qxd7 Nf5 Nxe4 Nxg7+ Bxg7 Nxe4 Qe6
12&  -115  15082   9765049   exd4 Nxd4 Be7 Bc4 O-O O-O Nb8d7 Bf4 Ne5 Bb3 c5 Nd4b5
12.  -115  16717  10815991   exd4 Nxd4 Be7 Bc4 O-O O-O Nb8d7 Bf4 Ne5 Bb3 c5 Nd4b5
Using g++:

Code: Select all

 1&    -1      0       123   Nc6
 1.    -1      1       157   Nc6
 2&   -13      1       230   Nc6 Bb5
 2.   -13      2       352   Nc6 Bb5
 3&    -3      4       814   Nc6 Bb5 Bd7
 3.    -3      6      1127   Nc6 Bb5 Bd7
 4&   -21     11      2492   Nc6 d5 Nb4 Be3
 4.   -21     21      4514   Nc6 d5 Nb4 Be3
 5&   -19     46     13127   Nb8d7 Be3 Be7 dxe5 Nxe5 Nxe5 dxe5
 5.   -19     50     14183   Nb8d7 Be3 Be7 dxe5 Nxe5 Nxe5 dxe5
 6&   -48     97     32764   Nb8d7 Bd3 exd4 Nxd4 c5 Nf5
 6&   -28    154     55506   exd4 Nxd4 c5 Nd4b5 Nc6 a4
 6.   -28    195     69070   exd4 Nxd4 c5 Nd4b5 Nc6 a4
 7&   -12    284    105240   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 Bd7
 7.   -12    312    116482   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 Bd7
 8&   -25    394    163498   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 c6 Be2
 8.   -25    561    241059   exd4 Nxd4 Nb8d7 Be3 Ne5 f3 c6 Be2
 9&   -33   1581    608170   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
 9.   -33   1917    785017   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
10&   -33   2742   1246247   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
10.   -33   3227   1515792   exd4 Qxd4 Be7 Bb5+ c6 Be2 O-O O-O d5 exd5 Nxd5 Nxd5 Qxd5 Qxd5 cxd5
11&   -29   4677   2348672   exd4 Qxd4 Be7 Bb5+ c6 Bc4 Nb8d7 Bf4 b5 Be2 Qb6
11.   -29   5664   2923281   exd4 Qxd4 Be7 Bb5+ c6 Bc4 Nb8d7 Bf4 b5 Be2 Qb6
12&   -28   9895   5395230   exd4 Qxd4 Nc6 Bb5 Bd7 Qc4 Be7 O-O O-O Nd5 Nxd5 Qxd5
12.   -28  13239   6898899   exd4 Qxd4 Nc6 Bb5 Bd7 Qc4 Be7 O-O O-O Nd5 Nxd5 Qxd5
jswaff

Re: compiler dependent scores!

Post by jswaff »

bob wrote:
If you use gcc with -O2, it will do a dependency analysis and report such potential problems so that you can fix them before they bite...
Unfortunately -O2 and even -Wall don't report any errors. This should be fun...
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: compiler dependent scores!

Post by bob »

jswaff wrote:
bob wrote:
If you use gcc with -O2, it will do a dependency analysis and report such potential problems so that you can fix them before they bite...
Unfortunately -O2 and even -Wall don't report any errors. This should be fun...
Note that GCC can't discover bad array references as the dependency analysis isn't that clever. I would then start looking at array references, and perhaps even look into something like purify or the bounds checker of your choice to look for bad array subscripts. But even that won't detect cases where you refer to some element of a locally declared array that has not yet been initialized. But if gcc finds/reports no errors, you are pretty much into the world of either array access issues or pointer issues if you use those anywhere...
jswaff

Re: compiler dependent scores!

Post by jswaff »

bob wrote:
jswaff wrote:
bob wrote:
If you use gcc with -O2, it will do a dependency analysis and report such potential problems so that you can fix them before they bite...
Unfortunately -O2 and even -Wall don't report any errors. This should be fun...
Note that GCC can't discover bad array references as the dependency analysis isn't that clever. I would then start looking at array references, and perhaps even look into something like purify or the bounds checker of your choice to look for bad array subscripts. But even that won't detect cases where you refer to some element of a locally declared array that has not yet been initialized. But if gcc finds/reports no errors, you are pretty much into the world of either array access issues or pointer issues if you use those anywhere...
Oh yes, all over the place. I just discovered that the bug only surfaces with -O2 or above. At -O1 the scores are "normal." Well, looks like a good time to learn how to use Valgrind.
jwes
Posts: 778
Joined: Sat Jul 01, 2006 7:11 am

Re: compiler dependent scores!

Post by jwes »

Since the problem appears to happen at ply 1, you could dump the ply 1 trees with both versions and see where they differ and then go in with your debugger, or even just start stepping with your debugger until you get a wrong number.
jswaff

getting VERY weird

Post by jswaff »

Very strange goings on..

I traced the problem back to the bitboard array to_boundary[Square][Direction]. The North, NorthWest, NorthEast directions only have one bit set. They are initialized as follows.

Code: Select all

        // precompute bitboards from each square to boundary
        for (int c=0;c<64;c++) {
                for (int k=0;k<8;k++) {
                        to_boundary[c][k]=0;
                        switch (k) {
                        case N: /* up */
                                if (c==E4) {
                                   printf("building to_boundary[E4][N]...\n");
                                }
                                for (int t=1;t<8;t++) {
           ------->                  if (c==E4) printf("considering t=%d\n",t);
                                        if (c-(t*8)<0) break;
                                        if (c==E4) printf("adding bm_mask %d\n",c-(t*8));
                                        to_boundary[c][k]|=bm_mask[c-(t*8)];
                                }
                                break;
                        case NW: /* upleft */

                       <snipped>
Now, with the printf I marked above commented in, all is well:

Code: Select all

building to_boundary[E4][N]...
considering t=1
adding bm_mask 28
considering t=2
adding bm_mask 20
considering t=3
adding bm_mask 12
considering t=4
adding bm_mask 4
considering t=5
in init:
00001000
00001000
00001000
00001000
00000000
00000000
00000000
00000000
But with it commented out:

Code: Select all

building to_boundary[E4][N]...
adding bm_mask 28
in init:
00000000
00000000
00000000
00001000
00000000
00000000
00000000
00000000
Now, this only happens with the Intel compiler with optimizations >= 02.
Also this is on a 64 bit machine; I haven't tried it on a 32 bit machine yet.
I know better than to be quick to blame a compiler, but ... ?

Edit: just double checked, it happens with -O1 as well, but not with -O0.

--
James
Alessandro Scotti

Re: getting VERY weird

Post by Alessandro Scotti »

Have you tried to declare t as volatile?
jswaff

Re: getting VERY weird

Post by jswaff »

Alessandro Scotti wrote:Have you tried to declare t as volatile?
I just did, and this does work:

Code: Select all

                                for (volatile int t=1;t<8;t++) {
//                                        if (c==E4) printf("considering t=%d\n",t);
                                        if (c-(t*8)<0) break;
                                        if (c==E4) printf("adding bm_mask %d\n",c-(t*8));
                                        to_boundary[c][k]|=bm_mask[c-(t*8)];
                                }
Why? t is local in scope. Looks like the compiler is optimizing most of my loop away when it shouldn't be.

--
James