nearest_1.f90 failure on i686-linux

[Steve Kargl]

On Mon, Oct 09, 2006 at 11:04:54AM +0200, Dominique Dhumieres wrote:
> On a G5 and OSX 10.3.9, with gfortran 4.2.0 20061007, the following code
> 
> ! { dg-do run }
> ! { dg-options "-O0 -ffloat-store" }
> ! PR fortran/27021
> ! Original code submitted by Dominique d'Humieres
> ! Converted to Dejagnu for the testsuite by Steven G. Kargl
> program chop
>   integer ix, iy, ixe, iye
> !  equivalence (x,ixe), (y,iye)
>   o = 1.
>   ixe = 1
>   iye = 1
>   print '(2z20.8)', ixe, iye
>   t = tiny(o)
>   td = nearest(t,-1.0)
>   x = td/2.0
>   y = nearest(tiny(o),-1.0)/2.0
> !  print '(2z20.8)', ixe, iye
> !  if (abs(x - y) /= 0.) call abort
>   ix = transfer(x,ix)
>   iy = transfer(y,iy)
>   print '(2z20.8)', ix, iy
>   if (ix /= iy) call abort
> end program chop
> 
> gives without options:
> 
> 00000001            00000001
> 00400000            00400000
> 
> with option -O3 it gives:
> 
> 00000001            00000001
> 8FE50588            8FE15C34
> Abort
> 
> Now if I uncomment the lines 'equivalence ...' and 'print ...',
> it gives with -O3:
> 
> 00000001            00000001
> 00400000            00400000
> 00400000            00400000
> 
> (leaving the line 'print ...' commented only changes the corresponding 
> printed line). In a similar way, if I uncomment only the line 'if ...',
> I get:
> 
> 00000001            00000001
> 00400000            00400000
> 
> To summarize, it looks like the results of the TRANSFER() depend on the 
> code before them dealing with x, y, ix, or iy (middle-end bug?).

I would suspect that it is target specific.  I can't reproduce 
this on i386-*-freebsd or amd64-*-freebsd.  If it were a generic
middle-end bug more people would see the problem.  The guts of
nearest.m4 are

real_type
nearest_r`'kind (real_type s, real_type dir)
{
  dir = copysign`'q (__builtin_inf`'q (), dir);
  if (FLT_EVAL_METHOD != 0)
    {
      /* ??? Work around glibc bug on x86.  */
      volatile real_type r = nextafter`'q (s, dir);
      return r;
    }
  else
    return nextafter`'q (s, dir);
}

Does OSX have FLT_EVAL_METHOD?  Can you check whether the
nextafterf and nextafter actually work?


-- 
Steve