I am an ardent admirer of Stockfish, and been using it since the day the very first version was released. Thoroughout the years, I have observed the great progress of Stockfish and it is truly remarkable to see it prosper. It is absolutely near-perfect in all areas of chess, but if there's one thing that makes Stockfish look like a 1200-elo rated chess engine, it's finding tactical or positional sacrifices in complex or simple positions. That's the main weakness, and I have seen many people report it but no progress have been seen so far on this. I believe there needs to be much attention paid on this.

Exposing the weakness:

PROBLEM 1:

8/1pN4r/5pkp/8/5K1p/2P4N/P3Bn2/8 w - - 0 1

In this position, Stockfish fails to find a very simple Bh5+, even after 2 hours of analysis while Houdini, Critter and even Toga found it within some seconds.

PROBLEM 2:

r1b2rk1/2q1bppp/pp2p3/2npP3/1n3P1P/2NBBN2/PPPQ2P1/1K1R3R w - - 0 14

Once again, Stockfish fails quite hard in finding an immensely simple Bxh7. And one more time, Houdini along with other weaker engines found this move easily.

PROBLEM 3:

4rb2/1p1q1ppk/p1n1p2p/2p1Pn2/3PNR2/2P2K2/P2QBP2/6R1 w - - 0 1

This is complete horror for Stockfish, as it fails in both evaluation and finding the right move which is Rxf5. Stockfish thinks it's black who is winning, while quite clearly...White has a 6-move mate over black.

PROBLEM 4 (the hardest one, also responsible for making Stockfish look like a chess beginner):

4q1kr/p6p/1prQPppB/4n3/4P3/2P5/PP2B2P/R5K1 w - - 0 24

Finding the right move, Qxe5 is impossible for Stockfish. It fails to find it, even after 24 hours of analysis.

There are many other problems which Stockfish fails miserably in solving and these four are among of them. I hope the developers take a great look on this and focus on fixing this weakness.

Hi,

I'd really love to work on an open source competitive multiplayer derivative of the StockFish app for iOS, unfortunately the technical reading of the law is that GPL is completely incompatible with iOS.

Even if I release my final source code, and distribute the app entirely for free (which is definitely the plan), I could be sued later if I'm not given express permission from all contributors.

I've started this as a discussion on the StockFish support page, which references FSF's stance on iOS and it's GPL 3.0 license.

http://support.stockfishchess.org/discussions/questions/1550-licensing-of-entire-ios-app

Would it be possible for all contributors to agree to an addendum to the license allowing iOS App Store distribution? ie: "As an addendum to GPL 3.0, you have my permission to publish free derivative software to the iOS App Store, as long you distribute any modified source code."

Thank you!

Reading blog...
http://blog.stockfishchess.org/

Stockfish 6
Stockfish 6 is now available!

Stockfish 5
Stockfish 5 is now available!

...
But no dates anywhere. (what is "now available?" 2014? 2013 ?)

Please add dates.
Also, if possible, add the major change list, that contribute the most towards ELO gain.

The following unusual, but legal position triggers an infinite loop with "go depth 1"

position fen 7k/QQQQR3/2B5/4KN1Q/3QQ3/8/8/4R3 b - - 0 1
go depth 1

Would you accept patches adding a command to probe the tablebases for debugging or adding some output to d?

As reported here:

http://talkchess.com/forum/viewtopic.php?t=55010&postdays=0&postorder=asc&topic_view=&start=10

"What I mentioned about the POPCNT version not having memory leak is incorrect. Out of the box there is no problem, but if you set the syzygy path for the engine the leak will become obvious in infinite analysis. The inclusion of syzygy seems to be the cause. I downloaded the release candidate stockfish_15011815_x64_modern.exe for this test."

To be confirmed.

Played a 100 game match between SF and K. Although SF won the match overall (53.5 to 46.5 - great result), it lost 4 dead draw games on time. Tc was 3min/40moves. repeating. Pondering off, 24 threads. Shortest game was 112 moves, longest game was 234 moves. K did not lose any games on time.

On https://stockfishchess.org/download/ one can see that there is version 7 available for download. They seem to be hosted on amazon aws. So far I got my binaries form the GitHub release page and this is also were I create my packages from. Is version 7 going to be added there too?

I wanted to propose adding an armv5 target. Maybe nobody uses this except me, so I'm not sure how important this is. Anyway, here are the steps I use to compile stockfish on my kirkwood devices (armv5te).

Regarding step 1, I think that replacement might be preferable even for armv7. Recent gcc is smart enough to perform that optimization when it encounters __builtin_ctz(), so there should be no need to add the asm and subsequent clz call. This also applies to MIPS. But I don't want to hurt any armv7 performance if I'm wrong... Mostly I suggest checking this out and (probably) switching for all ARM.

Step 2.b is quite specific to the hardware I run and also (less so) to the gcc version I use. (I use 4.8.x and greater) So 2.b is probably not recommended to be added in its entirety. Perhaps -mtune=armv5 would be best here. Probably -fno-caller-saves is universally useful too. I don't think PIE matters for armv5 which is why you don't see that anywhere.

So here's the steps I take when compiling for kirkwood:

1. update bitboard.h

Replace

    inline int lsb32(uint32_t v) {
      __asm__("rbit %0, %1" : "=r"(v) : "r"(v));
      return __builtin_clz(v);
    }

