HUGE() pain in the ...

[Steve Kargl]

On Sun, Jul 11, 2004 at 12:44:42PM +0100, Paul Brook wrote:
> > I not sure if this is a failure of MPFR or our output routine.
> > Anyone have any insight?
> 
> I have seen problems with our output routines when outputting numbers
> close to the limits of a type. I think it's something to do with the
> scaling code, but I never looked too closely.
> 

I tried finding the problem.  It appears to be in translating from
from gfortran frontend trees to the tree-ssa backend trees.  Consider,

  program z
  implicit none
  real(8) d, db
  db = radix(d)
  d = (1.e0_8 - db**(-digits(d)))*db**(maxexponent(d)-1)*db
  print *, huge(d), d
  end program z

If we use -fdump-parse-tree, we see

      ASSIGN db 2.00000000000000_8
      ASSIGN d (* (* (- 1.00000000000000_8 (** db -53)) (** db 1023)) db)
      WRITE UNIT=6 FMT=-1
      TRANSFER 1.79769313486232e308_8
      TRANSFER d
      DT_END

which shows HUGE(d) is correctly given as 1.79769313486232e308_8.  If I
then look at -fdump-tree-original I find

MAIN__ ()
{
  real8 d;
  real8 db;

  db = 2.0e+0;
  d = (1.0e+0-_gfortran_pow_r8_i4(db,-53))*_gfortran_pow_r8_i4(db,1023)*db;
  _gfortran_filename = "z.f90";
  _gfortran_line = 6;
  _gfortran_ioparm.unit = 6;
  _gfortran_ioparm.list_format = 1;
  _gfortran_st_write ();
  {
    real8 T.0;

    T.0 =  Inf;
    _gfortran_transfer_real (&T.0, 8);
  }
  _gfortran_transfer_real (&d, 8);
  _gfortran_st_write_done ();
}

which is of course not what we want.

I've looked at intermediate values in gfc_conv_mpfr_to_tree() from
trans-const.c and those values appear correct.  So, I believe the
call to build_real() in gfc_conv_mpfr_to_tree() is mangling the
number, but I can't find where build_real() lives.

-- 
Steve