[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jan 07, 2021 at 05:28:15PM +0000, mehdi.chinoune at hotmail dot com
wrote:
> There is no mention of your claims in the standard:
> 

I know what the standard says.

> Fortran 2018:
>   COUNT (optional) shall be an integer scalar. It is an INTENT (OUT) argument.
> It is assigned a processor-dependent value based on the value of a processor
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is kinda of important.

> clock, or −HUGE (COUNT) if there is no clock for the invoking image. The
> processor-dependent value is incremented by one for each clock count until the
> value COUNT_MAX is reached and is reset to zero at the next count. It lies in
> the range 0 to COUNT_MAX if there is a clock.
>   COUNT_RATE (optional) shall be an integer or real scalar. It is an INTENT
> (OUT) argument. It is assigned a processor-dependent approximation to the
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is kinda of important.

To understand what processor-dependent choices gfortran
made, you need to read the gfortran documentation where
the millisecond/nanosecond scaling/counting is discussed.
A fixed count_rate of 1000 and millisecond resolution worked
well 25 years.  On modern hardware and depending on what 
you want to time, a count_rate of 1000 and millisecond
resolution is unusable as it is not fine-grained enough. 
Setting the count_rate to a fixed 100000000 for nanosecond
counting on modern hardware is possible, but counting 
with integer(4) would give you 2.147483647 seconds before
the counter wraps around.  Not exactly usable for many.

If all you want to do is time a loop, use cpu_time().