This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: beta 20.1 and 19 and 18 'rint' function with gcc is broken
- To: N8TM at aol dot com
- Subject: Re: beta 20.1 and 19 and 18 'rint' function with gcc is broken
- From: Mumit Khan <khan at xraylith dot wisc dot edu>
- Date: Wed, 16 Dec 1998 13:51:34 -0600
- cc: gnu-win32 at cygnus dot com
N8TM@aol.com writes:
> In a message dated 12/16/98 1:34:09 AM Pacific Standard Time,
> khan@xraylith.wisc.edu writes:
>
> << The problem is the way rint is written in newlib -- it's using the old
> Sun code that I'm not too fond of. >>
> It is written to avoid the use of an fp co-processor. Maybe that would have
> been OK back in the pre-486 days.
I wasn't aware of that ... thanks for pointing it out.
A common problem among many of these numerical codes that were written to
avoid co-processor is seen in the following snippet (a reduced case of
newlib's rint implementation):
#include <stdio.h>
static const double TWO52 = 4.50359962737049600000e+15;
double
foo (double x)
{
double w = TWO52+x;
return w - TWO52; /* ooops if optimizer recognizes this! */
}
int
main ()
{
double x = 47.4;
double y = foo (47.4);
printf ("foo(47.4) = %f\n", y);
return 0;
}
The optimizer recognizes the pattern in foo (and it's not hard!), you
not only lose the current rounding mode, as a bonus, you lose the
expected result as well ;-)
Treating the affected variables, foo:w in this case, as "volatile" (which
I've had to resort to in certain cases in the past) is not right solution
in general.
Regards,
Mumit
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".