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