Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-15 Thread Tobias Burnus 

Janne Blomqvist wrote:
Attached is an updated patch which uses GetTickCount for 
system_clock_4; this should be fine as system_clock_4 wraps around in 
~25 days anyways. For system_clock_8 it uses 
QueryPerformance{Counter,Frequency}. 



The patch also adds an additional check for _POSIX_MONOTONIC_CLOCK.
Ok for trunk?


Regarding the documentation, I wonder whether one should do the 
following additional changes:
- Explicitly suggest to use a kind=8 argument für system_clock (for 
higher resolution and to avoid overflows).
- To change the system_clock example to use an integer(8) argument. 
Possibly, via iso_fortran_env's int64 or via selected_int_kind(18)



+ #if defined(CLOCK_MONOTONIC)  defined(_POSIX_MONOTONIC_CLOCK)

I'd add
   _POSIX_MONOTONIC_CLOCK = 0
as POSIX states: If a symbolic constant is defined with the value -1, 
the option is not supported.



+  uint32_t cnt = GetTickCount ();

I wonder whether a comment stating that GetTickCount instead of 
QueryPerformanceCounter is used as the extra precision and 49.7-days 
overflow do not matter with the 32bit system_clock - and as 
QueryPerformanceCounter has issues on some (very few) systems.



Otherwise, it looks fine to me.

Tobias

Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-15 Thread Janne Blomqvist 
On Mon, Apr 15, 2013 at 11:37 AM, Tobias Burnus bur...@net-b.de wrote:
 Janne Blomqvist wrote:

 Attached is an updated patch which uses GetTickCount for system_clock_4;
 this should be fine as system_clock_4 wraps around in ~25 days anyways. For
 system_clock_8 it uses QueryPerformance{Counter,Frequency}.


 The patch also adds an additional check for _POSIX_MONOTONIC_CLOCK.
 Ok for trunk?


 Regarding the documentation, I wonder whether one should do the following
 additional changes:
 - Explicitly suggest to use a kind=8 argument für system_clock (for higher
 resolution and to avoid overflows).
 - To change the system_clock example to use an integer(8) argument.
 Possibly, via iso_fortran_env's int64 or via selected_int_kind(18)


 + #if defined(CLOCK_MONOTONIC)  defined(_POSIX_MONOTONIC_CLOCK)

 I'd add
_POSIX_MONOTONIC_CLOCK = 0
 as POSIX states: If a symbolic constant is defined with the value -1, the
 option is not supported.


 +  uint32_t cnt = GetTickCount ();

 I wonder whether a comment stating that GetTickCount instead of
 QueryPerformanceCounter is used as the extra precision and 49.7-days
 overflow do not matter with the 32bit system_clock - and as
 QueryPerformanceCounter has issues on some (very few) systems.


 Otherwise, it looks fine to me.

I committed the attached patch with most of your suggestions as r197968.

Thanks for the review.



--
Janne Blomqvist


sysclockwin.3.diff
Description: Binary data

Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-15 Thread Tobias Burnus 

Janne Blomqvist wrote:

I committed the attached patch with most of your suggestions as r197968.


Thanks! Although, I assume you meant kind=8 in the last sentence:


+the underlying platform clock. @var{COUNT_MAX} usually equals
+@code{HUGE(COUNT_MAX)}. Note that the millisecond resolution of the
+@var{kind=4} version implies that the @var{COUNT} will wrap around in
+roughly 25 days. In order to avoid issues with the wrap around and for
+more precise timing, please use the @var{kind=4} version.


Hence, I committed the attached patch as obvious.

Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 197969)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2013-04-15  Tobias Burnus  bur...@net-b.de
+
+	* intrinsic.texi (SYSTEM_CLOCK): Recommend kind=8.
+
 2013-04-15  Janne Blomqvist  j...@gcc.gnu.org
 
 	PR fortran/56919
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi	(Revision 197969)
+++ gcc/fortran/intrinsic.texi	(Arbeitskopie)
@@ -12052,7 +12052,7 @@
 @code{HUGE(COUNT_MAX)}. Note that the millisecond resolution of the
 @var{kind=4} version implies that the @var{COUNT} will wrap around in
 roughly 25 days. In order to avoid issues with the wrap around and for
