Those random secnds.f testsuite failures actually mean something.

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

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