I think it is instead because is not the intended behaviour. It is a bug that works by luck...but still a bugUncombedCoconut wrote: So I don't construe this post as a bug report.
Thanks for pointing out this.
Moderators: hgm, Rebel, chrisw
I think it is instead because is not the intended behaviour. It is a bug that works by luck...but still a bugUncombedCoconut wrote: So I don't construe this post as a bug report.
I don' t have access to my PC now, but I am quite confident that does exist an overload (another function with the same name) that takes a square, otherwise compiler should have risen an error (a warning is not enough)....Sven Schüle wrote:
I looked at 1.9.1 sources, of course I do not know whether this problem was already present in 1.9, but if it was then it is quite likely that it causes the effect seen by Louis.
Thanks for your work on this.Sven Schüle wrote:Hi,
function ScalingFunction<KPsK>::apply() (endgame.cpp) uses a utility function in_front_bb() (bitboard.h) which takes a rank as second argument and indexes into a [2][8] array, but the apply() function passes a square to it (ksq) which is 0..63. That might be responsible for the crash.
The type of ksq is 'Square' and in_front_bb() requires a 'Rank'. Both are different enums (square.h) but the compiler seems to accept this (maybe with a warning?).
I looked at 1.9.1 sources, of course I do not know whether this problem was already present in 1.9, but if it was then it is quite likely that it causes the effect seen by Louis.
Sven
Code: Select all
/// in_front_bb() takes a color and a rank or square as input, and returns a
/// bitboard representing all the squares on all ranks in front of the rank
/// (or square), from the given color's point of view. For instance,
/// in_front_bb(WHITE, RANK_5) will give all squares on ranks 6, 7 and 8, while
/// in_front_bb(BLACK, SQ_D3) will give all squares on ranks 1 and 2.
inline Bitboard in_front_bb(Color c, Rank r) {
return InFrontBB[c][r];
}
inline Bitboard in_front_bb(Color c, Square s) {
return InFrontBB[c][square_rank(s)];
}
Right, missed that. But then the in_front_bb(Color, Rank) version seems to be unused.mcostalba wrote:I don' t have access to my PC now, but I am quite confident that does exist an overload (another function with the same name) that takes a square, otherwise compiler should have risen an error (a warning is not enough)....Sven Schüle wrote:
I looked at 1.9.1 sources, of course I do not know whether this problem was already present in 1.9, but if it was then it is quite likely that it causes the effect seen by Louis.
Code: Select all
/// in_front_bb() takes a color and a rank or square as input, and returns a
/// bitboard representing all the squares on all ranks in front of the rank
/// (or square), from the given color's point of view. For instance,
/// in_front_bb(WHITE, RANK_5) will give all squares on ranks 6, 7 and 8, while
/// in_front_bb(BLACK, SQ_D3) will give all squares on ranks 1 and 2.
inline Bitboard in_front_bb(Color c, Rank r) {
return InFrontBB[c][r];
}
inline Bitboard in_front_bb(Color c, Square s) {
return InFrontBB[c][square_rank(s)];
}
inline Bitboard in_front_bb_sq(Color c, Square s) {
return InFrontBB[c][square_rank(s)];
}
Code: Select all
/// KPsKScalingFunction scales endgames with king and two or more pawns
/// against king. There is just a single rule here: If all pawns are on
/// the same rook file and are blocked by the defending king, it's a draw.
template<>
ScaleFactor ScalingFunction<KPsK>::apply(const Position& pos) const {
assert(pos.non_pawn_material(strongerSide) == VALUE_ZERO);
assert(pos.piece_count(strongerSide, PAWN) >= 2);
assert(pos.non_pawn_material(weakerSide) == VALUE_ZERO);
assert(pos.piece_count(weakerSide, PAWN) == 0);
Square ksq = pos.king_square(weakerSide);
Bitboard pawns = pos.pieces(PAWN, strongerSide);
// Are all pawns on the 'a' file?
if ((pawns & ~FileABB) == EmptyBoardBB)
{
// Does the defending king block the pawns?
if ( square_distance(ksq, relative_square(strongerSide, SQ_A8)) <= 1
|| ( square_file(ksq) == FILE_A
&& (in_front_bb_sq(strongerSide, ksq) & pawns) == EmptyBoardBB))
return SCALE_FACTOR_ZERO;
}
// Are all pawns on the 'h' file?
else if ((pawns & ~FileHBB) == EmptyBoardBB)
{
// Does the defending king block the pawns?
if ( square_distance(ksq, relative_square(strongerSide, SQ_H8)) <= 1
|| ( square_file(ksq) == FILE_H
&& (in_front_bb_sq(strongerSide, ksq) & pawns) == EmptyBoardBB))
return SCALE_FACTOR_ZERO;
}
return SCALE_FACTOR_NONE;
}
Just so you know, you don't have to do that "set args" thing. Just "run arg1 arg2 ... argn" will work just fine... That's the only way I have ever done this, in fact...UncombedCoconut wrote:You're welcome. I am sorry that this (with near-certainty) does nothing to resolve the problem with the icc compile. Louis: Can you try running under gdb?
gdb stockfish
> set args bench 32 1 10 default depth
> run
[wait for the KABOOM]
> bt full
> quit
(If the # of threads were not equal to 1, "thread apply all bt full" would be preferred over "bt full".)
[edit]: The info to include would be the output of gdb after the "bt full" command. It will probably be verbose due to printing the value of large arrays, so it's probably a good idea to use a pastebin.
Yes I doSven Schüle wrote: Can you exclude that the compiler has mixed up the two overloaded versions?