Hide Forgot
I wish I could be more specific, but then I would be able to fix it. Here's the simplest FORTRAN program that demos the problem: WRITE(*,*) DNINT(0.0D0) END Reports 3.6028797E+16 instead of 0. Now, you may jump to the conclusion that this is just a DNINT() function problem, but in general, there's some very funky math problems on the Alpha that all quickly go away (100%) if one compiles with "-lcpml" the Compaq portable math library (including the above example). Hence, my guess it has something to do with the GNU clib-2.1 libm.
Try this C program: #include <stdio.h> #include <math.h> int main() { printf("%f\n",floor(0.1)); return 0; } It returns with 36028797018963968.000000 This would explain 100% of the funny results I was seeing. This would also explain why using the CMPL fixed the problem, it had it's own implementation of the floor() function.
That program works for me; I can not reproduce the problems reported. What are the compiler flags used to compile the test code?
This same problems shows up on my machine. I am running RedHat 6.1 on an AlphaStation 4/200 (233Mhz EV4 21064). This bug occurred in both the 6.0 and 6.1 releases. This bug shows up for an upgrade and a clean install.
Please move this bug back to the active list. I can't go and rework all of the makefiles for all of the applications which depend on the broken glibc to use cpml instead.