I don't seem to reproduce the problem on 2.6.15. 0/0 = nan 1/0 = inf 9.99989e-321/2 = 4.99994e-321 (0)<mcelrath@moya:/tmp> uname -a Linux moya.mcelrath.org 2.6.15 #1 SMP Mon Mar 13 15:01:04 PST 2006 alpha GNU/Linux The gcc I have installed is 4.0.3, but I couldn't guarantee that's what I used to compile this kernel... Tyson Whitehead [twhitehe@uwo.ca] wrote: > I was fooling around on my Alpha and just noticed that all the special IEEE > numbers (infs, nans, and denormals) are now being replaced by zeros. > > For example, > > #include <stdio.h> > > int main() { > double value1; > double value2; > > printf("Please enter the num: "); > scanf("%lf",&value1); > printf("Please enter the den: "); > scanf("%lf",&value2); > printf("\n%g/%g = %g\n",value1,value2,value1/value2); > > return 0; > } > > saved to "div.c" and compiled with "gcc -o div -lm -Wall div.c" gives > > 0/0 = 0 (should be nan) > 1/0 = 0 (should be inf) > 1e-320/2 = 0 (should be 5e-321: 1e-320 is a denormalized) > > Dumping the generated code with "objdump -d div | less" shows gcc is > generating all the required trap instructions and su extentions on the > floating point operations. This leaves me wondering if something has changed > in the IEEE floating point fixup code in newer kernels. > > Unfortunately, I'm stuck at 2.6.15 or greater due to new udev requirements > (and only 2.6.16 is available), but is there anyone else out there running an > older kernel (maybe even 2.4) that could give this a try? > > Thanks! -Tyson > -- Cheers, Bob McElrath [Univ. of California at Davis, Department of Physics] Only after you've tried to figure something out for yourself and failed are you ready to absorb "the answer."
Attachment:
signature.asc
Description: Digital signature