beta 20.1 and 19 and 18 'rint' function with gcc is broken

[Mumit Khan]

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".