[Bug fortran/47571] New: undefined reference to clock_gettime in Linux build of 02/01/2011

[Bug fortran/47571] New: undefined reference to clock_gettime in Linux build of 02/01/2011

[michael.a.richmond at nasa dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

           Summary: undefined reference to clock_gettime in Linux build of
                    02/01/2011
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: michael.a.richmond@nasa.gov
              Host: i686-pc-linux-gnu
            Target: i686-pc-linux-gnu
             Build: i686-pc-linux-gnu


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?

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |jb at gcc dot gnu.org
            Summary|undefined reference to      |[4.6 Regression] undefined
                   |clock_gettime in Linux      |reference to clock_gettime
                   |build of 02/01/2011         |in Linux build of
                   |                            |02/01/2011

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[michael.a.richmond at nasa dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #4 from Michael Richmond <michael.a.richmond at nasa dot gov> 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #6 from Janne Blomqvist <jb at gcc dot gnu.org> 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?

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|i686-pc-linux-gnu           |
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.02.01 16:02:50
               Host|i686-pc-linux-gnu           |
         AssignedTo|unassigned at gcc dot       |jb at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1
              Build|i686-pc-linux-gnu           |

--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 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).

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[michael.a.richmond at nasa dot gov]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #10 from Michael Richmond <michael.a.richmond at nasa dot gov> 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #11 from Janne Blomqvist <jb at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 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/)

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-01 20:02:38 UTC ---
(In reply to comment #9)
> How many fortran users actually need to more precise DATE_AND_TIME though?

None, since the DATE_AND_TIME API is limited to millisecond precision. The
motivation for using clock_gettime() is the SYSTEM_CLOCK intrinsic, whose
purpose is precise measurement of wall clock intervals. In this case, the
SYSTEM_CLOCK API allows us to expose the extra precision to user code, and
perhaps more importantly, we use CLOCK_MONOTONIC which is better suited for
this purpose than CLOCK_REALTIME.

The reason why DATE_AND_TIME now also uses clock_gettime() is that part of the
patch was some cleanup centralizing #ifdefs under a single gf_gettime()
function rather than sprinkling them around the code.

> Bringing in -lpthread (as dependency of -lrt) certainly has some extra
> overhead, e.g. everything that uses gthr* will suddenly use real locking.
> You could e.g. use clock_gettime only through a weakref, thus let the users
> choose if clock_gettime should be used or not.  If they don't link in librt,
> less precise implementation would be used, if they do link it in, it would
> become more precise (-lrt would be linked in automatically e.g. for -fopenmp
> compilations).

The above being said, this sounds like a good idea. I'll look into this rather
than trying to link librt statically.

(FWIW I don't think the extra locking overhead would matter in practice, as
libgfortran uses quite coarse grained locking, and AFAIK uncontested futexes
are very fast)

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2011-02/msg00075.htm
                   |                            |l

--- Comment #14 from Janne Blomqvist <jb at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #15 from Janne Blomqvist <jb at gcc dot gnu.org> 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu.org

--- Comment #16 from John David Anglin <danglin at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> 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?)

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #18 from Janne Blomqvist <jb at gcc dot gnu.org> 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?

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p
                   |atches/2011-02/msg00075.htm |atches/2011-02/msg00196.htm
                   |l                           |l

--- Comment #19 from Janne Blomqvist <jb at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[dave at hiauly1 dot hia.nrc.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #20 from dave at hiauly1 dot hia.nrc.ca 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[dave at hiauly1 dot hia.nrc.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #21 from dave at hiauly1 dot hia.nrc.ca 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #22 from Janne Blomqvist <jb at gcc dot gnu.org> 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #23 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-07 18:36:33 UTC ---
Fixed, closing.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |alpha-dec-osf5.1b
             Status|RESOLVED                    |REOPENED
                 CC|                            |ro at gcc dot gnu.org
               Host|                            |alpha-dec-osf5.1b
         Resolution|FIXED                       |
   Target Milestone|---                         |4.6.0
              Build|                            |alpha-dec-osf5.1b

--- Comment #24 from Rainer Orth <ro at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- 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
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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[dave at hiauly1 dot hia.nrc.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #27 from dave at hiauly1 dot hia.nrc.ca 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #28 from Tobias Burnus <burnus at gcc dot gnu.org> 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?

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

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.

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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[dave at hiauly1 dot hia.nrc.ca]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #30 from dave at hiauly1 dot hia.nrc.ca 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #32 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-03-14 11:34:00 UTC ---
Created attachment 23648
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23648
Proposed patch

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #34 from Janne Blomqvist <jb at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #35 from Janne Blomqvist <jb at gcc dot gnu.org> 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.. :)

[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23648|0                           |1
        is obsolete|                            |

--- 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.

Also, paths should be correct now, if the patch is applied in libgfortran/

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-15 17:08:03 UTC ---
Looks fine to me.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #40 from Janne Blomqvist <jb at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- 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.

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.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #43 from Rainer Orth <ro at gcc dot gnu.org> 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

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.6.0
            Summary|[4.6/4.7 Regression]        |[4.7 Regression] undefined
                   |undefined reference to      |reference to clock_gettime
                   |clock_gettime in Linux      |in Linux build of
                   |build of 02/01/2011         |02/01/2011
      Known to fail|                            |4.7.0

--- Comment #44 from Rainer Orth <ro at gcc dot gnu.org> 2011-03-17 13:30:34 UTC ---
Workaround installed on 4.6 branch.

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

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 ;-(

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

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- 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.
I think on a target which doesn't support weaks having GFORTRAN_USE_WEAK
defined to 1 is just wrong.

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[blomqvist.janne at gmail dot com]

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-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
>>   --> 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.

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.0                       |4.6.1

--- Comment #50 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-25 19:52:29 UTC ---
GCC 4.6.0 is being released, adjusting target milestone.

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p
                   |atches/2011-02/msg00196.htm |atches/2011-04/msg00802.htm
                   |l                           |l

--- Comment #51 from Janne Blomqvist <jb at gcc dot gnu.org> 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

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #52 from Janne Blomqvist <jb at gcc dot gnu.org> 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

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- 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
for 4.6.1? And can then the PR be closed?

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #54 from Janne Blomqvist <jb at gcc dot gnu.org> 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.

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #55 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot 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

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #56 from Janne Blomqvist <jb at gcc dot gnu.org> 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

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #57 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-04-18 15:58:41 UTC ---
Fixed, closing.

[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571

--- Comment #59 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
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