Gpc November 2001

gpc@gnu.de

28 participants
70 discussions

Re: Error recovery problem? (was: Label scope (?) bug in GPC)
by da Silva, Joe 21 Nov '01

21 Nov '01

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(a)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(a)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

2 1

Crystal-0.90 released
by Frank Heckenbach 20 Nov '01

20 Nov '01

This is to announce the first public release of crystal. Crystal is a web based mailing list archive. It is still under development, and some planned interesting features are still missing, but it should run stable already and has been tested (on some private lists) for several months. The main functionality of crystal is: - Archive incoming mails and make them accessible by date, author, subject, thread, topic, etc. - Do not require the archive to be updated regularly by a special command. Instead, each mail is visible as soon as it's received. - Make attachments accessible. - Provide a search function. - Allow authenticated and anonymous access (as configured by the administrator). - Let users send mails to the list via WWW (optionally anonymously). - Provide user administration where users can change, add and remove email addresses and change their passwords and other settings via WWW (optionally). - Can be configured either via config files or in the source. Crystal is free software (GNU GPL) and was written for GNU Pascal. More information and the sources for download can be found at http://fjf.gnu.de/crystal/ Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Change of URL for standards
by da Silva, Joe 19 Nov '01

19 Nov '01

Hmmm ... Actually, the "ftp.digital.com/pub/DEC/Pascal/" directory had vanished several weeks ago. Of course, as soon as I decided to mention this, it re-appears! :-/ Which is the best URL? Well, unless someone from Digital/Compaq is on this list, it's difficult to judge. My guess is that the "ftp.europe.digital.com/pub/DEC/Pascal/" directory _seems_ more stable (at this time;-) ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Saturday, November 17, 2001 8:28 PM > To: gpc(a)gnu.de > Subject: Re: Change of URL for standards > > da Silva, Joe wrote: > > > Just a brief note that the link to the ISO standards on web page : > > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/resources.html > > is no longer valid. It should now point to : > > ftp://ftp.europe.digital.com/pub/DEC/Pascal/ > > Thanks. I saw the link didn't work, but now it seems to work again. > Yesterday, all of the following URLs worked (and seemed to point to > the same thing). Anyone knows which one is the offical or preferred > one (otherwise, I'll list all of them). > > http://ftp.digital.com/pub/Digital/Pascal/iso10206_a4.ps.gz > http://ftp.digital.com/pub/Digital/Pascal/iso10206.ps.gz > ftp://ftp.europe.digital.com/pub/DEC/Pascal/ > ftp://ftp.digital.com/pub/DEC/Pascal/ > > And there are copies at: > > http://www.employees.org/~samiam/iso7185.ps > http://www.employees.org/~samiam/iso10206.ps > > Frank > > -- > Frank Heckenbach, frank(a)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

1 0

Re: gpc-test-suite+rhide problems
by Per Persson 18 Nov '01

18 Nov '01

>Per Persson wrote: >>1. When I run the test suite after installation of the gpc-20010924 with >>the gcc-core-2.95.2 >> according to the instructions (I have Red Hat Linux 6.2, kernel >>2.2.16-3 ) >>I get failure for 5 cases (out of 1763 ) > >> As I understand this, the problem seems to be the version of ncurses. >> But according to the KDE package manager I have ncurses 5.0-11 already >>installed. >> >> Do I need another version? >Frank Heckenbach wrote: >The check in crtc.c reads: > >So just check your ncurses.h file to see if/how >NCURSES_VERSION_MAJOR is set. A small possibility would be that >there are several versions installed, and an old one is used. Or the >installed one is broken -- it's a conincidence, but just today there >was a mail on the ncurses list from the maintainer: "[...] Redhat >7.2 does not ship ncurses 5.2 (as usual, Redhat ships a development >version of ncurses without noting this). [...] This is what Redhat >shipped (plus a few changes that I wouldn't want to own): [...]" > >So I wouldn't be surprised if similar problems exist in 6.2. In this >case, get an official ncurses version from ftp.gnu.org or mirrors, >and don't forget to complain to RH. ;-) I checked the ncurses.h file and NCURSES_VERSION_MAJOR was set to 4 although the file was dated 2000.. something. So I installed an update from REDHat (5.0-12). This time the file was dated even later but the NCURSES_VERSION_MAJOR was still set to 4. So then I downloaded the ncurses 5.0 sources from gnu and compiled. Now it works :=) (no failures when running test suite) > >Per Persson wrote: >>2. I have tried to install rhide in the the binary version >>rhide-1.4.7.8.linux.bin.tar.bz2 >> When I try to use this it seems to work, but when I compile a larger >>project I >> get error messages of the type: >> filtest.pas Error: Internal compiler error in 'scope_die_for' >>at >>dwarf2out.c:7794 >> >> then I compile the program using gpc at the command prompt it works. >> What can be the problem? > >Frank Heckenbach wrote: >The difference might be due to different compiler options. `-g' >seems a likely candidate. If you compile with `-g' on the command >line, does it crash as well. If so, you might want to use >`--debug-source' to find where in your program it crashes, but in >general, debug info generation in GPC is not very stable yet, so I >can't promise whether it can be fixed soon. > I tried the -g option with the gpc from the command prompt and the program compiled without problems (and an executable was produced), so I think the problem has to do with RHIDE in some way. The program also compiles from inside rhide in the djgpp version (gpc version 20010623, based on 2.95.3 20010315/djgpp (release)). I then tried to install another binary version (rhide-1.4.9-1.i386.rpm) but the result was the same. Should I try to compile rhide from the sources? Is it tricky? Thanks Per _________________________________________________________________ HÃ¤mta MSN Explorer kostnadsfritt pÃ¥ http://explorer.msn.se