With

    inline int lsb32(uint32_t v) {
      return __builtin_ctz(v);
    }

2. update Makefile

a) add configuration for armv5 target somewhere near the similar armv7 conf

            ifeq ($(ARCH),armv5)
                    arch = armv5
                    prefetch = yes
                    bsfq = yes
            endif

b) armv5 CXXFLAGS specific to this device and gcc version
ifeq ($(arch),armv5)
CXXFLAGS += -pipe -march=armv5te -mtune=xscale -fweb -fno-caller-saves -frename-registers -fomit-frame-pointer
endif

c) add armv5 target to the help section near armv7

            @echo "armv5                   > ARMv5 32-bit"

d) include armv5 in the sanity check
@test "$(arch)" = "ppc64" || test "$(arch)" = "ppc" || test "$(arch)" = "armv7" || test "$(arch)" = "armv5"

3. build

make profile-build ARCH=armv5

With icc, -m is similar to -march, and thus not additional, but overrides some previously set flags.

$ icc -mavx -msse
icc: command line warning #10120: overriding '-mavx' with '-msse'

Stockfish uses -fast for optimised builds, which is short for other flags. Such as -xHost, which can be overriden by the later set -msse and -msse3 flags. It makes for slower builds.

Last output after 9 sec, then no more output for 6 minutes !?
CPU still at 100% usage

