[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

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.