https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #7 from Harald Anlauf <anlauf at gmx dot de> --- (In reply to Harald Anlauf from comment #5) > (In reply to Francois-Xavier Coudert from comment #4) > > If you have another idea, please post a list of what you think should happen > > in all various cases (all possible combinations of arguments have to be > > allowed). > > Let's see: > > - For any number of arguments present (1, 2 or 3) > - always integer(4): msec resolution (as before) > - always integer(>=8): usec resolution (or whatever is possible) > - always real: I don't care, but I think it might be a good idea > to use the same as for integer of a compatible kind. > - different types and/or kinds: I don't care, since one should > expect problems (wrapping or truncation) anyway. > > But presence of non-presence should never make a difference > if consistent types and kinds are used. I played around with other compilers and posted the result at: https://groups.google.com/forum/?hl=en#!topic/comp.lang.fortran/5aoFFRNBP0g The only compiler that allows for different timer resolutions and produces an at least self-consistent result appears to be Intel. It actually treats each argument separately: if it is a 4-byte argument, it returns values referring to the low-res (0.1 msec) version; for an 8-byte argument one gets the high-res (1 usec) version. (Confirmed by looking at the explicit assembler code). That would be even simpler than any of the versions I discussed above. The actual implementation then might generate a call to _gfortran_system_clock_{4,8} for each present argument, with the respective kind taken into account.