Conditions :
With only 1 best line (couldn't reproduced with 2 best lines).
Syzygy 6 pieces
6 cores-6 threads

Same problem with version "stockfish_16011823_x64_modern.exe"

FEN: 3Q4/7p/p7/8/8/6p1/2k1n1P1/7K w - - 0 12

Stockfish_16012415_x64_modern:
...
50/76 00:01 44.831k 30.812k +5,78 12.Qa5 h6 13.Qa2+ Kd3 14.Qxa6+ Kd2 15.Qa5+ Ke3 16.Qb6+ Kd2 17.Qb4+ Kd3 18.Qa3+ Kd2 19.Qa7 Ke1 20.Qa5+ Kf1 21.Qf5+ Ke1 22.Qe6 h5 23.Qf5 h4 24.Qe5 Kf2 25.Qc5+ Kf1 26.Qf8+ Ke1 27.Qh6 Kf1 28.Qg5 Kf2 29.Qe5 Kf1 30.Qa5 Kf2 31.Qb4 Ke3 32.Qc5+ Kd2 33.Qe5 Ke1 34.Qf6 Kd2 35.Qg5+ Ke1 36.Qd5 Kf2 37.Qf7+ Ke1 38.Qg7 Kf2 39.Qa1 Ke3 40.Qa3+ Kf2 41.Qf3+ Ke1 42.Qf5 Kd2 43.Qa5+ Ke3 44.Qb6+ Kd2 45.Qd6+ Ke3 46.Qh6+ Kf2 47.Qe6 Ke1 48.Qd6 Kf1 49.Qf6+ Ke1
51/76 00:01 54.664k 30.419k +5,78 12.Qa5 h6 13.Qa2+ Kd3 14.Qxa6+ Kd2 15.Qa5+ Ke3 16.Qb6+ Kd2 17.Qb4+ Kd3 18.Qa3+ Kd2 19.Qa7 Ke1 20.Qa5+ Kf1 21.Qf5+ Ke1 22.Qe6 h5 23.Qf5 h4 24.Qe5 Kf2 25.Qc5+ Kf1 26.Qf8+ Ke1 27.Qh6 Kf1 28.Qg5 Kf2 29.Qe5 Kf1 30.Qa5 Kf2 31.Qb4 Ke3 32.Qc5+ Kd2 33.Qe5 Ke1 34.Qf6 Kd2 35.Qg5+ Ke1 36.Qd5 Kf2 37.Qf7+ Ke3 38.Qb3+ Kf2 39.Qb6+ Ke1 40.Qd6 Kf1 41.Qf6+ Ke1 42.Qf5 Kd2 43.Qa5+ Ke3 44.Qa3+ Kf2 45.Qf3+ Ke1 46.Qe3 Kf1 47.Qe4 Ke1 48.Qg4 Kf2 49.Qe6 Kf1
52/81 00:02 72.445k 31.663k +5,78 12.Qa5 h6 13.Qa2+ Kd3 14.Qxa6+ Kd2 15.Qa5+ Ke3 16.Qb6+ Kd2 17.Qb4+ Kd3 18.Qa3+ Kd2 19.Qa7 Ke1 20.Qa5+ Kf1 21.Qf5+ Ke1 22.Qe6 h5 23.Qf5 h4 24.Qe5 Kf2 25.Qc5+ Kf1 26.Qf8+ Ke1 27.Qh6 Kf1 28.Qg5 Kf2 29.Qe5 Kf1 30.Qa5 Kf2 31.Qb4 Ke3 32.Qc5+ Kd2 33.Qe5 Ke1 34.Qf6 Kd2 35.Qg5+ Ke1 36.Qd5 Kf2 37.Qf7+ Ke3 38.Qb3+ Kf2 39.Qb6+ Ke1 40.Qd6 Kf1 41.Qf6+ Ke1 42.Qf5 Kd2 43.Qa5+ Ke3 44.Qa3+ Kf2 45.Qf3+ Ke1 46.Qe3 Kf1 47.Qe4 Ke1 48.Qg4 Kf2 49.Qe6 Kf1 50.Qf7+ Ke1 51.Qg7 Kf2 52.Qa1
53/84 00:04 159.631k 34.182k +5,78 12.Qa5 h6 13.Qa2+ Kd3 14.Qxa6+ Kd2 15.Qa5+ Ke3 16.Qb6+ Kd2 17.Qb4+ Kd3 18.Qa3+ Kd2 19.Qa7 Ke1 20.Qa5+ Kf1 21.Qf5+ Ke1 22.Qe6 h5 23.Qf5 h4 24.Qe5 Kf2 25.Qc5+ Kf1 26.Qf8+ Ke1 27.Qh6 Kf1 28.Qg5 Kf2 29.Qe5 Kf1 30.Qa5 Kf2 31.Qb4 Ke3 32.Qc5+ Kd2 33.Qe5 Ke1 34.Qf6 Kd2 35.Qg5+ Ke1 36.Qd5 Kf2 37.Qf7+ Ke3 38.Qb3+ Kf2 39.Qb6+ Ke1 40.Qd6 Kf1 41.Qf6+ Ke1 42.Qf5 Kd2 43.Qa5+ Ke3 44.Qa3+ Kf2 45.Qf3+ Ke1 46.Qe3 Kf1 47.Qe4 Ke1 48.Qd3 Kf2 49.Qa3 Kf1 50.Qa1+ Kf2 51.Qb1 Ke3 52.Qb6+ Kd2
54/84 00:09 324.986k 35.748k +5,78 12.Qa5 h6 13.Qa2+ Kd3 14.Qxa6+ Kd2 15.Qa5+ Ke3 16.Qb6+ Kd2 17.Qb4+ Kd3 18.Qa3+ Kd2 19.Qa7 Ke1 20.Qa5+ Kf1 21.Qf5+ Ke1 22.Qe6 h5 23.Qf5 h4 24.Qe5 Kf2 25.Qc5+ Kf1 26.Qf8+ Ke1 27.Qh6 Kf1 28.Qg5 Kf2 29.Qe5 Kf1 30.Qa5 Kf2 31.Qb4 Ke3 32.Qc5+ Kd2 33.Qe5 Ke1 34.Qf6 Kd2 35.Qg5+ Ke1 36.Qd5 Kf2 37.Qf7+ Ke3 38.Qb3+ Kf2 39.Qb6+ Ke1 40.Qd6 Kf1 41.Qf6+ Ke1 42.Qf5 Kd2 43.Qa5+ Ke3 44.Qa3+ Kf2 45.Qf3+ Ke1 46.Qe3 Kf1 47.Qe4 Ke1 48.Qd3 Kf2 49.Qc4 Ke3 50.Qe6+ Kd2 51.Qd6+ Ke1 52.Qb4+ Kf1 53.Qc5
55/84 00:09 340.052k 35.935k +5,78 12.Qa5 h6 13.Qa2+ Kd3 14.Qxa6+ Kd2 15.Qa5+ Ke3 16.Qb6+ Kd2 17.Qb4+ Kd3 18.Qa3+ Kd2 19.Qa7 Ke1 20.Qa5+ Kf1 21.Qf5+ Ke1 22.Qe6 h5 23.Qf5 h4 24.Qe5 Kf2 25.Qc5+ Kf1 26.Qf8+ Ke1 27.Qh6 Kf1 28.Qg5 Kf2 29.Qe5 Kf1 30.Qa5 Kf2 31.Qb4 Ke3 32.Qc5+ Kd2 33.Qe5 Ke1 34.Qf6 Kd2 35.Qg5+ Ke1 36.Qd5 Kf2 37.Qf7+ Ke3 38.Qb3+ Kf2 39.Qb6+ Ke1 40.Qd6 Kf1 41.Qf6+ Ke1 42.Qf5 Kd2 43.Qa5+ Ke3 44.Qa3+ Kf2 45.Qf3+ Ke1 46.Qe3 Kf1 47.Qe4 Ke1 48.Qd3 Kf2 49.Qc4 Ke3 50.Qe6+ Kd2 51.Qd6+ Ke1 52.Qe7 Kf1

(normal build still works.)

g++ -o stockfish benchmark.o bitbase.o bitboard.o endgame.o evaluate.o main.o material.o misc.o movegen.o movepick.o pawns.o position.o search.o thread.o timeman.o tt.o uci.o ucioption.o syzygy/tbprobe.o -lgcov -arch x86_64 -mmacosx-version-min=10.6 -lpthread -Wall -Wcast-qual -fno-exceptions -fno-rtti -fprofile-arcs -ansi -pedantic -Wno-long-long -Wextra -Wshadow -arch x86_64 -mmacosx-version-min=10.6 -DNDEBUG -O3 -mdynamic-no-pic -DIS_64BIT -msse -DUSE_BSFQ -msse3 -mpopcnt -DUSE_POPCNT -flto
:unknown:Undefined local symbol LPBX0.10683.10683
:unknown:Undefined local symbol LPBX0.8784.8784
:unknown:Undefined local symbol LPBX0.7229.7229
:unknown:Undefined local symbol LPBX0.4739.4739
lto-wrapper: g++ returned 1 exit status
collect2: error: lto-wrapper returned 1 exit status

Try this code: || d > depth8 - 5 in 53 article tt.h Local tests was very good!

So long as they are only read/written under lock protection, we are safe from unwanted compiler optimization.

Also, the bool members of SignalsType should be std::atomic_flag, or std::atomic<bool>, if we wanted to modify them outside lock protection.

Am I missing something ?

In Makefile lto is turned off for mingw. But while using mingw compiler on Ubuntu 15.04 lto can be turned on. See, for example, http://abrok.eu/stockfish/

In position.cpp, void Position::set(const string& fenStr, bool isChess960, Thread* th):

There is no checking for colour of the rook when finding rsq for castling.

for (rsq = relative_square(c, SQ_A1); type_of(piece_on(rsq)) != ROOK; ++rsq) {}

In some positions, it may pick up an opponent rook:
4k3/pppppppp/8/8/8/8/PPPPPPPP/rR2K3 w Q - 0 1

When analysing the following position:
2k5/3P4/8/8/8/8/1r5p/R3K3 b Q - 0 1
bestmove with 5-men tables is c8d7, with "black wins" score.
If one makes that move and analyses the resulting position without syzygy, SF shows a "white wins" score.

The cause is probably the tablebase result being used without checking if castling rights exist.

I have this warnings when building with gcc

syzygy/tbprobe.cpp: In function ‘int probe_ab(Position&, int, int, int_)’:
syzygy/tbprobe.cpp:204:14: warning: array subscript is above array bounds [-Warray-bounds]
p[i++] = pop_lsb(&bb) ^ mirror;
^
syzygy/tbprobe.cpp:204:14: warning: array subscript is above array bounds [-Warray-bounds]
syzygy/tbprobe.cpp: In function ‘int Tablebases::probe_dtz(Position&, int_)’:
syzygy/tbprobe.cpp:314:14: warning: array subscript is above array bounds [-Warray-bounds]
p[i++] = pop_lsb(&bb) ^ mirror;
^
syzygy/tbprobe.cpp:314:14: warning: array subscript is above array bounds [-Warray-bounds]

rn3k1r/p2nqpp1/b1p1p2p/3pP3/1p1P1N2/3B2Q1/PPP1NPP1/2KR3R w - - 2 15
In this position the latest Stockfish with 5-men syzygy bases does not see the right move: Ng6+

Just to say that profile build failed with gcc48 and gcc49 and gcc51 (osX 10.10.3)
for both build and profile-build

the reason was g++: error: unrecognized command line option '-Wl'

PS: with clang only build worked (as usual)

Here is the message starting from the warning (same for the 3 gcc):

syzygy/tbprobe.cpp: In function 'probe_ab(Position&, int, int, int_)':
syzygy/tbprobe.cpp:206:14: warning: array subscript is above array bounds [-Warray-bounds]
p[i++] = pop_lsb(&bb) ^ mirror;
^
syzygy/tbprobe.cpp:206:14: warning: array subscript is above array bounds [-Warray-bounds]
syzygy/tbprobe.cpp: In function 'Tablebases::probe_dtz(Position&, int_)':
syzygy/tbprobe.cpp:316:14: warning: array subscript is above array bounds [-Warray-bounds]
p[i++] = pop_lsb(&bb) ^ mirror;
^
syzygy/tbprobe.cpp:316:14: warning: array subscript is above array bounds [-Warray-bounds]
g++ -o stockfish benchmark.o bitbase.o bitboard.o endgame.o evaluate.o main.o material.o misc.o movegen.o movepick.o pawns.o position.o psqt.o search.o thread.o timeman.o tt.o uci.o ucioption.o syzygy/tbprobe.o -lgcov -Wl -arch x86_64 -mmacosx-version-min=10.9 -lpthread -Wall -Wcast-qual -fno-exceptions -fno-rtti -std=c++11 -fprofile-generate -pedantic -Wno-long-long -Wextra -Wshadow -arch x86_64 -mmacosx-version-min=10.9 -DNDEBUG -O3 -mdynamic-no-pic -DIS_64BIT -msse -DUSE_BSFQ -flto
g++: error: unrecognized command line option '-Wl'
make[2]: *** [stockfish] Error 1
make[1]: *** [gcc-profile-make] Error 2
make: *** [profile-build] Error 2

I have major compiling issues on ARM/Linux hardware:

(to compile on ARM Cubietruck / Debian 7:)
A:
yes, the Makefile is for a specific OS, but uses the architecture only. I guess it is a Makefile bug, but I don't know what an acceptable general solution would be (maintainers?). As a workaround add -lpthread to the LDFLAGS in the Makefile (near line 326).

1. add -lpthread to the LDFLAGS
2. change to -mfloat-abi=hard (from softfp)

Please take a look, if compiling for ARM can be fixed / auto-detected anyhow.
NOTE: take care, because changing the Makefile can break Android compilation on ARM.

-Technologov

Maybe I'm doing something wrong, but Stockfish occasionally gives me a score of 0 when there are many moves in the position command, but if I use the fen from the same position, it finds a simple mate. Here's an example.

position startpos moves e2e4 e7e6 d2d4 f7f5 e4f5 d8h4 g1f3 f8b4 c1d2 h4e4 f1e2 c7c5 f5e6 d7e6 c2c3 h7h6 c3b4 e6e5 b1c3 e4g6 f3e5 g6f5 e2g4 g8f6 g4f5 c8f5 g2g4 f5g4 d1g4 f6g4 f2f3 b8c6 f3g4 c6d4 d2e3 a8d8 e3d4 c5d4 a1d1 a7a6 e1g1 h8f8 f1f8 e8f8 c3e2 d4d3 e5d3 b7b6 e2c3 f8e7 d3f4 d8d6 c3d5 e7d7 d5b6 d7c7 b6d5 c7b8 d5e3 d6c6 a2a4 b8c7 e3d5 c7d8 b4b5 c6d6 b5b6 d8d7 a4a5 d7d8 d1d4 h6h5 g4h5 d6h6 d5b4 d8e8 b4a6 e8f8 b6b7 g7g5 b7b8q f8f7 b8b7 f7f6 b7b6 f6e5 d4d5 e5e4 b6h6 e4f4 h6g5 f4e4 g5e5 e4f3 d5d3 f3g4 e5g5 g4g5 g1g2 g5f5 d3e3 f5f4 g2f2 f4g4 e3f3 g4h4 f3f4 h4g5 f2g3 g5h6 f4f5 h6h7 g3g4 h7h8 f5f6 h8h7 g4g5 h7g7 f6f5 g7h7 g5f6 h7g8 f5g5 g8h8 f6f7 h8h7 g5g7 h7h8 g7g6 h8h7 g6f6 h7h8 f6g6 h8h7 g6f6
go depth 10

gives the following

info depth 1 seldepth 1 multipv 1 score cp 0 nodes 2 nps 1000 tbhits 0 time 2 pv h7h8
info depth 2 seldepth 2 multipv 1 score cp 0 nodes 4 nps 2000 tbhits 0 time 2 pv h7h8
info depth 3 seldepth 2 multipv 1 score cp 0 nodes 6 nps 3000 tbhits 0 time 2 pv h7h8
info depth 4 seldepth 2 multipv 1 score cp 0 nodes 8 nps 4000 tbhits 0 time 2 pv h7h8
info depth 5 seldepth 2 multipv 1 score cp 0 nodes 10 nps 5000 tbhits 0 time 2 pv h7h8
info depth 6 seldepth 2 multipv 1 score cp 0 nodes 12 nps 6000 tbhits 0 time 2 pv h7h8
info depth 7 seldepth 2 multipv 1 score cp 0 nodes 14 nps 7000 tbhits 0 time 2 pv h7h8
info depth 8 seldepth 2 multipv 1 score cp 0 nodes 16 nps 8000 tbhits 0 time 2 pv h7h8
info depth 9 seldepth 2 multipv 1 score cp 0 nodes 18 nps 9000 tbhits 0 time 2 pv h7h8
info depth 10 seldepth 2 multipv 1 score cp 0 nodes 20 nps 10000 tbhits 0 time 2 pv h7h8
bestmove h7h8

Whereas

position fen 8/5K1k/N4R2/P6P/8/8/1P5P/8 b - - 37 68
go depth 10

outputs

info depth 1 seldepth 1 multipv 1 score mate -1 nodes 4 nps 4000 tbhits 0 time 1 pv h7h8 f6h6
info depth 2 seldepth 3 multipv 1 score mate -1 nodes 8 nps 8000 tbhits 0 time 1 pv h7h8 f6h6
info depth 3 seldepth 3 multipv 1 score mate -1 nodes 12 nps 12000 tbhits 0 time 1 pv h7h8 f6h6
info depth 4 seldepth 3 multipv 1 score mate -1 nodes 16 nps 16000 tbhits 0 time 1 pv h7h8 f6h6
info depth 5 seldepth 3 multipv 1 score mate -1 nodes 20 nps 20000 tbhits 0 time 1 pv h7h8 f6h6
info depth 6 seldepth 3 multipv 1 score mate -1 nodes 24 nps 24000 tbhits 0 time 1 pv h7h8 f6h6
info depth 7 seldepth 3 multipv 1 score mate -1 nodes 28 nps 28000 tbhits 0 time 1 pv h7h8 f6h6
info depth 8 seldepth 3 multipv 1 score mate -1 nodes 32 nps 32000 tbhits 0 time 1 pv h7h8 f6h6
info depth 9 seldepth 3 multipv 1 score mate -1 nodes 36 nps 36000 tbhits 0 time 1 pv h7h8 f6h6
info depth 10 seldepth 3 multipv 1 score mate -1 nodes 40 nps 40000 tbhits 0 time 1 pv h7h8 f6h6
bestmove h7h8 ponder f6h6

even though these positions are the same.

I also noticed that Fruit has this exact same problem; however, the Komodo I tried (an older free version) finds the mate with both commands.

In this position; 3r4/4r2k/3p1p1b/2n1p1pQ/2B1b3/P3B1PP/2PR1P2/3R2K1 w - - 0 34

At first, Stockfish decided to actually play for a DRAW when there's a clear mate in 9! It was not until 15 minutes, when SF decided to choose Bxg5 (which is the right move and can mate black in just 9 moves, or less)

This problem effects time management adversely.

I'm not very familiar with this code but it seems to me that

void update(Piece pc, Square to, Value v) {

    if (Gain)
        table[pc][to] = std::max(v, table[pc][to] - 1);

    else if (abs(table[pc][to] + v) < Max)
        table[pc][to] +=  v;
}

was maybe really intended to be

void update(Piece pc, Square to, Value v) {

    if (Gain)
        table[pc][to] = std::max(v, table[pc][to] - 1);
    else
        table[pc][to] = std::min(std::max(table[pc][to] + v, Value(1 - Max)), Value(Max - 1));
}

Let's say for example the current value of table[pc][to] is 200 and update() is called(Gain = false) with v of 40. The result will be 240. If instead update() gets called with v of 60 the result will be 200. It seems inconsistent that an update with a smaller v can result in a greater final value than an update with a larger v. I think the result of the v=60 update in this example should be 249(the maximum allowed). Could someone familiar with this code confirm that this is a bug? Also if I wanted to submit this fix to fishtest what would be the appropriate sprt parameters? I doubt it's a significant elo gain.

Thanks Fisherman

Stockfish sometimes lose on time because timer thread does not have enough processor time (when stockfish threads count equal processor phisical cores). It can be solved by increasing timer thread priority. In this case (in my tests) Stockfish never lose on time

I'm unsure if this is caused by polyglot or stockfish, but I'll post here anyway just in case.

Requires xboard, stockfish and polyglot to be installed
Steps to reproduce:

1. xboard -fcp stockfish -fUCI -scp stockfish -sUCI
2. Edit > Edit Position
3. Move black king to e3
4. Mode > Two Machines

Result: POLYGLOT: pipex_exit(): stockfish child terminated with signal 11.

Hi,

I use stockfish with scid and I have a crash on specific position, I test it only on stockfish :

$ stockfish
Stockfish 261014 64 by Tord Romstad, Marco Costalba and Joona Kiiski
position fen r3rRk1/1ppb2pp/p1p5/2n1q3/3N4/1P4Q1/PBPN2PP/6K1 b KQkq - 0 4
go infinite
info depth 1 seldepth 1 score cp 32 nodes 155 nps 22142 time 7 multipv 1 pv g8f8 d4e6 f8g8 b2e5 c5e6
info depth 2 seldepth 2 score cp 32 nodes 208 nps 29714 time 7 multipv 1 pv g8f8 d4e6 f8g8 b2e5 c5e6
info depth 3 seldepth 3 score cp 32 nodes 281 nps 40142 time 7 multipv 1 pv g8f8 d4e6 f8g8 b2e5 c5e6
info depth 4 seldepth 4 score cp 32 nodes 390 nps 48750 time 8 multipv 1 pv g8f8 d4e6 f8g8 b2e5 c5e6
info depth 5 seldepth 5 score cp 32 nodes 534 nps 66750 time 8 multipv 1 pv g8f8 d4e6 f8g8 b2e5 c5e6
info depth 6 seldepth 8 score cp 779 nodes 4051 nps 337583 time 12 multipv 1 pv g8f8 g3e5 e8e5 g2g4 c5b3 d4b3
info depth 7 seldepth 8 score cp 877 nodes 7420 nps 436470 time 17 multipv 1 pv g8f8 g3e5 e8e5 g2g4 d7g4 h8h7 e5h5 h7g6 c5b3 d4b3 h5h2
info depth 8 seldepth 9 score cp 877 nodes 8635 nps 479722 time 18 multipv 1 pv g8f8 g3e5 e8e5 g2g4 d7g4 h8h7 e5h5 h7g6 c5b3 d4b3 h5h2
info depth 9 seldepth 14 score cp 983 nodes 29470 nps 589400 time 50 multipv 1 pv g8f8 g1f1 e5g3 h2g3 c5b3 d2b3 f8f7 f1g1 g7g6 h8h7
Segmentation fault (core dumped)

Inter compiler under Linux gives following warnings:

icpc -Wall -Wcast-qual -fno-exceptions -fno-rtti -diag-disable 11,1476,10120 -Wcheck -Wabi -Wdeprecated -strict-ansi -I/usr/include/x86_64-linux-gnu/c++/4.8/ -g -fast -DIS_64BIT -msse -DUSE_BSFQ -msse3 -DUSE_POPCNT -c -o syzygy/tbprobe.o syzygy/tbprobe.cpp
In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(223): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
entry->num += pcs[i];
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(231): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->pawns[0] = pcs[TB_WPAWN];
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(232): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->pawns[1] = pcs[TB_BPAWN];
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(235): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->pawns[0] = pcs[TB_BPAWN];
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(236): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->pawns[1] = pcs[TB_WPAWN];
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(248): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->enc_type = 1 + j;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(838): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
norm[0] = ptr->enc_type - 1;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(868): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->pieces[0][i] = data[i + 1] & 0x0f;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(874): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->pieces[1][i] = data[i + 1] >> 4;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(886): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->pieces[i] = data[i + 1] & 0x0f;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(901): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->file[f].pieces[0][i] = data[i + j] & 0x0f;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(908): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->file[f].pieces[1][i] = data[i + j] >> 4;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(922): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
ptr->file[f].pieces[i] = data[i + j] & 0x0f;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(939): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
d->symlen[s] = d->symlen[s1] + d->symlen[s2] + 1;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(945): warning #2259: non-pointer conversion from "int" to "ushort={unsigned short}" may lose significant bits
return d[0] | (d[1] << 8);
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(1231): warning #2259: non-pointer conversion from "int" to "ubyte={unsigned char}" may lose significant bits
return d->min_len;
^

In file included from syzygy/tbprobe.cpp(21):
syzygy/tbcore.cpp(1241): warning #2259: non-pointer conversion from "int" to "ushort={unsigned short}" may lose significant bits
idxOffset = (idxOffset << 8) | (idxOffset >> 8);

Compiler:
$ icc -v
icc version 14.0.1 (gcc version 4.8.0 compatibility)

Make command:
make build debug=yes optimize=yes ARCH=x86-64-modern COMP=icc

Profile build broken with Clang after commit 46d5fff

Tested with Clang 3.5 on Ubuntu 14.04

Steps to reproduce:

make clean
make profile-build debug=yes optimize=yes ARCH=x86-64-modern COMP=clang

I noticed this problem with Stockfish 6 64 POPCNT.

Here the essential communication over uci.

Mon Nov 16 2015 12:42:01 GMT+0100 (CET) >>>> uci
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< Stockfish 6 64 POPCNT by Tord Romstad, Marco Costalba and Joona Kiiski
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< id name Stockfish 6 64 POPCNT
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< id author Tord Romstad, Marco Costalba and Joona Kiiski
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Write Debug Log type check default false
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Contempt type spin default 0 min -100 max 100
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Min Split Depth type spin default 0 min 0 max 12
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Threads type spin default 1 min 1 max 128
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Hash type spin default 16 min 1 max 1048576
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Clear Hash type button
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Ponder type check default true
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name MultiPV type spin default 1 min 1 max 500
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Skill Level type spin default 20 min 0 max 20
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Move Overhead type spin default 30 min 0 max 5000
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Minimum Thinking Time type spin default 20 min 0 max 5000
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Slow Mover type spin default 80 min 10 max 1000
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name UCI_Chess960 type check default false
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name SyzygyPath type string default
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name SyzygyProbeDepth type spin default 1 min 1 max 100
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name Syzygy50MoveRule type check default true
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< option name SyzygyProbeLimit type spin default 6 min 0 max 6
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< uciok
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) >>>> isready
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) <<<< readyok
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) >>>> setoption name MultiPV value 3
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) >>>> setoption name Hash value 32
Mon Nov 16 2015 12:42:01 GMT+0100 (CET) >>>> setoption name Threads value 1
Mon Nov 16 2015 12:42:30 GMT+0100 (CET) >>>> ucinewgame
Mon Nov 16 2015 12:42:30 GMT+0100 (CET) >>>> position fen 5r2/4q1k1/3p2p1/2pPp1bp/1pP1P1N1/rP4PQ/5P2/1R1R2K1 w - - 0 1
Mon Nov 16 2015 12:42:30 GMT+0100 (CET) >>>> setoption name MultiPV value 3
Mon Nov 16 2015 12:42:30 GMT+0100 (CET) >>>> go nodes 30000000

