[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 #5 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Francois-Xavier Coudert from comment #4)
> I'm not sure this is a bug, but this was definitely by design (as the
> comment indicates). I think this is allowed by the successive standards
> (which are, in any case, very weakly worded).

Well, let's see: the standard says:

  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 number of processor clock counts per second, or zero if there is
    no clock.

You're right, it does not say anything about consistency.
Nevertheless, I would prefer if a program that always uses
e.g. default integer == integer(4), the low-resolution (msec)
version continues to be used consistently.  That's what other
compilers do and what gfortran <= 4.9 did.

Also, the presence of a second argument (see comment #1) should
not change the behavior.

OTOH, it is the responsibility of a user to consistently use
arguments of the same type and kind to get consistent behavior.
(I.e. not mixing integer and real or integer(4) and integer(8)).
I do take care of that.

> The root of the problem is that we want to allow for SYSTEM_CLOCK to return
> high-precision values for large integer kinds, and fall back to
> lower-precision results that fit in fewer bytes for smaller integer kinds.

How is this fallback done?  Do you truncate the resolution?
E.g. high res. -> low res.: divide count_rate and count by 1000?

> Thus, one should call SYSTEM_CLOCK once with all the necessary arguments,
> and not multiple times with varying argument types.

Note that I did *not* call SYSTEM_CLOCK with varying argument types.

You're probably not aware of existing (f95) code that deals with
the problem of wrapping, which is always present (count does not
necessarily start with 0 at start of the program), although not
very likely with integer(8)... ;-)

> The only other consistent option I can see would be to simply go for
> high-resolution results in all cases, but that would mean that SYSTEM_CLOCK
> with 32-bit integers would wrap around in less than an hour.

No, that doesn't make sense.

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