09/21/87  fortran 
Known errors in the current release of fortran.
#	Associated TR's
Description

503  phx20525
When attempting to read a nonexistent record from a formatted file with
the "iostat=" keyword in the read statement, the returned error status
is incorrect.  When executing the program without the "iostat="
keyword, a correct error message is printed by fortran_io_.

The reason for this appears to be that a "read" statement in fortran
makes several calls to fortran_io_.  In the case that fails, the first
call to fortran_io_ returns the correct error status but subsequent
calls return an incorrect status which over writes the correct status
code.

Example:

          %global ansi77
                external com_err_ (descriptors)
                integer index, status

          c Create a formatted file containing odd numbered records
                open (50, form = "formatted", access = "direct",
               & mode = "inout", recl = 100)

                do 10 index = 1, 20, 2
          10    write (50,20 , rec = index) index
          20    format (i10)

          c Read an even numbered record
                read (50, 20, rec = 2, iostat = status) index
                call com_err_ (status, "")
                stop
                end

501  phx20337
Code that checks for zero trip do-loops is incorrect.

Consider the following do-loop:

      do 10 i = j, k, l
         a(i) = i
   10 continue

In '77 mode, the parser will emit the following code to represent the
loop:

      m = l
      i = j
      n = (k - j)/m + 1
      if (n .le. 0) goto 11
    9    a(i) = i
   10 i = i + m
      n = n - 1
      if (n .gt. 0) goto 9
   11 continue

Note that the variables that I called 'm' and 'n', and the labels '9'
and '11' in the above code are generated by the compiler in such a way
that they will not conflict with the user's variables and statement
labels.

The problem with the above code is that the expression for calculating
'n' in the third line is incorrect.  That line should read:

      n = (k - j + m)/m

The two expressions for 'n' look to be equivalent, but they are not
since the division is an integer division which discards the remainder.
Actually, the expressions give the same value except for some cases
where the termination condition for the loop is initially satisfied, in
which case the incorrect expression sets 'n' to 1, whereas the correct
expression will set it to zero.  In other words, the incorrect
expression will give the right answer if the body of the loop should be
executed at least once, but sometimes when the body should not be
executed at all, the incorrect expression will cause it to be executed
once.

500  phx20217
The compiler very strictly enforces the ANSI 77 restriction that you
can not execute a goto into a do loop from outside the loop.  This
strict enforcement results in the compiler complaining about legal
references to a label within the loop, as in the example below.

          %options ansi77;
          print*, "Results of both runs:"
          print*, "First run:"

          do 50, j = 1, 2
             assign 20 to jump

             do 30, i = 1, 20
                goto jump, (20, 10)
      20        k = i * 2
                print*, k, "*"
      10        k = i * j + 2
                print*, k, "^"
      30        continue

             assign 10 to jump
             print*, "Second run:"
      50     continue
          stop
          end

The compiler complains about the 'assign 10 to jump' as being illegal
when its use here is perfectly valid.

499  phx20212
The following program generates a compiler error on line 11 as a result
of the error on line 4.

          c      Test Program.
                  implicit logical(a-z)
                  read *, ifn
                  if ( ifn .eq. 2 ) then
                    ok = .true.
                  else
                    ok = .false.
                  endif

                  stop
                  end

491  phx20130
Functions which perform input/output cannot be evaluated by
input/output statements.

Example:

      character*10 f
      read(5,*) k
      write(6,10) func(k)
   10 format(1x,a10)
      stop
      end

      character*10 function func(l)
      write (6,20)l
  20  format (1x,a10)
      func = l
      return
      end

According to the fortran language definition, a function may not be
referenced within an expression appearing anywhere in an input/output
statement if such a reference causes another input/output statement to
be executed.

489  phx19348
Code generator gives fatal error 419 (the offset of an expression
cannot be found in storage) for do loops, as shown on line 5 in the
following example.
      %global ansi77
      integer array(3,3), i, n
      n = 2
      array(2,2) = 2
      do 10 i = array(2,n), 4
 10   continue
      end