and then after some time

Mon Nov 16 2015 12:42:38 GMT+0100 (CET) <<<< info depth 19 seldepth 35 multipv 1 score cp -187 nodes 5713122 nps 755604 tbhits 0 time 7561 pv g4h2 a3a2 d1f1 a2e2 b1d1 e2e4 d1e1 e4e1 f1e1 e7f7 h3g2 g5d2 e1f1 d2c3 g2e4 f7f5 e4f5 f8f5 f2f3 c3d4 g1g2 f5f8 f1e1 f8a8 h2f1 a8a3
Mon Nov 16 2015 12:42:38 GMT+0100 (CET) <<<< info depth 19 seldepth 35 multipv 2 score cp -437 nodes 5713122 nps 755604 tbhits 0 time 7561 pv g4e3 g5e3 f2e3 e7g5 g1h1 g5e3 d1e1 e3f3 h3g2 a3b3 g2f3 f8f3 b1b3 f3b3 h1g2 b3c3 e1a1 c3c4 g2f3 c4c3 f3f2 c3a3 a1b1 g7f6
Mon Nov 16 2015 12:42:38 GMT+0100 (CET) <<<< info depth 18 seldepth 35 multipv 3 score mate 0 nodes 5713122 nps 755604 tbhits 0 time 7561 pv d1f1 e7d7
Mon Nov 16 2015 12:42:38 GMT+0100 (CET) >>>> stop
Mon Nov 16 2015 12:42:38 GMT+0100 (CET) <<<< bestmove g4h2 ponder a3a2

