- Gpc - gnu.de

Re: RunError
by heckenb＠helena.hut.fi 22 Aug '98

22 Aug '98

Peter Gerwinski wrote: > > BTW, (Peter:) BP accepts "RunError" without an argument, so GPC should > > allow that, too. However, BP gives a "Runtime Error 0" then, which I don't > > like very much, since the exit status 0 usually means success. So, GPC > > should probably use some other error code... > > Which one? I'd say one in the "unsorted errors" range 0..99, perhaps 99 -- or 42. ;-) -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

3 2

Re: Weird error...
by Frank Heckenbach 22 Aug '98

22 Aug '98

Orlando Llanes wrote: > I got the following error: > > testpcx.pas:4: storage class specified for parameter `Close' Can't reproduce this one with my current version, so I assume it's been fixed by now. Much has changed since the last release, and this was probably among the bug fixes made. BTW (seeing the contents of edsys.pas and edfile.pas): GPC does support untyped files and BlockRead/BlockWrite (already since January), so there's actually no reason for you to do these workarounds you do with C files and direct libc calls. (And FillChar is build in which is internally the same as memset.) > testpcx.pas: In function `program_Testpcx': > testpcx.pas:33: warning: passing arg 4 of `Pcxencode' from incompatible > pointer type > > I have simplified the source as much as possible while leaving the > source structure as is to reproduce the error. I'm using GPC 2.8.1 under > DOS. The warning on line 33 is insignificant as far as I know, I'm passing > an address, and the routine expects a pointer. The warning is correct. You pass a pointer to EDUInt8 and the routine expects a PArray8 which is a quite different type. (Not all pointer types are the same in Pascal!) To get rid of the warning, you can use type casting. > BTW, if you recall, I got an error a long time ago about an empty > record. I found a way around that, I left the unit to keep up the source > structure, but I defined everything in an include file and included it > into the unit itself, now I don't have that problem anymore (I hope :}). This bug should have been fixed in the next version, too. (I had a lot of problems with various instances of this bug, too...) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: RunError
by Frank Heckenbach 22 Aug '98

22 Aug '98

Peter Gerwinski wrote: > Frank Heckenbach wrote: > > I (Peter Gerwinski) wrote: > > > > BTW, (Peter:) BP accepts "RunError" without an argument, so GPC should > > > > allow that, too. However, BP gives a "Runtime Error 0" then, which I don't > > > > like very much, since the exit status 0 usually means success. So, GPC > > > > should probably use some other error code... > > > > > > Which one? > > > > I'd say one in the "unsorted errors" range 0..99, perhaps 99 -- or 42. ;-) > > What about 81 (assertion failure)? Don't think so. It's got nothing do to with assertions -- or rather, it might have, but then, it might be something completely different. It's up to the programmer what s/he uses this error for... I think 80 (call to predefined procedure `Bug') would be closer. AFAICS, there's no predefined procedure `Bug' currently. Does the standard or some dialect demand one? If not, we could use that and replace `Bug' by `RunError'. But we can just as well use a new error code (error codes are not a scarce resource -- we have the full Integer range available, and currently only nearly 200 out of the first 1000 are used ;-)... And apropos assertions: it's easy to write a procedure for runtime assertions, like the following: procedure Assert (Condition : Boolean; const Message : String); begin if not Condition then Runtime_Error_CString (81, Message) end; (changing the text of the error message to "failed assertion `%s'"). Should I put this routine into the RTS? (This would also make it easier to change the error number, when the error numbers are rearranged.) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Weird error...
by Orlando Llanes 21 Aug '98

21 Aug '98

I got the following error: testpcx.pas:4: storage class specified for parameter `Close' testpcx.pas: In function `program_Testpcx': testpcx.pas:33: warning: passing arg 4 of `Pcxencode' from incompatible pointer type I have simplified the source as much as possible while leaving the source structure as is to reproduce the error. I'm using GPC 2.8.1 under DOS. The warning on line 33 is insignificant as far as I know, I'm passing an address, and the routine expects a pointer. BTW, if you recall, I got an error a long time ago about an empty record. I found a way around that, I left the unit to keep up the source structure, but I defined everything in an include file and included it into the unit itself, now I don't have that problem anymore (I hope :}). See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

1 0

Re[4]: trouble compiling
by Paul Doerwald 14 Aug '98

14 Aug '98