487  phx16544 phx17646
The fortran optimizer fails with a null pointer fault when compiling a
subroutine with a complex looping structure containing a number of
goto's and continue's.  The following example was derived from the IMSL
routine ZX4LR.

      %options card,ansi77
      subroutine null_ptr_bug (i1, i2, i3, i4)
   10 go to 505
  290 go to 380
  360 continue
  370 go to 395
  380 go to 385
  385 continue
  395 go to 10
  435 go to 9000
  505 if (.not.(i1.le.i2)) go to 520
      go to 1315
  520 go to 610
  610 continue
 1315 go to (520), i4
 9000 return
      end

486  phx17566
The optimizing code generator fails with fatal error 450 (an operand
which should be in the eaq was not found by get_eaq_name) on line 13 of
the following program:

      subroutine drcvrt(kdat)
      logical deci
      common /ccmisc/ kdig(10),kdot
      deci = .false.
 1000 do 2000 j = 1, 10
         if (kdat .ne. kdig(j)) go to 2000
         kdat = j
         go to 3000
 2000 continue
 2100 if (kdat .ne. kdot) go to 3000
         deci=.true.
         go to 1000
 3000 if (.not.deci) go to 1000
      return
      end

485  phx19253
The optimizing code generator gives fatal error 418 (no index or
pointer registers available for allocation) for line 10 of the
following program:

      subroutine s(am,m,t)
      dimension m(5,*),a(4),dd(6,4),d(4,4),t(3,*)
      i=1
      do 1 j=1,4
      a(j)=0.
      call x(t(1,j))
      call y(dd(1,j))
      call z(d(1,j))
      k=m(i,j)
      t(1,k)=t(1,k)-m(1,j)
    1 continue
      return
      end

484  phx19005
The optimizer eliminates a loop that is needed to initialize values in
an array.

In the following example the do loop is incorrectly eliminated.

          dimension h(10)
          do 1 i = 1,10
               h(i) = -1.e20
        1 continue
          read (5,*)  n, (h(i), i=1,n)
          write (6,2) n, (h(i), i=1,10)
        2 format (" Num of values read: ", i4, /1x, "values: ",/1x,10e10.2)
          end

483  phx18022
Probe does not work correctly on Fortran programs beginning with a
block data subprogram.  Sometimes variables cannot be displayed and
sometimes probe aborts when it tries to execute a break that has been
set.

          block data
          common /aa/ a,b,c
          data a,b,c /1,2,3/
          end
          subroutine sub
          common /aa/ a,b,c
          print *,a
          end

475  phx17684
The compiler does not allow statement functions of type character.
This is allowed in the Fortran ANSI 77 standards.

          character*2 c
          character*2 b
          b()="ab"
          c=b
          print*,c
          stop
          end

466  phx18762
The optimizer fails to reload PR7 (used when addressing arrays larger
than 16K elements) after a WRITE statement which causes an
out_of_bounds error when the program tries to reference another array
element at the beginning of a loop.

      dimension iam (50000)
      do 9 ll = 1,2
         do 7 ii = 1,3
            j2 = iam (1)
            if (j2 .eq. 0) iam (1) = 1
            write (6,*)ll
    7    continue
    9 continue
      end

438  phx18001
Optimizer fails when a format statement, whether used or not,
immediately follows an if-block.  When the if-block contains goto
statements, the optimizer mistakenly analyzes source lines following
the format statement as unreachable or unnecessary.

          subroutine sub (i)
          print 10, i
          if (i .gt.  0) then
               goto 20
          endif
       10 format (1x, i3)
          print 10, i
       20 return
          end

437  phx17992
Referencing variable extent arrays may cause fatal compiler error 454
in the optimizer.  Incorrect code is generated when using the
non-optimizing version of the compiler as indicated by problem number
426 of the error list.

          subroutine sub (n,w,x,y)
          integer w(n), x(n), y(n), z
          z(n) = x(n)
          y(z(n)) = w(n)
          end

436  phx18005
fort_optimizer fails with a not_in_read_bracket condition when a format
statement immediately follows an assigned goto statement.

          assign 10 to i
          goto i
    1000 format (1x)
      10 stop
          end

