Steven G. Kargl kargl at uw.edu
Tue Jan 26 22:27:10 UTC 2021

On Tue, Jan 26, 2021 at 10:06:19PM +0000, John Reid via J3 wrote:
> Steve Lionel via J3 wrote:
> > 
> >   * Add a note warning of unpredictable results if integer kinds are
> >     mixed across calls
> > 
> Do we really have to say anything about doing obviously stupid things like
> looking at the difference between COUNT values from different clocks?

Apparently, yes.  Steve L started to look at SYSTEM_CLOCK due to
a post by me in comp.lang.fortran about a gfortran bug report.
The user did

   use iso_fortran_env

   integer(int32_t) rate
   integer(int64_t) cnt1, cnt2

   call system_clock(count=cnt1, count_rate=rate)
   call system_clock(count_cnt2)
   print *, (cnt2 - cnt1) / real(rate)

The problem is that gfortren supports 2 clock rates, and decides
which one to use via min(kind(cnt1), kind(rate)).  For this 
example, the first call returns cnt1 in a millisecond time scale
and rate of 1000.  The second call returns cnt2 on a nanosecond
time scale.  As SYSTEM_CLOCK returns the number of ticks relative
to some reference (say, UNIX epoch), the value of cnt2 far exceeds
cnt1.  Thus, (cnt2 - cnt1) / 1000 was nanosecond count divided by
millisecond rate.

gfortran documents its processor-dependent behavior, but the 
bug reporter maintains gfortran has a bug because it does 
not match Intel Fortran.


More information about the J3 mailing list