- Gpc - gnu.de

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

gpc-test-suite+rhide problems
by Per Persson 16 Nov '01

16 Nov '01

Hi! I have two problems, that might be related: 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 ) I get error messsages something like this: PC="gpc" PFLAGS="--autobuild -g -O3 -Wall -Werror " SRCDIR="." "./test_run" "*.pas" | "./test_sum" TEST crttest.pas: /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/units/crtc.c:122: warning: #warning The CRT unit needs ncurses version 5.0 or newer because older 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? 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? Can it be related to the problem 1 above? Should I instead try to compile rhide from the sources? Thanks! Per _________________________________________________________________ HÃ¤mta MSN Explorer kostnadsfritt pÃ¥ http://explorer.msn.se

2 1

Re: GPC bug?: Boolean expression that doesn;t compile
by Maurice Lombardi 15 Nov '01

15 Nov '01

Mirsad Todorovac wrote: > Can you please point me to a complete stnadard somewhere on the net, so I > don't embarass myself again? Also extracted from the list [Joe da Silva] Yes, there are actually two ISO Pascal standards : 1. ISO 7185 - Non-extended (aka Classic) Pascal 2. ISO 10206 - Extended Pascal (superset) You can obtain a free copy of ISO 10206, in either A4 or US-Legal document size, at : http://ftp.digital.com/pub/Digital/Pascal/iso10206_a4.ps.gz http://ftp.digital.com/pub/Digital/Pascal/iso10206.ps.gz You can also find an easy-to-read introduction to Extended Pascal (by Prospero Software) at : http://www.prosperosoftware.com/epintro.html Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

New tests [that try to reveal 64 bit arch sets problem]
by Mirsad Todorovac 15 Nov '01

15 Nov '01

Hi, This test I've tried to tweak to isolate the set on Alpha problem. I hope they might give some help with finding bug (altough I'm aware that there are many other important things to do with GPC). New tests are in attachment (submitted for approval). I hope that it's not a problem - it may be harder to read on some email clients, but on the other hand it's easier to save them ... Results on SOlaris: all OK. Results on Alpha: mirsad06: Failed: extra: 31 IN [0..255]-[31..31] miss: 32 NOT IN [0..255]-[0..0] mirsad07: OK mirsad08: Failed: 32 not set but IN [0..255] mirsad09: Failed: 32 not set but IN [0..255] mirsad10: Failed: 31 set but not IN [32..95] mirsad11: Failed: 32 not set but IN [0..32] mirsad12: Failed: 31 set but not IN [32..32] I was surprized for mirsad07 passed OK, since I've designed it to fail on Alpha (you might say maliciously). It uses something like ``IF (i IN [start..endr]) THEN'' test which compiled correctly. This leas me to produce assembly, and I was surprized to see that it didn't call _p_set_in fucntion from RTS (p/rts/sets.pas, as Frank said). On the other hand, ``FOR i IN [start..endr] DO'' use _p_set_in and do fail. Once Frank has time, I hope this might help a step in the rigth direction. 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.

2 1

ANNOUNCEMENT: pas2po
by Eike Lange 15 Nov '01

15 Nov '01

Hi Folks! I finished writing a tool, similar to `xgettext' named `pas2po'. This program extracts all translatable strings out of a GNU Pascal source file and creates a po file, similar to xgettext. Missing is the timezone information. The output is not sorted, but there are no duplicate entries. Like xgettext output, you have to edit the file by hand to include the missing informations. (Later on, you can process this po file with `msgfmt' to create a mo file) You can download the actual sources via ftp from: agnes.dida.physik.uni-essen.de/pub/home/lange/pas2po-0.2.tar.gz See, that this is _completely_ different from that in inter-unit (tools), but shares the same name. I'll remove the one in inter-unit. Eike

1 0

Bug Report: SET OF BYTE not working properly!!!
by Mirsad Todorovac 15 Nov '01

15 Nov '01

