http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #48 from blomqvist.janne at gmail dot com 2011-03-22 13:49:08 UTC --- On Mon, Mar 21, 2011 at 16:47, ro at CeBiTec dot Uni-Bielefeld.DE <gcc-bugzi...@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 >> --> 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.
