Hi all, since the first version of my SYSTEM_CLOCK patch was not so well received, I propose here an alternative patch: It does not use a fixed COUNT_RATE, but adjusts it to match the resolution of the underlying library function which is used. For the int4 version it additionally limits COUNT_RATE to 1000, in order to provide a reasonable maximum timespan. The patch also has the effect that the reported COUNT_RATE can now depend e.g. on the linker flags used (as does the precision of the clock: 1 nanosec with -lrt and 1 microsec without).
Does anyone agree with me that this represents an improvement of the SYSTEM_CLOCK behavior? Cheers, Janus 2012/12/1 Janus Weil <ja...@gcc.gnu.org>: > Hi all, > > here is a straightforward patch for the intrinsic procedure > SYSTEM_CLOCK. It does two things: > 1) It reduces the resolution of the int8 version from 1 nanosecond to > 1 microsecond (COUNT_RATE = 1000000). > 2) It adds an int16 version with nanosecond precision. > > The motivation for item #1 was mainly that the actual precision is > usually not better than 1 microsec anyway (unless linking with -lrt). > This results in SYSTEM_CLOCK giving values whose last three digits are > zero. One can argue that this is not a dramatic misbehavior, but it > has disadvantages for certain applications, like e.g. using > SYSTEM_CLOCK to initialize the random seed in a Monte-Carlo > simulation. In general, I would say that the value of COUNT_RATE > should not be larger than the actual precision of the clock used. > > Moreover, the microsecond resolution for int8 arguments has the > advantage that it is compatible with ifort's behavior. Also I think a > resolution of 1 microsecond is sufficient for most applications. If > someone really needs more, he can now use the int16 version (and link > with -lrt). > > Regtested on x86_64-unknown-linux-gnu (although we don't actually seem > to have any test cases for SYSTEM_CLOCK yet). Ok for trunk? > > Btw, does it make sense to also add an int2 version? If yes, which > resolution? Note that most other compilers seem to have an int2 > version of SYSTEM_CLOCK ... > > Cheers, > Janus > > > 2012-12-01 Janus Weil <ja...@gcc.gnu.org> > > PR fortran/55548 > * gfortran.map (GFORTRAN_1.5): Add _gfortran_system_clock_16. > * intrinsics/system_clock.c (system_clock_8): Change resolution to > one microsec. > (system_clock_16): New function (with nanosecond resolution). > > 2012-12-01 Janus Weil <ja...@gcc.gnu.org> > > PR fortran/55548 > * intrinsic.texi (SYSTEM_CLOCK): Update documentation of SYSTEM_CLOCK. > > 2012-12-01 Janus Weil <ja...@gcc.gnu.org> > > PR fortran/55548 > * gfortran.dg/system_clock_1.f90: New test case.
pr55548_v2.diff
Description: Binary data