> I think it's better to continue this discussion on the list. If you agree, > be invited to bounce my mail there. Did I not reply to all? oops. You might want to update the list software so it changes the Reply-To: field to gpc(a)hut.fi -- I've made this mistake more than once... > (So do I. If only I had the time I would happily WTFM.)-: Many moons ago, I volunteered to wtfm -- I realized shortly after that I was incapable of doing so (time, and knowledge of Pascal). And since things always work better in a community effort, I made the suggestion I did... Sadly, though, I still haven't gotten anyone else's thoughts. I found a gcc-2.8.1 distribution on my computer that I had downloaded (and left in a stupid place that I never thought to look), so I unpacked that, and stuck gpc-980511 in the p directory. It detected the patch file. I suspect this will work now. (No more trying short cuts for me -- maybe in a few years when I've used Linux enough, and I'm a bit more into the programming loop -- I'm a university music student who hasn't coded actively since early high school, so I'm somewhat (read: very) out of the loop) Sorry to trouble you with all my pedantic questions... | clavicle(a)niagara.com "The LORD is my strength and my | www.niagara.com/~clavicle song; he has become my salvation." | ICQ#13902938 Exodus 15:2b

1 0

trouble compiling
by Paul Doerwald 13 Aug '98

13 Aug '98

It seems that the only reason I ever post in this list is for help compiling GPC. I've got gcc 2.8.1 and gpc-980511. These are the errors I get: (root) pollux:/usr/src/gcc-2.8.1>make LANGUAGES=pascal cd p; make "AR_FLAGS=rc" "AR_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ar" "BISON=bison" "BISONFLAGS=" "CC=gcc" "CFLAGS=-g" "CLIB=" "GCC_FOR_TARGET=./xgcc -B./" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "LN=ln -s" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "RANLIB_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ranlib" "RANLIB_TEST_FOR_TARGET=[ -f /usr/i486-pc-linux-gnu/bin/ranlib ]" "SHELL=/bin/sh" "STAGE_PREFIX=" "exeext=" "objext=.o" "exec_prefix=/usr" "prefix=/usr" "tooldir=/usr/i486-pc-linux-gnu" "bindir=/usr/bin" "libsubdir=/usr/lib/gcc-lib/i486-pc-linux-gnu/2.8.1" "CROSS=" "AR_FLAGS=rc" "AR_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ar" "BISON=bison" "BISONFLAGS=" "CFLAGS=-g" "X_CFLAGS=" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "MAYBE_TARGET_DEFAULT=" "MAYBE_USE_COLLECT2=" "RANLIB_FOR_TARGET=/usr/i486-pc-linux-gnu/bin/ranlib" "RANLIB_TEST_FOR_TARGET=[ -f /usr/i486-pc-linux-gnu/bin/ranlib ]" "SHELL=/bin/sh" "bindir=/usr/bin" "exec_prefix=/usr" "gxx_include_dir=/usr/include/! ! ! g++" "includedir=/usr/local/include" "libsubdir=/usr/lib/gcc-lib/i486-pc-linux-gnu/2.8.1" "prefix=/usr" "target_alias=i486-pc-linux-gnu" "tooldir=/usr/i486-pc-linux-gnu" "gpc_version=980511" "rts_version=2.8" "version=2.8.1" ../gpc1 make[1]: Entering directory `/usr/src/gcc-2.8.1/p' rm -f ../gpc1 gcc -DIN_GCC -DGPC -g -o ../gpc1 \ `cat stamp-gbe` ../c-aux-info.o ../c-iterate.o ../c-pragma.o ../choose-temp.o ../pexecute.o gpc-common.o gpc-convert.o gpc-decl.o gpc-lang.o gpc-lex.o gpc-typeck.o module.o gpi-hash.o circle-buf.o objects.o parse.o rts.o types.o util.o setop.o version.o `if [ xobstack.o != x ]; then echo ../obstack.o; else true; fi` `case "gcc" in "cc") if [ x != x ]; then echo ../; else true; fi ;; esac` `if [ x != x ]; then echo ../; else true; fi` gpc-common.o: In function `build_pascal_binary_op': /usr/src/gcc-2.8.1/p/gpc-common.c:2572: undefined reference to `emit_string_move' /usr/src/gcc-2.8.1/p/gpc-common.c:2587: undefined reference to `emit_string_move' gpc-decl.o: In function `grokdeclarator': /usr/src/gcc-2.8.1/p/gpc-decl.c:5924: undefined reference to `size_volatile' gpc-decl.o: In function `handle_forward_pointers': /usr/src/gcc-2.8.1/p/gpc-decl.c:9049: undefined reference to `dbxout_set_type_status' /usr/src/gcc-2.8.1/p/gpc-decl.c:9055: undefined reference to `dbxout_set_type_status' module.o: In function `execute': /usr/src/gcc-2.8.1/p/module.c:466: undefined reference to `version_flag' module.o: In function `module_must_be_recompiled': /usr/src/gcc-2.8.1/p/module.c:685: undefined reference to `version_flag' module.o: In function `compile_module': /usr/src/gcc-2.8.1/p/module.c:802: undefined reference to `version_flag' module.o: In function `load_tree': /usr/src/gcc-2.8.1/p/module.c:1799: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/module.c:1853: undefined reference to `size_volatile' parse.o: In function `yyparse': /usr/src/gcc-2.8.1/p/parse.y:1563: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/parse.y:1629: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/parse.y:4766: undefined reference to `maybe_find_function_data' rts.o: In function `build_rts_call': /usr/src/gcc-2.8.1/p/rts.c:3503: undefined reference to `emit_string_move' types.o: In function `assign_string': /usr/src/gcc-2.8.1/p/types.c:639: undefined reference to `emit_string_move' /usr/src/gcc-2.8.1/p/types.c:690: undefined reference to `emit_string_pad' types.o: In function `prediscriminate_schema': /usr/src/gcc-2.8.1/p/types.c:1056: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1058: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1089: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/types.c:1092: undefined reference to `size_volatile' types.o: In function `build_pascal_pointer_type': /usr/src/gcc-2.8.1/p/types.c:1738: undefined reference to `dbxout_set_type_status' util.o: In function `handle_formal_conf_array_param_list': /usr/src/gcc-2.8.1/p/util.c:738: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/util.c:763: undefined reference to `size_volatile' util.o: In function `initialize_world': /usr/src/gcc-2.8.1/p/util.c:1816: undefined reference to `size_volatile' /usr/src/gcc-2.8.1/p/util.c:1819: undefined reference to `size_volatile' make[1]: *** [../gpc1] Error 1 make[1]: Leaving directory `/usr/src/gcc-2.8.1/p' make: *** [gpc1] Error 2 Any suggestions? Paul.

2 1

an idea for documentation
by Paul Doerwald 13 Aug '98

13 Aug '98

A couple months ago, there was a big struggle on the list over the out-of-date reference manual for GPC, and people proposed suggesting changes through the list. I have another idea, and I just thought I'd run it past all of you (especially you, Peter) Since there are a few people who *really* know GPC and all its function and procedure calls, but they don't have the time to document the whole thing as well as write it, but they always had corrections to what people submitted.... What I'm thinking is an extensive, online script (I would give it a shot, in Perl) that would allow everyone to update an online version of the documentation (that would be stored in HTML). Everyone could make their own changes; if they see a little problem, they can clarify it, and expand on each others' work. I wouldn't bother with passwords and special access -- I would just have regular backups made so that if someone hit it and tried to screw it up, we'd have a good copy backed up. The HTML file could (somehow?) be translated into texi, for distribution with GPC. Is this something that would be of value? I'd be interested to hear your suggestions. Paul.

1 0

Re: Memory access...
by heckenb＠helena.hut.fi 05 Aug '98

05 Aug '98

Orlando Llanes wrote: > The question I'm about to ask pertains to the DJGPP/DOS platform, tho > it may apply to other platforms if present. How can I access mroe than 8MB > while keeping compatible with the GPC Pointer type? I ask because I tried > allocating >8MB and I got a runtime error saying that GPC is out of heap > space. I know there are DPMI functions, but which one can allocate >8MB > while still maintaining the near pointer type? Thanks in advance! Looks like a DPMI configuration issue. I just ran the following program in DosEmu succesfully, after I increased the DPMI memory size (in DosEmu, that's as simple as setting "dpmi 32768" in /etc/dosemu.conf, but I don't know how this is done in native Dos): program x; const m=33000000; type t=array[1..m] of byte; var a:^t; i:integer; begin new(a); for i:=1 to m do a^[i]:=i and $ff; for i:=1 to m do if a^[i]<>i and $ff then runerror(42); writeln('OK') end. However, I can't seem to allocate more than 32 MB in DPMI, so this might be the limit of DPMI. (Anyone knows? From other source, I sometimes hear 16 MB, sometimes 64 MB as the limit. 32 MB is just in between, so according to the usual Dos kind of logic, this might be correct... >:-) BTW, (Peter:) BP accepts "RunError" without an argument, so GPC should allow that, too. However, BP gives a "Runtime Error 0" then, which I don't like very much, since the exit status 0 usually means success. So, GPC should probably use some other error code... -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Memory access...
by Orlando Llanes 05 Aug '98

05 Aug '98

The question I'm about to ask pertains to the DJGPP/DOS platform, tho it may apply to other platforms if present. How can I access mroe than 8MB while keeping compatible with the GPC Pointer type? I ask because I tried allocating >8MB and I got a runtime error saying that GPC is out of heap space. I know there are DPMI functions, but which one can allocate >8MB while still maintaining the near pointer type? Thanks in advance! See ya! Orlando Llanes "Meine Damen und Herren, Elvis hat soeben das Gebaeude verlassen!" "Look out fo' flyeeng feet" O__/ a010111t(a)bc.seflin.org \/|____. O <__. \/\> / \ ____________|___\______ http://ourworld.compuserve.com/homepages/Monkey414

1 0

compiling gpc sources in plain dos / djgpp
by Maurice Lombardi 04 Aug '98

04 Aug '98

Hi all, Sometimes ago I have seen in a message of DJ Delorie in comp.os.msdos.djgpp, saying that now djgpp with the autoconf port can build with minor modification nearly every unix program governed by configure shell scripts. I have thus retried to build gpc under plain DOS from gcc-2.8.1 and the latest alpha sources gpc-980511.tar.gz. It works indeed with very few modifications, but everything contained in the directory p/config/msdos is now outdated, the configuration for gcc has been completely changed between 2.7.2.x and 2.8.x. I give in attachment a couple of files suggested for doing the modifications automatically (a driver prepare.bat and a shell script doprepar.sh), and a couple of instruction files (install.txt for binaries, the old one only slightly updated, and readme.djgpp for sources) to be put into the p/config/msdos directory (replacing the old ones). The modifications are - a few 8.3 issues stamp-objlist -> s-objlist .gdbinit -> gdb.ini g??.info-NN -> g??.iNN (only when LFN=n) - GCC is built into the build.djgpp subdirectory of the gnu/gc-2.81 source directory, while gpc must be built into the source directory itself. - enlarge the stack for gpc1 and gpc-cpp. Done by modifying a file config/i386/x-go32 which is already used by Delorie for enlarging the stack of cc1 cc1plus and cc1obj. With these modifications (plus one below to be done in the gpc sources themselves) all compiles, and the built compiler gives the same results as the binaries contained in the distribution for everything I have tried, some private programs, test programs from bgi2grx, the gpc test and testsuite. The modification suggested to gpc sources themselves is the following While looking around in the gcc "makefile.in" I have found the following: # Install the info files. # $(INSTALL_DATA) might be a relative pathname, so we can't cd into srcdir # to do the install. The sed rule was copied from stmp-int-hdrs. install-info: doc installdirs lang.install-info -rm -f $(infodir)/cpp.i* $(infodir)/gcc.i* for f in $(srcdir)/cpp.i* $(srcdir)/gcc.i*; do \ realfile=`echo $$f | sed -e 's|.*/$[^/]*$$$|\1|'`; \ $(INSTALL_DATA) $$f $(infodir)/$$realfile; \ done -chmod a-x $(infodir)/cpp.i* $(infodir)/gcc.i* ... and in the file "make-lang.in" from gpc, we indeed cd into the srcdir, and this fails when I install in a relative directory (to see what happens without overwriting my previous binary installation of gpc). So I suggest to replace in "gpc/p/make-lan.in" the old content pascal.install-info: $(srcdir)/p/doc/gpc.info -rm -f $(infodir)/gpc.info* ; cd $(srcdir)/p/doc; for f in gpc.info*; \ do $(INSTALL_DATA) $$f $(infodir)/$$f; done -chmod a-x $(infodir)/gpc.info* by the new content pascal.install-info: $(srcdir)/p/doc/gpc.info -rm -f $(infodir)/gpc.info* ; for f in $(srcdir)/p/doc/gpc.info*; do \ realfile=`echo $$f | sed -e 's|.*/$[^/]*$$$|\1|'`; \ $(INSTALL_DATA) $$f $(infodir)/$$realfile; \ done -chmod a-x $(infodir)/gpc.info* The doprepar.sh will take care of info* -> i* afterwards, only for the dos/LFN=no case. I have checked thas this works. Finally I have taken the .tar.gz sources untarred by the djtar utility. For .zip sources there remain a couple of problems to be solved: .gdbinit is ignored by pkzip and extracted as _.gdb by infozip. The extraction as _gdbinit done by djtar is supposed in the doprepar.sh script. in gpc-980401.zip I have tried, the info files have the long names gpc.info-NN, which cause problem both with pkunzip and infozip. This is also the case in the .tar.gz archive, but djtar takes care of this, by translating them to gpc.iNN, when LFN=no. The simplest workaround is probably not to include these files, since they are rebuilt easily from texi sources. the gpc diff filenames gpc-2.8.0.diff and gpc-2.8.1.diff are extracted by djtar as gpc-2.8-0 and gpc-2.8-1, which is fine for doprepar.sh, while infozip extract both as gpc-2_8_.dif (and barks for overwriting). This has no importance for alpha or beta stages, where you can supply only .tar.gz files, but needs to be solved when releasing an official version (everything is in zip format in the djgpp archives). Hope this helps. -- 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr @echo off echo ... starting from p/config/msdos directory: pwd echo ... going to gcc source dir: cd ..\..\.. pwd echo ... running doprepar shell script sh p\config\msdos\doprepar.sh

1 0