- Gpc - gnu.de

bug?
by Adam Naumowicz 23 Nov '01

23 Nov '01

Hello, Maybe that is a known bug but I encountered a strange problem and don't know what happens. I reduced the example to these three silly files: --------------------- program tester; uses tester1; begin ImpSgnList.Init(8); end. ---------------------- unit tester1; interface uses tester2; var ImpSgnList:MList; implementation end. ---------------------- unit tester2; interface type MList = object constructor Init(ALimit: Integer); end; implementation constructor MList.Init(aLimit: Integer); begin end; end. ---------------------- The result of execution is as follows: tester.dpr: In main program: tester.dpr:5: Internal compiler error in `call_method', at objects.c:137 Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://home.pages.de/~GNU-Pascal/todo.html> for details. I use the following compiler version: Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs gpc version 20010623, based on 2.95.3 20010315 (release) BTW: the same is with my another GPC version: Reading specs from /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/specs gpc version 20010121, based on 2.95.2 19991024 (release) I hope there is an explanation of this behavior, or if this is a new bug, there will be a way to correct it. Regards, Adam Naumowicz -------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------

3 4

Re: `Reply-To' (solution)
by da Silva, Joe 22 Nov '01

22 Nov '01

Most e-mail systems, I'm told, know not to send "vacation" responses to mailing lists. So in most cases, this won't be a problem (eg. how often has anyone seen such a response message on a mailing list?). Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, November 21, 2001 11:01 PM > To: gpc(a)gnu.de > Subject: Re: `Reply-To' (solution) > > Russell Whitaker wrote: > > > > Recently there was a discussion about whether the mailing list > > > software should automatically add `Reply-To' headers. > > > > > > Peter now told me that the new majordomo version used has the option > > > to set it on a per-user basis, so those who like it can have it, and > > > those who'd feel disturbed by it won't be. > > > > > > If you want it, just send a mail to <majordomo(a)gnu.de> with the > > > following command in the body: > > > > > > set gpc replyto your(a)mail.address > > > > > > (where your(a)mail.address, of course, is the address with which > > > you're subscribed to the list). > > > > > If someone also goes on vacation and uses an auto "vacation reply" > > will that set up an endless mail loop? > > Good point. If it uses the `Reply-To' header, and sends multiple > message to the same recipient (which I consider rather broken, > anyway) and the mailing list software doesn't detect vacation > replies or mail loops, then probably yes. > > So I suggest everyone who uses vacation replies to not use the > Reply-To feature unless they know for sure it won't cause problems > (I'm not sure) ... and unless they want to find themselves kicked > from the list when they return. ;-) > > 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

3 2

`Reply-To' (solution)
by Frank Heckenbach 21 Nov '01

21 Nov '01

Recently there was a discussion about whether the mailing list software should automatically add `Reply-To' headers. Peter now told me that the new majordomo version used has the option to set it on a per-user basis, so those who like it can have it, and those who'd feel disturbed by it won't be. If you want it, just send a mail to <majordomo(a)gnu.de> with the following command in the body: set gpc replyto your(a)mail.address (where your(a)mail.address, of course, is the address with which you're subscribed to the list). 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 2

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