the score mate 0 in the multipv 3 is wrong

stockfishMate0.txt

I attached a more verbose log file.

Please provide support for cmake. Attached a sample CMakeLists.txt as used currently in Fedora.

cmake_minimum_required (VERSION 2.6)
project (Stockfish)

set(EXE stockfish)

include_directories(${PROJECT_SOURCE_DIR}/syzygy)

aux_source_directory(. SOURCES)

add_executable(${EXE} ${SOURCES} syzygy/tbprobe.cpp)

target_link_libraries(${EXE} -lpthread)

Bug exposed by the fact that sorting all moves by SEE has the same node counts as sorting only captures by SEE.

Stockfish lost track of the winning line.

Eval dropped from +26.13 to 0.00.

Potentially this is caused by the combination of the following:

• 3 fold repetitions
• Lazy SMP
• Transposition table

I'm participating in a competition on kaggle.com 'FindingElo' [http://www.kaggle.com/c/finding-elo]. They recommended using your chess engine for position analysis. Besides providing 50000 games for analysis they opened the competition to allow us to find games online. I've analyzed a little over 28 million FEN positions using the convention below, so I think it's safe to say this is not coincidence that it will always segfault on this particular FEN string (at least in my tests).

I also received confirmation from Daylen Yang (Support staff) that he was able to replicate the issue.

