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.