2 1

Bug Report: goto bug
by John P.R. Archer 17 Nov '01

17 Nov '01

Sorry about this horrid use of gotos in the following nasty bit of code but it core dumps on Solaris 2.6 - it's easy to workaround in the following snippet but not so easy (actually just very laborious) in the original inherited code. 'bye for now, John For info:- gpc -v returns:- Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release) (* sample program *) program bug1 (Output); procedure level_1 ; procedure level_2 ; label 2; procedure level_3 ; begin (* level_3 code *) writeln( 'level_3' ) ; writeln( 'goto 2' ) ; goto 2 ; writeln( 'should not get here' ) ; end ; (* level_3 code *) begin (* level_2 code *) writeln( 'level_2' ) ; level_3 ; writeln( 'should not get here' ) ; return ; 2: writeln( 'label 2' ) ; end ; (* level_2 code *) begin (* level_1 code *) writeln( 'level_1' ) ; level_2 ; writeln( 'should not get here' ) ; end ; (* level_1 code *) begin level_1 ; end.

4 14

Change of URL for standards
by da Silva, Joe 17 Nov '01

17 Nov '01

Just a brief note that the link to the ISO standards on web page : http://agnes.dida.physik.uni-essen.de/~gnu-pascal/resources.html is no longer valid. It should now point to : ftp://ftp.europe.digital.com/pub/DEC/Pascal/ Joe.

2 1

GPC/SET bug[64 bit Alpha]: new bug
by Mirsad Todorovac 17 Nov '01

17 Nov '01