I was originally thinking a core on one of my CPUs was going bad, but then I realized it was always only happening on this particular FEN.

> uci
> ucinewgame
> position fen 8/6qk/8/5KPp/1Q3p2/4P1P1/8/1p6 w - - 0 70
> go depth 14

Syed Fahad reported in Talkchess that SF does not compile on MSVC 2013 32-bit, because _BitScanForward64 etc. are missing:
http://talkchess.com/forum/viewtopic.php?t=54798

Checking from the MSVC documentation, this intrinsic is not supported in 32-bit mode:
http://msdn.microsoft.com/en-us/library/wfd9z0bb.aspx

SF (gives a winning score to this position because it thinks that g1=B?? wins
(Without Syzygy, but we could probably find side effects with Syzygy too.)
8/8/3k4/8/8/7K/6pP/4b3 b - - 1 4

See details here : http://www.talkchess.com/forum/viewtopic.php?t=58952

The hack in Makefile to workaround a gcc 4.7 bug when profiling:

Deleting corrupt ucioption.gc* profile files is necessary to avoid an

"internal compiler error" for gcc versions 4.7.x

@rm -f ucioption.gc*

Yields to this warning:

g++ -Wall -Wcast-qual -fno-exceptions -fno-rtti -fbranch-probabilities -ansi -pedantic -Wno-long-long -Wextra -Wshadow -g -O3 -DIS_64BIT -msse -DUSE_BSFQ -msse3 -mpopcnt -DUSE_POPCNT -c -o ucioption.o ucioption.cpp
ucioption.cpp: In function ‘_Tp* __gnu_cxx::new_allocator<_Tp>::allocate(__gnu_cxx::new_allocator<Tp>::size_type, const void) [with _Tp = std::_Rb_tree_node<std::pair<const std::basic_string, UCI::Option> >; __gnu_cxx::new_allocator<_Tp>::pointer = std::Rb_tree_node<std::pair<const std::basic_string, UCI::Option> >; __gnu_cxx::new_allocator<_Tp>::size_type = long unsigned int]’:
ucioption.cpp:160:1: note: file /home/marco/Documents/Stockfish/src/ucioption.gcda not found, execution counts estimated
} // namespace UCI

