TalkChess.com

Even so, the proof game for a position like this would be hundreds of moves and almost certainly beyond the capabilities of a brute force search.

Although the likelihood of an incorrect cutoff affecting the search in a meaningful way seems small, would it be worth verifying other aspects of the hash entry to reduce collisions? For example, checking that the stored move is pseudo-legal.

Yes, Syzygy wasn't used there.

Perhaps it's to do with one of your interior node recognisers? Topple doesn't have any of those yet.

Is that position even reachable from the start?

Topple decides on h5 in a few ms and finds a mate a while later. info depth 5 seldepth 8 score cp 427 time 5 nodes 41736 nps 6956000 pv h4h5 f1g1 g4f5 g1f1 f5g6 e7e6 h5h6 info depth 30 seldepth 56 score mate 19 time 423727 nodes 4387405243 nps 10354000 hashfull 999 tbhits 0 pv h4h5 f1f2 h5h 6 e7f8 g...

GCC 9.1.0 generates an executable of pretty much the same speed for me.

I didn't know msys2 existed - I've been stuck on mingw-w64 with an outdated gcc version until now.

Congrats! 100 elo is huge

Topple 0.6.1 is a mostly bugfix update that should resolve the illegal moves that have been plaguing endgames with 5-piece tablebases:
https://github.com/konsolas/ToppleChess ... tag/v0.6.1

~snip~ ~snip~ Looks like this one is my bad. It seems to be related to this issue: https://github.com/konsolas/ToppleChess/issues/21 I've only tested with 6-piece tablebases and with automatic adjudication, so it seems like I've overlooked some issues which occur when 5-piece tablebases are used wi...