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
