I have done following changes:

• formulate the asset in evaluate_passed_pawns stricter
• remove unneeded include
• merge in current master and fix the resulting problem

The assert is triggered at following position for the b4 pawn:
6k1/6p1/6Pp/p1p4P/1p6/1P6/1pK2P2/3N4 w - - 0 8

So i have relaxed the assert to consider only opponent pawns.

I noticed that there is no need to test b the first time entering the while loop because it has already been tested as part of the if condition above. Also once we OR in s there is no need to keep ORing it in again. I would therefore write it like this which I hope explains it better.

else if (stoppers == SquareBB[s + Up]
            && relative_rank(Us, s) >= RANK_5
            && (b = (shift<Up>(supported) & ~theirPawns)))
            do
                if (!more_than_one(theirPawns & PawnAttacks[Us][pop_lsb(&b)]))
                {
                    e->passedPawns[Us] |= s;
                    break;
                }
            while (b);

Congrats again!

@locutus2

The old assert was

    assert(!(pos.pieces(PAWN) & forward_bb(Us, s)));

To allow for the new case and only the new case, it seems you should use two asserts, one for each color:

    assert(!(pos.pieces(Us, PAWN) & forward_bb(Us, s)));
    assert(!(pos.pieces(Them, PAWN) & forward_bb(Us, s + pawn_push(Us))));

@snicolet
Thanks this asserts seems better and clearer (but not perfect too).

@mstembera
This was a design decision because i prefer a simpler and compacter version. I think the speed difference should be negligible. But here Joona has to decide.

@snicolet
Sorry, i have to revert. Your assert fails to the same position of above, because its possible i have a real passed pawn before my candidate. Perhaps this case should be excluded but that is another patch.

The current assert is so unspecific that i think now that we should drop it.