Bug 3308

Summary: floor() function in libm (glibc-2.1) is broken on Alpha.
Product: [Retired] Red Hat Linux Reporter: niles
Component: glibcAssignee: Cristian Gafton <gafton>
Status: CLOSED WORKSFORME QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-07-09 22:17:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description niles 1999-06-07 01:59:19 UTC
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.

Comment 1 niles 1999-06-07 02:58:59 UTC
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.

Comment 2 Cristian Gafton 1999-07-09 22:17:59 UTC
That program works for me; I can not reproduce the problems reported.
What are the compiler flags used  to compile the test code?

Comment 3 moof 2000-01-05 04:13:59 UTC
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.

Comment 4 moof 2000-01-05 04:17:59 UTC
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.