[J3] SYSTEM_CLOCK

[Steven G. Kargl]

On Thu, Jan 28, 2021 at 03:56:17PM +0000, John Reid via J3 wrote:
> Vipul Parekh via J3 wrote:
> > Dear John,
> > 
> > Thank you for the draft interp, a good start.
> > 
> > Please note a significant issue with SYSTEM_CLOCK intrinsic, as worded
> > in the current standard, is with respect to the change introduced in
> > Fortran 2003 that allowed COUNT_RATE argument, which is OPTIONAL as well
> > as INTENT(OUT), to be a REAL scalar.  This is further compounded by the
> > "processor-dependent" phraseology in the wording that makes it
> > difficult for practitioners of Fortran to consume the intrinsic reliably
> > in their codes.  From what I can understand, your draft interp does
> > *not* address this issue with COUNT_RATE as a real scalar.  Can you
> > please take this into consideration?
> 
> I have already done this. My proposed wording for [420:16] is "If an image
> has more than one  clock, the clock is determined by the kind of the
> integer  arguments or is processor dependent if there are no integer 
> arguments. "
> 
> In your example,
>        call system_clock( t1, count_rate_r32 )
> will get the count rate for the intended clock.
> 
> Intel conforms to this now, but gfortran does not. I see no justification
> for the gfotran behaviour.
> 

Does it matter that you don't see a justification?  The Fortran
standard permits a Fortran processor to select a clock rate based
on its actual arguments.  gfortran does

   k = min(kind(COUNT), kind(COUNT_RATE), kind(COUNT_MAX))
   if (k < 4) no clock
   if (k == 4) millisecond time scale
   if (k > 4) nanosecond time scale

If an actual argument is not present then of course it is not
in the expression for k.  Why does it do this?  It is likely
due to the limited usefulness of COUNTing with a 32-bit signed
integer on a nanosecond time scale.

-- 
Steve