Which C-preprocessor options to use?

In addition to different compiler-switch versions, you can generate versions of TONTO which will

The following sections describe how to compile TONTO so that these additional features become available.

All these options are controlled by C-preprocessor directives which appear in the macros file; the features can be turned on or off independently.

Note that you must recompile TONTO if any of the features described in the section are to be activated

The USE_ERROR_MANAGEMENT switch

Error checking in TONTO is achieved using C preprocessor macros which stand for calls to certain routines in the TONTO system.

To remove this facility, delete the -DUSE_ERROR_MANAGEMENT switch in the Makefile near the top, e.g.

DEFS    := -DCOMPAQ -DUSE_ERROR_MANAGEMENT

The way this switch works is as follows:

In the macros file, a test is done to establish if the USE_ERROR_MANAGEMENT switch has been defined by the preprocessor (for example, because it has been set as a compile switch in ther Makefile as above). If this switch is defined, other macros DIE, WARN, DIE_IF, and WARN_IF are defined to be calls to certain Fortran subroutines which issue the required warnings.

It is not recommended that you remove this switch, as it does not affect performance greatly.

Once the change has been made, you will have to recompile TONTO for that change to take effect.

The USE_PRE_AND_POST_CONDITIONS switch

This switch is turned off by default.

To include precondition and postcondition facilities, add the -DUSE_PRE_AND_POST_CONDITIONS macros to the DEFS variable in the Makefile, e.g.

DEFS    := -DCOMPAQ -DUSE_PRE_AND_POST_CONDITIONS

Note that enabling the USE_CALL_STACK_MANAGEMENT switch automatically turns on the USE_ERROR_MANAGEMENT switch.

Note that using this switch can lead to significant performance degradation (say up to 30% in execuation time).

The way this switch works is as follows:

In the macros file, a test is done to establish if the above USE_PRE_AND_POSTCONDITIONS switch has been defined by the preprocessor (for example, because it has been set as a compile switch in the Makefile, as above). If it is defined, other macros ENSURE and VERIFY are defined to be calls to certain Fortran subroutines which issue the required warnings.

The USE_CALL_STACK_MANAGEMENT switch

This switch is turned off by default.

To include precondition and postcondition facilities, add the -DUSE_CALL_STACK_MANAGEMENT switch to the DEFS variable in the Makefile, e.g.

DEFS    := -DCOMPAQ -DUSE_CALL_STACK_MANAGEMENT

Using this switch not only produces a calling stack whenever an error is generated, but it also turns on memory management facilities and pre and post condition checking. The memory management facility will issue a warning whenever the routine exits with a memory leak --- unless the routine is explicitly marked [leaky] on its definition line. For further information on [leaky], look in the chapter called The foo preprocessor>.

Note that using this switch can lead to significant performance degradation (up to 30% in execution time).

The LANGUAGE_FORTRAN_90 switch

This switch is turned off by default for Fortran95 compliant compilers.

If you want to set the Fortran language level to Fortran90 (if it is not already set) simply add the -DLANGUAGE_FORTRAN_90 switch to the definition of the DEFS variable in the Makefile, e.g.

DEFS    := -DCOMPAQ -DLANGUAGE_FORTRAN_90

The way this works is as follows:

The pure and elemental keywords are usually conditionally compiled in the TONTO system, using C preprocessor macros PURE and ELEMENTAL. There are also macros ALWAYS_PURE and ALWAYS_ELEMENTAL. These are required because some routines must always be pure or elemental---for example if they appear in the initialization of variables in a declaration line. (In this case, programmers should note that separate definition lines should be used when the language level is reduced to Fortran90). Note that, if the foo preprocessor is being used the pure, elemental, always_pure, and always_elemental attributes of a routine are activated by square brakets on the routine declaration line. For further detailes, refer to the chapter describing the foo preprocessor.

The BROKEN_TYPE_INITIALIZATION switch

Unfortunately it seems to be quite common that many Fortran95 compilers cannot correctly cope with derived type initialization.

Derived type initialization can be switched off via the BROKEN_TYPE_INITIALIZATION switch,

DEFS    := -DCOMPAQ -DBROKEN_TYPE_INITIALIZATION

This switch is automatically activated when the LANGUAGE_FORTRAN_90 switch is set, since type initialization is a Fortran95 feature.

Notes

[1]

This is only available for routines which are not pure according to the fortran definition; pure routines are not allowed to have any I/O operations embedded within them, including I/O operations which issue error messages