at 1:43 PM, Stephan Kramer wrote:
George Bosilca wrote:
Stephan,
You might be right. intptr_t is a signed type, which allows the
result of % to be potentially negative. However, on the other side,
mod is defined as a size_t which [based on my memory] is
definitively unsigned as it represent a s
ber gets wrapped in the assignment to the signed integer mod:
UINT_MAX+1-x
- in the subtraction CACHE_LINE_SIZE-mod, the result is wrapped around
again, giving CACHE_LINE_SIZE+x
Cheers
Stephan
On Oct 16, 2008, at 7:29 PM, Stephan Kramer wrote:
George Bosilca wrote:
I did investigate this i
appear
in the subsequent element loop. This is confirmed with the output of
some debugging statements I've pasted below. Also I haven't come across
the same bug on 64bit machines.
I guess this should be uintptr_t instead?
Cheers
Stephan Kramer
The debugging output:
mpidebug: num
uffer. Any help would be much appreciated
Stephan Kramer
Patrick,
I'm unable to reproduce the buffer overrun with the latest trunk. I
run valgrind (with the memchekcer tool) on a regular basis on the
trunk, and I never noticed anything like that. Moreover, I went over
the code, and I canno
