When I compile the following program: PROGRAM call_date_and_time CHARACTER(LEN=8) date CHARACTER(LEN=10) time CALL DATE_AND_TIME(date, time) END PROGRAM call_date_and_time I get the message: /home/mrichmon/usr/local/gfortran/bin/../lib/gcc/i686-pc-linux-gnu/4.6.0/../../../libgfortran.a(date_and_time.o): In function `gf_gettime': /home/jerry/gcc/trunk/libgfortran/intrinsics/time_1.h:211: undefined reference to `clock_gettime' collect2: ld returned 1 exit status This bug is specific to the following build: http://gfortran.org/download/i686/gfortran-4.6-20110201-linux-i686.tar.gz Is it due to Patch 81226?
clock_gettime is part of POSIX. Linux's man page states: Feature Test Macro Requirements for glibc _POSIX_C_SOURCE >= 199309L
On Linux/Glibc libgfortran is built with _GNU_SOURCE, which according to the glibc manual is a superset of all kinds of _POSIX_C_SOURCE=[latest_supported_standard] XOPEN_SOURCE=[latest_supported_standard] and so forth. My guess is that the issue is due to mismatch between the build environment and the environment where gfortran is executed. It might be that the OP is running on some old distro that doesn't provide librt.so which is needed by clock_gettime() on Glibc. OP, what does "ldd /path/to/libgfortran.so.3" say? FWIW, I have no idea what "Patch 81226" refers to.
clock_gettime is defined in librt, so if libgfortran started using librt symbols, it needs to a) link against it dynamically for libgfortran.so b) arrange for gfortran driver to pass in -lrt when linking libgfortran statically.
(In reply to comment #2) > OP, what does "ldd /path/to/libgfortran.so.3" say? linux-gate.so.1 => (0xffffe000) libm.so.6 => /lib/libm.so.6 (0xb772b000) libc.so.6 => /lib/libc.so.6 (0xb75c0000) /lib/ld-linux.so.2 (0xb7822000) I am running SuSE Linux 11.3
For the symbols defined in librt, cf. http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/librt.html Regarding http://gcc.gnu.org/ml/fortran/2011-01/msg00326.html >> 2) Uses clock_gettime() if available and (In reply to comment #3) > clock_gettime is defined in librt, so if libgfortran started using librt > symbols It probably means that one needs to use libgfortran.spec for that as f951 has no knowledge whether clock_gettime is available. Is is clear that librt exists if clock_gettime is available? librt seems to be a Linux-specific library-name choice. If not, one could consider moving back to a clock_gettime-free libgfortran.
(In reply to comment #3) > clock_gettime is defined in librt, so if libgfortran started using librt > symbols, it needs to a) link against it dynamically for libgfortran.so Yes, that's what it does, using a configure.ac snippet lifted from libgomp. On my system, ldd libgfortran.so shows: linux-vdso.so.1 => (0x00007fff71ae9000) libquadmath.so.0 => /home/janne/src/gfortran/trunk/install/lib/../lib64/libquadmath.so.0 (0x00007f885a485000) libm.so.6 => /lib/libm.so.6 (0x00007f885a1df000) librt.so.1 => /lib/librt.so.1 (0x00007f8859fd7000) libc.so.6 => /lib/libc.so.6 (0x00007f8859c54000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f8859a36000) /lib64/ld-linux-x86-64.so.2 (0x00007f885a9cf000) where the librt and libpthread dependencies are due to using clock_gettime() from librt. > b) > arrange for gfortran driver to pass in -lrt when linking libgfortran > statically. Right, I haven't considered this part. Anyone have any idea how that could be done?
So using -static I was able to reproduce this bug on x86_64-unknown-linux-gnu. As Jakub mentioned, the driver must link in librt when linking statically. I'll look into how this could be done. As a workaround for the reporter, dynamic linking works fine.
(In reply to comment #6) > > clock_gettime is defined in librt, so if libgfortran started using librt > > symbols, it needs to a) link against it dynamically for libgfortran.so > > Yes, that's what it does But why doesn't it work then, cf. comment 4? openSUSE 11.3 is neither old nor very special. > > b) > > arrange for gfortran driver to pass in -lrt when linking libgfortran > > statically. > Right, I haven't considered this part. Anyone have any idea how that could be > done? Via libgfortran/libgfortran.spec.in and some configure script? Cf. libgomp and libgomp/configure.ac's # Set up the set of libraries that we need to link against for libgomp. # Note that the GOMP_SELF_SPEC in gcc.c will force -pthread for -fopenmp, # which will force linkage against -lpthread (or equivalent for the system). # That's not 100% ideal, but about the best we can do easily. if test $enable_shared = yes; then link_gomp="-lgomp %{static: $LIBS}" else link_gomp="-lgomp $LIBS" fi AC_SUBST(link_gomp) By the way, there is also -lrt added via libgomp/configure.tgt for HPUX.
How many fortran users actually need to more precise DATE_AND_TIME though? 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).
(In reply to comment #7) > As a workaround for the reporter, dynamic linking works fine. When I use "gfortran -Bdynamic call_date_and_time.f90" I get the same error
(In reply to comment #8) > (In reply to comment #6) > > > clock_gettime is defined in librt, so if libgfortran started using librt > > > symbols, it needs to a) link against it dynamically for libgfortran.so > > > > Yes, that's what it does > > But why doesn't it work then, cf. comment 4? openSUSE 11.3 is neither old nor > very special. Because the original report links statically (as can be deduced from the presence of libgfortran.a). As I mentioned, static linking is broken but dynamic works. FWIW, I suspect the output of ldd in comment #4 refers to the system provided libgfortran, as neither librt nor libquadmath is present. > > > > b) > > > arrange for gfortran driver to pass in -lrt when linking libgfortran > > > statically. > > Right, I haven't considered this part. Anyone have any idea how that could be > > done? > > Via libgfortran/libgfortran.spec.in and some configure script? > > Cf. libgomp and libgomp/configure.ac's > > # Set up the set of libraries that we need to link against for libgomp. > # Note that the GOMP_SELF_SPEC in gcc.c will force -pthread for -fopenmp, > # which will force linkage against -lpthread (or equivalent for the system). > # That's not 100% ideal, but about the best we can do easily. > if test $enable_shared = yes; then > link_gomp="-lgomp %{static: $LIBS}" > else > link_gomp="-lgomp $LIBS" > fi > AC_SUBST(link_gomp) > > > By the way, there is also -lrt added via libgomp/configure.tgt for HPUX. Thanks, I'll have to take a look at this later tonight.
I concur with Jakub. If (big "if") I have understood weakrefs correctly, one does something like in libquadmath/quadmath_weak.h and then can use them then in the following way if (__weak_reference_name) res = __weak_reference_name () else res = some_other_function (Cf. also http://stackoverflow.com/questions/274753/)
(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)
Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00075.html I'm a bit unsure about the whole weakref stuff, but this seems to work for me on x86_64-unknown-linux-gnu.
Author: jb Date: Wed Feb 2 08:48:24 2011 New Revision: 169517 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169517 Log: PR 47571 Weakref trickery for clock_gettime() Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/time_1.h
(In reply to comment #15) > Author: jb > Date: Wed Feb 2 08:48:24 2011 > New Revision: 169517 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169517 > Log: > PR 47571 Weakref trickery for clock_gettime() > > Modified: > trunk/libgfortran/ChangeLog > trunk/libgfortran/configure > trunk/libgfortran/configure.ac > trunk/libgfortran/intrinsics/time_1.h Causes /usr/ccs/bin/ld: Invalid symbol type for plabel (.libs/date_and_time.o, clock_ge ttime). collect2: ld returned 1 exit status on hppa2.0w-hp-hpux11.11. Weak references don't work on this target and probably others.
(In reply to comment #16) > on hppa2.0w-hp-hpux11.11. Weak references don't work on this target and > probably others. If weak symbols do not work, why is then SUPPORTS_WEAK set? (Or, if it isn't set, why does it fail?)
To add to Tobias comment, in the patch the only place where a weakref is used is +#ifdef SUPPORTS_WEAK +static int weak_gettime (clockid_t, struct timespec *) + __attribute__((__weakref__("clock_gettime"))); +#else +static inline int weak_gettime (clockid_t clk_id, struct timespec *res) +{ + return clock_gettime (clk_id, res); +} +#endif That is, for some reason SUPPORTS_WEAK must be defined on HPUX even though weak references are not actually supported. Why is this?
Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html This is my previous janitorial patch, + a kludge which I believe should fix the issue on HP-UX and other targets that support weak references but not weak undefined references.
> > on hppa2.0w-hp-hpux11.11. Weak references don't work on this target and > > probably others. > > If weak symbols do not work, why is then SUPPORTS_WEAK set? (Or, if it isn't > set, why does it fail?) The situation is messy and difficult: 1) The backend defines TARGET_SUPPORTS_WEAK. This is needed for C++. The support varies based on assembler, etc. The target has COMDAT and secondary symbol symbol support when GAS is used. This allows for multiple definitions of functions and data. However, undefined weak symbols are not supported. It is not possible to check whether a function is defined or not using a `if'. A function pointer is actually a pointer to a function descriptor (plabel). 2) Libgfortran defines SUPPORTS_WEAK based on #pragma weak. This is probably wrong for PA HP-UX. There is a similar situation in gthr-posix.h where there is a mechanism to override SUPPORTS_WEAK. 3) I think the actual error was caused by the lack of a declaration for clock_gettime as a function. The default symbol type is data. Was <time.h> included? 4) Because of 1, the `if' will always evaluate to true. HP-UX has clock_gettime, so this shouldn't be a problem. Dave
> Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html > > This is my previous janitorial patch, + a kludge which I believe should fix the > issue on HP-UX and other targets that support weak references but not weak > undefined references. Fixes build error on HP-UX. Dave
Author: jb Date: Sat Feb 5 16:22:04 2011 New Revision: 169852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169852 Log: PR 47571 Fix HPUX bootstrap regression, cleanup Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/date_and_time.c trunk/libgfortran/intrinsics/system_clock.c trunk/libgfortran/intrinsics/time_1.h
Fixed, closing.
All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an undefined reference to clock_gettime: clock_gettime | 0000000000000000 | U | 0000000000000000 The function is defined in librt only.
(In reply to comment #24) > All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an > undefined reference to clock_gettime: > The function is defined in librt only. Also with GLIBC Linux one only gets it via librt; on Linux and on HPUX it works via a weakref; seemingly it does not work on Tru64. Does it have weakrefs? Does the problem only occur for static or also for dynamic linkage? Cf. previous patches http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00075.html and http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html
> --- Comment #25 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-03-07 16:08:23 UTC --- > (In reply to comment #24) >> All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an >> undefined reference to clock_gettime: >> The function is defined in librt only. > > Also with GLIBC Linux one only gets it via librt; on Linux and on HPUX it works > via a weakref; seemingly it does not work on Tru64. Does it have weakrefs? Does Tru64 UNIX doesn't support weak undefined symbols, which seems to be what weakrefs are. > the problem only occur for static or also for dynamic linkage? I haven't yet tried static linking, but when using a dynamic libgfortran.so, the breakage occurs as described. Rainer
> >> All fortran testing is broken on Tru64 UNIX, where libgfortran.so has an > >> undefined reference to clock_gettime: > >> The function is defined in librt only. > > > > Also with GLIBC Linux one only gets it via librt; on Linux and on HPUX it works > > via a weakref; seemingly it does not work on Tru64. Does it have weakrefs? Does The function clock_gettime is available in both libc and librt on PA-RISC HP-UX. I see a compilation warning on 32-bit HP-UX that `if (clock_gettime)' will always evaluate to true. Since libc is always linked in, there isn't a problem on PA HP-UX. Dave
(In reply to comment #26) > Tru64 UNIX doesn't support weak undefined symbols, which seems to be > what weakrefs are. Hmm, I think it is going to be difficult. What we want to have: a) If libc has clock_gettime, use it unconditionally b) If librt has clock_gettime and weak refs are supported, use it if available c) If librt has it, but no weak refs are supported, don't use it. d) If it not available at all, don't use it. (b) and (d) work; also (a) works - albeit with a warning. Now one needs to support (c). I think the best would be to set (effectively) HAVE_CLOCK_GETTIME to false. One possibility would be to replace: #ifdef HAVE_CLOCK_GETTIME # ifdef SUPPORTS_WEAK ... # else by #if define(HAVE_CLOCK_GETTIME) && define(SUPPORTS_WEAK) That would exclude platforms, where libc supports clock_gettime but which do not have weak refs. Another possibility is a link-time check which does not work well for some cross-compilations. What do you think?
(In reply to comment #28) > (In reply to comment #26) > > Tru64 UNIX doesn't support weak undefined symbols, which seems to be > > what weakrefs are. > > Hmm, I think it is going to be difficult. What we want to have: > > a) If libc has clock_gettime, use it unconditionally > b) If librt has clock_gettime and weak refs are supported, use it if > available > c) If librt has it, but no weak refs are supported, don't use it. > d) If it not available at all, don't use it. Yes, sounds like a good plan. > (b) and (d) work; also (a) works - albeit with a warning. Now one needs to > support (c). Indeed; the patch was developed based on the understanding that only Linux has clock_gettime in librt, and Linux supports weakrefs, so (c) does not need to be considered. Oh well. > I think the best would be to set (effectively) HAVE_CLOCK_GETTIME > to false. > > One possibility would be to replace: > > #ifdef HAVE_CLOCK_GETTIME > # ifdef SUPPORTS_WEAK > ... > # else > > by > > #if define(HAVE_CLOCK_GETTIME) && define(SUPPORTS_WEAK) > > That would exclude platforms, where libc supports clock_gettime but which do > not have weak refs. Another possibility is a link-time check which does not > work well for some cross-compilations. > > What do you think? I think the easiest way would be to change the test in configure.ac where we check for clock_gettime in librt, so that we set, say, HAVE_CLOCK_GETTIME_LIBRT instead of HAVE_CLOCK_GETTIME, thus allowing us to distinguish whether the function a) exists at all b) is in libc or librt. That being said, I'd prefer to postpone this fix to stage 1 due to - I'm currently moving flats so my stuff is all over and I'm very busy - AFAIU 4.6 release is imminent? - I lack the ability to test all weird and wonderful targets. - This close to release I'd very much like to avoid regressions in primary or secondary targets. - As can be seen in the reopening of this PR, for less used targets there might anyway be a month latency between something landing in trunk and getting test reports. Thus, I'd suggest fixing this in stage 1, then, after getting reports that the fix works, backport hopefully in time for 4.6.1. Of course, the above is only my own justifications and constraints; if someone else wants to fix it ASAP, go right ahead.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 > > --- Comment #29 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-08 22:38:49 UTC --- > (In reply to comment #28) > > (In reply to comment #26) > > > Tru64 UNIX doesn't support weak undefined symbols, which seems to be > > > what weakrefs are. > > > > Hmm, I think it is going to be difficult. What we want to have: > > > > a) If libc has clock_gettime, use it unconditionally > > b) If librt has clock_gettime and weak refs are supported, use it if > > available > > c) If librt has it, but no weak refs are supported, don't use it. > > d) If it not available at all, don't use it. > > Yes, sounds like a good plan. > > > (b) and (d) work; also (a) works - albeit with a warning. Now one needs to > > support (c). > > Indeed; the patch was developed based on the understanding that only Linux has > clock_gettime in librt, and Linux supports weakrefs, so (c) does not need to be > considered. Oh well. > > > I think the best would be to set (effectively) HAVE_CLOCK_GETTIME > > to false. > > > > One possibility would be to replace: > > > > #ifdef HAVE_CLOCK_GETTIME > > # ifdef SUPPORTS_WEAK > > ... > > # else > > > > by > > > > #if define(HAVE_CLOCK_GETTIME) && define(SUPPORTS_WEAK) > > > > That would exclude platforms, where libc supports clock_gettime but which do > > not have weak refs. Another possibility is a link-time check which does not > > work well for some cross-compilations. > > > > What do you think? > > I think the easiest way would be to change the test in configure.ac where we > check for clock_gettime in librt, so that we set, say, HAVE_CLOCK_GETTIME_LIBRT > instead of HAVE_CLOCK_GETTIME, thus allowing us to distinguish whether the > function a) exists at all b) is in libc or librt. I think it is unnecessary to check whether clock_gettime is in librt as we don't want libgfortran to depend on librt in general. This reduces the accuracy when weak references are not supported and clock_gettime is only in librt. The case where weak references are supported and clock_gettime isn't available at all seems remote. If weak references are supported, always define weak_gettime as __attribute__((__weakref__("clock_gettime"))). Probably, the extra overhead of the runtime check is acceptable. If weak references are not supported and clock_gettime is in libc, define weak_gettime as we currently do: static inline int weak_gettime (clockid_t clk_id, struct timespec *res) { return clock_gettime (clk_id, res); } Condition the code that uses weak_gettime on either having clock_gettime in libc or weak references. This could be tweaked to eliminate the `if' when clock_gettime is in libc. Dave
> That being said, I'd prefer to postpone this fix to stage 1 due to > > - I'm currently moving flats so my stuff is all over and I'm very busy > - AFAIU 4.6 release is imminent? > - I lack the ability to test all weird and wonderful targets. > - This close to release I'd very much like to avoid regressions in primary or > secondary targets. > - As can be seen in the reopening of this PR, for less used targets there might > anyway be a month latency between something landing in trunk and getting test > reports. Not really: the delay was caused because the test system broke and it took me quite some time to get myself a replacement. Normally, I bootstrap everywhere once a week and analyse results. > Thus, I'd suggest fixing this in stage 1, then, after getting reports that the > fix works, backport hopefully in time for 4.6.1. > > Of course, the above is only my own justifications and constraints; if someone > else wants to fix it ASAP, go right ahead. I'd really like to see this fixed before 4.6.0: it is a regression from 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively minor gain on other platforms. If all else fails, I'd go as far as advocating to revert the patch that introduced clock_gettime (and quite late in the release cycle, I might say). Sorry for being so late to reply: I've been totally swamped this week. Thanks. Rainer
Created attachment 23648 [details] Proposed patch
I think you should add below the hunk defining conditionally GF_CLOCK_MONOTONIC: #ifndef GF_CLOCK_MONOTONIC #undef HAVE_CLOCK_GETTIME #undef HAVE_CLOCK_GETTIME_LIBRT #endif now that you don't define GF_CLOCK_MONOTONIC if CLOCK_REALTIME isn't defined.
(In reply to comment #31) > > That being said, I'd prefer to postpone this fix to stage 1 due to > > > > - I'm currently moving flats so my stuff is all over and I'm very busy > > - AFAIU 4.6 release is imminent? > > - I lack the ability to test all weird and wonderful targets. > > - This close to release I'd very much like to avoid regressions in primary or > > secondary targets. > > - As can be seen in the reopening of this PR, for less used targets there might > > anyway be a month latency between something landing in trunk and getting test > > reports. > > Not really: the delay was caused because the test system broke and it > took me quite some time to get myself a replacement. Normally, I > bootstrap everywhere once a week and analyse results. Ok, that's nice to hear. Of course, it doesn't change the fact that this time it did take a month, and, one might add, at almost the worst possible moment. ;) > > Thus, I'd suggest fixing this in stage 1, then, after getting reports that the > > fix works, backport hopefully in time for 4.6.1. > > > > Of course, the above is only my own justifications and constraints; if someone > > else wants to fix it ASAP, go right ahead. > > I'd really like to see this fixed before 4.6.0: it is a regression from > 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively > minor gain on other platforms. Well, do we really have any actual gfortran users on Tru64? Whereas a high-resolution monotonic clock, while admittedly not a huge feature per se, is something that is now available to gfortran users on some rather more popular platforms. > If all else fails, I'd go as far as > advocating to revert the patch that introduced clock_gettime There has been a number of patches in this area more or less related to clock_gettime, so IMHO fixing it properly is simpler and less prone to introduce new regressions. My previous message in this PR hopefully does exactly this and introduces a patch which should fix it along the lines previously discussed. As my normal gcc development machine is packed in a box, I haven't been able to test it. Also, note that it won't apply cleanly as the paths are messed up (but the contents should otherwise apply fine). As I mentioned previously, I'd prefer to commit it after the 4.6 release, but if the reviewer(s) feel it's safe I'm fine with getting it in for 4.6. > (and quite > late in the release cycle, I might say). Yes, it started out as a simple patch which turned into a morass of system-dependent stuff wrt. where clock_gettime lives and various levels of weakref support. Sorry about that.
(In reply to comment #33) > I think you should add below the hunk defining conditionally > GF_CLOCK_MONOTONIC: > #ifndef GF_CLOCK_MONOTONIC > #undef HAVE_CLOCK_GETTIME > #undef HAVE_CLOCK_GETTIME_LIBRT > #endif > now that you don't define GF_CLOCK_MONOTONIC if CLOCK_REALTIME isn't defined. Thanks; that should protect against the case where clock_gettime is available but neither CLOCK_REALTIME nor CLOCK_MONOTONIC are. Ideally, this shouldn't be necessary as POSIX specifies that CLOCK_REALTIME must always be available if clock_gettime exists, but I suppose both belts and suspenders are nice in this case.. :)
CLOCK_REALTIME should be available, at least on POSIX compliant systems, but must it be defined as preprocessor macro? http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html talks about manifest constants, not macros. So it wouldn't surprise me if it was defined in an enum rather than using #define. Alternatively to those undefs would be to do #ifdef CLOCK_MONOTONIC #define GF_CLOCK_MONOTONIC CLOCK_MONOTONIC #else #define GF_CLOCK_MONOTONIC CLOCK_REALTIME #endif and just keep using GF_CLOCK_MONOTONIC only in code guarded with HAVE_CLOCK_GETTIME or HAVE_CLOCK_GETTIME_LIBRT, or #ifdef CLOCK_MONOTONIC #define GF_CLOCK_MONOTONIC CLOCK_MONOTONIC #elif defined (HAVE_CLOCK_GETTIME) || defined (HAVE_CLOCK_GETTIME_LIBRT) #define GF_CLOCK_MONOTONIC CLOCK_REALTIME #endif if you prefer that.
>> I'd really like to see this fixed before 4.6.0: it is a regression from >> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively >> minor gain on other platforms. > > Well, do we really have any actual gfortran users on Tru64? Whereas a > high-resolution monotonic clock, while admittedly not a huge feature per se, is > something that is now available to gfortran users on some rather more popular > platforms. Why would they tell me: `Hey, I'm using gfortran on Tru64 UNIX and all is fine.'? You will only learn if things break. >> If all else fails, I'd go as far as >> advocating to revert the patch that introduced clock_gettime > > There has been a number of patches in this area more or less related to > clock_gettime, so IMHO fixing it properly is simpler and less prone to > introduce new regressions. My previous message in this PR hopefully does > exactly this and introduces a patch which should fix it along the lines > previously discussed. As my normal gcc development machine is packed in a box, > I haven't been able to test it. Also, note that it won't apply cleanly as the > paths are messed up (but the contents should otherwise apply fine). There have been some subsequent suggestions/updates, so I'm uncertain if I should test this patch or wait for an update. > As I mentioned previously, I'd prefer to commit it after the 4.6 release, but > if the reviewer(s) feel it's safe I'm fine with getting it in for 4.6. Now that 4.6 has branched, it's safer to commit to mainline after some testing and only backport to 4.6 after it has proven correct. If all else fails, one could apply a hack to 4.6 along the lines of #if defined(__alpha__) && defined(__osf__) #undef HAVE_CLOCK_GETTIME #endif or some configure.ac equivalent. Ugly but still better than completely breaking Fortran. Rainer
Created attachment 23669 [details] Updated patch This patch takes into account the comments by Jakub, and unconditionally sets GF_CLOCK_MONOTONIC if clock_gettime is available; this should fix a bug if CLOCK_* are not preprocessor macros. Also, paths should be correct now, if the patch is applied in libgfortran/
Looks fine to me.
(In reply to comment #37) > >> I'd really like to see this fixed before 4.6.0: it is a regression from > >> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively > >> minor gain on other platforms. > > > > Well, do we really have any actual gfortran users on Tru64? Whereas a > > high-resolution monotonic clock, while admittedly not a huge feature per se, is > > something that is now available to gfortran users on some rather more popular > > platforms. > > Why would they tell me: `Hey, I'm using gfortran on Tru64 UNIX and all > is fine.'? You will only learn if things break. While I have no proof, I find it difficult to imagine that we have a significant amount of bleeding edge users that upgrade to the latest and greatest gcc release on an expensive platform where new hw isn't sold since many years, and the OS is scheduled to go EOL in a year or so. So while IMHO it would be nice if we could get a fix into 4.6, I don't think it's the end of the world if these users, if they exist at all, will have to wait until 4.6.1. > >> If all else fails, I'd go as far as > >> advocating to revert the patch that introduced clock_gettime > > > > There has been a number of patches in this area more or less related to > > clock_gettime, so IMHO fixing it properly is simpler and less prone to > > introduce new regressions. My previous message in this PR hopefully does > > exactly this and introduces a patch which should fix it along the lines > > previously discussed. As my normal gcc development machine is packed in a box, > > I haven't been able to test it. Also, note that it won't apply cleanly as the > > paths are messed up (but the contents should otherwise apply fine). > > There have been some subsequent suggestions/updates, so I'm uncertain if > I should test this patch or wait for an update. The suggestion are only for the potential corner case where CLOCK_* are not preprocessor macros but e.g. enums. In any case, this is fixed in the updated patch I just posted, so feel free to try that one. > Now that 4.6 has branched, it's safer to commit to mainline after some > testing and only backport to 4.6 after it has proven correct. I agree. > If all > else fails, one could apply a hack to 4.6 along the lines of > > #if defined(__alpha__) && defined(__osf__) > #undef HAVE_CLOCK_GETTIME > #endif > > or some configure.ac equivalent. Ugly but still better than completely > breaking Fortran. Yes, that's a possibility. OTOH I think my patch should be fairly simple and safe, but ultimately that's up to the reviewer(s) to decide.
(In reply to comment #37) > #if defined(__alpha__) && defined(__osf__) > #undef HAVE_CLOCK_GETTIME > #endif > > or some configure.ac equivalent. Ugly but still better than completely > breaking Fortran. Thinking about this some more, while the above is ugly it should at least be safe. Please consider it approved from my part for 4.6; if you get approval from the release manager, please commit it. I'll regtest and submit my patch to review for trunk, and backport to the 4.6 branch after it has been in trunk for a while; I suspect this won't make the 4.6 release and will thus have to wait for 4.6.1. Hence your patch is a usable compromise for 4.6.0.
> --- Comment #41 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-15 20:38:18 UTC --- > (In reply to comment #37) >> #if defined(__alpha__) && defined(__osf__) >> #undef HAVE_CLOCK_GETTIME >> #endif >> >> or some configure.ac equivalent. Ugly but still better than completely >> breaking Fortran. > > Thinking about this some more, while the above is ugly it should at least be > safe. Please consider it approved from my part for 4.6; if you get approval > from the release manager, please commit it. Regtest in progress, will submit and Cc: a RM once this has finished. > I'll regtest and submit my patch to review for trunk, and backport to the 4.6 > branch after it has been in trunk for a while; I suspect this won't make the > 4.6 release and will thus have to wait for 4.6.1. Hence your patch is a usable > compromise for 4.6.0. Thanks, that's all I'm asking for :-) Rainer
Author: ro Date: Thu Mar 17 13:29:01 2011 New Revision: 171095 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171095 Log: PR fortran/47571 * intrinsics/system_clock.c [__alpha__ && __osf__] (HAVE_CLOCK_GETTIME): Undef. Modified: branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/intrinsics/system_clock.c
Workaround installed on 4.6 branch.
> --- Comment #38 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-15 17:04:41 UTC --- > Created attachment 23669 [details] > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23669 > Updated patch > > This patch takes into account the comments by Jakub, and unconditionally sets > GF_CLOCK_MONOTONIC if clock_gettime is available; this should fix a bug if > CLOCK_* are not preprocessor macros. This patch doesn't work: SUPPORTS_WEAK is 1, GTHREAD_USE_WEAK is 1 since acinclude.m4 (LIBGFOR_GTHREAD_WEAK) doesn't set it to 0, and HAVE_CLOCK_GETTIME_LIBRT is 1, too, so we still have an undefined reference to clock_gettime ;-( Could we please avoid this mess with SUPPORTS_WEAK and GTHREAD_USE_WEAK and make configure define SUPPORTS_WEAKREF or something like this, since this is what we are actually looking for? If we include alpha*-dec-osf* in the list of targets that don't support weakrefs, things should start working again, but I'd prefer a patch where you can actually read *and understand* what's going on here. Apart from that, has anyone actually *measured* the overhead of simply linking libgfortran with librt on Linux, rather than claiming that there might be some? It the overhead were acceptable or even neglegible, we could avoid all this mess in the first place, link with -lrt if need be, and be done with it. Additionally, the usage model for the weakref seems questionable to me: while the technique is well-known and common on ELF targets to produce code that can work with or without libpthread linked into the application (which is what users will actually do!), which user is supposed to link his Fortran code with librt to get improved system clock resolution? I dare say that close to nobody will even think about this. Rainer
You clearly don't understand that linking librt in means linking both librt and libpthread in, thus both some overhead at the start of application, for various places in the C library that behave differently if libpthread is linked in, and even gthr* suddenly is more costly just because librt has been linked in. I think on a target which doesn't support weaks having GFORTRAN_USE_WEAK defined to 1 is just wrong.
> --- Comment #46 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-21 16:34:39 UTC --- > You clearly don't understand that linking librt in means linking both librt and > libpthread in, thus both some overhead at the start of application, for various > places in the C library that behave differently if libpthread is linked in, and > even gthr* suddenly is more costly just because librt has been linked in. Of course I do, I was just asking for what the actual overhead is. > I think on a target which doesn't support weaks having GFORTRAN_USE_WEAK > defined to 1 is just wrong. No, this target (and others) do support weak, just not weakrefs. The macros should reflect their meaning (SUPPORTS_WEAKREF) and have all necessary knowledge in one place (acinclude.m4) instead of playing games with both SUPPORTS_WEAK and GTHREAD_USE_WEAK. Rainer
On Mon, Mar 21, 2011 at 16:47, ro at CeBiTec dot Uni-Bielefeld.DE <gcc-bugzilla@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 > > --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-21 14:47:20 UTC --- >> --- Comment #38 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-15 17:04:41 UTC --- >> Created attachment 23669 [details] >> --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23669 >> Updated patch >> >> This patch takes into account the comments by Jakub, and unconditionally sets >> GF_CLOCK_MONOTONIC if clock_gettime is available; this should fix a bug if >> CLOCK_* are not preprocessor macros. > > This patch doesn't work: > > SUPPORTS_WEAK is 1, GTHREAD_USE_WEAK is 1 since acinclude.m4 > (LIBGFOR_GTHREAD_WEAK) doesn't set it to 0, and HAVE_CLOCK_GETTIME_LIBRT > is 1, too, so we still have an undefined reference to clock_gettime ;-( Thanks for testing this! > Could we please avoid this mess with SUPPORTS_WEAK and GTHREAD_USE_WEAK > and make configure define SUPPORTS_WEAKREF or something like this, since > this is what we are actually looking for? The point was to piggyback on the existing weakref support in libgfortran rather than reinvent the wheel, but yeah, it's a bit confusing. It seems that target backends expose macros with these same names, but they are not visible anymore when compiling libgfortran, hence the current hack trying to recreate them in libgfortran configuration. Or at least, that's the most plausible reason I came up with, I did not write that particular code nor do I claim any deep expertise in this matter. > If we include alpha*-dec-osf* in the list of targets that don't support > weakrefs, things should start working again, but I'd prefer a patch where > you can actually read *and understand* what's going on here. Would it be possible to create some test using AC_LINK_IFELSE to check whether weakrefs are supported? That way we could get rid of the ugly blacklist for defining GTHREAD_USE_WEAK. In any case, IMHO that's the topic of a separate patch. > Apart from that, has anyone actually *measured* the overhead of simply > linking libgfortran with librt on Linux, rather than claiming that there > might be some? It the overhead were acceptable or even neglegible, we > could avoid all this mess in the first place, link with -lrt if need be, > and be done with it. The overhead is application dependent, and while I suspect that it's negligible for most, it's not that far fetched to imagine an application where it could make a big difference. For instance, the seed of the RANDOM_NUMBER intrinsic is protected by a weakrefed mutex; thus it's easy to imagine a program that makes lots of RANDOM_NUMBER calls becoming a lot slower if every call results in an unecessary mutex lock/unlock. > Additionally, the usage model for the weakref seems questionable to > me: while the technique is well-known and common on ELF targets to > produce code that can work with or without libpthread linked into the > application (which is what users will actually do!), which user is > supposed to link his Fortran code with librt to get improved system > clock resolution? I dare say that close to nobody will even think about > this. Probably not many. OTOH there are quite many who use OpenMP, and as enabling OpenMP implicitly links in librt, they get the better clock for free.
>> Could we please avoid this mess with SUPPORTS_WEAK and GTHREAD_USE_WEAK >> and make configure define SUPPORTS_WEAKREF or something like this, since >> this is what we are actually looking for? > > The point was to piggyback on the existing weakref support in > libgfortran rather than reinvent the wheel, but yeah, it's a bit > confusing. ... especially since SUPPORTS_WEAK is unused now outside of intrinsics/system_clock.c. > It seems that target backends expose macros with these same names, but > they are not visible anymore when compiling libgfortran, hence the > current hack trying to recreate them in libgfortran configuration. Or > at least, that's the most plausible reason I came up with, I did not > write that particular code nor do I claim any deep expertise in this > matter. Indeed: I suppose someone saw them in gcc/gthr*.h. It seems like every user of that file needs to recreate those definitions. From what I can see, libquadmath gets this wrong, e.g.: quadmath_weak.h has #if SUPPORTS_WEAK but this isn't defined anywhere ;-( Terrible user interface, btw. >> If we include alpha*-dec-osf* in the list of targets that don't support >> weakrefs, things should start working again, but I'd prefer a patch where >> you can actually read *and understand* what's going on here. > > Would it be possible to create some test using AC_LINK_IFELSE to check > whether weakrefs are supported? That way we could get rid of the ugly One should be able to use gcc/testsuite/gcc.dg/attr-weakref-1.c as basis. > blacklist for defining GTHREAD_USE_WEAK. In any case, IMHO that's the > topic of a separate patch. Indeed, and the only sensible (read: the autoconf way) approach if feasible. >> Apart from that, has anyone actually *measured* the overhead of simply >> linking libgfortran with librt on Linux, rather than claiming that there >> might be some? It the overhead were acceptable or even neglegible, we >> could avoid all this mess in the first place, link with -lrt if need be, >> and be done with it. > > The overhead is application dependent, and while I suspect that it's > negligible for most, it's not that far fetched to imagine an > application where it could make a big difference. For instance, the > seed of the RANDOM_NUMBER intrinsic is protected by a weakrefed mutex; > thus it's easy to imagine a program that makes lots of RANDOM_NUMBER > calls becoming a lot slower if every call results in an unecessary > mutex lock/unlock. Ok, though it would be useful to have some hard data on this to make an informed decision. >> Additionally, the usage model for the weakref seems questionable to >> me: while the technique is well-known and common on ELF targets to >> produce code that can work with or without libpthread linked into the >> application (which is what users will actually do!), which user is >> supposed to link his Fortran code with librt to get improved system >> clock resolution? I dare say that close to nobody will even think about >> this. > > Probably not many. OTOH there are quite many who use OpenMP, and as > enabling OpenMP implicitly links in librt, they get the better clock > for free. True, but those same users will be mightly confused if the clock resolution suddenly drops without OpenMP ;-( I wonder how we want to continue from here: adding alpha*-dec-osf* to the host list in libgfortran/acinclude.m4 (GTHREAD_USE_WEAK) on top of your patch allowed testing to finish successfully. Should we go this way or apply my workaround from the 4.6 branch to mainline until this is all sorted out properly? Thanks. Rainer
GCC 4.6.0 is being released, adjusting target milestone.
Updated patch which hopefully fixed alpha-osf bootstrap failure: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00802.html
Author: jb Date: Fri Apr 15 04:21:19 2011 New Revision: 172469 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172469 Log: PR 47571 Fix bootstrap regression on alpha-dec-osf Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/system_clock.c
Rainer, all: Is the problem now fixed on 4.7? If so, should it be backported for 4.6.1? And can then the PR be closed?
(In reply to comment #53) > Rainer, all: Is the problem now fixed on 4.7? If so, should it be backported > for 4.6.1? And can then the PR be closed? FWIW, I just opened PR 48664 in order to track the replacement of the target blacklist in acinclude.m4 with a proper autoconf test, per the discussion in comments #48 and #49.
> --- Comment #53 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-04-18 11:47:45 UTC --- > Rainer, all: Is the problem now fixed on 4.7? If so, should it be backported Yes: I had the patch in my local tree before so I could bootstrap on alpha-dec-osf5.1b. Over the weekend, I've removed the local patch and bootstrap succeeded, so all is fine. > for 4.6.1? And can then the PR be closed? I think so: Jakub asked that the hack I put into 4.6.0 so we wouldn't ship a broken libgfortran be replaced by a backport for 4.6.1. Rainer
Author: jb Date: Mon Apr 18 15:49:16 2011 New Revision: 172656 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172656 Log: PR 47571 Fix weakref trickery breakage on alpha-dec-osf This is a backport from mainline r172469. It also removes the temporary fix from r171095. Modified: branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/acinclude.m4 branches/gcc-4_6-branch/libgfortran/config.h.in branches/gcc-4_6-branch/libgfortran/configure branches/gcc-4_6-branch/libgfortran/configure.ac branches/gcc-4_6-branch/libgfortran/intrinsics/system_clock.c
Author: fxcoudert Date: Mon Aug 31 10:37:30 2015 New Revision: 227335 URL: https://gcc.gnu.org/viewcvs?rev=227335&root=gcc&view=rev Log: PR libfortran/47571 * acinclude.m4 (LIBGFOR_GTHREAD_WEAK): Remove. (LIBGFOR_CHECK_WEAKREF): New test. * configure.ac: Call LIBGFOR_CHECK_WEAKREF instead of LIBGFOR_GTHREAD_WEAK. * config.h.in: Regenerate. * configure: Regenerate. * intrinsics/system_clock.c: Use SUPPORTS_WEAKREF instead of SUPPORTS_WEAK and GTHREAD_USE_WEAK. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/system_clock.c
Author: fxcoudert Date: Mon Aug 31 14:02:43 2015 New Revision: 227347 URL: https://gcc.gnu.org/viewcvs?rev=227347&root=gcc&view=rev Log: PR libfortran/47571 * acinclude.m4 (LIBGFOR_GTHREAD_WEAK): Reinstate. * configure.ac: Call LIBGFOR_GTHREAD_WEAK again. * config.h.in: Regenerate. * configure: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac