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

["anlauf at gmx dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432

--- Comment #13 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Francois-Xavier Coudert from comment #12)
> (In reply to Harald Anlauf from comment #10)
> > Partial patch to handle proposed behavior of system_clock
> 
> Thanks for the partial patch. Some quick critique:
>   - it doesn't handle mixed argument kinds (you said you don't care, but
> others might)

I originally said that I wouldn't care, but after playing with other
compilers I reconsidered (see comment #7).

Actually the patch does handle it in the most simple way: all arguments
are independent.  See the test case in comment #11.  (My tentative patch
did not remove code that compares the kinds of the arguments etc.)

>   - it creates multiple calls to the library (performance issue, especially
> on a timing routine)

True.  But as long as only COUNT is present, there's no performance
difference to the old behavior.  That's how I use SYSTEM_CLOCK.

Optimizations for multiple present arguments are possible but require
lengthy coding.  I haven't looked at the library code, but calls to
determine count_max and count_rate should be extremely cheap.

>   - I disagree with the logic for COUNT_RATE: we don't care what kind it is,
> because any "decent" kind (32-bit int, 64-bit int, or any real kind) is
> large enough to store the value.

Probably true for all present and future gfortran implementations.
(With crayftn I have seen COUNT_RATE = cpu clockspeed for integer(8),
and 2.6 GHz is too large for 32 bit...).

Nevertheless, I'd prefer the same COUNT_RATE for default integer(4)
and default real(4), and similarly for integer(>=8) and real(>=8).

> We've got to define an implementation that works for everyone, and for all
> corner cases. Then we can implement it. I've indicated on comp.lang.fortran
> what I think is the best strategy:
> 
>   a) if any integer kind is 1 or 2, we emit a warning at compile-time and
> behave as if no clock is available

OK.  This is better than a timer with ridiculously low count_rate/_max.

>   b) for COUNT_RATE, we treat a real as a "wide" int (64-bit or more)

I'd prefer real(4) ~ integer(4), see above reasoning.

>   c) if the kinds of present arguments don't match, issue a compile-time
> warning

OK.  (No other compiler I've met complains here, but it's good to warn
users to expect trouble).

>   d) if all present args are wide, go for high-res, otherwise go for low-res.

That's up to you.  But I'd prefer to stay consistent with what other
compilers do.  (I didn't post the crayftn behavior, but it is sort
of similar to what Intel does, except for somewhat odd count_rates.)

> How does that sound?
> 
> 
> I will have some time to deal with this in a week.