https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
kargl at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |INVALID --- Comment #14 from kargl at gcc dot gnu.org --- (In reply to Chinoune from comment #12) > First example: > > $ ifort bug_gcc_tic.f90 -o test.x > $ ./test.x > count(int_32): > count_rate(int32) = 10000 > count_rate(int64) = 10000 > count_rate(real32) = 10000.00 > count_rate(real64) = 10000.0000000000 > count(int_64): > count_rate(int32) = 1000000 > count_rate(int64) = 1000000 > count_rate(real32) = 1000000. > count_rate(real64) = 1000000.00000000 > > Unlike gfortran, count_rate with ifort depends only on the precision of the > first argument of system_clock. It doesn't mixup. That is not required by the Fortran Standard, but conforms because COUNT and COUNT_RATE are processor-dependent. I also took the opportunity to look at the Intel Fortran documentation at https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/a-to-z-reference/s-1/system-clock.html dated 4 dec 2020. Note, the following hightlighted sentence on that page: "All integer arguments used must have the same integer kind parameter." That is not required by Fortran Standard. Why would Intel require compatible kind type parameters? Your program in comment #0 does meet the requirements placed on system_clock() by Intel.