-more precise timing, please use the @var{kind=4} version.
+more precise timing, please use the @var{kind=8} version.
 
 If there is no clock, or querying the clock fails, @var{COUNT} is set
 to @code{-HUGE(COUNT)}, and @var{COUNT_RATE} and @var{COUNT_MAX} are

Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-15 Thread Janne Blomqvist 
On Mon, Apr 15, 2013 at 3:51 PM, Tobias Burnus bur...@net-b.de wrote:
 Janne Blomqvist wrote:

 I committed the attached patch with most of your suggestions as r197968.


 Thanks! Although, I assume you meant kind=8 in the last sentence:

 +the underlying platform clock. @var{COUNT_MAX} usually equals
 +@code{HUGE(COUNT_MAX)}. Note that the millisecond resolution of the
 +@var{kind=4} version implies that the @var{COUNT} will wrap around in
 +roughly 25 days. In order to avoid issues with the wrap around and for
 +more precise timing, please use the @var{kind=4} version.


 Hence, I committed the attached patch as obvious.

Indeed, thanks for spotting it, and fixing it quickly!


--
Janne Blomqvist

Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-13 Thread Janne Blomqvist 
On Fri, Apr 12, 2013 at 11:49 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
 On 12/04/2013 19:47, Janne Blomqvist wrote:

 As I don't have a Windows system to test on, I would appreciate if somebody
 more familiar with that platform could take a quick look. In particular, I
 *think* it should be Ok to use win32 API functions on Cygwin (that is,
 cygwin-gcc ships the windows.h and other necessary headers out of the
 box?),

   Well, after installing the w32api package, but basically yes, that's fine
 for simple stuff like that.  (You shouldn't go doing things like creating
 threads or synchronisation through the Win32 API, but calling GetTickCount[64]
 will be fine.)

Ok, thanks.

 and that _WIN32 is the correct macro to use to select code which is common
 to MinGW and Cygwin.

   Alas no:

 $ gcc-4 -E -  /dev/null -dM | grep WIN
 #define __WINT_MAX__ 4294967295U
 #define __WINT_MIN__ 0U
 #define __SIZEOF_WINT_T__ 4
 #define __CYGWIN__ 1
 #define __WINT_TYPE__ unsigned int
 #define __CYGWIN32__ 1

   You should probably use #if defined(__MINGW32__) || defined (__CYGWIN__),
 since that'll also work on 64-bit Cygwin, as opposed to using __CYGWIN32__.  I
 think __MINGW32__ is defined for 64-bit as well as 32-bit targets.

Ok, I'll do that. Thanks for the info. FWIW, I grepped through the gcc
tree and there's quite a lot of

#if defined(_WIN32)  !defined(__CYGWIN__)

and similar, which in the light of the above, is pointless.

And yes, I also recall that mingw-w64 also defines __MINGW32__.


--
Janne Blomqvist

Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-13 Thread Janne Blomqvist 
On Sat, Apr 13, 2013 at 1:02 AM, Tobias Burnus bur...@net-b.de wrote:
 Janne Blomqvist wrote:

 the attached patch implements the SYSTEM_CLOCK intrinsics on the MinGW
 and Cygwin targets using the GetTickCount/GetTickCount64 functions.
 These should be quite robust monotonic clocks and AFAICS are the best
 we can do on Windows.


 I think using QueryPerformanceCounter is the better approach. It is
 supported since Windows 2000 and recommended as high-performance counter:
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms644900%28v=vs.85%29.aspx

I didn't want to use QPC, as it can apparently be unreliable, see e.g.
the PEP 418 I linked to previously. But it seems that the worst issues
are caused by old and somewhat rare hardware, or have been fixed in
more recent Windows service packs, so maybe it's not worth worrying
about.

 I really dislike GetTickCount, which overflows after 50 days - that's not
 what you want to have. And GetTickCount64 only exists since Vista/2008. By
 contrast, QueryPerformanceCounter should allow for finer resolution and it
 is already available since Windows 2000.

Attached is an updated patch which uses GetTickCount for
system_clock_4; this should be fine as system_clock_4 wraps around in
~25 days anyways. For system_clock_8 it uses
QueryPerformance{Counter,Frequency}.

 Regarding clock_gettime: I really think we should check check
 _POSIX_MONOTONIC_CLOCK as well. Currently,  only MONOTONIC_CLOCK is checked,
 which is always available (on POSIX conform systems).

 See GLIBCXX_ENABLE_LIBSTDCXX_TIME in libstdc++-v3/acinclude.m4 - and in
 particular ac_has_clock_monotonic.

The patch also adds an additional check for _POSIX_MONOTONIC_CLOCK.

Ok for trunk?

Frontend ChangeLog:

2013-04-13  Janne Blomqvist  j...@gcc.gnu.org

PR fortran/56919
* intrinsics.texi (SYSTEM_CLOCK): Update documentation.

libgfortran ChangeLog:

2013-04-13  Janne Blomqvist  j...@gcc.gnu.org

