BUGS - known bugs in the Fortran compiler.

If two routines of a Fortran program declare the same common area (either labelled or unlabelled) but the declarations result in different sizes, when it comes time for the loader to assign the space for the common area, it will obtain the size from the first routine found using the common area. If the reference in the first routine does not happen to be the largest, other routines legitimately using the extremity of the common area may overwrite instructions or data belonging to other subprograms. This problem might come up when converting Fortran software from other systems where the loader was more intelligent.

Odd results are occasionally returned by function calls. The FORTRAN compiler compiles all functions and subroutines separately. When you invoke a function in a program, the default is to type the function according to the familiar Fortran convention of the first letter of the variable name. Thus if you write a REAL FUNCTION NEWX, and call it with

x = NEWX( ... )

the compiler assumes it is returning an integer result and goes to some pains to convert it to real, completely screwing up the result. To fix this, declare the type of the function explicitly in the calling routine, e.g.

REAL NEWX

Two numbers that are supposed to be exactly equal may not compare as equal. There are two possible reasons for this. First, if they are computed in a slightly different manner, round-off errors will make the least significant digits differ, so they won't be exactly equal. This is why you may get the warning message about equality comparisons not being meaningful in logical if expressions. Second, when a floating point number is in a register, the mantissa occupies a full 36 bits (72 for double precision) and the exponent is in a separate register. When the number is stored in a word, the least significant bits are thrown away to make room for the exponent in the word. Now, if you have something like

x = func(...)
if( x .eq. y ) return

the Fortran compiler keeps "x" in the register and compares it to "y" in storage. This won't work if the least significant bits of "x" are non-zero. The problem may be remedied by interposing some kind of assignment or operation that forces the number to be stored. (Many users put in a print to find out what is going wrong, only to have the problem disappear!)

Subroutine arguments in FORTRAN are called by name, so that if you modify an argument you change its value in the caller. Unfortunately, this affects literals also. Thus if routine a does a call B(1) and routine B does a B=B+1 and returns, every time thereafter that routine B refers to the literal value 1, it will get a 2! The only way around this is to avoid the situation entirely.

Because of a problem with FORTRAN/GELOAD, your job may abort with "CALL NAME MISSING" when using link overlays with Fortran programs compiled using the ASCII option. This usually means that you called LINK/LLINK with CALL LLINK("X") when you should have said CALL LLINK("X ") (five spaces).

If a small TSS ASCII Fortran program contains no explicit character set activity (i.e. no print or character assigns), the program is typed BCD by the compiler. This results in failure at execution time in discerning the proper internal character set (e.g. the ATTACH subroutine fails to discern ASCII arguments). To fix this, insert a "dummy" character assignment to force proper typing.

When compiling an ASCII file in TSS under FORTRAN and using the FORM option, an asterisk in column 1 is not recognized as marking a comment line. There is no fix for this -- be warned.

With FORTRAN, exponents represented as fractions are rounded downwards when converted to real. Thus

8**(1/3) -> 8**(0) -> 1.000

Always use the decimal representation of the fraction, e.g. 8**.333333.

Incorrect code is sometimes generated for FORTRAN programs containing logical expressions. You may get a fatal error "CODE GENERATED MAY BE INCORRECT". This is known to have occurred in the statement

g(i,j) = tempa .or. tempb

To fix, simplify complex logical expressions and assign array elements to temporaries.

In batch FORTRAN, a program may abort in the execute activity with "missing subroutine .rconv .fltx1 ..." etc. and a DRL fault. This happens when the $OPTION FORTRAN card is missing or incorrectly placed. Place the card ahead of all other loader control cards (except $LOWLOAD) and before the $FORTRAN card.

By default, the Fortran I/O package puts only 72 characters on a line, and the rest on the next. The default can be changed with a call to FPARAM. For example,

CALL FPARAM(1,120)

sets the line length to 120 characters.

Always use

REAL FUNCTION X

instead of

FUNCTION X
REAL X

Variables referenced by an implicit statement may not be affected by it.

The backspace function does not work. It backspaces a physical record instead of a logical record.

The character "?" disappears when an attempt is made to print it on the line printer from a batch FORTRAN program (in BCD). This occurs because the "?" is used as an ignore character for the printer. You can correct this by using another character instead of "?" for output, or by outputting "!!?" which appears as "?" on the printer.

In a Fortran program, the argument of an implicitly typed function is not converted correctly when the function appears in a subroutine call. You can fix this by explicitly typing the function.

Copyright © 1996, Thinkage Ltd.