Next: Array Size, Previous: Timer Wraparounds, Up: Run-time Environment Limits
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
.)