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).
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
libg2c implementations of these intrinsics
cannot be directly linked to
(which normally would avoid the non-Y2K-intrinsic warning).
The renamed forms of the
of these renamed procedures
may be linked to
by appending the string _y2kbug
to the name of the procedure
in the source code.
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
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
libE77 portion of
which purposely calls a nonexistent procedure
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
of invoking procedures in
not be used.
When used, some of the correctness checking
normally performed by g77
In particular, it is probably better to use the
INTRINSIC method of invoking
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
to code compiled by g77
that involve the string y2kbug,
and these are not explained above,
that probably indicates
that a version of
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
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
(The old library calls it
Similarly, linking previously-compiled code
to a new library
might yield an unresolved reference
(The new library calls it
The proper fix for the above problems
is to obtain the latest release of g77
and related products
and install them on all systems,
then recompile, relink, and install
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