429  phx17778
Bad code is generated in '77 mode in SUBROUTINE, FUNCTION and ENTRY
statements which contain a dummy argument that is used in the
specification of a bound of a variable dimension array, if that dummy
argument appears in another such statement of the subprogram, but in a
different position in the argument list.  The bad code will either
result in some type of addressing error (such as an out-of-bounds
fault) or incorrect dimensioning of variable dimension arrays.  For
example, execution of the following program results in an out-of-bounds
fault in the SUBROUTINE statement:

      %global ansi77
      integer iv(3)
      data iv/1, 2, 3/
      call showiv(iv, 3)
      end
      subroutine showiv(iv, n)
      integer iv(n)
      print *, iv
      return
      entry showi(n)
      print *, n
      end

426  phx17415 phx17849
The nonoptimizing version of the 10.2 'fortran' compiler generates
incorrect code in statement functions for referencing variable extent
arrays.  The following program demonstrates this problem.  The 'pick'
statement function should return the value of the indicated element of
the array 'x', but instead it returns the value of the following
element.

      real x(2)
      data x/1.0, 2.0/
      call sub(x, 2)
      end
      subroutine sub(x, n)
      real x(n)
      pick(idx) = x(idx)
      print *, pick(1), x(1)
      end

422  phx17020
The following program generates bad code for calculating array
subscripts in the do loop containing the elseif statement when compiled
with the -optimize control argument.

      subroutine x
      integer n
      parameter (n=5)
      integer a(2, n)
      integer count
      a (1, 2) = 5
      do 30 count=1,n
          print,"count=",count,"a(1,",count,")=",a(1,count)
          if (a (1, count) .eq.  5) then
                    goto 40
          elseif (a (1, count) .eq.  1) then
                    goto 40
          endif
   30 continue
      print, "array full when loop index is ", count
      do 10 i=1,n
      print, "a (1, ", i, ") =", a (1, i)
   10 continue
      return
   40 continue
      print, "found one"
      end

421  phx16459
The following program causes the compiler to go into an infinite loop
in the optimizer when compiled with -ot -ansi77 and -card.

      character*2 function prbnam(idext)
      character class*6, digit*10
      data class/'abcdef'/, digit/'1234567890'/
      prbnam = class(kclass:kclass)//digit(iid:iid)
      return
      end
      function n(i)
      n=i
      return
      end

420  phx16007 phx16249
The following programs cause fort_optimizing_cg to give fatal error 453
(Attempt to load global item in a reserved register) when compiled
optimized.

Program 1:

      common /com1/ n(10)
      common /com2/ a(10, 10)
      common /com3/ b(10, 10)
      common /com4/ i6
      do 10 i = 1, n(1)
         n(i) = 1
         do 10 j = 1, 1
            write (i6, 1000) a(j, i), b(j, i)
            call sub (1)
            call sub (1)
   10 continue
 1000 format(v)
      end
      subroutine plot
      real t1(8133), t2(8133)
      t1(1) = 0
      t2(1) = 0
      return
      end

Program 2:

      double precision a, ul, c, x, r, eps, wd, e, z
      dimension a (110,110), ul (110,110), c (110), x (110), r (110)
      common eps, e
      do 10 ijk = 1, 15
        n = 99
        wd = .010d0
        eps = 1.0d-15
        do 1 i = 1, n
          z = i*wd
    1     c (i) = yy (z)
        call inia (a, n)
    2   call test (a, n, ul, c, x, r)
        if (e .le. eps) go to 10
        go to 2
   10 continue
      stop
      end

413  phx16547
Although the limit on the size of a FORTRAN source program is
ostensibly one segment (1044480 characters), it is not usually possible
to compile programs even half that size.  This is because the compiler
has several internal tables that it builds and each of these tables is
limited to a segment in size.  A very large program cannot be compiled
in one piece because one or more of these internal tables will
overflow.

397  phx15693
When do-loops are nested, the compiler does not check that each loop
has a different index variable.  For example, the following obviously
incorrect program is compiled without comment:

      do 20 i = 1, 3
         do 10 i = 1, 2
            print *, i
   10    continue
   20 continue
      end

