public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/55548] New: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
@ 2012-11-30 14:07 janus at gcc dot gnu.org
2012-12-01 10:18 ` [Bug fortran/55548] " janus at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2012-11-30 14:07 UTC (permalink / raw)
To: gcc-bugs
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'
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
2012-11-30 14:07 [Bug fortran/55548] New: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt) janus at gcc dot gnu.org
@ 2012-12-01 10:18 ` janus at gcc dot gnu.org
2012-12-03 22:07 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2012-12-01 10:18 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
2012-11-30 14:07 [Bug fortran/55548] New: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt) janus at gcc dot gnu.org
2012-12-01 10:18 ` [Bug fortran/55548] " janus at gcc dot gnu.org
@ 2012-12-03 22:07 ` janus at gcc dot gnu.org
2012-12-03 22:19 ` janus at gcc dot gnu.org
2015-08-16 19:55 ` fxcoudert at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2012-12-03 22:07 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
2012-11-30 14:07 [Bug fortran/55548] New: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt) janus at gcc dot gnu.org
2012-12-01 10:18 ` [Bug fortran/55548] " janus at gcc dot gnu.org
2012-12-03 22:07 ` janus at gcc dot gnu.org
@ 2012-12-03 22:19 ` janus at gcc dot gnu.org
2015-08-16 19:55 ` fxcoudert at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2012-12-03 22:19 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
2012-11-30 14:07 [Bug fortran/55548] New: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt) janus at gcc dot gnu.org
` (2 preceding siblings ...)
2012-12-03 22:19 ` janus at gcc dot gnu.org
@ 2015-08-16 19:55 ` fxcoudert at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2015-08-16 19:55 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-08-16 19:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-30 14:07 [Bug fortran/55548] New: SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt) janus at gcc dot gnu.org
2012-12-01 10:18 ` [Bug fortran/55548] " janus at gcc dot gnu.org
2012-12-03 22:07 ` janus at gcc dot gnu.org
2012-12-03 22:19 ` janus at gcc dot gnu.org
2015-08-16 19:55 ` fxcoudert at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).