This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sun, Oct 10, 2004 at 10:16:13AM -0700, Dan Kegel wrote: > Nope. I just know that the ARM ABI specifies hardware FP, so > I figure they must have gotten the FP emulation bugs out of > the way a long time ago. If you're on little-endian, that's probably true. There are not many folks using big-endian ARM, so things there are still kind-of broken. For example, this afternoon I was wondering why ntpd was constantly adjusting my clock in the wrong direction, and then found this (on big-endian.) So you see that at least one really obvious bug in kernel fp emulation went undetected for a couple of years. Actually, before a patch went into 2.6.9-rc2 to fix fp byte order, hardfloat on big-endian didn't work at all. I don't think linux even supports any ARM CPUs with a hardware FP unit, please correct me if I'm wrong on that. [root@enp2611 tmp]# cat x.c #include <stdio.h> #include <stdlib.h> #include <math.h> int main() { volatile double x; x = 1.0; printf("%f\n", x); x = -x; printf("%f\n", x); return 0; } [root@enp2611 tmp]# gcc -Wall -o x x.c [root@enp2611 tmp]# ./x 1.000000 1.000000 [root@enp2611 tmp]# --L ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |