[Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55548

Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to janus from comment #3)
 Leftover to-do item:
 
  Using SYSTEM_CLOCK with integer(16) arguments currently results in:
  sysclock.f90:(.text+0x455): undefined reference to 
  `_gfortran_system_clock_16'
 
 ... add an integer(16) version of SYSTEM_CLOCK!

This was one sometime before gfortran 5.0. Closing!

[Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55548



--- Comment #2 from janus at gcc dot gnu.org 2012-12-03 22:06:45 UTC ---

Author: janus

Date: Mon Dec  3 22:06:41 2012

New Revision: 194105



URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194105

Log:

2012-12-03  Janus Weil  ja...@gcc.gnu.org



PR fortran/55548

* intrinsics/system_clock.c (gf_gettime_mono): Add argument 'tck',

which returns the clock resolution.

(system_clock_4): Get resolution from gf_gettime_mono, but limit to

1000/s.

(system_clock_8): Get resolution from gf_gettime_mono.



2012-12-03  Janus Weil  ja...@gcc.gnu.org



PR fortran/55548

* intrinsic.texi (SYSTEM_CLOCK): Update documentation of SYSTEM_CLOCK.



Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/intrinsic.texi

trunk/libgfortran/ChangeLog

trunk/libgfortran/intrinsics/system_clock.c

[Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55548



--- Comment #3 from janus at gcc dot gnu.org 2012-12-03 22:19:27 UTC ---

(In reply to comment #0)

 However, the precision claimed by the COUNT_RATE argument should better match

 the actual precision (also with default flags!).

 

 

 Possible solutions:

 1) Use a nanosecond COUNT_RATE only when -lrt is given, and microsecond

 otherwise.



This has been implemented in r194105.





Leftover to-do item:



 Using SYSTEM_CLOCK with integer(16) arguments currently results in:

 sysclock.f90:(.text+0x455): undefined reference to `_gfortran_system_clock_16'



... add an integer(16) version of SYSTEM_CLOCK!

[Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55548



janus at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-12-01

 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from janus at gcc dot gnu.org 2012-12-01 10:18:17 UTC ---

I just checked the COUNT_RATE results of a few other compilers that I have

access to:



ifort 12.1.2:

integer(2): 1E3 (1 ms)

integer(4): 1E4 (0.1 ms)

integer(8): 1E6 (1 microsec)



sunf95 12.3:

integer(2): 1E3 (1 ms)

integer(4): 1E3 (1 ms)

integer(8): 1E3 (1 ms)



g95 0.93:

integer(2): 1E4 (0.1 ms)

integer(4): 1E4 (0.1 ms)

integer(8): 1E4 (0.1 ms)



None of them supports integer(16). sunf95 and g95 both give a COUNT_MAX of -1

with integer(2).