From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: Re: beta 20.1 and 19 and 18 'rint' function with gcc is broken
17 Dec 1998 01:29:48 -0800
Message-ID: <199812161951.NAA15513.cygnus.gnu-win32@modi.xraylith.wisc.edu>
References: <725c6019 DOT 3677bf23 AT aol DOT com>
To: N8TM AT aol DOT com
Cc: gnu-win32 AT cygnus DOT com

N8TM AT aol DOT com writes:
> In a message dated 12/16/98 1:34:09 AM Pacific Standard Time,
> khan AT xraylith DOT wisc DOT 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 AT cygnus DOT com" with one line of text: "help".