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().