Bug 47571 - [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
[4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01...
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P4 normal
: 4.6.1
Assigned To: Janne Blomqvist
http://gcc.gnu.org/ml/gcc-patches/201...
: wrong-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-01 14:23 UTC by Michael Richmond
Modified: 2011-04-18 15:58 UTC (History)
5 users (show)

See Also:
Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
Build: alpha-dec-osf5.1b
Known to work: 4.6.0
Known to fail: 4.7.0
Last reconfirmed: 2011-02-01 16:02:50


Attachments
Proposed patch (2.72 KB, patch)
2011-03-14 11:34 UTC, Janne Blomqvist
Details | Diff
Updated patch (2.94 KB, patch)
2011-03-15 17:04 UTC, Janne Blomqvist
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Richmond 2011-02-01 14:23:59 UTC
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?
Comment 1 Tobias Burnus 2011-02-01 14:56:30 UTC
clock_gettime is part of POSIX.

Linux's man page states:
   Feature Test Macro Requirements for glibc
     _POSIX_C_SOURCE >= 199309L
Comment 2 Janne Blomqvist 2011-02-01 15:08:13 UTC
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.
Comment 3 Jakub Jelinek 2011-02-01 15:14:14 UTC
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.
Comment 4 Michael Richmond 2011-02-01 15:27:19 UTC
(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
Comment 5 Tobias Burnus 2011-02-01 15:29:50 UTC
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.
Comment 6 Janne Blomqvist 2011-02-01 15:50:52 UTC
(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?
Comment 7 Janne Blomqvist 2011-02-01 16:02:50 UTC
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.
Comment 8 Tobias Burnus 2011-02-01 16:08:10 UTC
(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.
Comment 9 Jakub Jelinek 2011-02-01 16:13:24 UTC
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).
Comment 10 Michael Richmond 2011-02-01 16:18:49 UTC
(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
Comment 11 Janne Blomqvist 2011-02-01 16:20:06 UTC
(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.
Comment 12 Tobias Burnus 2011-02-01 16:26:33 UTC
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/)
Comment 13 Janne Blomqvist 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)
Comment 14 Janne Blomqvist 2011-02-01 21:14:18 UTC
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.
Comment 15 Janne Blomqvist 2011-02-02 08:48:27 UTC
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
Comment 16 John David Anglin 2011-02-03 00:44:13 UTC
(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.
Comment 17 Tobias Burnus 2011-02-03 07:38:44 UTC
(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?)
Comment 18 Janne Blomqvist 2011-02-03 09:53:50 UTC
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?
Comment 19 Janne Blomqvist 2011-02-03 12:47:59 UTC
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.
Comment 20 dave 2011-02-03 15:33:37 UTC
> > 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
Comment 21 dave 2011-02-04 14:42:39 UTC
> 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
Comment 22 Janne Blomqvist 2011-02-05 16:22:09 UTC
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
Comment 23 Janne Blomqvist 2011-02-07 18:36:33 UTC
Fixed, closing.
Comment 24 Rainer Orth 2011-03-07 14:53:42 UTC
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.
Comment 25 Tobias Burnus 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 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 26 ro@CeBiTec.Uni-Bielefeld.DE 2011-03-07 16:20:17 UTC
> --- 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
Comment 27 dave 2011-03-07 17:59:27 UTC
> >> 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
Comment 28 Tobias Burnus 2011-03-08 09:34:36 UTC
(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?
Comment 29 Janne Blomqvist 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.

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.
Comment 30 dave 2011-03-09 00:10:22 UTC
> 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
Comment 31 ro@CeBiTec.Uni-Bielefeld.DE 2011-03-11 16:45:31 UTC
> 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
Comment 32 Janne Blomqvist 2011-03-14 11:34:00 UTC
Created attachment 23648 [details]
Proposed patch
Comment 33 Jakub Jelinek 2011-03-14 11:41:53 UTC
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.
Comment 34 Janne Blomqvist 2011-03-14 11:42:47 UTC
(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.
Comment 35 Janne Blomqvist 2011-03-14 11:50:26 UTC
(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.. :)
Comment 36 Jakub Jelinek 2011-03-14 12:07:54 UTC
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.
Comment 37 ro@CeBiTec.Uni-Bielefeld.DE 2011-03-15 16:24:01 UTC
>> 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
Comment 38 Janne Blomqvist 2011-03-15 17:04:41 UTC
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/
Comment 39 Jakub Jelinek 2011-03-15 17:08:03 UTC
Looks fine to me.
Comment 40 Janne Blomqvist 2011-03-15 17:19:43 UTC
(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.
Comment 41 Janne Blomqvist 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.

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 42 ro@CeBiTec.Uni-Bielefeld.DE 2011-03-16 11:58:25 UTC
> --- 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
Comment 43 Rainer Orth 2011-03-17 13:29:04 UTC
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
Comment 44 Rainer Orth 2011-03-17 13:30:34 UTC
Workaround installed on 4.6 branch.
Comment 45 ro@CeBiTec.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 ;-(

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
Comment 46 Jakub Jelinek 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.
I think on a target which doesn't support weaks having GFORTRAN_USE_WEAK defined to 1 is just wrong.
Comment 47 ro@CeBiTec.Uni-Bielefeld.DE 2011-03-21 16:49:19 UTC
> --- 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
Comment 48 blomqvist.janne 2011-03-22 13:49:08 UTC
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.
Comment 49 ro@CeBiTec.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
Comment 50 Jakub Jelinek 2011-03-25 19:52:29 UTC
GCC 4.6.0 is being released, adjusting target milestone.
Comment 51 Janne Blomqvist 2011-04-11 20:23:43 UTC
Updated patch which hopefully fixed alpha-osf bootstrap failure: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00802.html
Comment 52 Janne Blomqvist 2011-04-15 04:21:26 UTC
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
Comment 53 Tobias Burnus 2011-04-18 11:47:45 UTC
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?
Comment 54 Janne Blomqvist 2011-04-18 12:07:29 UTC
(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 55 ro@CeBiTec.Uni-Bielefeld.DE 2011-04-18 14:07:10 UTC
> --- 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
Comment 56 Janne Blomqvist 2011-04-18 15:49:23 UTC
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
Comment 57 Janne Blomqvist 2011-04-18 15:58:41 UTC
Fixed, closing.