Hi, As far as I remember so far we've seen that some numbers were put in SET OF BYTE, but weren't found in by IN operator (which was acknowleged as a bug for Alpha/64bit platform - I don't know whether the test failed on any other architecture?). This is a test which stresses other issue: I've found some numbers IN SET which were NOT added to it! (Only on Alpha/64bit, on 32bit Solaris all tests pass with OK!). Also initialization fails, but IMHO all this bugs have something in common; so I went forth with these examples only in hope that they will help nail the bug. mirsad The test is (all four new tests are in attachment for your convenience): --mirsad05.pas------------------------------------------------------------ PROGRAM setranges5(output); { Written by: Mirsad Todorovac Nov 2001; copying by GPL. ------------------------------------------------------------ Stresses setrange construction and adding; checks if there's more in SET than we've put in. lasts few seconds where I've tested it.} CONST maxN = 255; VAR seta, setb, setc: SET OF 0..maxN; i, j, len, start, endr: Cardinal; failed: Boolean = false; BEGIN FOR i:= 0 TO maxN DO IF ((i IN seta) OR (i IN setb) OR (i IN setc)) THEN writeln('Failed: SET not initialized empty!'); FOR len:= 1 TO maxN+1 DO BEGIN FOR start:= 0 TO maxN-len+1 DO BEGIN endr := start+len-1; {writeln('constr. range = ', start, ',', endr);} setb := seta + [start .. endr]; FOR i:= 0 TO maxN DO BEGIN IF (((i < start) AND (i IN setb)) OR ((i > endr) AND (i IN setb))) THEN IF (NOT failed) THEN BEGIN writeln('Failed: ', i,' outside range found IN SET! ', '[',start, '..', endr,']'); {It's sufficient for one example to fail to find a bug!} failed := True; END END END END; IF (NOT failed) THEN writeln('OK'); END. ----------------------------------------------------------------------- -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

4 22

Re: Zodiac, Linux, sparse sets [Was: GPC/SET bug[64 bit Alpha]: new
by Mirsad Todorovac 16 Nov '01

16 Nov '01

On Thu, 15 Nov 2001, Frank Heckenbach wrote: > > Maybe. But (Visual) Basic, C++ and FORTRAN also evolve, don't they? > > For example, consider Visual Basic's "collections", which are basically > > sets of members which can have various types (also mentioned in gpc > > info's TODO list as ???). > > Err, where? info -f gpc::Welcome::Note To Do::Planned features::Planned features: Other types->item 9 in list. [ ... ] > > Anyway, range checking can be life saving. For example, remember Arianne > > launch failure when a 16-bit counter that was there for years rolled-over > > into negative when something was speeded-up. (In the time of design they > > said it can never go over 16 bits.) So, the unit failed, after which > > rendundant unit was consultet only to have the same result (of course, > > using the same software and same 16-bit counter). Then the rocket's > > computer thought it started to fall down and activated self-destruct > > sequence, even though it was climbing. > > > > This story makes me agree that extensive range-checking, especially with > > arrays, sets and (last but not the least) implicit precision conversions > > is very important. That's also a weakness of C language which C++ hasn't > > eliminated (but I'm slightly off-topic maybe?) ... > > Not really. Range-checking will at best generate runtime errors, not > correct the problems automatically. If Ariane's software would have > generated an error (even it if was an exception that could be > handled), it's quite unlikely that it could've found the cause of > the problem and corrected it (in real-time, therefore fully > automatically!). Here I'd always leave the possibility to programmer whether to compile-in range checking or not. Yet, in Arianne example, if you get runtime errors, it doesn't have to end execution, some errors may be recoverable. For example, life-support computers and similar applications can't just say "panic: freeing free inode: syncing file systems ..." (common message on SunOS 4.1.x :-) ... ). But to allow for error to go undetected is neither a good solution. > Range-cheking is mostly a debugging aid that will tell the > programmer more early about possible problems and easy debugging. > For an end-user application, it might even have negative impacts -- > think of an editor or smoething which suddenly abort with a runtime > error (while without a check it might behave wrongly but may just > keep working long enough so the users can save his changes). Of > course, the problem can be alleviated by catching runtime errors > (like I do, e.g., in PENG) which GPC allows but is certainly not > standard. On the other hand, by leaving range-checking out we could be able to calculate very expensive computations invain, and never be sure in results. I've got the grasp of that feeling while trying to design some of recent tests for example - there's just nothing firm and proven to attach to sometimes. For example, in 1995 Pentium had a float division bug. Then they tried to cover up and say it doesn't ocur too often (incredible). Yet, was anybody able to run tests of dividing every compination of two 80-bit double numbers to see if the result is correct to the last bit? This would require 2^80*2^80 ~ 1.461*10^48 tests. With 1 Gflops, this would require approx 4*10^31 years ... Much much longer than the Universe lasts. > So what I want to say is just that I don't see range-checks as the > panacea that some of you seem to. They're a debugging aid, sure, but > I've found other debugging aids (e.g., GPC's warnings about using > uninitialized variables) at least as useful. Yes, but UCSD pascal had it back then in 1987. If it can be switched on and off with compiler directive, I can't see why not? For example, who excludes floating-point checks to make code run faster and get a matrix full of NaN (not-a-number) as a result? With the editor example you have a point - but writer of the editor could disable runtime checks in production binary. On the other hand, in complex calculation with no range checking results become useless with slightest error ... To range checking I would especially add pointer checking. I think it's possible to avoid lots of wasted hours if we test whether pointer points at regularly allocated part of memory, or to a freed block. And this one could be very easily implemented. Of course, it shouldn't run in production binary, since checking every ointer for validit before dereferencing would be tremendously slow. But, if you don't like it - no problem, you are the boss :-) mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

3 3

GPC bug?: Boolean expression that doesn;t compile
by Mirsad Todorovac 16 Nov '01

16 Nov '01

Hi, all, Please don't hate me - while writting mirsad08.pas I came to this problem: line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough). I reduced the example to the minimum at which problem still appears. Changing ... AND (i<start OR i>endr) AND ... to ... AND ((i<start) OR (i<endr)) AND ... made it compile. Here is the material: --------------------------------------------------------------------------- > more mirsad13.pas PROGRAM boolexp(output); { Written by: Mirsad Todorovac Nov 2001; copying by GPL. ------------------------------------------------------------ Accidentally discovered that this didn't compile. } VAR flag: Boolean; extra: Boolean; i, start, endr: Cardinal; BEGIN IF (NOT extra AND (i<start OR i>endr) AND (flag = true)) THEN {!thisline!} BEGIN extra := true; END; END. > gpc mirsad13.pas mirsad13.pas: In main program: mirsad13.pas:14: parse error before `>' mirsad13.pas:14: warning: expression used as a statement - value is ignored mirsad13.pas:14: warning: expression used as a statement - value is ignored mirsad13.pas:14: parse error before `)' > Best regards, Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

4 7

Label scope (?) bug in GPC
by da Silva, Joe 16 Nov '01

16 Nov '01

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>>

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc November 2001