395  phx15639
The FORTRAN/77 Standard (cf 15.7.4) requires that entry points of a
character function be of type character with the same length as that of
the function, but allows entry points of noncharacter functions to be
of any type other than character.  Our FORTRAN compiler always requires
the type of an entry point to a function to be the same as that of the
function.

393  phx15638 phx16947 phx20352
The optimizer dies with a reference through null pointer when the
following routine is compiled:

      subroutine bug(m, n)
      if (m.eq.1) then
         n = n + 1
      endif
   10 format(a)
      end

378  phx15112
The 'ansi77' representation of character variables is incompatible with
the 'ansi66' representation.  The difference (in PL/I jargon) is that
character variables are 'aligned' in '66 mode, but 'unaligned' in '77
mode.  This difference means that a 'fortran' or 'pl1' subprogram with
character arguments that works when called from a 'fortran' routine
compiled in one mode will usually not work correctly when called from a
'fortran' routine compiled in the other mode.

368  phx14553
Common sub-expression removal, of constant sub-expressions, which are
common from within a loop, and outside all loops in a program may
produce a situation where a temporary gets re-used.  This problem will
only show up if the execution flow is convoluted to by-pass the program
area where the sub-expression would be used, and to enter the area
where the temporary is re-used first, then flow back to the area where
the sub-expression is used.

356  phx13581
The fortran compiler produces an error 445 indicating a node has an
invalid data field.  This occurs in the non-optimizing code generator.
This error occurs when an error is declared in a block-if statment such
that the block-if is not processed, but the 'else' is processed.  This disrupts
the internal processing stack causing the compiler error.

178  
The -table option may not produce the desired results if the -optimize option
is also used.  [This is not a bug.  Optimized code is not intended to be
debugged.]

164  
Error messages may not include a line number.  [This is not a bug.  A line
number is irrelevant to some errors.]

121  phx14792
The numbering of records of direct access files in '77 mode is in
violation of the FORTRAN/77 Standard.  According to the Standard,
record numbers are positive integers (cf Section 12.2.4.2) such that if
a file supports both sequential and direct access, the direct access
record number of a record is the same as the ordinal of that record
when the file is accessed sequentially (cf Section 12.2.4.1).  (For
example, the record which is first if a file is accessed sequentially
is record number 1 when the file is accessed directly.)  The current
implementation allows zero as a valid record number and uses one less
than the sequential ordinal of a record as its direct access record
number.  (For example, the record which is first if a file is accessed
sequentially is record number 0 when the file is accessed directly.)

It is quite easy to change the first record to record 1 instead of
record 0 to meet the ANSI 77 standard (ANSI X3.9,12.2.4.2).

However, if we were to follow this standard for the numbering of
records right away, a lot of existing programs would end up giving
incorrect information.  It is because according to the current Multics
Fortran standard (AT58-03, 5-3, 5-7, 5-12), record 0 can be used as the
direct access record number which is one less than the sequential
access ordinal of a record.

The status of this entry is changed to LIMITATION.

In the future if we were going to follow the ANSI77 standard, the
changes will be made in the procedure "get_record" in fortran_io_.pl1
as follows:

     Around line 2311 change from
     if PS.record_number <0 | PS.record_number > 99999999
     then call print_error (error_table_$no_record);

     To

     if PS.record_number < 1 | PS.record_number > 99999999
     then call print_error (error_table_$no_record);

     Around line 2328 change from
     record_key = PS.record_number;

     To
     record_key = PS.record_number - 1;


                                          -----------------------------------------------------------


Historical Background

This edition of the Multics software materials and documentation is provided and donated
to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. 
as a contribution to computer science knowledge.  
This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology,
Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL
and BULL HN Information Systems Inc. to the development of this operating system. 
Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970),
renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership
of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture 
for managing computer hardware properly and for executing programs. Many subsequent operating systems 
incorporated Multics principles.
Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., 
as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. .

                                          -----------------------------------------------------------

Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without
fee is hereby granted,provided that the below copyright notice and historical background appear in all copies
and that both the copyright notice and historical background and this permission notice appear in supporting
documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining
to distribution of the programs without specific prior written permission.
    Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc.
    Copyright 2006 by BULL HN Information Systems Inc.
    Copyright 2006 by Bull SAS
    All Rights Reserved