Those random secnds.f testsuite failures actually mean something.

[Brooks Moses]

The common wisdom, from last time I asked about this, was that the 
random occasional failures in secnds.f and secnds-1.f were just a case 
of things randomly landing outside the tolerances, and didn't mean anything.

Well, I finally got fed up with them :) and decided to put in a better 
test which uses bracketing rather than an arbitrary tolerance.  And I 
was still getting failures, and then when I started debugging the 
testcase I ran into something weird.  Consider the following code:

C {dg-do run}
       character*20 dum1, dum2, dum3
       real t1, t1a, t2, t2a
       real dat1, dat2
       integer i, j, values(8)
       t1 = secnds (0.0)
       call date_and_time (dum1, dum2, dum3, values)
       t1a = secnds (0.0)
       dat1 = 0.001*real (values(8)) + real (values(7)) +
      &        60.0*real (values(6)) + 3600.0* real (values(5))
C The following line is critical here.
C     write (*,*) (((dat1 - t1) < 0.) .or. ((dat1 - t1) > (t1a - t1)))
       if (((dat1 - t1) < 0.) .or. ((dat1 - t1) > (t1a - t1))) then
         write (*,*) (((dat1 - t1) < 0.) .or. ((dat1 - t1) > (t1a - t1)))
         write (*,*) dat1, t1, t1a, dat1-t1, t1a-t1
         call abort ()
       end if
       end

This randomly fails, on about 30% of the optimized passes.  The debug 
output it prints is something like:

  F
    16806.37       16806.37       16806.37       0.000000       0.000000

Note the "F", for the exact check that theoretically just evaluated as 
true in the IF statement.

Furthermore, if I uncomment the WRITE statement prior to the IF, the 
failures go away.

Looks like we've got a weird optimization bug going on....

(I've also filed this as PR 30752.)

- Brooks