1
2 09/21/87 fortran
3 Known errors in the current release of fortran.
4 # Associated TR's
5 Description
6
7 503 phx20525
8 When attempting to read a nonexistent record from a formatted file with
9 the "iostat=" keyword in the read statement, the returned error status
10 is incorrect. When executing the program without the "iostat="
11 keyword, a correct error message is printed by fortran_io_.
12
13 The reason for this appears to be that a "read" statement in fortran
14 makes several calls to fortran_io_. In the case that fails, the first
15 call to fortran_io_ returns the correct error status but subsequent
16 calls return an incorrect status which over writes the correct status
17 code.
18
19 Example:
20
21 %global ansi77
22 external com_err_ descriptors
23 integer index, status
24
25 c Create a formatted file containing odd numbered records
26 open 50 form = "formatted" access = "direct"
27 & mode = "inout" recl = 100
28
29 do 10 index = 1, 20, 2
30 10 write 5020 rec = index index
31 20 format i10
32
33 c Read an even numbered record
34 read 50 20 rec = 2 iostat = status index
35 call com_err_ status ""
36 stop
37 end
38
39 501 phx20337
40 Code that checks for zero trip do-loops is incorrect.
41
42 Consider the following do-loop:
43
44 do 10 i = j, k, l
45 ai = i
46 10 continue
47
48 In '77 mode, the parser will emit the following code to represent the
49 loop:
50
51 m = l
52 i = j
53 n = k - j/m + 1
54 if n .le. 0 goto 11
55 9 ai = i
56 10 i = i + m
57 n = n - 1
58 if n .gt. 0 goto 9
59 11 continue
60
61 Note that the variables that I called 'm' and 'n', and the labels '9'
62 and '11' in the above code are generated by the compiler in such a way
63 that they will not conflict with the user's variables and statement
64 labels.
65
66 The problem with the above code is that the expression for calculating
67 'n' in the third line is incorrect. That line should read:
68
69 n = k - j + m/m
70
71 The two expressions for 'n' look to be equivalent, but they are not
72 since the division is an integer division which discards the remainder.
73 Actually, the expressions give the same value except for some cases
74 where the termination condition for the loop is initially satisfied, in
75 which case the incorrect expression sets 'n' to 1, whereas the correct
76 expression will set it to zero. In other words, the incorrect
77 expression will give the right answer if the body of the loop should be
78 executed at least once, but sometimes when the body should not be
79 executed at all, the incorrect expression will cause it to be executed
80 once.
81
82 500 phx20217
83 The compiler very strictly enforces the ANSI 77 restriction that you
84 can not execute a goto into a do loop from outside the loop. This
85 strict enforcement results in the compiler complaining about legal
86 references to a label within the loop, as in the example below.
87
88 %options ansi77;
89 print*, "Results of both runs:"
90 print*, "First run:"
91
92 do 50, j = 1, 2
93 assign 20 to jump
94
95 do 30, i = 1, 20
96 goto jump, 20 10
97 20 k = i * 2
98 print*, k, "*"
99 10 k = i * j + 2
100 print*, k, "^"
101 30 continue
102
103 assign 10 to jump
104 print*, "Second run:"
105 50 continue
106 stop
107 end
108
109 The compiler complains about the 'assign 10 to jump' as being illegal
110 when its use here is perfectly valid.
111
112 499 phx20212
113 The following program generates a compiler error on line 11 as a result
114 of the error on line 4.
115
116 c Test Program.
117 implicit logicala-z
118 read *, ifn
119 if ifn .eq. 2 then
120 ok = .true.
121 else
122 ok = .false.
123 endif
124
125 stop
126 end
127
128 491 phx20130
129 Functions which perform input/output cannot be evaluated by
130 input/output statements.
131
132 Example:
133
134 character*10 f
135 read5* k
136 write610 funck
137 10 format1xa10
138 stop
139 end
140
141 character*10 function funcl
142 write 620l
143 20 format 1xa10
144 func = l
145 return
146 end
147
148 According to the fortran language definition, a function may not be
149 referenced within an expression appearing anywhere in an input/output
150 statement if such a reference causes another input/output statement to
151 be executed.
152
153 489 phx19348
154 Code generator gives fatal error 419 the offset of an expression
155 cannot be found in storage for do loops, as shown on line 5 in the
156 following example.
157 %global ansi77
158 integer array33, i, n
159 n = 2
160 array22 = 2
161 do 10 i = array2n, 4
162 10 continue
163 end
164
165 487 phx16544 phx17646
166 The fortran optimizer fails with a null pointer fault when compiling a
167 subroutine with a complex looping structure containing a number of
168 goto's and continue's. The following example was derived from the IMSL
169 routine ZX4LR.
170
171 %options card,ansi77
172 subroutine null_ptr_bug i1 i2 i3 i4
173 10 go to 505
174 290 go to 380
175 360 continue
176 370 go to 395
177 380 go to 385
178 385 continue
179 395 go to 10
180 435 go to 9000
181 505 if .not.i1.le.i2 go to 520
182 go to 1315
183 520 go to 610
184 610 continue
185 1315 go to 520, i4
186 9000 return
187 end
188
189 486 phx17566
190 The optimizing code generator fails with fatal error 450 an operand
191 which should be in the eaq was not found by get_eaq_name on line 13 of
192 the following program:
193
194 subroutine drcvrtkdat
195 logical deci
196 common /ccmisc/ kdig10,kdot
197 deci = .false.
198 1000 do 2000 j = 1, 10
199 if kdat .ne. kdigj go to 2000
200 kdat = j
201 go to 3000
202 2000 continue
203 2100 if kdat .ne. kdot go to 3000
204 deci=.true.
205 go to 1000
206 3000 if .not.deci go to 1000
207 return
208 end
209
210 485 phx19253
211 The optimizing code generator gives fatal error 418 no index or
212 pointer registers available for allocation for line 10 of the
213 following program:
214
215 subroutine sammt
216 dimension m5*,a4,dd64,d44,t3*
217 i=1
218 do 1 j=1,4
219 aj=0.
220 call xt1j
221 call ydd1j
222 call zd1j
223 k=mij
224 t1k=t1k-m1j
225 1 continue
226 return
227 end
228
229 484 phx19005
230 The optimizer eliminates a loop that is needed to initialize values in
231 an array.
232
233 In the following example the do loop is incorrectly eliminated.
234
235 dimension h10
236 do 1 i = 1,10
237 hi = -1.e20
238 1 continue
239 read 5* n, hi i=1n
240 write 62 n, hi i=110
241 2 format " Num of values read: " i4 /1x "values: "/1x10e10.2
242 end
243
244 483 phx18022
245 Probe does not work correctly on Fortran programs beginning with a
246 block data subprogram. Sometimes variables cannot be displayed and
247 sometimes probe aborts when it tries to execute a break that has been
248 set.
249
250 block data
251 common /aa/ a,b,c
252 data a,b,c /1,2,3/
253 end
254 subroutine sub
255 common /aa/ a,b,c
256 print *,a
257 end
258
259 475 phx17684
260 The compiler does not allow statement functions of type character.
261 This is allowed in the Fortran ANSI 77 standards.
262
263 character*2 c
264 character*2 b
265 b="ab"
266 c=b
267 print*,c
268 stop
269 end
270
271 466 phx18762
272 The optimizer fails to reload PR7 used when addressing arrays larger
273 than 16K elements after a WRITE statement which causes an
274 out_of_bounds error when the program tries to reference another array
275 element at the beginning of a loop.
276
277 dimension iam 50000
278 do 9 ll = 1,2
279 do 7 ii = 1,3
280 j2 = iam 1
281 if j2 .eq. 0 iam 1 = 1
282 write 6*ll
283 7 continue
284 9 continue
285 end
286
287 438 phx18001
288 Optimizer fails when a format statement, whether used or not,
289 immediately follows an if-block. When the if-block contains goto
290 statements, the optimizer mistakenly analyzes source lines following
291 the format statement as unreachable or unnecessary.
292
293 subroutine sub i
294 print 10, i
295 if i .gt. 0 then
296 goto 20
297 endif
298 10 format 1x i3
299 print 10, i
300 20 return
301 end
302
303 437 phx17992
304 Referencing variable extent arrays may cause fatal compiler error 454
305 in the optimizer. Incorrect code is generated when using the
306 non-optimizing version of the compiler as indicated by problem number
307 426 of the error list.
308
309 subroutine sub nwxy
310 integer wn, xn, yn, z
311 zn = xn
312 yzn = wn
313 end
314
315 436 phx18005
316 fort_optimizer fails with a not_in_read_bracket condition when a format
317 statement immediately follows an assigned goto statement.
318
319 assign 10 to i
320 goto i
321 1000 format 1x
322 10 stop
323 end
324
325 429 phx17778
326 Bad code is generated in '77 mode in SUBROUTINE, FUNCTION and ENTRY
327 statements which contain a dummy argument that is used in the
328 specification of a bound of a variable dimension array, if that dummy
329 argument appears in another such statement of the subprogram, but in a
330 different position in the argument list. The bad code will either
331 result in some type of addressing error such as an out-of-bounds
332 fault or incorrect dimensioning of variable dimension arrays. For
333 example, execution of the following program results in an out-of-bounds
334 fault in the SUBROUTINE statement:
335
336 %global ansi77
337 integer iv3
338 data iv/1, 2, 3/
339 call showiviv 3
340 end
341 subroutine showiviv n
342 integer ivn
343 print *, iv
344 return
345 entry showin
346 print *, n
347 end
348
349 426 phx17415 phx17849
350 The nonoptimizing version of the 10.2 'fortran' compiler generates
351 incorrect code in statement functions for referencing variable extent
352 arrays. The following program demonstrates this problem. The 'pick'
353 statement function should return the value of the indicated element of
354 the array 'x', but instead it returns the value of the following
355 element.
356
357 real x2
358 data x/1.0, 2.0/
359 call subx 2
360 end
361 subroutine subx n
362 real xn
363 pickidx = xidx
364 print *, pick1, x1
365 end
366
367 422 phx17020
368 The following program generates bad code for calculating array
369 subscripts in the do loop containing the elseif statement when compiled
370 with the -optimize control argument.
371
372 subroutine x
373 integer n
374 parameter n=5
375 integer a2 n
376 integer count
377 a 1 2 = 5
378 do 30 count=1,n
379 print,"count=",count,"a1"count"=",a1count
380 if a 1 count .eq. 5 then
381 goto 40
382 elseif a 1 count .eq. 1 then
383 goto 40
384 endif
385 30 continue
386 print, "array full when loop index is ", count
387 do 10 i=1,n
388 print, "a 1 " i " =", a 1 i
389 10 continue
390 return
391 40 continue
392 print, "found one"
393 end
394
395 421 phx16459
396 The following program causes the compiler to go into an infinite loop
397 in the optimizer when compiled with -ot -ansi77 and -card.
398
399 character*2 function prbnamidext
400 character class*6, digit*10
401 data class/'abcdef'/, digit/'1234567890'/
402 prbnam = classkclass:kclass//digitiid:iid
403 return
404 end
405 function ni
406 n=i
407 return
408 end
409
410 420 phx16007 phx16249
411 The following programs cause fort_optimizing_cg to give fatal error 453
412 Attempt to load global item in a reserved register when compiled
413 optimized.
414
415 Program 1:
416
417 common /com1/ n10
418 common /com2/ a10 10
419 common /com3/ b10 10
420 common /com4/ i6
421 do 10 i = 1, n1
422 ni = 1
423 do 10 j = 1, 1
424 write i6 1000 aj i, bj i
425 call sub 1
426 call sub 1
427 10 continue
428 1000 formatv
429 end
430 subroutine plot
431 real t18133, t28133
432 t11 = 0
433 t21 = 0
434 return
435 end
436
437 Program 2:
438
439 double precision a, ul, c, x, r, eps, wd, e, z
440 dimension a 110110, ul 110110, c 110, x 110, r 110
441 common eps, e
442 do 10 ijk = 1, 15
443 n = 99
444 wd = .010d0
445 eps = 1.0d-15
446 do 1 i = 1, n
447 z = i*wd
448 1 c i = yy z
449 call inia a n
450 2 call test a n ul c x r
451 if e .le. eps go to 10
452 go to 2
453 10 continue
454 stop
455 end
456
457 413 phx16547
458 Although the limit on the size of a FORTRAN source program is
459 ostensibly one segment 1044480 characters, it is not usually possible
460 to compile programs even half that size. This is because the compiler
461 has several internal tables that it builds and each of these tables is
462 limited to a segment in size. A very large program cannot be compiled
463 in one piece because one or more of these internal tables will
464 overflow.
465
466 397 phx15693
467 When do-loops are nested, the compiler does not check that each loop
468 has a different index variable. For example, the following obviously
469 incorrect program is compiled without comment:
470
471 do 20 i = 1, 3
472 do 10 i = 1, 2
473 print *, i
474 10 continue
475 20 continue
476 end
477
478 395 phx15639
479 The FORTRAN/77 Standard cf 15.7.4 requires that entry points of a
480 character function be of type character with the same length as that of
481 the function, but allows entry points of noncharacter functions to be
482 of any type other than character. Our FORTRAN compiler always requires
483 the type of an entry point to a function to be the same as that of the
484 function.
485
486 393 phx15638 phx16947 phx20352
487 The optimizer dies with a reference through null pointer when the
488 following routine is compiled:
489
490 subroutine bugm n
491 if m.eq.1 then
492 n = n + 1
493 endif
494 10 formata
495 end
496
497 378 phx15112
498 The 'ansi77' representation of character variables is incompatible with
499 the 'ansi66' representation. The difference in PL/I jargon is that
500 character variables are 'aligned' in '66 mode, but 'unaligned' in '77
501 mode. This difference means that a 'fortran' or 'pl1' subprogram with
502 character arguments that works when called from a 'fortran' routine
503 compiled in one mode will usually not work correctly when called from a
504 'fortran' routine compiled in the other mode.
505
506 368 phx14553
507 Common sub-expression removal, of constant sub-expressions, which are
508 common from within a loop, and outside all loops in a program may
509 produce a situation where a temporary gets re-used. This problem will
510 only show up if the execution flow is convoluted to by-pass the program
511 area where the sub-expression would be used, and to enter the area
512 where the temporary is re-used first, then flow back to the area where
513 the sub-expression is used.
514
515 356 phx13581
516 The fortran compiler produces an error 445 indicating a node has an
517 invalid data field. This occurs in the non-optimizing code generator.
518 This error occurs when an error is declared in a block-if statment such
519 that the block-if is not processed, but the 'else' is processed. This disrupts
520 the internal processing stack causing the compiler error.
521
522 178
523 The -table option may not produce the desired results if the -optimize option
524 is also used. This is not a bug. Optimized code is not intended to be
525 debugged.
526
527 164
528 Error messages may not include a line number. This is not a bug. A line
529 number is irrelevant to some errors.
530
531 121 phx14792
532 The numbering of records of direct access files in '77 mode is in
533 violation of the FORTRAN/77 Standard. According to the Standard,
534 record numbers are positive integers cf Section 12.2.4.2 such that if
535 a file supports both sequential and direct access, the direct access
536 record number of a record is the same as the ordinal of that record
537 when the file is accessed sequentially cf Section 12.2.4.1. For
538 example the record which is first if a file is accessed sequentially
539 is record number 1 when the file is accessed directly. The current
540 implementation allows zero as a valid record number and uses one less
541 than the sequential ordinal of a record as its direct access record
542 number. For example the record which is first if a file is accessed
543 sequentially is record number 0 when the file is accessed directly.
544
545 It is quite easy to change the first record to record 1 instead of
546 record 0 to meet the ANSI 77 standard ANSI X3.912.2.4.2.
547
548 However, if we were to follow this standard for the numbering of
549 records right away, a lot of existing programs would end up giving
550 incorrect information. It is because according to the current Multics
551 Fortran standard AT58-03 5-3 5-7 5-12, record 0 can be used as the
552 direct access record number which is one less than the sequential
553 access ordinal of a record.
554
555 The status of this entry is changed to LIMITATION.
556
557 In the future if we were going to follow the ANSI77 standard, the
558 changes will be made in the procedure "get_record" in fortran_io_.pl1
559 as follows:
560
561 Around line 2311 change from
562 if PS.record_number <0 | PS.record_number > 99999999
563 then call print_error error_table_$no_record;
564
565 To
566
567 if PS.record_number < 1 | PS.record_number > 99999999
568 then call print_error error_table_$no_record;
569
570 Around line 2328 change from
571 record_key = PS.record_number;
572
573 To
574 record_key = PS.record_number - 1;