https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
--- Comment #6 from Chinoune <mehdi.chinoune at hotmail dot com> --- (In reply to Steve Kargl from comment #5) > 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(). I am not asking for advice here, I reported a bug with its reproducer. It is not your concern what kind of integer I choose to use since it is not invalid. The standard doesn't say anything about mixing precisions. I didn't say that gfortran should report 1000 or 10000 or 14659827, I know It is a processor-dependent. The problem is that gfortran doesn't give the correct values for count/count_rate when it is int64/int32 or int64/real32 which doesn't have any basis in the standard. Please, stop trolling.