This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows
- From: Tobias Burnus <burnus at net-b dot de>
- To: fortran at gcc dot gnu dot org
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 13 Apr 2013 00:02:17 +0200
- Subject: Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows
- References: <CAO9iq9FBmgY8A9b7PXKAbcXhHKuMk8mk_cYAgo_mcP2yCcXUyw at mail dot gmail dot com>
Janne Blomqvist wrote:
the attached patch implements the SYSTEM_CLOCK intrinsics on the MinGW
and Cygwin targets using the GetTickCount/GetTickCount64 functions.
These should be quite robust monotonic clocks and AFAICS are the best
we can do on Windows.
I think using QueryPerformanceCounter is the better approach. It is
supported since Windows 2000 and recommended as high-performance
I really dislike GetTickCount, which overflows after 50 days - that's
not what you want to have. And GetTickCount64 only exists since
Vista/2008. By contrast, QueryPerformanceCounter should allow for finer
resolution and it is already available since Windows 2000.
- Also Cygwin uses QueryPerformanceCounter for clock_gettime, now as is,
before it subtracted some offset which caused it to start with 0 from
process startup time. (I belive QueryPerformanceCounter counts from
- MinGW-w64 also uses it for the monotonic clock_gettime - at least in
- I think MinGW does't support it (yet?).
* * *
Regarding clock_gettime: I really think we should check check
_POSIX_MONOTONIC_CLOCK as well. Currently, only MONOTONIC_CLOCK is
checked, which is always available (on POSIX conform systems).
See GLIBCXX_ENABLE_LIBSTDCXX_TIME in libstdc++-v3/acinclude.m4 - and in