Node: Intrinsic Groups, Next: , Up: Compiler Intrinsics



Intrinsic Groups

A given specific intrinsic belongs in one or more groups. Each group is deleted, disabled, hidden, or enabled by default or a command-line option. The meaning of each term follows.

Deleted
No intrinsics are recognized as belonging to that group.
Disabled
Intrinsics are recognized as belonging to the group, but references to them (other than via the INTRINSIC statement) are disallowed through that group.
Hidden
Intrinsics in that group are recognized and enabled (if implemented) only if the first mention of the actual name of an intrinsic in a program unit is in an INTRINSIC statement.
Enabled
Intrinsics in that group are recognized and enabled (if implemented).

The distinction between deleting and disabling a group is illustrated by the following example. Assume intrinsic FOO belongs only to group FGR. If group FGR is deleted, the following program unit will successfully compile, because FOO() will be seen as a reference to an external function named FOO:

     PRINT *, FOO()
     END
     

If group FGR is disabled, compiling the above program will produce diagnostics, either because the FOO intrinsic is improperly invoked or, if properly invoked, it is not enabled. To change the above program so it references an external function FOO instead of the disabled FOO intrinsic, add the following line to the top:

     EXTERNAL FOO
     

So, deleting a group tells g77 to pretend as though the intrinsics in that group do not exist at all, whereas disabling it tells g77 to recognize them as (disabled) intrinsics in intrinsic-like contexts.

Hiding a group is like enabling it, but the intrinsic must be first named in an INTRINSIC statement to be considered a reference to the intrinsic rather than to an external procedure. This might be the "safest" way to treat a new group of intrinsics when compiling old code, because it allows the old code to be generally written as if those new intrinsics never existed, but to be changed to use them by inserting INTRINSIC statements in the appropriate places. However, it should be the goal of development to use EXTERNAL for all names of external procedures that might be intrinsic names.

If an intrinsic is in more than one group, it is enabled if any of its containing groups are enabled; if not so enabled, it is hidden if any of its containing groups are hidden; if not so hidden, it is disabled if any of its containing groups are disabled; if not so disabled, it is deleted. This extra complication is necessary because some intrinsics, such as IBITS, belong to more than one group, and hence should be enabled if any of the groups to which they belong are enabled, and so on.

The groups are:

badu77
UNIX intrinsics having inappropriate forms (usually functions that have intended side effects).
gnu
Intrinsics the GNU Fortran language supports that are extensions to the Fortran standards (77 and 90).
f2c
Intrinsics supported by AT&T's f2c converter and/or libf2c.
f90
Fortran 90 intrinsics.
mil
MIL-STD 1753 intrinsics (MVBITS, IAND, BTEST, and so on).
unix
UNIX intrinsics (IARGC, EXIT, ERF, and so on).
vxt
VAX/VMS FORTRAN (current as of v4) intrinsics.