GNU Info

(g77-300.info)Year 2000 (Y2K) Problems

---

Next: Array Size Prev: Timer Wraparounds Up: Run-time Environment Limits

---

Enter node , (file) or (file)node

Year 2000 (Y2K) Problems
------------------------

   While the `g77' compiler itself is believed to be Year-2000 (Y2K)
compliant, some intrinsics are not, and, potentially, some underlying
systems are not, perhaps rendering some Y2K-compliant intrinsics
non-compliant when used on those particular systems.

   Fortran code that uses non-Y2K-compliant intrinsics (listed below)
is, itself, almost certainly not compliant, and should be modified to
use Y2K-compliant intrinsics instead.

   Fortran code that uses no non-Y2K-compliant intrinsics, but which
currently is running on a non-Y2K-compliant system, can be made more
Y2K compliant by compiling and linking it for use on a new
Y2K-compliant system, such as a new version of an old,
non-Y2K-compliant, system.

   Currently, information on Y2K and related issues is being maintained
at `http://www.gnu.org/software/year2000-list.html'.

   See the following for intrinsics known to have potential problems in
these areas on at least some systems: Note: Date Intrinsic, Note:
IDate Intrinsic (VXT).

   The `libg2c' library shipped with any `g77' that warns about
invocation of a non-Y2K-compliant intrinsic has renamed the `EXTERNAL'
procedure names of those intrinsics.  This is done so that the `libg2c'
implementations of these intrinsics cannot be directly linked to as
`EXTERNAL' names (which normally would avoid the non-Y2K-intrinsic
warning).

   The renamed forms of the `EXTERNAL' names of these renamed procedures
may be linked to by appending the string `_y2kbug' to the name of the
procedure in the source code.  For example:

     CHARACTER*20 STR
     INTEGER YY, MM, DD
     EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
     CALL DATE_Y2KBUG (STR)
     CALL VXTIDATE_Y2KBUG (MM, DD, YY)

   (Note that the `EXTERNAL' statement is not actually required, since
the modified names are not recognized as intrinsics by the current
version of `g77'.  But it is shown in this specific case, for purposes
of illustration.)

   The renaming of `EXTERNAL' procedure names of these intrinsics
causes unresolved references at link time.  For example, `EXTERNAL
DATE; CALL DATE(STR)' is normally compiled by `g77' as, in C,
`date_(&str, 20);'.  This, in turn, links to the `date_' procedure in
the `libE77' portion of `libg2c', which purposely calls a nonexistent
procedure named `G77_date_y2kbuggy_0'.  The resulting link-time error
is designed, via this name, to encourage the programmer to look up the
index entries to this portion of the `g77' documentation.

   Generally, we recommend that the `EXTERNAL' method of invoking
procedures in `libg2c' _not_ be used.  When used, some of the
correctness checking normally performed by `g77' is skipped.

   In particular, it is probably better to use the `INTRINSIC' method
of invoking non-Y2K-compliant procedures, so anyone compiling the code
can quickly notice the potential Y2K problems (via the warnings
printing by `g77') without having to even look at the code itself.

   If there are problems linking `libg2c' to code compiled by `g77'
that involve the string `y2kbug', and these are not explained above,
that probably indicates that a version of `libg2c' older than `g77' is
being linked to, or that the new library is being linked to code
compiled by an older version of `g77'.

   That's because, as of the version that warns about non-Y2K-compliant
intrinsic invocation, `g77' references the `libg2c' implementations of
those intrinsics using new names, containing the string `y2kbug'.

   So, linking newly-compiled code (invoking one of the intrinsics in
question) to an old library might yield an unresolved reference to
`G77_date_y2kbug_0'.  (The old library calls it `G77_date_0'.)

   Similarly, linking previously-compiled code to a new library might
yield an unresolved reference to `G77_vxtidate_0'.  (The new library
calls it `G77_vxtidate_y2kbug_0'.)

   The proper fix for the above problems is to obtain the latest
release of `g77' and related products (including `libg2c') and install
them on all systems, then recompile, relink, and install (as
appropriate) all existing Fortran programs.

   (Normally, this sort of renaming is steadfastly avoided.  In this
case, however, it seems more important to highlight potential Y2K
problems than to ease the transition of potentially non-Y2K-compliant
code to new versions of `g77' and `libg2c'.)