Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-bb
-
ftn110.d13
There are no other files named ftn110.d13 in the archive.
EDIT DESCRIPTIONS FOR FORTRAN-10-V10
EDIT 342 FOR FORDDT
[SYMPTOM]
Auopatch-built FORDDT does not reflect true version number.
[DIAGNOSIS]
Autopatch won't update the version number of a reserved edit number if
it is the only edit for a particular freeze period.
[CURE]
Force a dummy update.
********************************************************************************
EDIT 4223 FOR FOROTS
[SYMPTOM]
When a default width is used for a format descriptor, it is not
flagged by the VAX compatibility flagger.
[DIAGNOSIS]
At run time there is no check whether the default width for a
format descriptor is used.
[CURE]
Check for use of default width and issue a warning when the VAX
flagger is being used. This is accomplished by edit 4223.
********************************************************************************
EDIT 4225 FOR FOROTS
[SYMPTOM]
Unable to build FOROTS when FTDSK is set non-zero.
[DIAGNOSIS]
If FTDSK is set non-zero, DEVTAB is not defined. DEVTAB needs to
be defined in order to build FOROTS correctly. DEVTAB is also used to
define the negative units, i.e., REREAD, TYPE, ACCEPT, etc.
[CURE]
Add a check for a non-zero FTDSK and define the necessary units.
This is accomplished by edit 4225 to FOROPN.
********************************************************************************
EDIT 4227 FOR FOROTS
[SYMPTOM]
SORT doesn't word with character strings that are a multiple
of 5 in length or if the string doesn't begin on a word
boundary.
[DIAGNOSIS]
Only quoted command strings to SORT are allowed. This is
because they must be null terminated. Since sort only gets
the address of the string it (the string) must begin on a
word boundary.
[CURE]
If we get passed a character string, make a copy of it and
make sure its null terminated and begins on a word boundary
before giving it to SORT.
********************************************************************************
EDIT 4231 FOR FOROTS
[SYMPTOM]
Edit 4223 causes FORMAT statements to be processed incorrectly.
[DIAGNOSIS]
The CALL in edit 4223 does not generate a PUSHJ P,.
[CURE]
Change the CALL to a PUSHJ P,. This is accomplished by edit 4231
to FORFMT.
********************************************************************************
EDIT 4233 FOR FOROTS
[SYMPTOM]
Some illegal format specifications will cause an "illegal memory
reference" error at runtime.
[DIAGNOSIS]
In COMSET, the address of the format statement is obtained.
However, it is not being checked for an acceptable address.
[CURE]
Check that the address of the format statement is not below .JBDA
and not above page 777 of section 37. This is accomplished by edit
4233.
********************************************************************************
EDIT 4234 FOR FOROTS
[SYMPTOM]
SORT with edit 4227 doesn't compute the number of arguments
correctly.
[DIAGNOSIS]
Edit 4227 has a bug in it (for tops-10 only).
[CURE]
Have FORSRT count the number of args' correctly.
********************************************************************************
EDIT 4235 FOR FOROTS
[SYMPTOM]
Incorrect results may be given for exponentiation of GFLOATING
numbers (for example: .5000000001**.25 gives .805... instead of
.840...).
[DIAGNOSIS]
The GFLOATING exponentiation routine uses an incorrect method of
getting the exponent of the magnitude of certain intermediate GFLOATING
numbers. A MOVM on the first word of the double word value is used
followed by stripping out the exponent field. This does not work for
all negative GFLOATING numbers where the mantissa part in the first word
is all zero (the first non-zero bit of the mantissa is in the second
word). Due to the fact that these errors occur in an intermediate
calculation, it is impossible to specify the class of input numbers
which will result in this problem.
[CURE]
Get the exponent field correctly for these intermediate
GFLOATING numbers.
********************************************************************************
EDIT 2550 FOR FORTRA
[SYMPTOM]
Incorrect optimizations, such as constant propagation, carried
over statement functions which have a function call with a parameter
other than a formal of the statement function. For example, in the
below program IB is modified in the function call to YFUN within the
statement function. The compiler decides that the only variables that
could be changed in a statement function are its formals, and
therefore it thinks IB could not be changed. During constant
propagation, the compiler substitutes 1 for IB in the IF statement and
then deletes the test IF(1.NE.2) because it will always be false.
CHARACTER*20 ACHAR,DCHAR
INTEGER ONE,TWO
DATA ONE/1/,TWO/2/
c statement function
SFUN(I,K) = I*YFUN(IB)+K*2
ACHAR='1234567890'
IB=1
100 DCHAR(3:3) = ACHAR(SFUN(TWO,ONE):6)
IF (IB .NE. 2)
1 TYPE *,'? wrong value of IB = ',IB,
1 ' ,it should be 2'
END
FUNCTION YFUN(IN)
YFUN=2
IN=IN+1
END
[DIAGNOSIS]
The compiler must look at both the parameters to statement
functions as well as the body of statement functions when calculating
definition points.
[CURE]
When calculating definition points at a statement function call,
look at both the parameters to the statement function as well as the
body of the statement function.
********************************************************************************
EDIT 2551 FOR FORTRA
[SYMPTOM]
Long common subexpressions with negative operands which are the
same over several statements may have the wrong code generated for
them when the program containing them is compiled /OPT.
[DIAGNOSIS]
A neg flag is being lost during the calculation of common
subexpressions.
[CURE]
When combining the Y and Z together in the expression -(-X+Y)+Z,
as well as remembering the flags immediately on the Y and Z, we also
must look at the flags that are one level above the flag. So the
flags on the expression (-X+Y) must be XORed with the flags on Y to
get the new flags on Y when it is combined together with Z. The
resulting expression should now be X+(-Y+Z) instead of X+(Y+Z) as the
compiler was incorrectly generating.
********************************************************************************
EDIT 2552 FOR FORTRA
[SYMPTOM]
RECTYPE is an accepted abbreviation for RECORDTYPE.
[DIAGNOSIS]
RECTYPE shouldn't be an accepted abbreviation for RECORDTYPE.
[CURE]
Remove RECTYPE.
********************************************************************************
EDIT 2554 FOR FORTRA
[SYMPTOM]
Compiler ICEs when computing definition points of some statement
functions.
[DIAGNOSIS]
Whenever computing definition points of a statement function
call, routine DEFWORK is called on the body of the statement function.
This should only be done if we have a user function call in the body
of the statement function.
[CURE]
If the USRFNFLG is set in the statement function statement node
then call routine FCNLOK on the right hand side of the assignment
statement in the statement function body. There is no need to call
DEFWORK (to call FCNLOK on left and right side of assignment in
statement function).
********************************************************************************
EDIT 2557 FOR FORTRA
[SYMPTOM]
An error message is issued when a generic function name is used
in an INTRINSIC statement.
[DIAGNOSIS]
The compiler is checking for specific function names in INTRINSIC
statements and issuing an error when a generic function name is used.
However, this is not consistent with the FORTRAN-77 standard.
[CURE]
A check should be made for the use of generic names as actual
arguments in routine calls. This is accomplished by edit 2557.
********************************************************************************
EDIT 2560 FOR FORTRA
[SYMPTOM]
In some rare cases continuation lines are ignored.
[DIAGNOSIS]
When going onto the next continuation line, CHARPOS (pointer to
the present position in the line) is not changed. Therefore,
everything to the left of CHARPOS' present position is ignored.
[CURE]
When going onto the next continuation line, always set CHARPOS to
the beginning of the line.
********************************************************************************
EDIT 2561 FOR FORTRA
[SYMPTOM]
PROAR. and PROSB. get warnings from IMPLICIT NONE. This only
happens when compiling /DEBUG:BOUNDS or /DEBUG:ALL.
[DIAGNOSIS]
PROAR. and PROSB. are FORTRAN-supplied functions used for array
bounds checking and substring bounds checking. Since they are not
user symbols, they should not get warnings. IMPLICIT NONE processing
does not know that they are not user functions.
[CURE]
Mark symbol table entries for PROAR. and PROSB. as being
library functions.
********************************************************************************
EDIT 2562 FOR FORTRA
[SYMPTOM]
When using IMPLICIT NONE, a symbol in an EXTERNAL statement gets
a warning that it must be explicitly declared.
[DIAGNOSIS]
If the symbol isn't used as a function name in the same program
it shouldn't get the warning because it could be a subroutine name.
[CURE]
Add a check for the symbol being used as a function name in the
same program.
********************************************************************************
EDIT 2563 FOR FORTRA
[SYMPTOM]
Programs with subprograms as formal parameters to entry
statements, die with an illegal instruction.
[DIAGNOSIS]
The indirect bit is set in the MOVEM storing the address of the
subprogram into the dummy argument. Therefore, the address actually
gets stored into AC0, leaving 0 in the dummy argument. The PUSHJ to
this subprogram causes a jump to AC0 and results in an illegal
instruction.
[CURE]
When moving the address of a formal into a dummy argument, ignore
any indirect bit that may be set in the STE.
********************************************************************************
END OF FORTRAN-10-V10