This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows
- From: Tobias Burnus <burnus at net-b dot de>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 15 Apr 2013 10:37:51 +0200
- Subject: Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows
- References: <CAO9iq9FBmgY8A9b7PXKAbcXhHKuMk8mk_cYAgo_mcP2yCcXUyw at mail dot gmail dot com> <51688469 dot 4060000 at net-b dot de> <CAO9iq9HTfRn3Pa3se9Ntois7gMywkUav9ydVfPQLjARCY7Qnzg at mail dot gmail dot com>
Janne Blomqvist wrote:
Attached is an updated patch which uses GetTickCount for
system_clock_4; this should be fine as system_clock_4 wraps around in
~25 days anyways. For system_clock_8 it uses
QueryPerformance{Counter,Frequency}.
The patch also adds an additional check for _POSIX_MONOTONIC_CLOCK.
Ok for trunk?
Regarding the documentation, I wonder whether one should do the
following additional changes:
- Explicitly suggest to use a kind=8 argument fÃr system_clock (for
higher resolution and to avoid overflows).
- To change the system_clock example to use an integer(8) argument.
Possibly, via iso_fortran_env's int64 or via selected_int_kind(18)
+ #if defined(CLOCK_MONOTONIC) && defined(_POSIX_MONOTONIC_CLOCK)
I'd add
&& _POSIX_MONOTONIC_CLOCK >= 0
as POSIX states: "If a symbolic constant is defined with the value -1,
the option is not supported."
+ uint32_t cnt = GetTickCount ();
I wonder whether a comment stating that GetTickCount instead of
QueryPerformanceCounter is used as the extra precision and 49.7-days
overflow do not matter with the 32bit system_clock - and as
QueryPerformanceCounter has issues on some (very few) systems.
Otherwise, it looks fine to me.
Tobias