Bug 30752 - SECNDS() or DATE_AND_TIME() intrinsic optimized incorrectly.
Summary: SECNDS() or DATE_AND_TIME() intrinsic optimized incorrectly.
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: wrong-code
Depends on:
Reported: 2007-02-10 00:12 UTC by Brooks Moses
Modified: 2007-02-10 00:55 UTC (History)
45 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Brooks Moses 2007-02-10 00:12:09 UTC
Consider the following piece of code, derived from the secnds-1.f test case (with some changes I'd added to avoid the 20ms arbitrary tolerance):

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

If I run this through the usual testsuite apparatus, it will fail on about 30% (on average) of the optimized runs, but never (so far as I've seen) with -O0.  The output, though, usually looks like this:

   16806.37       16806.37       16806.37       0.000000       0.000000

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

If I uncomment the WRITE statement prior to the IF, the failures go away.
Comment 1 Andrew Pinski 2007-02-10 00:22:28 UTC
Can you try with -ffloat-store, this might be just the normal PR 323 :).
Comment 2 Brooks Moses 2007-02-10 00:55:13 UTC
Yup, that seems to make the problem go away.  Thanks!

*** This bug has been marked as a duplicate of 323 ***