[Bug fortran/56919] [4.6/4.7/4.8/4.9 Regression] Wrong result for SYSTEM_CLOCK on Cygwin

jb at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Apr 11 18:32:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919

--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> 2013-04-11 18:32:19 UTC ---
(In reply to comment #0)
> The problem is that Cygwin does not support CLOCK_MONOTONIC; using it will
> return always return 0.
> 
> Note that Cygwin not only defines CLOCK_MONOTONIC but since Cygwin-1.7.6 also 
> "_POSIX_MONOTONIC_CLOCK 200112L" [1]. Thus, _POSIX_MONOTONIC_CLOCK [2] can also
> not be used.

Aagh, one wonders what demented logic caused them to claim they support it and
then not actually do so in any kind of useful manner.. *sigh*

> Nick suggests to simply call gf_gettime unconditionally. [3]

I wonder what, if any, specific issues there actually are..

Anyways, clock_gettime works fine on Linux, and IMHO it would be an annoying
regression to replace the current high-resolution monotonic clock with a lower
resolution non-monotonic clock, particularly since with recent glibc it should
be available to all users and not only those who link in librt (e.g. implicitly
via -fopenmp).

I don't know how cygwin implements CLOCK_MONOTONIC, but anyway, AFAIK on
windows a robust monotonic clock is available via the GetTickCount (and on
Vista/2008 and up, GetTickCount64 as well) function. Thus I'd suggest that both
MINGW and CYGWIN version should use those functions in the implementation of
the SYSTEM_CLOCK intrinsic. 

An overview of various timing functions can be found e.g. at
http://www.python.org/dev/peps/pep-0418/


> [3] http://gcc.gnu.org/ml/fortran/2013-04/msg00086.html



More information about the Gcc-bugs mailing list