Dear Sirs, Following program (implementing sieve of Eratosthenes) doesn't work as expected: after adding [i] to SET it doesn't appear to be in it!!! This is for i in [32..63,96..127,160..191,224-255]. Numbers 95 and 195 _couldn't_be_removed_ from SET sieve. > gpc --version 2.95.3 20010315 (release) > uname -a OSF1 domac.alu.hr V4.0b 564 alpha --marvin01.pas-------------------------------------------------------------- PROGRAM sieveprogram(input,output); {Sieve of Eratosthenes for finding prime numbers} CONST maxN = 255; VAR i,j,k: CARDINAL; sieve: SET OF Byte; BEGIN FOR i:= 1 TO maxN DO {initialize sieve} BEGIN sieve := sieve + [i]; IF (NOT (i IN sieve)) THEN writeln('Error: ', i, ' not in SET after adding!'); END; FOR i:= 2 TO maxN DO BEGIN IF (i IN sieve) THEN FOR k := i+1 TO maxN DO IF ((k MOD i = 0) AND (k IN sieve)) THEN BEGIN sieve := sieve - [k]; IF (k IN sieve) THEN writeln('Error: ', k, ' in SET after deletion!'); END END; FOR i:= 2 TO maxN DO IF (i IN sieve) THEN BEGIN writeln('Checking if really prime: ', i); FOR j:= 2 TO i-1 DO IF (i MOD j = 0) THEN writeln('Error: ', i,' % ', j, ' = 0.'); END END. -------------------------------------------------------------------------- Program compiles with warnings: > gpc marvin01.pas marvin01.pas: In main program: marvin01.pas:12: warning: constructing limited integer set `0..511' marvin01.pas:23: warning: constructing limited integer set `0..511' > -------------------------------------------------------------------------- Program output (unexpected errors): -------------------------------------------------------------------------- > ./a.out Error: 32 not in SET after adding! Error: 33 not in SET after adding! . . . Error: 63 not in SET after adding! Error: 96 not in SET after adding! Error: 97 not in SET after adding! Error: 98 not in SET after adding! . . . Error: 127 not in SET after adding! Error: 160 not in SET after adding! Error: 161 not in SET after adding! Error: 162 not in SET after adding! . . . Error: 191 not in SET after adding! Error: 224 not in SET after adding! Error: 225 not in SET after adding! Error: 226 not in SET after adding! . . . Error: 255 not in SET after adding! Error: 159 in SET after deletion! Error: 95 in SET after deletion! Error: 95 in SET after deletion! Checking: 2 Checking: 3 Checking: 5 Checking: 7 Checking: 11 Checking: 13 Checking: 17 Checking: 19 Checking: 23 Checking: 29 Checking: 31 Checking: 67 Checking: 71 Checking: 73 Checking: 79 Checking: 83 Checking: 89 Checking: 95 Error: 95 % 5 = 0. Error: 95 % 19 = 0. Checking: 131 Checking: 137 Checking: 139 Checking: 149 Checking: 151 Checking: 157 Checking: 159 Error: 159 % 3 = 0. Error: 159 % 53 = 0. Checking: 193 Checking: 197 Checking: 199 Checking: 211 Checking: 223 > ------------------------------------------------------------------------- Thank you for reading this far. Best regards, Marvin -- 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 11

Q: Availability of GPC + GTK+ worldwide?
by Mirsad Todorovac 13 Nov '01

13 Nov '01

Hi, I just had a crazy idea of developing an application in GNU Pascal - yet it struck me: if I distribute in source code, how many (in %) sites will be able to install it? This lead me to another thought: when will GPC be stable enough to include it in main gcc-3.0.x (or later) distribution? (I guess this might help the compiler be more wide spread, as happened wiht g77 ...) 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

Problems building GPC when host!=build
by Andris Pavenis 13 Nov '01

13 Nov '01

Configuring in p/rts fails when host!=build (for example when building native compiler for DJGPP or MINGW under Linux) as newly built xgcc and xgpc cannot be run on build system. In this case we should run corresponding cross-compiler instead. Included patch is tested only for --build=i686-pc-linux-gnu, --host=i586-mingw32msvc --target=i586-mingw32msvc Andris --- gpc-20010924/p/Make-lang.in~1 Mon Sep 24 19:59:48 2001 +++ gpc-20010924/p/Make-lang.in Tue Oct 30 17:57:24 2001 @@ -154,8 +154,12 @@ ADD_RTS_PARENT_DIR = sed -e 's,-B$[^/][^:]$,-B../../\1,g;s,^$[^/][^:]$,../../\1,' # The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR -RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ - PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" +RTS_COMPILERS = CC="`if test \"$(build_canonical)\" = \"$(host_canonical)\" ; then \ + echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR); \ + else echo $(GCC_FOR_TARGET); fi`" \ + PC="`if test \"$(build_canonical)\" = \"$(host_canonical)\" ; then \ + echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR);\ + else echo $(GPC_FOR_TARGET); fi`" GPC_GENERATED_SRC = \ $(srcdir)/p/parse.c \

3 10