[J3] SYSTEM_CLOCK

[John Reid]

Steven G. Kargl wrote:
> 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)

Well, he was not  looking at the difference between COUNT values from 
different clocks and this code would be picked up at compile time with 
the suggested changes because of different integer kinds in a single 
call of SYSTEM_CLOCK

Cheers,

John.
>
> 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.
>