PR fortran/56919
* intrinsics/time_1.h: Check __CYGWIN__ in addition to
__MINGW32__.
* intrinsics/system_clock.c (GF_CLOCK_MONOTONIC): Check
_POSIX_MONOTONIC_CLOCK as well.
(system_clock_4): Use GetTickCount on Windows.
(system_clock_8): Use QueryPerformanceCounter and
QueryPerformanceCounterFrequency on Windows.


--
Janne Blomqvist


sysclockwin.2.diff
Description: Binary data

[Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-12 Thread Janne Blomqvist 
Hi,

the attached patch implements the SYSTEM_CLOCK intrinsics on the MinGW
and Cygwin targets using the GetTickCount/GetTickCount64 functions.
These should be quite robust monotonic clocks and AFAICS are the best
we can do on Windows. See e.g.
http://www.python.org/dev/peps/pep-0418/ for details.

As I don't have a Windows system to test on, I would appreciate if
somebody more familiar with that platform could take a quick look. In
particular, I *think* it should be Ok to use win32 API functions on
Cygwin (that is, cygwin-gcc ships the windows.h and other necessary
headers out of the box?), and that _WIN32 is the correct macro to use
to select code which is common to MinGW and Cygwin.

Ok for trunk?

2013-04-12  Janne Blomqvist  j...@gcc.gnu.org

PR fortran/56919
* intrinsics/time_1.h: Use _WIN32 instead of __MINGW32__ to catch
both MinGW and Cygwin.
* intrinsics/system_clock.c (system_clock_4): Use GetTickCount on
_WIN32.
(system_clock_8): Use GetTickCount64 or fallback to GetTickCount
on _WIN32.
* configure.ac (AC_CHECK_FUNCS_ONCE): Check presence of
GetTickCount64.
* config.h.in: Regenerated.
* configure: Regenerated.



--
Janne Blomqvist


sysclockwin.diff
Description: Binary data

Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-12 Thread Dave Korn 
On 12/04/2013 19:47, Janne Blomqvist wrote:

 As I don't have a Windows system to test on, I would appreciate if somebody
 more familiar with that platform could take a quick look. In particular, I
 *think* it should be Ok to use win32 API functions on Cygwin (that is,
 cygwin-gcc ships the windows.h and other necessary headers out of the
 box?),

  Well, after installing the w32api package, but basically yes, that's fine
for simple stuff like that.  (You shouldn't go doing things like creating
threads or synchronisation through the Win32 API, but calling GetTickCount[64]
will be fine.)

 and that _WIN32 is the correct macro to use to select code which is common
 to MinGW and Cygwin.

  Alas no:

 $ gcc-4 -E -  /dev/null -dM | grep WIN
 #define __WINT_MAX__ 4294967295U
 #define __WINT_MIN__ 0U
 #define __SIZEOF_WINT_T__ 4
 #define __CYGWIN__ 1
 #define __WINT_TYPE__ unsigned int
 #define __CYGWIN32__ 1

  You should probably use #if defined(__MINGW32__) || defined (__CYGWIN__),
since that'll also work on 64-bit Cygwin, as opposed to using __CYGWIN32__.  I
think __MINGW32__ is defined for 64-bit as well as 32-bit targets.

cheers,
  DaveK

Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows

2013-04-12 Thread Tobias Burnus 

Janne Blomqvist wrote:

the attached patch implements the SYSTEM_CLOCK intrinsics on the MinGW
and Cygwin targets using the GetTickCount/GetTickCount64 functions.
These should be quite robust monotonic clocks and AFAICS are the best
we can do on Windows.


I think using QueryPerformanceCounter is the better approach. It is 
supported since Windows 2000 and recommended as high-performance 
counter: 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644900%28v=vs.85%29.aspx


I really dislike GetTickCount, which overflows after 50 days - that's 
not what you want to have. And GetTickCount64 only exists since 
Vista/2008. By contrast, QueryPerformanceCounter should allow for finer 
resolution and it is already available since Windows 2000.



- Also Cygwin uses QueryPerformanceCounter for clock_gettime, now as is, 
before it subtracted some offset which caused it to start with 0 from 
process startup time. (I belive QueryPerformanceCounter counts from 
system startup.)
- MinGW-w64 also uses it  for the monotonic clock_gettime - at least in 
experimental/winpthreads.

- I think MinGW does't support it (yet?).

* * *

Regarding clock_gettime: I really think we should check check 
_POSIX_MONOTONIC_CLOCK as well. Currently,  only MONOTONIC_CLOCK is 
checked, which is always available (on POSIX conform systems).


See GLIBCXX_ENABLE_LIBSTDCXX_TIME in libstdc++-v3/acinclude.m4 - and in 
particular ac_has_clock_monotonic.


Tobias