[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

["jb at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-01 20:02:38 UTC ---
(In reply to comment #9)
> How many fortran users actually need to more precise DATE_AND_TIME though?

None, since the DATE_AND_TIME API is limited to millisecond precision. The
motivation for using clock_gettime() is the SYSTEM_CLOCK intrinsic, whose
purpose is precise measurement of wall clock intervals. In this case, the
SYSTEM_CLOCK API allows us to expose the extra precision to user code, and
perhaps more importantly, we use CLOCK_MONOTONIC which is better suited for
this purpose than CLOCK_REALTIME.

The reason why DATE_AND_TIME now also uses clock_gettime() is that part of the
patch was some cleanup centralizing #ifdefs under a single gf_gettime()
function rather than sprinkling them around the code.

> Bringing in -lpthread (as dependency of -lrt) certainly has some extra
> overhead, e.g. everything that uses gthr* will suddenly use real locking.
> You could e.g. use clock_gettime only through a weakref, thus let the users
> choose if clock_gettime should be used or not.  If they don't link in librt,
> less precise implementation would be used, if they do link it in, it would
> become more precise (-lrt would be linked in automatically e.g. for -fopenmp
> compilations).

The above being said, this sounds like a good idea. I'll look into this rather
than trying to link librt statically.

(FWIW I don't think the extra locking overhead would matter in practice, as
libgfortran uses quite coarse grained locking, and AFAIK uncontested futexes
are very fast)