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

[Bug fortran/55548] New: 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

             Bug #: 55548
           Summary: SYSTEM_CLOCK with integer(8) provides nanosecond
                    resolution, but only microsecond precision (without
                    -lrt)
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: janus@gcc.gnu.org


Simple test case:

  integer(8) :: t, rate, cmax
  call system_clock(t, rate, cmax)
  print *, t, rate, cmax
end

When compiling this without any special flags (and in particular without -lrt),
this gives a rate of 1000000000 (corresponding to 1 nanosecond), but the values
of t are only precise to 1 microsecond (the last three digits are always zero).
This is on x86_64-unknown-linux-gnu (Linux 3.4.11, glibc 2.15).

I am aware that linking with -lrt (which is mentioned in the docu) solves this
problem and makes SYSTEM_CLOCK yield values which indeed have nanosecond
precision.

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.
2) Always use microsecond with integer(8), and nanosecond with integer(16).


Using SYSTEM_CLOCK with integer(16) arguments currently results in:
sysclock.f90:(.text+0x455): undefined reference to `_gfortran_system_clock_16'

[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).

[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=gcc&view=rev&rev=194105
Log:
2012-12-03  Janus Weil  <janus@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  <janus@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)

[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!