http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-04-11 21:18:43 UTC --- (In reply to comment #3) > 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. That has now been fixed, cf. http://gcc.gnu.org/ml/fortran/2013-04/msg00097.html > - Newlib's system_clock handling is completely broken, but as it returns -1, > one could fall through to gf_gettime Actually, it only has _POSIX_MONOTONIC_CLOCK set on RTEMS+Cygwin, which support it. Thus, it probably makes to check: #if defined(_POSIX_MONOTONIC_CLOCK) && _POSIX_MONOTONIC_CLOCK >= 0 in addition to check only for MONOTONIC_CLOCK is required to be in time.h according to POSIX. Cf. http://gcc.gnu.org/ml/fortran/2013-04/msg00099.html > - 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). The question is what we do here? Leave it? Modify it? Or add a note? (In reply to comment #2) > > Nick suggests to simply call gf_gettime unconditionally. [3] > I wonder what, if any, specific issues there actually are.. Seems to be just difficult to implement: It has to be monotonic and can it cannot be based on clock ticks - unless they have a well-defined frequency. Thus, one can either query the clock - or try to play tricks which does not work well. Examples: GetTickCount (overflows after 49.7 days), Cygwin (used the process start time not, e.g., system start time as base) - and there are presumably tons of other clever ways which are broken in one or the other way.