Do we even need the file tbprobe.cpp in syzygy? This file has undefined functions...

Possible regression in Skill Level, as reported here:

https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/ysxxf_zTpAg

Clang found this.

if (v1 >= 0 || v1 < 100)

which doesn't seem entirely intentional.

Will there ever be documentation for the code?

Under 64-bit OS 64-bit compiler creates a working executable when make is invoked with ARCH=x86-32. But this executable is working only under 64-bit OS and not working under 32-bit OS.

Assert in idle_loop():

assert(Threads.size() > 2);

Steps to reproduce: Compile with debug on, set threads to 2, run 'go infinite', wait about 5 minutes.

This is a reminder that we need to think about ARMv8 (64-bit ARM), ideally before releasing SF6. We need to use hardware (through compiler intrinsics if possible) for:

• prefetch
• lsb/msb
• popcount

Does anyone have experience with Android NDK and an ARMv8 device to run some tests?

When we reach the maximum depth, we can finish the search without a raise of
Signals.stop. However, if we are pondering or in an infinite search,
the UCI protocol states that we shouldn't print the best move before the
GUI sends a "stop" or "ponderhit" command.

This does not happens because main thread always set

Signals.stop = true;

to stop the threads.

The 32 bit Windows compiles on abrok give wrong bench numbers lately (Windows 8.1 32bit, CPU Intel Core Duo and CPU i3):
These 2 commits:
Commit #1
Author: Stefan Geschwentner
Date: Tue Feb 3 11:19:33 2015 +0800
Timestamp: 1422933573

