Thanks for addressing the label scope problem, and for the tips about DJGPP, Frank.
I should perhaps have been more clear however, that the inconsistent behaviour I observed with the DJGPP port of the compiler, when errors or warnings were reported, is a separate problem, I think. In other words, this is not specific to the label scope problem, although I used this as an example of this behaviour.
So, have others using the DJGPP port observed similar behaviour when errors or warnings are reported? Does this also occur with other ports of GPC (20010924-2.95.3)? To recap, "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".
Joe.
-----Original Message----- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Friday, November 16, 2001 1:48 PM To: gpc@gnu.de Subject: Re: Label scope (?) bug in GPC
da Silva, Joe wrote:
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.
Indeed. Thanks. Fixed.
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.
Since I've changed a lot WRT labels in the meantime, I can't reproduce it now. Please check again with the next version.
I apologise for the poor visual quality of these screen dumps, but this was to achieve acceptable compression of the two JPEG files
For such kinds of images, PNG is much better suited than JPEG. I suppose it would archive better compression, and it would surely be more readable.
However, much better than any image is text (smaller, copyable, and I won't have to switch between my editor and GUI just to read it :-). You can use the `redir' utility under DJGPP:
# Redirect StdErr to foo redir -e foo command args
# Redirect StdOut and StdErr to foo redir -e foo -oe command foo
For more info, see the DJGPP FAQ (see redir in the index).
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
da Silva, Joe wrote:
Thanks for addressing the label scope problem, and for the tips about DJGPP, Frank.
I should perhaps have been more clear however, that the inconsistent behaviour I observed with the DJGPP port of the compiler, when errors or warnings were reported, is a separate problem, I think. In other words, this is not specific to the label scope problem, although I used this as an example of this behaviour.
So, have others using the DJGPP port observed similar behaviour when errors or warnings are reported? Does this also occur with other ports of GPC (20010924-2.95.3)? To recap, "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".
Such behaviour might be due to uninitialized variables etc. in the compiler. I've observed similar things under Linux (though more reproducible). If you can, you might want to locate the crash position in the compiler. -- On Linux, I get the core file (must not be disabled, of course) and use gdb to find the source position within gpc1 (must not be stripped). I don't know the details on DJGPP, but I see something in the DJGPP FAQ (chapter 12.2 in version 2.30) about `symify' which might do the job.
The two functions I've found almost all crashes in in the last time are get_type_name() and get_operator_identifier(). So if you find it crashing there, I wouldn't be too surprised. I've added a number of safety checks there recently, so reporting any crash there before the next release is probably not worth it. But after the release, please do so if you can -- and report any other crash positions.
Frank