Re: [testsuite gfortran] partial fix for secnds*.f

[Brooks Moses <brooks dot moses at codesourcery dot com>]

Dominique Dhumieres wrote:
> Fix the erratic failures of the tests secnds.f and secnds-1.f:
> (1) do the appropriate shifts for timings around midnight,
> (2) use some tolerances for the timing comparisons, the chosen
> value: 8ms, is approximately 24.0*3600.0-nearest(24.0*3600.0,-1.0).
[...]
> I am submitting this patch for analysis, but I have found a remaining 
> problem on Linux at midnight:
>
>                 nearest(t1, -1.)       dat1             nearest(t1a, 1.)
> secnds.f        86398.625          -1.3740234           86398.641
> secnds-1.f      86399.992           0.0000000           86400.008
>
> apparently date_and_time is zero at midnight while secnds() is
> 86400. I don't know if this a bug in one of the intrinsic or if
> this the intended behavior.  It will be easy to use an additional 'if'
> to handle the case, but I'ld prefer to know if the behavior is the 
> expected one.  This problem can only be tested once a day!

This is the standard-required behavior for DATE_AND_TIME.  SECNDS is 
nonstandard, and the G77 manual doesn't document its behavior at midnight.

Probably we want to emulate whatever g77 did, but we also probably don't 
really care.  Thus, IMHO the test should be set up to pass regardless of 
what SECNDS returns at midnight.

I assume that dat1 was negative because of your midnight-shift 
correction?  Otherwise, that would be somewhat concerning, as it should 
always be nonnegative.  (I'm having a little trouble figuring out how 
the midnight shift would cause that, though; any ideas?)

> --- gcc-4.3-20070505/gcc/testsuite/gfortran.dg/secnds.f Sat Apr 28 04:10:46 2007
> +++ gcc-4.3-20070504/gcc/testsuite/gfortran.dg/secnds.f Thu May 10 20:57:14 2007
> @@ -6,14 +6,18 @@ C Contributed by Paul Thomas  <pault@gcc
>  C
>        character*20 dum1, dum2, dum3
>        real t1, t1a, t2, t2a
> -      real*8 dat1, dat2
> +      real*4 dat1, dat2

This should probably just be "real" rather than "real*4".

[...]
> @@ -23,5 +27,8 @@ C
>        t2 = secnds (t1)
>        dat2 = 0.001*real (values(8)) + real (values(7)) +
>       &        60.0*real (values(6)) + 3600.0* real (values(5))
> -      if (((dat2 - dat1) < t2a) .or. ((dat2 - dat1) > t2)) call abort ()
> +      ! handle midnight shift
> +      if ((dat2 - dat1) < -12.0*3600.0 ) dat1 = dat1 - 24.0*3600.0
> +      if (((dat2 - dat1) < t2a - 0.008) .or.
> +     &    ((dat2 - dat1) > t2 + 0.008)) call abort ()

I don't really like using magic numbers like this.  How about defining

  tol = 2.0 * (24.0 * 3600.0 - nearest (24.0 * 3600.0, -1.0))

at the beginning, and using that?  Though, actually, there's a better 
phrasing of the same idea:

  tol = 2.0 * spacing (24.0 * 3600.0)

Does that seem to work as well?

- Brooks