Add bonus for pawn attack threats

Latent pawn attacks: Add a bonus to safe pawn pushes which attacks an
enemy piece. Based on an idea of Lyudmil Tsvetkov.

STC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 7925 W: 1666 L: 1537 D: 4722

LTC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 40109 W: 6841 L: 6546 D: 26722

Bench: 7696257
Resolves #240

gives bench 7695175,

Commit #2
Author: Joona Kiiski
Date: Sun Feb 8 19:28:01 2015 +0000
Timestamp: 1423423681

Pawn Center Bind Bonus

Bonus for two pawns controlling the same central square

STC:

LLR: 3.14 (-2.94,2.94) [-1.50,4.50]
Total: 15974 W: 3291 L: 3133 D: 9550

LTC:

LLR: 3.24 (-2.94,2.94) [0.00,6.00]
Total: 10449 W: 1837 L: 1674 D: 6938

Idea from Lyudmil Tsvetkov.

Bench: 7699138

Resolves #248

gives bench 7637783.

I get the following error;

tbcore.cpp(67): error C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead.
To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\string.h(112) : see declaration of 'strcpy'

Any fix?

Time management needs to be rewritten or simplified, and there also seems to be a bug with pondering.

The Ponder UCI option defaults to true, and AFAIK fishtest doesn't send ponder=off when running tests, and in Timemanager.cpp we have this:
if (Options["Ponder"])
optimumTime += optimumTime / 4;
Seems SF always uses 25% more time than originally intended.

Further, in TimeManager.h we have:
int available() const { return int(optimumTime * unstablePvFactor * 0.76); }

Currently we first add 25% time, and later remove 24%.