http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-04-11 20:14:13 UTC --- First, I think we made a thinko with the random_seed example at http://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fSEED.html it uses (as does Angelo's code): CALL SYSTEM_CLOCK(COUNT=clock) seed = clock + 37 * (/ (i - 1, i = 1, n) /) CALL RANDOM_SEED(PUT = seed) If clock_gettime uses the seconds since the epoch (or since system start), everything is fine. However, under Cygwin (cf. comment 1) the time since process start seems to be used. Result: The timing might be quite similar. Actually, at least with the testing of Angelo, http://gcc.gnu.org/ml/fortran/2013-04/msg00092.html + http://gcc.gnu.org/ml/fortran/2013-04/msg00084.html, it even seems as if the clock rate is that slow that one can do several system calls in no time (= 0 nanoseconds). Also gettimeofday and clock_gettime(CLOCK_REALTIME,...) show the same number of nanoseconds with Cygwin. (Contrary to Linux.) Thus, we should really update the RANDOM_SEED example to use something wall-time based. * * * (In reply to comment #2) > 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* If one looks at newlib, one finds in src/newlib/libc/include/time.h: #define CLOCK_REALTIME (clockid_t)1 #define CLOCK_PROCESS_CPUTIME_ID (clockid_t)2 #define CLOCK_THREAD_CPUTIME_ID (clockid_t)3 #define CLOCK_MONOTONIC (clockid_t)4 And src/newlib/libc/sys/linux/clock_gettime.c does not handle CLOCK_MONOTONIC: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/sys/linux/clock_gettime.c?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=src If one looks at the code, that should return "-1" as status code, if CLOCK_MONOTONIC has failed. I think we should change system_clock to use: /* Newlib defines CLOCK_MONOTONIC but doesn't support it. Thus, if clock_gettime failed, fall through to gf_gettime. */ if (return_value == 0) return; ... That way, all those embedded systems which use newlib will get a proper result. (gfortran has embedded users, at least one user on VxWorks.) * * * > > Nick suggests to simply call gf_gettime unconditionally. [3] > I wonder what, if any, specific issues there actually are... I wonder as well - at least for newlib it is clear why it fails. > I don't know how cygwin implements CLOCK_MONOTONIC See: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/times.cc?cvsroot=src It uses QueryPerformanceCounter (cf. hires_ns::nsecs, called by clock_gettime). I have not yet fully understand why it is 0. Cf. http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904%28v=vs.85%29.aspx > 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. Looking through the list of functions at the URL below, I think calling QueryPerformanceCounter makes most sense - which is what Cygwin does: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644900(v=vs.85).aspx * * * In summary: - Cygwin is probably okay - it just starts from 0 with the first call to system_clock(monotonic,...) which is fine but different to Linux. - Newlib's system_clock handling is completely broken, but as it returns -1, one could fall through to gf_gettime - gfortran's random_seed example is bad if the system_clock(monotonic,...) behaves as with Cygwin - or everything else based on the timing of the process instead of the system up time (like GetTickCount - with overflow issues) or ticks since the epoch (as system_clock on Linux). - There seems to be a design issue with system_clock according to Nick, but we don't know which one it is.
