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: Date Intrinsic, 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.)