http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #49 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> 2011-03-23 13:13:53 UTC ---
>> 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
