count_leading_zeros on 64-bit ppc
David Harvey
dmharvey at math.harvard.edu
Sun Jun 3 14:46:45 CEST 2007
hi there,
I think there may be a bug in count_leading_zeros in longlong.h on 64-
bit PPC platforms. This is GMP 4.2.1.
This is a bit worrying since I looked in longlong.h, and it looks
like assembly is used directly:
#define count_leading_zeros(count, x) \
__asm__ ("cntlzd %0,%1" : "=r" (count) : "r" (x))
So if I'm reading this right, it might be a bug in the chip itself.
Here is an example program that illustrates the bug:
======================================
#define UWtype unsigned long
#define UHWtype unsigned long
#define UDWtype unsigned long
#define W_TYPE_SIZE 64
#include <stdio.h>
#include <gmp.h>
#include "longlong.h"
int main()
{
unsigned long x = 0x0000000001379102;
unsigned long c;
count_leading_zeros(c, x);
printf("%d\n", c);
return 0;
}
======================================
I compile with
gcc -m64 count-test.c -I/Users/david/gmp/install/include/
On the G5, the program output is 40, whereas it should be 39. I've
tried it on an opteron and an intel chip, both correctly print 39
(extra #defines are needed to make it compile on those machines).
William Hart reports that this bug is probably present on the PS3
too, which uses some kind of ppc chip. He hasn't tested it directly
(still some hardware issues making it hard to get stuff on and off
the machine), but he observed last week some tests in our code
failing on the PS3, they are exactly the same tests that fail on my
G5, and they pass on our other test architectures. This is how we
found the bug: we analysed our test code and tracked it down to
count_leading_zeros returning the wrong result on the G5.
My gcc version is
george$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
build 5247)
george$ uname -a
Darwin George.local 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22
20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh
powerpc
david
More information about the gmp-bugs
mailing list