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)
