It's at times like these, that I wish the mailing list archive was still working. There have been some discussions recently about the operation of labels on some platforms, plus a separate thread about errors when compiling the P4 interpreter. Unfortunately, I didn't keep a copy of these postings, but from memory, the following is new information on these issues ...
By chance, I found a copy of the P4 compiler and interpreter "lying around" on my hard drive, so I thought I would see what happened when I tried to compile the interpreter, "PINT.P", with GPC ...
From memory, the previous discussions on this, concluded that
the error reported by GPC was correct, since declaring a label but not using it, is regarded by the standard(s) as an error. However, on checking the "PINT.P" source more carefully, the label in question was in fact used correctly. Furthermore, while the 20010924/2.95.3 compiler reported an error, the "2.0 release" version did not. The situation that occurs in the "PINT.P" source can be simplified to the following code :
program test;
label 1;
procedure outer; label 1; procedure inner; begin {inner} goto 1 end; {inner} begin {outer} 1: end; {outer}
begin {test} 1: end. {test}
The compiler seems to think that the "goto" in the procedure "inner", goes to the label in the main program, rather than the label in the procedure "outer", which by the "rules of scope", is the appropriate label. This seems to be what is happening, since by changing the label number in the main program from "1" to "2", the compiler no longer complains that the label in procedure "outer" has been "declared but not used". Also, if the "goto" statement is simply commented out, again the compiler stops complaining about the label in procedure "outer". So, there seems to be some confusion by the compiler about the scope of labels in "goto" statements, and possibly corruption of the internal information, that the compiler gathers about the label in procedure "outer", when this occurs.
The above error occurred using the DJGPP port of GPC, both on a pure DOS platform and a W95 platform. I doubt this behaviour is platform or build specific, although I'm just speculating, of course.
However, there is an additional problem which may be platform/build "specific". It seems that whenever an error or warning is issued, the compiler misbehaves, often crashing. This behaviour is inconsistent, so that consecutive runs of the compiler with the same source code and environment produce different results. When no error or warning is reported, everything seems fine and the results are consistent. Attached for example, are some screen dumps of the 20010924 DJGPP compiler, attempting to compile the above sample program. I apologise for the poor visual quality of these screen dumps, but this was to achieve acceptable compression of the two JPEG files (I couldn't find a way of obtaining a text file from the screen dumps).
Joe.
<<gpc-err.ZIP>>