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

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.