| OK, I reproduced it with the latest compiler. We'll let you know if
there is a workaround when we can look a little closer at it.
-John
Note to Meg/or/me:
Oddly, when I used /SWITCH=FE_IC* to see if the CIL was bad, I got 12
integrity checks in the CIL. With a BL33 compiler, I only got 2
integrity checks in the CIL and the 2 were not in the list of 12 I
got with the BL32 compiler. Its as if FE_IC* didn't work right with
the BL33 compiler, we need to check that it works.
|
| Well, I'll fix this by saying its an illegal program that the
compiler didn't detect.
In a FOR statement, the index variable must be a "whole" variable.
It can't be a array element, record field, pointer dereference, etc.
The compiler already detects all of these cases:
FOR r.loop_counter := 1 to 10 DO
.......^
%PASCAL-E-SYNASSIN, Syntax: ":=" or IN expected
at line number 37 in file PAS$:[REAGAN.WORK.NOTE830]P.PAS;7
FOR r.loop_counter := 1 to 10 DO
........^
%PASCAL-E-FORACTVAR, FOR loop control must be a true variable
at line number 37 in file PAS$:[REAGAN.WORK.NOTE830]P.PAS;7
FOR arr[1] := 1 to 10 DO
.........^
%PASCAL-E-SYNASSIN, Syntax: ":=" or IN expected
at line number 39 in file PAS$:[REAGAN.WORK.NOTE830]P.PAS;7
FOR arr[1] := 1 to 10 DO
...........^
%PASCAL-E-FORACTVAR, FOR loop control must be a true variable
at line number 39 in file PAS$:[REAGAN.WORK.NOTE830]P.PAS;7
For pointer dereferences, we catch that error, but don't issue
the secondary FORACTVAR message.
FOR int_ptr^ := 1 to 10 DO
.............^
%PASCAL-E-SYNASSIN, Syntax: ":=" or IN expected
at line number 35 in file PAS$:[REAGAN.WORK.NOTE830]P.PAS;7
For pointer dereference to a record, we catch that also
FOR record_type_ptr^.loop_counter := 1 to 10 DO
.....................^
%PASCAL-E-SYNASSIN, Syntax: ":=" or IN expected
at line number 33 in file PAS$:[REAGAN.WORK.NOTE830]P.PAS;7
However, when you use a WITH to open the scope of record_type_ptr^,
we didn't detect the use of a record field as the FOR index variable.
We do detect this if you don't use a pointer. For example,
VAR
r : record_type;
WITH R DO
FOR loop_counter := 1 to 10 DO
x := x + 1;
FOR loop_counter := 1 to 10 DO
........^
%PASCAL-E-FORACTVAR, FOR loop control must be a true variable
at line number 42 in file PAS$:[REAGAN.WORK.NOTE830]P.PAS;8
So the user's program is illegal, but the compiler does have the
following bugs:
1) For explicit "ptr^" as a FOR index, we don't print the 2nd FORACTVAR
message.
2) For implicit record-fields from a opened WITH statement using a
pointer, we don't issue any errors and pass bogus data to the code
generator. The code generator doesn't like it and crashes/burns.
We should issue the FORACTVAR message just like the case with
the WITH statement that doesn't use a pointer-dereference.
-John
|
| OK, I've fixed this. The compiler now detects the illegal program.
FOR loop_counter := 1 to 10 DO
........^
%PASCAL-E-FORACTVAR, FOR loop control must be a true variable
at line number 43 in file PAS$:[REAGAN.WORK.NOTE830]NOTE830.PAS;2
I'll put in a release note highlighting this chance. Nobody has
been relying on this on Alpha since you break the compiler. However,
from my testing, it sometimes "does the right thing" on the VAX
(and sometimes not) depending on the phase of the moon and wind
direction. :-)
-John
|