- Gpc - gnu.de

pascal and other languages
by Mehdi Khaldi 13 Feb '03

13 Feb '03

Hi, Could I include cpp files in a pascal program? How to do? I tried with c file and it works. But I would like to know the problems about name mangling. Actually, what happens if in my cpp file, I have 2 functions with the same name? What are their declarations to use them in my pascal programs? thanks

2 1

String Question
by Richard D. Jackson 13 Feb '03

13 Feb '03

When using a plain String I'm getting this warning warning: missing string capacity -- assuming 255 Getting rid of this warning for Var's is not a problem as I just do: mystring : String (some number); But how do you get rid of the warning when a function returns a string such as this: function foobar( test : Integer): String; I have tried to add a capacity argument to String but then I get this error: parse error before '(' So the question is how can you assign the capacity to a String type when you are returning it from a function? I would prefer to not have to make a type for this if possible. Also while on the subject of strings are gpc strings protected against buffer overruns? Thanks Richard Jackson

4 9

Re: String Question
by Prof. A Olowofoyeku (The African Chief) 13 Feb '03

13 Feb '03

Richard D. Jackson wrote: >What is interesting is that. >Given > >var > buff : String (255); > >I can stuff 30925 chars into it after that majic number I get a >segfault. So what is happening here? If I suround a string with >other vars they are not getting overwriten wich is a good thing but >I still wonder why it did not segfault at 256. That is just chance. Take the same program to another PC running the same OS (or compile for another OS) and you might well get the segfault in a different place. I also don't think that you can rely on other variables not being overwritten. Something is being overwritten. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

1 0

Re: gpc with gdb
by Frank Heckenbach 12 Feb '03

12 Feb '03

mkhaldi(a)softaddicts.ca wrote: > >Does it happen with a simple test program such as the following, or only in > >more complicates cases? > It happened in a simple case like your example. I just put a value to this > integer! > > >What did you type in gdb? Which backend (GCC) version does your GPC use? > I have : > - gdb 5.1-4 > - gcc 2.96 but I built gpc with gcc 2.95 core. > - I use DDD like graphical debug tool. > > Sorry but I forgot a thing : > I can't examine the value of this variable. How to do? I'm not familiar with ddd, i gdb you type `p <expression>' where `<expression>' can simply be a variable name. frank@goedel:~/work>cat foo.pas program Foo; var i: Integer = 42; begin end. frank@goedel:~/work>gpc -g foo.pas frank@goedel:~/work>gdb ./a.out GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-pc-linux-gnulibc1"... (gdb) p i $1 = 42 (gdb) q Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

gpc with gdb
by Mehdi Khaldi 12 Feb '03

12 Feb '03

Hi, When I compile a pascal program with gpc and -g option. I try to use the binary file with gdb. But when I want to examine a value of a variable, gdb says the type of the variable is "void" instead of "integer". What is the solution to examine variables? I have gdb5.1.x and gpc is the last release before the last updates dating 02/09/2003 thanks

2 1

build problems on hp ux 11.0
by Tom Wurgler 12 Feb '03

12 Feb '03

Hi, I am running HP-UX 11.0 and am attempting to build gcc and gpc. I can build the gcc fine by itself, but when I attempt gcc with gpc, I get the failure listed below. I am trying to build gcc 3.2.1 and the alpha version of gpc-20030209. I start with a freshly unpacked gcc, then unpack the gpc and move the "p" directory into the gcc subdir of the build dir. Is all this correct? Then I type "make bootstrap" the same as for gcc alone? I know about the quadlib path bug in gcc 3.2.1. BTW, I start out with setenv CC cc (the HP ansi c compiler). Anyway, thanks for any pointers anyone can give me. Tom ============================================================================ Tom Wurgler The Goodyear Tire & Rubber Company Principal Engineer Tire-Vehicle Engineering Technology Phone: 330-796-1656 Technical Center D/460G Fax: 330-796-3292 P.O.Box 3531 internet mail: twurgler(a)goodyear.com Akron, Ohio 44309-3531 ============================================================================ [gcc-3.2.1.obj]rds294[69]% make bootstrap make[1]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/libiberty' make[2]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/libiberty/testsuite' make[1]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/libiberty' make[1]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/zlib' : make ; exec true "AR_FLAGS=rc" "CC_FOR_BUILD=cc" "CFLAGS=-g" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-O2 -g" "INSTALL=/bin/sh /u/rdstt1/t901353/src/gcc-3.2.1/install-sh -c" "INSTALL_DATA=/bin/sh /u/rdstt1/t901353/src/gcc-3.2.1/install-sh -c -m 644" "INSTALL_PROGRAM=/bin/sh /u/rdstt1/t901353/src/gcc-3.2.1/install-sh -c " "INSTALL_SCRIPT=/bin/sh /u/rdstt1/t901353/src/gcc-3.2.1/install-sh -c" "LDFLAGS=" "LIBCFLAGS=-g" "LIBCFLAGS_FOR_TARGET=-O2 -g" "MAKE=make" "MAKEINFO=makeinfo " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/home/rdstt1/t901353/local" "infodir=/home/rdstt1/t901353/local/info" "libdir=/home/rdstt1/t901353/local/lib" "prefix=/home/rdstt1/t901353/local" "tooldir=/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00" "AR=ar" "AS=as" "CC=cc" "CXX=c++" "LD=ld" "LIBCFLAGS=-g" "NM=nm" "PICFLAG=" "RANLIB=true" "DESTDIR=" DO=all multi-do make[1]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/zlib' Bootstrapping the compiler make[1]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc' make CC="stage1/xgcc -Bstage1/ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/" \ STAGE_PREFIX=stage1/ \ CFLAGS="-g -O2" LDFLAGS="" WARN_CFLAGS="\$(GCC_WARN_CFLAGS)" STRICT_WARN="-Wtraditional -pedantic -Wno-long-long" libdir=/home/rdstt1/t901353/local/lib LANGUAGES="c gcov c++ f77 java objc pascal" MAKEOVERRIDES= OUTPUT_OPTION="-o \$@" make[2]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc' (cd intl && make all) make[3]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/intl' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/intl' make[2]: Circular libgcc.a <- pascal dependency dropped. if [ -f specs.ready ] ; then \ true; \ else \ echo timestamp > specs.ready; \ fi if [ -f fixhdr.ready ] ; then \ true; \ else \ echo timestamp > fixhdr.ready; \ fi make GCC_FOR_TARGET="./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include" \ HOST_PREFIX="" HOST_PREFIX_1="ignore-" \ AR_FOR_TARGET="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ar; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ar | sed -e $t ; fi; fi`" \ AR_CREATE_FOR_TARGET="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ar; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ar | sed -e $t ; fi; fi` rc" \ AR_FLAGS_FOR_TARGET="" \ CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long" \ RANLIB_FOR_TARGET="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi`" \ RANLIB_TEST_FOR_TARGET="[ -f ` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi` ] || ( [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" \ NM_FOR_TARGET="` if [ -f ./nm ] ; then echo ./nm ; elif [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/nm-new ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/nm-new ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo nm; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo nm | sed -e $t ; fi; fi`" AWK="gawk" \ LIBGCC2_CFLAGS="-O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED " \ INCLUDES="-I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include" \ CONFIG_H="tconfig.h " MACHMODE_H="machmode.h machmode.def" \ LIB1ASMSRC='' \ MAKEOVERRIDES= \ -f libgcc.mk all make[3]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc' for d in libgcc; do \ if [ -d $d ]; then true; else /bin/sh ../../gcc-3.2.1/gcc/mkinstalldirs $d; fi; \ done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include -c ../../gcc-3.2.1/gcc/quadlib.c -o libgcc/./quadlib.o cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include -DL_eprintf -c ../../gcc-3.2.1/gcc/libgcc2.c -o libgcc/./_eprintf.o cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include -DL_bb -c ../../gcc-3.2.1/gcc/libgcc2.c -o libgcc/./_bb.o cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include -DL__gcc_bcmp -c ../../gcc-3.2.1/gcc/libgcc2.c -o libgcc/./__gcc_bcmp.o cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled rm -rf ./libgcc.a ar rc ./libgcc.a libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./_cmpdi2.o libgcc/./_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o libgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o libgcc/./_fixunssfdi.o libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./_floatdixf.o libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o libgcc/./_floatditf.o libgcc/./_clear_cache.o libgcc/./_trampoline.o libgcc/./__main.o libgcc/./_exit.o libgcc/./_absvsi2.o libgcc/./_absvdi2.o libgcc/./_addvsi3.o libgcc/./_addvdi3.o libgcc/./_subvsi3.o libgcc/./_subvdi3.o libgcc/./_mulvsi3.o libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o libgcc/./_divdi3.o libgcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o libgcc/./lib2funcs.o libgcc/./quadlib.o libgcc/! ./_eprintf.o libgcc/./_bb.o libgcc/./__gcc_bcmp.o if [ -f ranlib ] || ( [ hppa2.0w-hp-hpux11.00 = hppa2.0w-hp-hpux11.00 ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] ) ; then \ ranlib ./libgcc.a ; \ else true; fi; ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include -fexceptions -c ../../gcc-3.2.1/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled ../../gcc-3.2.1/gcc/unwind-pe.h:61: warning: `size_of_encoded_value' defined but not used ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include -fexceptions -c ../../gcc-3.2.1/gcc/unwind-dw2-fde.c -o libgcc/./unwind-dw2-fde.o cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include -fexceptions -c ../../gcc-3.2.1/gcc/unwind-sjlj.c -o libgcc/./unwind-sjlj.o cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled rm -rf ./libgcc_eh.a ar rc ./libgcc_eh.a libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o libgcc/./unwind-sjlj.o if [ -f ranlib ] || ( [ hppa2.0w-hp-hpux11.00 = hppa2.0w-hp-hpux11.00 ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] ) ; then \ ranlib ./libgcc_eh.a ; \ else true; fi; ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -o libgcc_s.sl libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./_cmpdi2.o libgcc/./_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o libgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o libgcc/./_fixunssfdi.o libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./_floatdixf.o libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o libgcc/./_floatditf.o libgcc/./_clear_cache.o libgcc/./_trampoline.o libgcc/./__main.o libgcc/./_exit.o libgcc/./_! absvsi2.o libgcc/./_absvdi2.o libgcc/./_addvsi3.o libgcc/./_addvdi3.o libgcc/./_subvsi3.o libgcc/./_subvdi3.o libgcc/./_mulvsi3.o libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o libgcc/./_divdi3.o libgcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o libgcc/./lib2funcs.o libgcc/./quadlib.o libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o libgcc/./unwind-sjlj.o -lc && rm -f libgcc_s.1 && ln -s libgcc_s.sl libgcc_s.1 make[3]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc' echo "int xxy_us_dummy;" >tmp-dum.c ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include -S tmp-dum.c echo '/*WARNING: This file is automatically generated!*/' >tmp-under.c if grep _xxy_us_dummy tmp-dum.s > /dev/null ; then \ echo "int prepends_underscore = 1;" >>tmp-under.c; \ else \ echo "int prepends_underscore = 0;" >>tmp-under.c; \ fi /bin/sh ../../gcc-3.2.1/gcc/move-if-change tmp-under.c underscore.c rm -f tmp-dum.c tmp-dum.s echo timestamp > s-under stage1/xgcc -Bstage1/ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.2.1/gcc -I../../gcc-3.2.1/gcc/. -I../../gcc-3.2.1/gcc/config -I../../gcc-3.2.1/gcc/../include underscore.c -o underscore.o cc1: warning: -g is only supported when using GAS on this processor, cc1: warning: -g option disabled stage1/xgcc -Bstage1/ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -o Tcollect2 \ collect2.o tlink.o hash.o intl.o underscore.o version.o ./intl/libintl.a ../libiberty/libiberty.a /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (../libiberty/libiberty.a(cplus-dem.o)) was detected. The linked output may not run on a PA 1.x system. mv -f Tcollect2 collect2 cd ../../gcc-3.2.1/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.2.1" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ar; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ar | sed -e $t ; fi; fi`" AR_FLAGS="rc" RANLIB="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi`" RANLIB_TEST="[ -f ` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa! 2.0w-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi` ] || ( [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" RTSFLAGS="" DESTDIR="../.." generated-files make[3]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1/gcc/p/rts' make[3]: Nothing to be done for `generated-files'. make[3]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1/gcc/p/rts' cd ../../gcc-3.2.1/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.2.1" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ar; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ar | sed -e $t ; fi; fi`" AR_FLAGS="rc" RANLIB="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi`" RANLIB_TEST="[ -f ` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa! 2.0w-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi` ] || ( [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" RTSFLAGS="" DESTDIR="../.." generated-files make[3]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1/gcc/p/rts' make[3]: Nothing to be done for `generated-files'. make[3]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1/gcc/p/rts' ../../gcc-3.2.1/gcc/p/script/mkdir-p p/rts src=`cd ../../gcc-3.2.1/gcc && pwd` && \ cd ./p/rts && \ CC="`echo ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" PC="`echo ./xgpc -B./ -I./p/rts' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" CONFIG_SITE=nonexisting-file \ $src/p/rts/configure --silent > /dev/null --srcdir=$src/p/rts \ `if [ x@with_shared@ = xyes ]; then echo '--with-shared'; fi` cd ./p/rts && make CC="`echo ./xgcc -B./ -B/home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/bin/ -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/include -isystem /home/rdstt1/t901353/local/hppa2.0w-hp-hpux11.00/sys-include' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" PC="`echo ./xgpc -B./ -I./p/rts' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" GCC_VERSION="3.2.1" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ar ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ar; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ar | sed -e $t ; fi; fi`" AR_FLAGS="rc" RANLIB="` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-! hpux11.00" ] ; then echo ranlib; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi`" RANLIB_TEST="[ -f ` if [ -f /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ] ; then echo /u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/../binutils/ranlib ; else if [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] ; then echo ranlib; else t='s,^,hppa2.0w-hp-hpux11.00-,'; echo ranlib | sed -e $t ; fi; fi` ] || ( [ "hppa2.0w-hp-hpux11.00" = "hppa2.0w-hp-hpux11.00" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" RTSFLAGS="" DESTDIR="../.." all make[3]: Entering directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/p/rts' echo '{ rts-config.inc. Generated automatically from rts-config.h. }' > rts-config.inc sed -e 's,/\*,{,g;s,\*/,},g;s,^[ \t]*#$.*$,{$\1},' rts-config.h >> rts-config.inc ../.././xgpc -B../.././ -I../.././p/rts -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/u/rdstt1/t901353/src/gcc-3.2.1/gcc/p/rts --automake --print-needed-options "/u/rdstt1/t901353/src/gcc-3.2.1/gcc/p/rts/endian.pas" 2> "needed-options" || true if grep -v '^--' "needed-options" > /dev/null; then echo "needed-options: `cat "needed-options"`" >&2; rm -f "needed-options"; false; else true; fi needed-options: gpc1: warning: -g is only supported when using GAS on this processor, gpc1: warning: -g option disabled make[3]: *** [needed-options] Error 1 make[3]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/u/rdstt1/t901353/src/gcc-3.2.1.obj/gcc' make: *** [bootstrap] Error 2 [gcc-3.2.1.obj]rds294[70]%

2 1

gpc 20030209 - Filemode
by Prof A Olowofoyeku (The African Chief) 11 Feb '03

11 Feb '03

Hi Frank Having to put the GPC or system unit in the USES clause just to access the Filemode variable is going to cause major problems. There are many reasons (lack of qualified identifiers being a major one) why one would not want to use either unit. Up till now, we have not needed either of them to in order to use Filemode. The new situation is giving me plenty of headache with regard to a lot of existing code that uses Filemode while deliberately staying away from the GPC and System units. What is the impetus for this change, and can it be reversed? Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

2 3

gpc 20030209 - again
by Prof A Olowofoyeku (The African Chief) 11 Feb '03

11 Feb '03

Hi This program dies with a compiler error (function result not assigned). program bar; function foo : integer; begin Writeln ('bar'); end; begin writeln (foo); end. In previous GPC versions, a warning was generated. Any reason for turning it into an error? I guess some standard requires this - right? Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

2 2

Optomisation problem solved
by Silvio a Beccara 11 Feb '03

11 Feb '03

Hi, I solved my sigsegv problems with -O3 optimisation by simply upgrading to version 20020304. Bye Silvio | Hi, | | when compiling a program with optimisation option -O3 sometimes everything | works fine, some others the program crashes for no reason. Recompiling | without -O3 eliminates the problem. | | I use GPC version: | | Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs | gpc version 20020304, based on 2.95.3 20010315 (release) | | Any suggestion? | | Silvio a Beccara

1 0

gpc 20030209 and asmnames
by Prof A Olowofoyeku (The African Chief) 10 Feb '03

10 Feb '03

Hi Frank The asmnames for many routines in the GPC unit have changed (primarily a change of case). This (because asmnames are case-sensitive) breaks existing units (e.g., Sysutils) that rely on asmnames to work around the absence of qualified identifiers. Are these case changes likely to be continuous, or are you finished with the changes now? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

1 0

lgcc?
by Paul Daily 10 Feb '03

10 Feb '03

2 1

Re: GPC: daily digest V1 #206
by Tom Schneider 10 Feb '03

10 Feb '03

I noticed a minor error in the GPC list: > GPC: daily digest > > This is Digest Volume 1 : Issue 206 : Digest Style "text" > Below is a summary of all the messages, showing the subject of each post > and who posted it, followed by the full text of all messages. Re: use of 'in' clause > Re: Inefficiency of `mod' > gpc-20030209 > lgcc? > Re: gpc-20030209 > > ---------------------------------------------------------------------- > > Date: Sun, 9 Feb 2003 13:35:08 +0100 > From: Frank Heckenbach <frank(a)g-n-u.de> > To: gpc(a)gnu.de > Subject: Re: use of 'in' clause > Message-ID: <200302091235.NAA09482(a)goedel.fjf.gnu.de> ... The first message is: > Subject: Re: use of 'in' clause But in the 'index' that line is fused with the previous line: > and who posted it, followed by the full text of all messages. Re: use of 'in' clause I suggest putting two additional carriage returns (writeln(digest);writeln(digest);) before the first message index line. This will separate it away from the introductory paragraph. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

1 0

Optimisation crashes
by Silvio a Beccara 09 Feb '03

09 Feb '03

Hi, when compiling a program with optimisation option -O3 sometimes everything works fine, some others the program crashes for no reason. Recompiling without -O3 eliminates the problem. I use GPC version: Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gpc version 20020304, based on 2.95.3 20010315 (release) Any suggestion? Silvio a Beccara

3 5

Compiler crash
by Andrew Gregory 07 Feb '03

07 Feb '03

I'm getting an access violation in gpc1.exe at 0x00578a24 during compile on Windows NT. I'm using MinGW 2.0.0-3 with core gcc 3.2.1, and gpc 2.1 20020510 (from MinGW site). The code is in the form of an include file. I tested it as a console application - and it works. I've re-packaged so that it can be called from C, based on the gpc_c_pas.pas example. Two integer functions are called, with all parameters being passed as double value and variable parameters. Now I get a crash. Someone may have seen this crash before - any ideas? Dr Watson produced this: function: <nosymbols> 005789fb 0f84c7000000 je 00578ac8 00578a01 8b5e10 mov ebx,[esi+0x10] ds:02034226=???????? 00578a04 85db test ebx,ebx 00578a06 751c jnz 00578a24 00578a08 681a090000 push 0x91a 00578a0d 68d2895700 push 0x5789d2 00578a12 68a04a5700 push 0x574aa0 00578a17 68fb815700 push 0x5781fb 00578a1c e87bc30600 call 005e4d9c 00578a21 8d7600 lea esi,[esi] ds:02034226=???????? FAULT ->00578a24 f6430a80 test byte ptr [ebx+0xa],0x80 ds:0267a08e=?? 00578a28 0f848e000000 je 00578abc 00578a2e 837b1000 cmp dword ptr [ebx+0x10],0x0 ds:0267a08e=???????? 00578a32 7413 jz 00578a47 00578a34 833ddca65e0000 cmp dword ptr [005ea6dc],0x0 ds:005ea6dc=00000000 00578a3b 743f jz 00578a7c 00578a3d a1d8a65e00 mov eax,[005ea6d8] ds:005ea6d8=00a35790 00578a42 394338 cmp [ebx+0x38],eax ds:0267a08e=???????? 00578a45 7535 jnz 00578a7c 00578a47 83c4f8 add esp,0xf8 00578a4a 6820855700 push 0x578520 00578a4f 53 push ebx Andrew. ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. -------------------------------------------------------------------

3 2

Re: Porting from DEC pascal to GPC
by Wood David 07 Feb '03

07 Feb '03

Rob Koopman wrote: We are investigating to port about 400.000 lines of DEC Vax Pascal (started as VMS application later ported to OSF1 UNIX). One of our concerns is the maturity of the GPC environment. During our initial tests we encountered some compiler problems (segfault, internal error). An obvious question is did someone else try this before. ( DEC Pascal has funny extentions) We've ported quite a lot of DEC Pascal to GPC without major problems. Certainly GPC2.1 hasn't given us problems with segfaults or internal errors on both i386 or Alpha platforms. We have had to do quite a lot of manual code conversions though. Areas which spring to mind that needed changing in our code was: GPC doesn't read enumerated types from files; GPC doesn't support the :=ZERO assignment; GPC doesn't use file i/o and read qualifiers, especially ERROR:= CONTINUE; VARYING [] OF CHAR must be replaced by STRING(); REAL is best defined as SINGLE; VMS runtime library functions aren't available (obviously!). I can't do key detection as I do under VMS INHERIT and ENVIRONMENT become INTERFACE/IMPLEMENTATION and USES Remove [GLOBAL] and [EXTERNAL] [STATIC] becomes static No D+0 etc. for double precision exponents The only compiler bug - global string definitions in modules don't always work yet (I don't think?) I have code examples of how I've worked around the enumerated type reading and ZERO issues if you wish. Regards David Wood QinetiQ Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

3 2

UCSD strings
by Adriaan van Os 07 Feb '03

07 Feb '03

In the GPC docs I found that UCSD (BP) strings are on the todo list for the compiler. Below is an outline for an intermediate solution I write for the Macintosh Toolbox. The "Carbon" API has 700 (!) references to UCSD-Pascal strings. For binary compatibility, I have little choice. If appropriate, I will be pleased to write runtime support routines (in Pascal) for UCSD strings, when they are getting integrated into the compiler. Regards, Adriaan van Os ----------------- TYPE Str255 = PACKED RECORD Length: byte; chars: packed array[ 1..255] of char END; Str32 = PACKED RECORD Length: byte; chars: packed array[ 1..32] of char; pad: char {for binary compatibility} END; {etcetera} OPERATOR + ( const theStr1 : Str255; const theStr2 : Str255) AD: Str255; OPERATOR = ( const theStr1 : Str255; const theStr2 : Str255) EQ: Str255; OPERATOR > ( const theStr1 : Str255; const theStr2 : Str255) GT: Str255; OPERATOR < ( const theStr1 : Str255; const theStr2 : Str255) ST: Str255; OPERATOR >= ( const theStr1 : Str255; const theStr2 : Str255) GE: Str255; OPERATOR <= ( const theStr1 : Str255; const theStr2 : Str255) SE: Str255; Plus: (1) standard routines Pos, Insert, Delete and Concat (2) conversion routines from and to string-constants and GPC "long strings".

2 1

gcc-3.2.2
by Russell Whitaker 06 Feb '03

06 Feb '03

Hi gcc-3.2.2 is now out. Tried building gpc with it: Minor problem: Patch for 3.2.1 works, gives a few offset complaints. Not so minor problem: Build quit - incompatable definitions of global_trees p/gpc.h: 667 tree.h: 1951 Hope this helps Russ

2 2

Re: Porting from DEC pascal to GPC
by Wood David 06 Feb '03

06 Feb '03

> Some general pointers beyond those I already mentioned: > > Define a few syntax reassignments at the top of the DEC Pascal: > > {--- Command Substitution ---} > > {$define WRITEV WRITESTR} > {$define READV READSTR} > > {--- Type Substitution ---} > > {$define uint cardinal} > {$define sngl single} > {$define dble double} > {$define zero(a) DEC_zero(a, #0, sizeof(a))} > > {--- File Handling ---} > > {$define status(a) IOResult} > {$define open(a, b) assign(a,b)} > > {--- Read enumerated types / booleans from files ---} > > {$define readlnenum(a,b,c) readenum(a,b,c);readln(a)} > {$define readlnbool(a,b) readbool(a,b);readln(a)} > > Then create a UNIT for inclusion in the Pascal modules to do some other > bits: > > UNIT OS_linux; > > INTERFACE > > USES > const_type; > > TYPE > Tstring = String(2048); > Pstring = ^String; > > FUNCTION LoCaseStr(CONST s : string) : Tstring; asmname > '_p_locase_str'; > PROCEDURE LoCaseString(VAR s : string); asmname '_p_locase_string'; > PROCEDURE DEC_zero(VAR param; ch : char; size : longint ); asmname > 'memset'; > > FUNCTION pad(str : string; fill : char; size : integer) : linestring; > PROCEDURE linux_reset( VAR ip_file : TEXT); > > PROCEDURE ReadBool (VAR f : TEXT; VAR ans : BOOLEAN); > PROCEDURE ReadEnum (VAR f : TEXT; VAR ans; CONST IDs : ARRAY OF > PString); > PROCEDURE WriteEnum (VAR f : TEXT; VAR EnumVal; CONST IDs : ARRAY [m .. > n : Integer] OF PString); > > CONST {This is just an example} > ModeIDs : ARRAY [0..2] of PString = (@'interactive', > @'batch', > @'batch_with_display'); > > IMPLEMENTATION > {************************************************************************* > *******************************************} > FUNCTION pad(str : STRING; fill : CHAR; size : Integer) : linestring; > > VAR > returned_string : linestring; > i, len_str : INTEGER; > > BEGIN > returned_string := str; > > len_str := length(str); > IF len_str > 255 THEN > len_str := 255; > > FOR i := (len_str+1) TO size DO > returned_string := returned_string + fill; > > pad := returned_string; > END; > {************************************************************************* > *******************************************} > > {************************************************************************* > *******************************************} > PROCEDURE linux_reset( VAR ip_file : TEXT); > > BEGIN > {$I-} { Disable I/O error checking } > reset(ip_file); > {$I+} > END; > {************************************************************************* > *******************************************} > > {************************************************************************* > *******************************************} > {*** Enumerated types > ***} > {************************************************************************* > *******************************************} > PROCEDURE ReadWord (VAR f : TEXT; VAR s : String); > > CONST > SpaceCharacters = [' ',#9]; > WordChars = ['A'..'Z', 'a'..'z', '_', '0'..'9']; { > Allowed characters } > > BEGIN > s:= ''; > WHILE f^ IN SpaceCharacters DO { > Skip over whitespace and blank lines } > IF EOLN(f) > THEN READLN(f) > ELSE GET(f); > > WHILE NOT EOF (f) AND NOT EOLn (f) AND (f^ IN WordChars) DO { > Build string from WordChar characters } > BEGIN > s:= s + f^; > GET (f) > END > END; > {************************************************************************* > *******************************************} > > {************************************************************************* > *******************************************} > PROCEDURE ReadBool (VAR f : TEXT; VAR ans : BOOLEAN); > > VAR s : TString; > > BEGIN > ReadWord (f, s); > { Read word from text file } > LoCaseString (s); > { Change to lower case } > IF s = 'false' THEN > { Assign logical based on value } > ans := FALSE > ELSE IF s = 'true' THEN > ans := TRUE > ELSE > BEGIN > writeln('Error reading boolean from file.'); > halt > END > END; > {************************************************************************* > *******************************************} > > {************************************************************************* > *******************************************} > PROCEDURE ReadEnum (VAR f : TEXT; VAR ans; CONST IDs : ARRAY OF PString); > > TYPE > enum = (z_a, z_b, z_c, z_d, z_e, z_f, z_g, z_h, z_i, z_j, z_k, z_l, > z_m); { Dummy enumerated type } > > VAR > s : TString; > temp : enum; > > BEGIN > ReadWord (f, s); { Read > word from text file } > LoCaseString (s); { Change > to lower case } > temp:= Low(enum); { Select > first value } > WHILE (temp <= enum(High (IDs))) AND { While > value < max value AND} > (LoCaseStr (IDs [ord(temp)]^) <> s) DO Inc (temp); { > string not yet found, increase value} > > IF ord(temp) <= High (IDs) { If > string was found } > THEN > enum(ans) := temp { assign > value to variable } > ELSE > BEGIN > writeln('Error reading enumerated type from file.'); > halt > END > END; > {************************************************************************* > *******************************************} > > {************************************************************************* > *******************************************} > PROCEDURE WriteEnum (VAR f : TEXT; VAR EnumVal; CONST IDs : ARRAY [m .. n > : Integer] OF PString); > > TYPE > enum = (z_a, z_b, z_c, z_d, z_e, z_f, z_g, z_h, z_i, z_j, z_k, z_l, > z_m); { Dummy enumerated type } > > BEGIN > WRITE (f, IDs [ord(enum(EnumVal))]^) > END; > {************************************************************************* > *******************************************} > END. > > Using {*V*} for DEC syntax and {*L*} for gpc syntax, module headers look > like this: > > {*V*}[INHERIT('gen_lib.pen','globals.pen')]MODULE example_mod; > {*L*}{MODULE example_mod interface;} > {*L*}{ export example_mod =(task1);} > {*L*}{ PROCEDURE task1(request:integer);} > {*L*}{END.} > > {*L*}{MODULE example_mod implementation;} > {*L*}{#INCLUDE <os_linux.h>} > {*L*}{USES os_linux, gen_lib, globals;} > VAR > ... > [GLOBAL]PROCEDURE task1(request:integer); > > Unit headers look like this: > > {*V*}[ENVIRONMENT ('globals.pen')]MODULE globals_mod; > {*L*}{UNIT globals;} > {*L*}{#include <os_linux.h>} > {*L*}{INTERFACE} > > VAR > ... > > {*L*}{IMPLEMENTATION} > > END. > > And some other changes are: > > {*V*} a:= ZERO; > {*L*} zero(a); > {*V*} a : array [1..3] of double:= ZERO; > {*L*} a : array [1..3] of double:= (0,0,0); > {*V*} OPEN(myfile,"filename.dat",ERROR:=CONTINUE, HISTORY:= OLD); > {*L*} OPEN(myfile,"filename.dat"); linux_reset(myfile); > {*V*}READLN(myfile,Booleanvar); > {*L*}READLNBOOL(myfile, Booleanvar); > {*V*}READLN(myfile,Enumeratedvar); > {*L*}READLNENUM(myfile, Enumeratedvar, EnumstringIDs); > > Where ERROR:=CONTINUE is used with READLN, bracket the READLN with {I-} > and {I+}. These are compiler directives recognised by GNU Pascal (and > ignored by DEC Pascal) which disable I/O error checking. > > Replace SYS$OUTPUT with /dev/stdout. > Replace SYS$INPUT with /dev/stdin. > > Regards > > David Wood > QinetiQ Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

1 0

Porting from DEC pascal to GPC
by Rob Koopman 06 Feb '03

06 Feb '03

Hello: We are investigating to port about 400.000 lines of DEC Vax Pascal (started as VMS application later ported to OSF1 UNIX). One of our concerns is the maturity of the GPC environment. During our initial tests we encountered some compiler problems (segfault, internal error). An obvious question is did someone else try this before. ( DEC Pascal has funny extentions) Regards, Rob Koopman

3 2

Re: Porting from DEC pascal to GPC
by Rob Koopman 06 Feb '03

06 Feb '03

Martin Liddle wrote: We ported an application with a similar number of lines to yours from Extended Pascal and it now runs very well. What operating system and hardware are you moving the application to? We port a library (as in University library) application to SUN Solaris for hardware like Sun V480. Regards Rob Koopman

1 0

Re: Porting from DEC pascal to GPC
by Rob Koopman 06 Feb '03

06 Feb '03

David Wood wrote: We've ported quite a lot of DEC Pascal to GPC without major problems. Certainly GPC2.1 hasn't given us problems with segfaults or internal errors on both i386 or Alpha platforms. We have had to do quite a lot of manual code conversions though. We also identified a lot of potential manual code conversions. Enough to hesitate about the jump. Happy to hear the compiler did not cause problems. David Wood wrote: Areas which spring to mind that needed changing in our code was: <snip> I have code examples of how I've worked around the enumerated type reading and ZERO issues if you wish. We are surely interested in the Zero example. We do not use reading of enumerated types. In addition to this did you automatically tackle writev, readv?. Rob Koopman

1 0

Crash
by Andrew Gregory 06 Feb '03

06 Feb '03

Sorry to trouble you but I fixed it. I had something like: program Myprogram; {$gpc-main=Dummy} const eps_air = 1.000637; light = 2.99792458E2; {mm and GHz} function fun1(a: double, var b : double) : integer ; asmname 'fun1'; function fun2(a: double, var b : double) : integer; asmname 'fun2'; {$include "maincode.pas"} // the functions and procs are here begin WriteLn ('This is never called.'); Flush (Output); end. When I moved the const declarations into maincode.pas it compiled ok. Very strange. Andrew. ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. -------------------------------------------------------------------

1 0

GPC
by Mehdi Khaldi 05 Feb '03

05 Feb '03

Hi, When I use a graphical debugger, I can't examine variables. The message is "no symbol in current context". What do I have to do to examine these ones? Is it when I compile? Thanks

2 1

suse
by Richard Rothbauer 05 Feb '03

05 Feb '03

Your "Installation instructions for GPC binary distribution" does not work for SUSE8.1 comment "installation problem, can not exec 'gpcpp' : No such file ore directory" What to do? Kind regards R.Rothbauer

2 1

Own traps
by Andrew Gregory 04 Feb '03

04 Feb '03

I am porting some complex mathematical Pascal code to GPC. In certain places in the middle of procedures at the nth level there are things like if (X<-1) then begin writeln('Error X<1'); halt end; Since I'm aiming to produce a DLL (main function in C), if X<1 I need to leave the Pascal routine immediately and return an integer failure code to my C program. How can I replace the halt statement by a jump to an exit point, with a stack clean-up? Andrew. ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. -------------------------------------------------------------------

3 2

gpc compiler for OS X - problem
by Ed Stoeffhaas 03 Feb '03

03 Feb '03

Hi Adriann, Thanks for your suggestions. I downloaded and installed the binary package of the gpc pascal compiler yesterday. It seemed to install easily and without problem. When I type "gpc" I get the expected output: "Reading specs from /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ specs Configured with: ../gpc-3.2.1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc321d3 Thread model: single gpc version 20021128, based on gcc-3.2.1" But when I try to compile a program, I get the following errors, even for these two demo programs included with the package: [bluejay:~] ed% gpc factorial.pas factorial.pas:31: module/unit interface `Gpc' could not be imported [bluejay:~] ed% gpc datetimedemo.pas gpc: installation problem, cannot exec `as': No such file or directory I cannot locate the file "as" anywhere. What is wrong? Did I do something incorrect in the installation? I would appreciate any assistance you could give me on this matter. Sincerely Ed Stoeffhaas

4 3

Basic problem on OS X : cannot import units
by Antoine Gautier 01 Feb '03

01 Feb '03

Hello all. I just installed gpc on OS X from the microbizz binaries. Simple programs compile ok, but not when I try to use units. Do I need to set env variables in the tcsh ? add a path to the units somewhere ? Thanks ! Here is an example (is ok without the USES) : [ip-98-110:~] antoine% cat test.pas program test; uses gpc; begin writeln ('Hello world'); end. [ip-98-110:~] antoine% gpc test.pas test.pas:3: module/unit interface `Gpc' could not be imported [ip-98-110:~] antoine% which gpc /usr/bin/gpc [ip-98-110:~] antoine% gpc -v Reading specs from /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ specs Configured with: ../gpc-3.2.1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc321d3 Thread model: single gpc version 20021128, based on gcc-3.2.1 [ip-98-110:~] antoine% ls -la /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ units/dos.pas -rw-rw-rw- 1 antoine staff 23088 Jan 11 04:39 /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ units/dos.pas [ip-98-110:~] antoine%

3 4

Testsuite results for gpc on Mac OS X
by Adriaan van Os 01 Feb '03

01 Feb '03

Below are the results of the testsuite for gpc-20021128 with gcc-3.2.1 on Mac OS X.2.3 (Darwin 6.3). I can send in more information as needed. Regards, Adriaan van Os P.S. Same results with -gstabs -------------- [G4:~] adriaan% gpc -v Reading specs from /usr/local/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/specs Configured with: ../gpc-3.2.1/configure --enable-languages=c,pascal --prefix=/usr/local/gpc321d3 Thread model: single gpc version 20021128, based on gcc-3.2.1 [G4:~] adriaan% cd ~/gnu/testgpc/test [G4:~/gnu/testgpc/test] adriaan% make Running the GPC Test Suite. This may take a while ... rm -f *.dat *.o *.s *.gpm *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.gpm todo/*.gpi todo/*.gpd todo/core { gpc --version | head -1; gpc --print-search-dirs | grep install | head -1; hostname || echo "unknown host"; } | \ sed -e 's,^,Testing ,;N;s,\n.*gcc-lib[/\], (,;s,[/\].*,),;N;s,\n, (,;s,$,),' Testing gpc 20021128, based on gcc-3.2.1 (powerpc-apple-darwin6.3) (G4.local.) echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | "./test_sum" TEST agettext2test.pas: SKIPPED: libintl not installed TEST asmtest.pas: SKIPPED: only for IA32 TEST asmtest2.pas: SKIPPED: only for IA32 TEST asmtest3.pas: SKIPPED: only for IA32 TEST backtracerr.pas: 2c2,71 < ./test_run: line 188: 22183 Segmentation fault ./"$A_OUT" "$x" --- > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to b(c) > b: about to yy > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > d: > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > b: back from yy > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > program: back from b( d ) failed TEST bill5.pas: SKIPPED: `attribute( section(".ltext") )' not available TEST dario.pas: SKIPPED: only for IA32 TEST fay.pas: 1c1,12 < ./test_run: line 188: 28960 Segmentation fault ./"$A_OUT" "$x" --- > stacking 1 > Doing successors of 1 > stacking 2 > Doing successors of 2 > Now checking if 2 is an SCC root > Now checking if 1 is an SCC root > 1 is an SCC root; SP= 2 T= 1 > Yield SCC should pass 1 out to TakeUSCC > YieldUSCC passes 1 to TakeUSCC > TakeUSCC receives V= 1 from YieldUSCC > The SCC's constituents are: > 2 1 failed TEST fjf165a.pas: SKIPPED: German locale not installed TEST fjf35.pas: ./test_run: line 199: 7712 Segmentation fault ./"$A_OUT" "$x" TEST fjf434a.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST fjf434ax.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST fjf464c.pas: ./test_run: line 199: 13383 Segmentation fault ./"$A_OUT" "$x" TEST fjf464e.pas: ./test_run: line 199: 13441 Segmentation fault ./"$A_OUT" "$x" TEST fjf480a.pas: SKIPPED: librx not installed TEST fjf480b.pas: SKIPPED: librx not installed TEST fjf480c.pas: SKIPPED: librx not installed TEST fjf558m.pas: O./test_run: line 199: 23669 Bus error ./"$A_OUT" "$x" TEST fjf558n.pas: O./test_run: line 199: 23691 Bus error ./"$A_OUT" "$x" TEST fjf56.pas: SKIPPED: only for IA32 TEST fjf582.pas: ./test_run: line 199: 26315 Segmentation fault ./"$A_OUT" "$x" TEST fjf664.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST fjf77.pas: SKIPPED: range of LongReal not sufficient for test TEST fjf92.pas: SKIPPED: only for IA32 TEST fproc.pas: 4c4,11 < ./test_run: line 188: 5375 Segmentation fault ./"$A_OUT" "$x" --- > Stack frame: 0 formal print = 4 formal routine = 4 > Stack frame: 1 formal print = 4 formal routine = 4 > Stack frame: 2 formal print = 4 formal routine = 4 > Stack frame: 3 formal print = 4 formal routine = 4 > Stack frame: 4 formal print = non-local jump > Stack frame: 8 formal print = -1 formal routine = -1 > Stack frame: 9 formal print = -1 formal routine = -1 > Stack frame: 10 formal print = -1 formal routine = -1 failed TEST gettexttest.pas: SKIPPED: libintl not installed TEST gmptest.pas: SKIPPED: libgmp not installed TEST goto4.pas: O./test_run: line 199: 5666 Bus error ./"$A_OUT" "$x" TEST goto5.pas: O./test_run: line 199: 5688 Bus error ./"$A_OUT" "$x" TEST heapmo2.pas: OK ./test_run: line 199: 6054 Bus error ./"$A_OUT" "$x" TEST heapmontest.pas: OK ./test_run: line 199: 6086 Segmentation fault ./"$A_OUT" "$x" TEST jj5.pas: SKIPPED: `attribute (stdcall)' not available TEST knuth1.pas: ./test_run: line 199: 7349 Segmentation fault ./"$A_OUT" "$x" TEST longr2.pas: SKIPPED: no LongReal math routines available TEST math.pas: 2d1 < ./test_run: line 188: 8385 Segmentation fault ./"$A_OUT" "$x" failed TEST nlgpp.pas: ./test_run: line 199: 10696 Segmentation fault ./"$A_OUT" "$x" TEST nlgpp2.pas: 2c2,30 < ./test_run: line 188: 10718 Segmentation fault ./"$A_OUT" "$x" --- > Recursive start 10 True > Recursive start 9 True > Recursive start 8 True > Recursive start 7 True > Recursive start 6 True > Recursive start 5 True > Recursive start 4 True > Recursive start 3 True > Recursive start 2 False > Recursive start 1 False > Recursive start 0 False > DoGoto 3 True > OK > Recursive end 3 True > Recursive before goto 4 True > Recursive end 4 True > Recursive before goto 5 True > Recursive end 5 True > Recursive before goto 6 True > Recursive end 6 True > Recursive before goto 7 True > Recursive end 7 True > Recursive before goto 8 True > Recursive end 8 True > Recursive before goto 9 True > Recursive end 9 True > Recursive before goto 10 True > Recursive end 10 True > Main end failed TEST nonlocgoto.pas: 3c3 < ./test_run: line 188: 10852 Bus error ./"$A_OUT" "$x" --- > it worked failed TEST readb1.pas: ./test_run: line 199: 12272 Segmentation fault ./"$A_OUT" "$x" TEST readb10.pas: ./test_run: line 199: 12299 Segmentation fault ./"$A_OUT" "$x" TEST readb11.pas: ./test_run: line 199: 12326 Segmentation fault ./"$A_OUT" "$x" TEST readb12.pas: ./test_run: line 199: 12353 Segmentation fault ./"$A_OUT" "$x" TEST readb13.pas: ./test_run: line 199: 12380 Segmentation fault ./"$A_OUT" "$x" TEST readb2.pas: ./test_run: line 199: 12482 Segmentation fault ./"$A_OUT" "$x" TEST readb3.pas: ./test_run: line 199: 12509 Segmentation fault ./"$A_OUT" "$x" TEST readb4.pas: ./test_run: line 199: 12536 Segmentation fault ./"$A_OUT" "$x" TEST readb5.pas: ./test_run: line 199: 12563 Segmentation fault ./"$A_OUT" "$x" TEST readb6.pas: ./test_run: line 199: 12590 Segmentation fault ./"$A_OUT" "$x" TEST readb7.pas: ./test_run: line 199: 12617 Segmentation fault ./"$A_OUT" "$x" TEST readb8.pas: ./test_run: line 199: 12644 Segmentation fault ./"$A_OUT" "$x" TEST readb9.pas: ./test_run: line 199: 12671 Segmentation fault ./"$A_OUT" "$x" TEST reade1.pas: ./test_run: line 199: 13098 Segmentation fault ./"$A_OUT" "$x" TEST reade10.pas: ./test_run: line 199: 13125 Segmentation fault ./"$A_OUT" "$x" TEST reade11.pas: ./test_run: line 199: 13153 Segmentation fault ./"$A_OUT" "$x" TEST reade12.pas: ./test_run: line 199: 13181 Segmentation fault ./"$A_OUT" "$x" TEST reade13.pas: ./test_run: line 199: 13208 Segmentation fault ./"$A_OUT" "$x" TEST reade15.pas: ./test_run: line 199: 13260 Segmentation fault ./"$A_OUT" "$x" TEST reade2.pas: ./test_run: line 199: 13312 Segmentation fault ./"$A_OUT" "$x" TEST reade3.pas: ./test_run: line 199: 13339 Segmentation fault ./"$A_OUT" "$x" TEST reade4.pas: ./test_run: line 199: 13366 Segmentation fault ./"$A_OUT" "$x" TEST reade5.pas: ./test_run: line 199: 13393 Segmentation fault ./"$A_OUT" "$x" TEST reade6.pas: ./test_run: line 199: 13420 Segmentation fault ./"$A_OUT" "$x" TEST reade7.pas: ./test_run: line 199: 13447 Segmentation fault ./"$A_OUT" "$x" TEST reade8.pas: ./test_run: line 199: 13474 Segmentation fault ./"$A_OUT" "$x" TEST reade9.pas: ./test_run: line 199: 13501 Segmentation fault ./"$A_OUT" "$x" TEST readg1.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg10.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg11.pas: ./test_run: line 199: 13572 Segmentation fault ./"$A_OUT" "$x" TEST readg12.pas: ./test_run: line 199: 13599 Segmentation fault ./"$A_OUT" "$x" TEST readg13.pas: ./test_run: line 199: 13626 Segmentation fault ./"$A_OUT" "$x" TEST readg15.pas: ./test_run: line 199: 13678 Segmentation fault ./"$A_OUT" "$x" TEST readg2.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg3.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg4.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg5.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg6.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg7.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg8.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST readg9.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed TEST regextest.pas: SKIPPED: librx not installed TEST systemtest.pas: Error in HeapError #2 TEST t6334-2.pas: ./test_run: line 199: 17360 Illegal instruction ./"$A_OUT" "$x" TEST t6p6p3p4.pas: ./test_run: line 199: 17382 Bus error ./"$A_OUT" "$x" TEST trap2test.pas: ./test_run: line 199: 17848 Segmentation fault ./"$A_OUT" "$x" TEST traptest.pas: ./test_run: line 199: 17884 Segmentation fault ./"$A_OUT" "$x" # of GPC tests 2857 # of GPC tests passed 2772 # of GPC tests skipped 18 # of GPC tests failed 67

2 14

Standard question: Exporting of predefined identifiers
by Frank Heckenbach 01 Feb '03

01 Feb '03

Does EP allow a module to export a predefined identifier? The standard makes it clear that it can re-export an identifier imported from another module (e.g., 6.11.6, example 2), but what about predefined things? As in my other mail, I can't seem to find a wording that prohibits it (but I might overlook something). In particular, exporting "magic" routines with renaming would seem quite confusing to me. module m interface; export m = (WriteLn => Foo); end. program p; import m; begin Foo (1 : 2) { Nice!? } end. If this is allowed, the problem in the `System' unit with the redeclaration of `Integer' could be resolved by letting the `GPC' module export `Integer' with renaming, so `System' could use the renamed one on the right side of the redeclaration (`type Integer = OriginalInteger (16);'). But somehow I doubt this is alright ... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 4

SizeOf packed record is different when record placed into packed array [0..0], see source please
by Ingvar Marny 31 Jan '03

31 Jan '03

Hi All. program test; type t1 = packed record item1 : byte; item2: byte; item3: byte; end; t2 = packed array [0..0] of t1; begin writeln ('SizeOf (t1): ', SizeOf (t1)); writeln ('SizeOf (t2): ', SizeOf (t2)); readln; end. Output of program: SizeOf (t1): 3 SizeOf (t2): 4 Could anybody tell me - why? Thanks. software: gpc version 2.1 (20020510), based on 2.95.3 20010315 (release) Linux RedHat 2.5.52

3 2

Standard question: Nested functions with the same name
by Frank Heckenbach 31 Jan '03

31 Jan '03

Consider the following situation: program Foo; function a: Integer; function a: Integer; begin a := 42 end; begin a := a end; begin WriteLn ('OK') end. The problem here is that within the outer `a', the identifier `a' can mean both its result variable and the local function `a'. BP allows the declaration, but not the assignment `a := a' (because apparently interprets `a' to mean the local `a'), so there seems to be no way to return a meaningful value from the outer `a' which would render the function quite useless. In EP I don't seem to find any wording that forbids it (but it's quite confusing as usual, so I might have missed it). GPC currently doesn't allow the declaration of the inner `a'. This seems reasonable to me, but is it conforming with the standard? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 3

Can you make libgpc.a a shared lib?
by Richard D. Jackson 31 Jan '03

31 Jan '03

Is it possible to make libgpc.a a shared lib? If so how do I go about it? If not why not? I didn't find a answer in the doc's so I'm asking here. Thanks Richard

5 24

unsubscribe
by marcov＠stack.nl 30 Jan '03

30 Jan '03

unsubscribe gpc-doc marcov(a)stack.nl

1 0

gpc assembler and make?
by Chihiro Yamada 30 Jan '03

30 Jan '03

Hiya, I've been looking for a Pascal compiler for OS X for a while now, so was very glad to find one here <http://www.microbizz.nl/gpc.html> However, I've been having some problems with installing it. I ran the installer, and applied the fixes, however when we try to run gpc on a test file we get an error: [sven:~] aubrey% gpc test.pas gpc: installation problem, cannot exec `as': No such file or directory So we don't seem to have the assembler. There seems also not to be a linker or "make", both of which I expect we need. Can anyone tell me where we could get hold of these? Lastly, is there anything else not in the package and not standard in OSX itself we need to get? (I have of course installed the Developers tools) Thanks Chihiro ---------------------------------------------------------------------- Chihiro Yamada. FlyBase (Cambridge), http://fly.ebi.ac.uk:7081/ Department of Genetics, University of Cambridge, email: c.yamada(a)gen.cam.ac.uk Downing Street, Tel : 01223-333963 Cambridge, CB2 3EH, FAX : 01223-333992 United Kingdom. Memes don't exist. Spread the Word. ----------------------------------------------------------------------

2 1

None
by Chihiro Yamada 30 Jan '03

30 Jan '03

subscribe gpc cy200(a)gen.cam.ac.uk

1 0

Correction in Documentation
by Muhammad Umer Mansoor 29 Jan '03

29 Jan '03

Hello, When going through the GPC Online manual, I encountered a mistake in section: 7.1.3 Constant Declaration. It is in the following lines: " Furthermore, you can also assign initialization values to types: program InitTypeDemo; type MyInteger = Integer value 42; var i: MyInteger; begin WriteLn (i) end. Here, all variables of type MyInteger are automatically initialized to 0 when created. " The mistakes in the line that says, "Here, all variables of type MyInteger are automatically initialized to 0 when created.", which is not the case. All variables of type MyInteger when created will be initialized to 42, not 0. So, the corrected statement might look like: "Here, all variables of type MyInteger are automatically initialized to 42 when created." Muhammad Umer Mansoor <mansoorm(a)cpsc.ucalgary.ca>

2 1

Re: install gpc
by Frank Heckenbach 29 Jan '03

29 Jan '03

> >Which GCC version? > Gcc version given in GPC site's download tree Which one? There are several ones. > >GPC contains a GCC patch which, among other things, declares these > >two variables. So I suppose it was not applied. Normally, it is > >automatically applied when you run configure (and you get a > >confirmation request). Did you run configure (again) after putting > >in the GPC sources, and did you use with `--enable-languages=pascal' > >option? > I did what is written in install file. > Where is the patch file? The patch file is included with GPC. When you ran `configure --enable-languages=pascal', did you get a message about patching? PS: Your reply was sent to me personally. Please make sure to reply to the list ("group reply"). Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

install gpc
by Mehdi Khaldi 29 Jan '03

29 Jan '03

Hi, I try to install gpc. First of all, I have to build and compile GCC core. My plateform is Alpha with RedHat. When I build (ie : configure + make), an alphaev6-unknown-linux folder is created but no files or other folders in itself. Is it an error? Is it right? Because, after that, I build gpc and an other errors occur : set_word_size undeclared set_words_big_endian undeclared What do I have to do? Thanks

2 1

Re: problems compiling gpc-20021128
by Richard D. Jackson 28 Jan '03

28 Jan '03

On Mon, 2003-01-27 at 15:54, Prof A Olowofoyeku (The African Chief) wrote: <snip> > It is there: > "http://www.gnu-pascal.de/" -> "To the download area" -> > "Contributions" > Even with you pointing it out it took a minute to find it. <snip> > The link is there - but you are not blind. It takes a bit of searching > to find things - and I agree that better navigational guides would be > nice. However, Frank is very busy,and has his hands full with GPC > development - and I am not sure he has the time to do all the things > that are necessary in this respect. > I'm going to move this over to the doc list and see if there is a willingnes to let some else fix that up. As I'm not sure how the web pages are created right now. Richard

2 1

Testing GNU Pascal
by Artur Zaroda 28 Jan '03

28 Jan '03

Hello, All the tests below were on the latest (?) binary release of GNU Pascal for mingw. The result of "gpc -v" is: gpc version 2.1 (20020510), based on 2.95.3-6 (mingw special) I'm interested in standard (ISO) modes, especially ISO 7185, so I have been using the "--classic-pascal" option. I'm only indicating that (in FLAG comments) where I suspect that, what GNU Pascal currently does may be appropriate, when standard compliance is not requested. First, some test programs with non-standard features: program az1(output); (* FLAG --classic-pascal *) const c=2+2; (* WRONG - violation of 6.3 of ISO 7185 *) begin writeln('failed') end. program az2(output); (* FLAG --classic-pascal *) const p=nil; (* WRONG - violation of 6.3 of ISO 7185 *) begin writeln('failed') end. program az3(output); (* FLAG --classic-pascal *) procedure q(x:integer); const xx=x*x; (* WRONG - violation of 6.3 of ISO 7185 *) begin end; begin writeln('failed') end. program az4(output); (* FLAG --classic-pascal *) begin case 4 of 2+2: (* WRONG - violation of 6.8.3.5 of ISO 7185 *) end; writeln('failed') end. program az5(output); (* FLAG --classic-pascal *) var r:record case boolean of false..true:() (* WRONG - violation of 6.8.3.5 of ISO 7185 *) end; begin writeln('failed') end. program az6(output); (* FLAG --extended-pascal *) begin if ord('')=32 then; (* WRONG - violation of 6.7.6.4 of ISO 10206 *) writeln('failed') end. program az7(output); (* FLAG --classic-pascal *) begin if []<[1] then; (* WRONG - violation of 6.7.2.5 of ISO 7185 *) writeln('failed') end. program az8(output); (* FLAG --classic-pascal *) type t=set of char; function f:t; (* WRONG - violation of 6.6.2 of ISO 7185 *) begin f:=[] end; begin writeln('failed') end. program az9(output); (* FLAG --classic-pascal *) type t=record end; var x:t; function f:t; (* WRONG - violation of 6.6.2 of ISO 7185 *) begin f:=x end; begin writeln('failed') end. program az10(output); (* FLAG --classic-pascal *) procedure q(procedure r); begin end; begin q(nil); (* WRONG - violation of 6.6.3.4 of ISO 7185 *) writeln('failed') end. program az11(output); (* FLAG --classic-pascal *) var a:record case b:boolean of true,false:() end; procedure p(var x:boolean); begin end; begin p(a.b); (* WRONG - violation of 6.6.3.3 of ISO 7185 *) writeln('failed') end. program az12(output); (* FLAG --classic-pascal *) procedure q(procedure r); begin r:=r (* WRONG - violation of 6.4.6 of ISO 7185 *) end; begin writeln('failed') end. program az13(output); (* FLAG --classic-pascal *) var t:array [boolean] of integer; begin if t=t then; (* WRONG - violation of 6.7.2.5 of ISO 7185 *) writeln('failed') end. program az14(output); (* FLAG --classic-pascal *) begin if 'ab'='abc' then; (* WRONG - violation of 6.7.2.5 of ISO 7185 *) writeln('failed') end. program az15(output); (* FLAG --classic-pascal *) begin write('failed'); writeln('1':0,'22':0,3:0) (* WRONG - violation of 6.9.3.1 of ISO 7185 *) (* Besides, writing "13" seems inconsistent *) end. program az16(output); (* FLAG --classic-pascal *) var r:record end; begin with (r) do; (* WRONG - violation of 6.8.3.10 of ISO 7185 *) writeln('failed') end. program az17(output); (* FLAG --classic-pascal *) var p:^integer; begin new((p)); (* WRONG - violation of 6.6.5.3 of ISO 7185 *) writeln('failed') end. program az18(output); (* FLAG --classic-pascal *) var a:array [1..1] of integer; begin (a)[1]:=10; (* WRONG - violation 6.5.3.2 of ISO 7185 *) writeln('failed') end. Correct programs, which don't compile: (* az19.pas: In main program: az19.pas:4: division by zero *) program az19(output); begin if false then writeln('failed: ',1/0) else writeln('OK') end. (* az20.pas: In main program: az20.pas:7: warning: ISO Pascal forbids this use of packed array components *) program az20(output); (* FLAG --classic-pascal -Werror *) var t:packed array [1..1,1..1] of boolean; i:integer; begin i:=1; t[1,i]:=false; writeln('OK') end. (* az21.pas: In main program: az21.pas:11: type mismatch in array index az21.pas:11: array subscript is not of ordinal type *) program az21(output); var t:array [1..1] of integer; procedure r(x:integer); begin end; function q:integer; begin q:=1 end; begin r(t[q]); writeln('OK') end. (* az22.pas: In procedure `P': az22.pas:5: function definition does not match previous declaration az22.pas: In function `X': az22.pas:6: undeclared identifier `Y' (first use in this routine) az22.pas:6: (Each undeclared identifier is reported only once az22.pas:6: for each routine it appears in.) az22.pas:7: warning: return value of function not assigned *) program az22(output); function x:integer;forward; procedure p; function x(y:integer):integer; begin x:=y end; begin end; function x; begin x:=1 end; begin writeln('OK') end. (* az23.pas: In main program: az23.pas:3: parse error before `..' az23.pas:5: parse error before `Else' *) program az23(output); begin if []=(..) then writeln('OK') else writeln('failed') end. Incorect programs - should not compile: program az24(output); begin if 1.1 in [] then; (* WRONG - real is not an ordinal type *) writeln('failed') end. program az25(output); var real:real; (* WRONG - can't create new definition and use the old one *) begin writeln('failed') end. program az26(output); begin writeln('failed: ',1:2.3) (* WRONG - field width should be integer *) end. program az27(output); begin writeln('failed: ','xx':true) (* WRONG - field width should be integer *) end. program az28(output); var i:integer; begin for i:=0 to nil do; (* WRONG - type of final value not compatible with integer *) writeln('failed') end. program az29(output); var f:file of file of char; (* WRONG - file type is an illegal component type *) begin writeln('failed') end. program az30(output,output); (* WRONG - program parameters are not distinct *) begin writeln('failed') end. program az31(output); type t=record x:^r(* WRONG *)eal end; begin writeln('failed') end. program az32(output); procedure q;forward; (* WRONG - no definition of procedure q *) begin writeln('failed') end. program az33(output); begin writeln('failed: ',3:2:1) (* WRONG - that form is only applicable to reals *) end. program az34(output); function f:integer; begin f:=1 end; procedure p(function f); (* WRONG - incorrect declaration of functional parameter *) begin end; begin writeln('failed') end. program az35(output); var output:file of real; begin writeln('failed') (* WRONG - output is not of type "text" *) end. Programs demonstrating internal compiler error: (* d:\src\gcc-2.95.3-20010828\gcc\p\gpc-common.c:1390:build_pascal_binary_op: failed assertion `result' az36.pas: In main program: az36.pas:4: Internal compiler error. *) program az36(output); begin if 0 in ([]*[1]) then writeln('failed') else writeln('OK') end. (* az37.pas: In main program: az37.pas:3: ISO Pascal requires an entire `for' variable az37.pas:3: invalid operands to binary <= az37.pas:3: invalid lvalue in assignment az37.pas:3: Internal compiler error in `do_abort', at toplev.c:2301 *) program az37(output); begin for char:=1 to 1 do; (* WRONG *) writeln('failed') end. Programs crashing compiler: program az38(output); begin if 1 in 1 then; (* WRONG *) writeln('failed') end. program az39(output); var s:set of boolean; begin s:=1; (* WRONG *) writeln('failed') end. program az40(output); procedure q(x:integer);forward; procedure q; begin end; function r; (* WRONG *) begin r:=1 end; begin writeln('failed') end. program az41(output); var t:array [(a)] of integer; begin t[char]:=1; (* WRONG *) writeln('failed') end. program az42(output); const s=1; type t=^s; (* WRONG *) begin writeln('failed') end. Finally, programs giving incorrect results: program az43(output); (* FLAG --classic-pascal *) (* The reason, I'm including that option is that there may be some dialect implemented by GNU Pascal, which does not define the order of evaluation for parameters of "write". ISO standards are clear about it *) var a,b,c,d,x:integer; f:text; (* Result is correct if you change that to f:file of integer *) function g(y:integer):integer; begin write(f,x*y); x:=x+2; g:=x+y; end; begin rewrite(f); x:=1; write(f,g(3),g(1)); reset(f); read(f,a,b,c,d); if (a=3) and (b=6) and (c=3) and (d=6) then writeln('OK') else writeln('failed: ',a,b,c,d) end. program az44(output); var x:integer; function f:integer; begin f:=x; x:=2 end; begin x:=1; if [1]=[f] then writeln('OK') else writeln('failed') end. program az45(output); var x:boolean; function f:integer; begin f:=1; x:=true end; begin x:=false; if 1 in [1,f] then if x then writeln('OK') else writeln('failed') end.

4 8

compile pascal
by Mehdi Khaldi 28 Jan '03

28 Jan '03

Hi, I try to compile GPC and I got an error message : "make : *** no rule to make target 'binobj.pas', nedded by binobj' What is the problem? PS: I 've just download GPC without gcc. thanks

3 2

problems compiling gpc-20021128
by Richard D. Jackson 28 Jan '03

28 Jan '03

I'm having some issues in getting gpc compiled following the directions at http://www.gnu-pascal.de/gpc_42.html#SEC42 Here is what I have done and the results I'm getting. 1st attempt used gcc-core-3.2.1.tar.gz & gpc-20021128.tar.gz followed the directions from the above page and everything compiled as expeced. I read the README in the test directory and it indicated to run make in the test dir or make check in the p dir. I did the make check in the p dir. During the test gpc would get Internal compiler errors on every test which meant that all tests failed. NOTE: The this was done prior to runing make install. Here is one of the error messages I got just so you know the exact output. TEST aturbo3test.pas: /home/src/gcc-3.2.1/gcc/p/test/../units/system.pas: In function `Memavail': /home/src/gcc-3.2.1/gcc/p/test/../units/system.pas:827: Internal compiler error in gen_tagged_type_instantiation_die, at dwarf2out.c:11247 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. gpc1: /home/src/gpc-build/gcc/xgpc exited with status 1 gpc1: /home/src/gpc-build/gcc/xgpc exited with status 1 failed After this failed I decided to install the full gpc sources that my distribution uses ( gentoo by the way ). the source used is gpc-3.2.1 with some patches applied: gcc-3.2.1-branch-update-20021208.patch gcc-3.2.1-bug-url.patch gcc32-ada-make.patch gcc32-shared-pthread.patch gcc32-testsuite.patch gcc32-tls-reload-fix.patch (NOTE: I can supply these to any one that wants them. most of them are really small except the branch-update patch wich is about 1M when compressed with bzip2 ) When I ran configure on this one I had one gpc patch fail to apply. It was the bug url patch as the above gentoo patch had changed the url to a gentoo url verses the gnu url so I fixed the gpc patch to reflect the change and got a clean gpc patch. Now on to running make. When Make ran I got this error which I have been unable to track down as from what I can see it looks OK. In file included from /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/p/gpc-common.c:27: /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/p/gpc.h:667: conflicting types for `global_trees' /var/tmp/portage/gcc-3.2.1-r6/work/gcc-3.2.1/gcc/tree.h:1956: previous declaration of `global_trees' make[1]: *** [p/gpc-common.o] Error 1 Line 667 in gpc.h extern tree size_type_node; Line 1956 in tree.h extern tree global_trees[TI_MAX]; tree.h line 1998 #define size_type_node global_trees[TI_SIZE_TYPE] TI_MAX & TI_SIZE_TYPE are part of a enum where TI_MAX is the last item and TI_SIZE_TYPE is last part of the enum. I've greped the sources for gcc and gpc and can't seem to find where tree is defined to see what is going on. If anyone could point me where to look to solve this I would appreciate it. In the mean time I'm going to give another go at doing it from the clean gcc sources. but this time I'm going to get the full sources. Thanks Richard

4 12

Yet, another GPC Installation problem
by Jorge Balseiro López 25 Jan '03

25 Jan '03

Hello again, folks: IÂ´m sorry to be a bit dummy about hits matter, but I really needo to get the gpc compiler working on my computer. IÂ´ve installed the Latest gcc package, as I told you before, to solve the problem of the 'as' compiler lack on my OS. After that, I discovered that I didnÂ´t have the binutils installed correctly, so I did it well this time. OK until here. The problem is that now, when I try to compile my .pas source I get the following error message: " /usr/bin/ld: cannot open crt1.o: No such file or directory collect2: ld returned 1 exit status." Any answer could be of help. Thanks in advance, Jorge Balseiro.

1 0

Found a type-o in programming.texi
by Richard D. Jackson 25 Jan '03

25 Jan '03

Found a minor type-o in the programming section of the manual. attached find a diff to fix it. Richard

2 1

Cross-compiling for Wintel
by Adriaan van Os 25 Jan '03

25 Jan '03

Maybe, some of you have any experience cross-compiling for Wintel. Suppose, I build a cross-compiler (running on Mac OS X) that compiles Windows code for i386. (1) Do I need a cross-linker too ? How does the linker know about Win32 DLLs and LIBs to link with ? (2) Do produced executables run as native Windows GUI programs or DLLs (without a UNIX compatible shell installed) ? (3) Same question for DOS programs. (4) Are there any GPC Pascal interfaces to the Win32 API ? (5) What about cross-debugging with two machines ? Regards, Adriaan van Os

4 3

GPC based on GCC 3.2.1?
by Silvio a Beccara 24 Jan '03

24 Jan '03

Dear all, it seems that GCC 3.2.1 overcomes many of the shortcomings of the previous 3.x releases. Moreover, there are rumours that it should be considerably faster than any previous release. Is it planned to release a version of GPC based on GCC 3.2.1 soon? Is it difficult or lengthy a job? Thanks Silvio a Beccara

2 1

Documentation error
by Richard D. Jackson 24 Jan '03

24 Jan '03

Found this small error in the Programming documentatin. In section 7.1.3 Constant Declaration. Down about halfway on the page you wil find this Furthermore, you can also assign initialization values to types: program InitTypeDemo; type MyInteger = Integer value 42; var i: MyInteger; begin WriteLn (i) end. Here, all variables of type MyInteger are automatically initialized to 0 when created. The variables are initialized to 42 not 0. Attached is a patch to fix this. Richard

3 2

GPC Installation problem
by Jorge Balseiro López 24 Jan '03

24 Jan '03

Dear folks: IÂ´m running a Red Hat Linux 8.0 distribution on a i686-pc-compatible. IÂ´ve downloaded de combined gpc-gcc binary package avaliable at www.gnu-pascal.de. I follow the installation instructions precisely, and everything works well, until I try to compile a source file, where I get the following error: "gpc installation problem. Cannot exec 'as'. No such file or directory" Any ideas? Thanks in advance, Jorge Balseiro.

4 3

gcc: Internal GPC problem: internal option `--amtmpfile' not given
by Adriaan van Os 24 Jan '03

24 Jan '03

I am experimenting a bit with gpc and gcc: [G4:~/gnu/testgpc/demos] adriaan% gcc hello.pas gcc: Internal GPC problem: internal option `--amtmpfile' not given Is this a compiler, configure or install problem ? Or is it a non-feature ? In more detail: [G4:~/gnu/testgpc/demos] adriaan% gcc -v hello.pas Reading specs from /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ specs Configured with: ../gpc-3.2.1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc321d3 Thread model: single gcc version 3.2.1 /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ gpcpp -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__NO_INLINE__ -D__APPLE_CC__=999 -D__DYNAMIC__ hello.pas /var/tmp//ccD97Waf.i GNU Pascal Compiler PreProcessor version 20021128, based on gcc-3.2.1 (Darwin/PowerPC) gcc: Internal GPC problem: internal option `--amtmpfile' not given [G4:~/gnu/testgpc/demos] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ specs Configured with: ../gpc-3.2.1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc321d3 Thread model: single gpc version 20021128, based on gcc-3.2.1 [G4:~/gnu/testgpc/demos] adriaan% gcc -v Reading specs from /Developer/Pascal/gpc321d3/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ specs Configured with: ../gpc-3.2.1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc321d3 Thread model: single gcc version 3.2.1 Regards, Adriaan van Os

2 3

cross-compiling for Wintel
by Adriaan van Os 23 Jan '03

23 Jan '03

Maybe, some of you have any experience cross-compiling for Wintel. Suppose, I build a cross-compiler (running on Mac OS X) that compiles Windows code for i386. (1) Do I need a cross-linker too ? How does the linker know about Win32 DLLs and LIBs to link with ? (2) Does the produced executable run as a native Windows GUI program or DLL (without a UNIX compatible shell installed) ? (3) Same question for DOS programs. (4) Are there any GPC Pascal interfaces to the Win32 API ? (5) What about cross-debugging with two machines ? Regards, Adriaan van Os

1 0

Compilation problem with gpc 20021128
by Martin Liddle 23 Jan '03

23 Jan '03

I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message: ml.p:12: passing arg1 of Sys_stat from incompatible array. The code compiles OK under 20020426 based on gcc 2.95.2. Am I doing something wrong or is this a bug? (Note if the function rmdir line is commented out in ml2 then the program compiles. If the code of ml2 is merged with ml then the code compiles). unit ml2; interface Const CstrSize = 254; type StatRecord = Array[1..20] of Integer; CstrIndex = 1..CstrSize+1; Cstring0 = packed array [CstrIndex] of char; function Cstr(protected S: string): Cstring0; function rmdir(protected Path: Cstring0): integer; C_language; function sys_stat(protected Path: Cstring0; var Buf: StatRecord): integer; asmname 'stat'; implementation function Cstr; var I, U: CstrIndex; Result: Cstring0; begin U := length(S); if U > CstrSize then U := CstrSize; for I := 1 to U do Result[I] := S[I]; Result[U+1] := chr(0); Cstr := Result; end { Cstr }; end. Program ml; uses gpc, { cstrings,} ml2; procedure make_standard_error(progname:Tstring); var retval1:integer; statrec:statrecord; begin retval1:=sys_stat(Cstr(progname+'.err'),statrec); end; Begin Writeln('Starting'); Make_standard_error('ml'); end. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

4 17

Re: Gpc package for `pkgadd' available?
by Rick Roland 23 Jan '03

23 Jan '03

A million tanks! >-----Original Message----- >From: Mariusz Zynel [mailto:mariusz@math.uwb.edu.pl] > >I've just build GPC 2.1 (on top of GCC 2.95.2) on Solaris 8 x86. >The package can be download from: > >ftp://math.uwb.edu.pl/solaris/x86/5.8 > >-- > . >Mariusz Zynel University of Bialystok, Institute of Mathematics > Akademicka 2, 15-267 Bialystok, Poland >----------------------------------------------------------------------- >mailto:mariusz@math.uwb.edu.pl office: +48 (85) 745 7552 >http://math.uwb.edu.pl/~mariusz mobile: +48 (604) 777 588 > > LGT Financial Services Limited Herrengasse 12, P.O. Box 85, FL-9490 VADUZ Principality of Liechtenstein Tel. +423 235 24 44, Fax +423 235 24 40 Mail: lgt.fs(a)lgt.com Web: http://www.lgt.com ---------------------------------------------------------------------- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. -----------------------------------------------------------------------

1 0

Gpc package for `pkgadd' available?
by Roland Rick 22 Jan '03

22 Jan '03

Hallo all Does anyone know, where a Solaris 8 package (for `pkgadd') of the current (is this now 2.1 or 2.95.x? I'm a litte confused by the version numbers) stable gpc version is available? Many thanks for any help! CU, Roland

5 9

gpc-20021128/gcc-3.2.1/mingw32 test results
by J. David Bryan 21 Jan '03

21 Jan '03

Notes from building gpc-20021128 with gcc-3.2.1 configured for i486-pc-mingw32: * GPC will not build with the version of os-hacks.h on the GPC Web site; a patched version is required. * GPC will build with the FSF gcc-3.2.1 sources, but compiled programs that use files will fault in _p_bind (bad pointer). Building with the FSF sources + the Mingw-specific patches from the mingw.org Web site works. * GPC will not run on Win9x/WinME systems, due to a Mingw-specific change in gcc/config/i386/xm-mingw32.h. Patching gpc.c is required. * Test suite results are: agettext2test.pas: SKIPPED: libintl not installed crttest.pas: SKIPPED: no curses library found environo.pas: SKIPPED: setenv not present in libc fjf480a.pas: SKIPPED: librx not installed fjf480b.pas: SKIPPED: librx not installed fjf480c.pas: SKIPPED: librx not installed fjf582.pas: failed [Exception c00000fd (stack overflow)] fjf663.pas: failed [runs forever -- aborted by ulimit] gettexttest.pas: SKIPPED: libintl not installed gmptest.pas: SKIPPED: libgmp not installed pipetest.pas: SKIPPED: IOSelect not yet implemented for mingw regextest.pas: SKIPPED: librx not installed # of GPC tests 2855 # of GPC tests passed 2843 # of GPC tests skipped 10 # of GPC tests failed 2 "fjf582" fails because GPC allocates about 144KB of stack with -O0 and -O1 but allocates about 4.1MB with -O2 and -O3. The default stack reserve set in "ld" is 2MB. Increasing the default manually allows "fsf582" to succeed. Specifically, the generated code is: [with -O0 and -O1] _pascal_main_program: pushl %ebp movl %esp, %ebp movl $147976, %eax call __alloca ... [with -O2 and -O3] _pascal_main_program: pushl %ebp movl $4259848, %eax movl %esp, %ebp call __alloca ... "fjf663" appears to loop indefinitely and is aborted due to time limit. -- Dave

4 18

How to make gpc *.o linkable for native SUN F77 compiler
by Roland Rick 21 Jan '03

21 Jan '03

Hi gpc cracks I have an interesting problem: Original source: Borland Delphi 6 Target source: gpc Because gpc knows a lot about Delphi concepts, this is no problem at all and will be done quite quickly. But: The functions and procedures of the gpc object code (e.g. myFuncs.o, produced by gpc) should be linkable with an VERY OLD native SUN SPARC compiler, the `f77' from SUN's WorkShop 4.2 (a release from 1995). YES, tasks like that really exist! If no one can help, I have to translate the Delphi/gpc source to standard Pascal, what means, working again with include files instead of UNITS (and many more worse things). Remembers me of 1985... ;) (Last but not least this will also be an absolutely boring job to do...) Unfortunately no newer native `pc' from SUN exists. I REALLY would appreciate any help. Cheers, Roland

5 5

Re: Pascal in Mac OS X
by Adriaan van Os 18 Jan '03

18 Jan '03

Sources, binaries, patches and building instructions for GPC on Mac OS X can be found at http://www.microbizz.nl/gpc.html Regards, Adriaan van Os

1 0

can I use C++ units in GPC projects? It tells me "C++ compiler is not installed" although it present in the system
by IM 17 Jan '03

17 Jan '03

Hi All! I need to use C++ units (*.cpp) in my GPC projects. If I use C units (*.c) in my project (just like {$L socketmain.c}) it's ok but if I try to use {$L socketmain.cpp} then Pascal compiler tells me gpc: ./socketmain.cpp: C++ compiler not installed on this system. But it installed. Two things I tried to do: 1. Export environment variables CXX and CPP with "g++" value 2. Change *cpp_options in my gpc specs file. There was no such section before, so I inserted it into from gcc specs file. Now this section looks like: *cpp_options: %{C:%{!E:%eGNU C does not support -C without using -E}} %{std*} %{nostdinc*} %{C} %{v} %{I*} %{P} %{$} %I %{MD:-M -MF %W{!o: %b.d}%W{o*:%.d%*}} %{MMD:-MM -MF %W{!o: %b.d}%W{o*:%.d%*}} %{M} %{MM} %W{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{M|MD|MM|MMD:%{o*:-MQ %*}} %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2 -D__GNUC_PATCHLEVEL__=%v3} %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs} %c %{Os:-D__OPTIMIZE_SIZE__} %{O*:%{!O0:-D__OPTIMIZE__}} %{fno-inline|O0|!O*:-D__NO_INLINE__} %{ffast-math:-D__FAST_MATH__} %{fshort-wchar:-U__WCHAR_TYPE__ -D__WCHAR_TYPE__=short\ unsigned\ int} %{fshow-column} %{fno-show-column} %{fleading-underscore} %{fno-leading-underscore} %{foperator-names} %{fno-operator-names} %{ftabstop=*} %{remap} %{g3:-dD} %{W*} %{w} %{pedantic*} %{H} %{d*} %C %{D*&U*&A*} %{i*} %Z %i %{E:%{!M*:%W{o*}}} But nothing changed. What have I do to compile projects with C++ files? I have not ideas for the present, please give them to me:) Software versions: Linux: RedHat (kernel 2.5.52) gpc: gpc version 2.1 (20020510), based on 2.95.3 20010315 (release) gcc: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) mailto:marny@rambler.ru

5 8

Re: Upper/lower case in identifiers
by Tom Schneider 15 Jan '03

15 Jan '03

Frank: > > ... So if I want to cut and paste to search for the name in > > my program, it fails. > > I didn't like this as well, and that's exactly why I've brought up > the issue. Oh good! > > Why not take the first [occurrence] of a variable as the name to use on > > all output? > > The first, or the most recent one, that's still a question. After > some experimenting, there seem to be points for both ways. I'm > implementing the latter now (though it should be easy to change). > So, e.g.: > > program Baz; > > procedure Foo; > var BaR: Integer; > begin > end; > > begin > WriteLn (bar) > end. > > will complain about an unknown identifier `bar', not `BaR' ... I would strongly vote for using the first occurrence because that is the one which is the definition! If one is disciplined, then all later cases should follow the definition! > > Note: only Germans like to capitalize all nouns! > > I know, and that's not the reason why this rule was introduced (long > ago). Rather it was to avoid asmname conflicts with libc routines > etc. -- see, e.g., Pierre's mail for detailed explanations. Oh. I think that you should either: 1. ignore the conflicts and let the user deal with them. Warn the user that a conflict has occurred. or 2. protect the user from such conflicts so they never have to deal with them. I want to be able to write 'vanilla flavor' Pascal programs that will work on many compilers. I have great hope that GPC is the end-all solution, but even so it is nice to allow my programs to work on other compilers. So I do not want to be forced to change variable names because of conflicts specific to the internal workings of a particular compiler. For example, the fact that I cannot name a procedure 'main' on the Sun compiler is rather obnoxious - I was forced to rename all my 'main' procedures to 'themain', and even have a tool for modifying Pascal programs to make such variable-name switches: http://www.lecb.ncifcrf.gov/~toms/delila/worcha.html ... written in vanilla Pascal of course! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

3 2

Re: Upper/lower case in identifiers
by Tom Schneider 14 Jan '03

14 Jan '03

| I actually think that your existing convention (1st upper, rest | lower) is an excellent way to resolve most things. I am quite sure | I don't have a grasp of the conflicting systematic I also don't understand the conflicts, but this rule is painful. If I name a variable 'something' then I expect to be able to search the error messages for 'something' but of course it got changed to 'Something'. So if I want to cut and paste to search for the name in my program, it fails. Why not take the first occurence of a variable as the name to use on all output? Then internally have a table (as others have suggested) mapping the first occurence to the actual one. Flag variables that map to the same word but which are not the same. This way the compiler merely demands consistency, but is 'case insensitive'. Note: only Germans like to capitalize all nouns! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

4 4

Re: Upper/lower case in identifiers
by Tom Verhoeff 14 Jan '03

14 Jan '03

Frank wrote: >As you probably know, GPC currently converts all identifiers to >first letter upper-case/rest lower-case. Since this is often not >nice, I plan to change this. This would affect at least the >following things: It is not clear to me what change you propose. You probably mean (because this is easiest to implement) to (optionally?) drop the conversion altogether and consequently have case-sensitive identifiers. This is contrary to Pascal standards, but has some advantages in the C/Unix-dominated tool world. Of course, I would NOT recommend program Example1; const MIXEDCASE = True; var MixedCase: Integer; mixedCase: Real; ALTERNATIVELY, it might be possible to convert all occurences of the same identifier (modulo case) to the casing found on the defining occurrence. Thus program Example2; var MixedCase: Integer; ... readln ( mixedCase ) ; writeln ( mixedcase ) would work properly and all external handling would be via the identifier MixedCase. This also seems easy to implement (at the expense of a slightly more expense compare for lookup) and more in line with Pascal: When creating a symbol-table entry you store the casing as found. When looking up a name you compare names modulo case (e.g. convert both comparands to lower case), when you get a hit you use the actual casing found in the symbol table. This makes Example1 illegal and makes Example2 work as expected. >While I'm at it, it might be easy to add a warning if an identifier >is used with varying case (something like `var Foo: Integer; [...] >WriteLn (FOO)'). Such an option would be quite helpful, even if you do not make changes to the case handling. >- Any ideas for the name of the option? (`-Widentifier-case'?) Seems fine. >- Default? (I suppose off, though I think I myself would prefer on.) I would prefer on, because we have come to know that case variations of the same identifier are confusing. >- Should it work across units/modules? Or should it be a tri-state > option (never/current file/global)? Across units/modules would be best, but I can imagine that with legacy code it might be helpful to restrict the scope of the checking. Tom

4 7

Building gpc on Mac OS X.2
by Adriaan van Os 11 Jan '03

11 Jan '03

I have found a much simpler way to build gpc (with gcc-3.2.1) on Mac OS X, than what I did before. A summary is given below. I will put full instructions, together with binaries, on my website, somewhere next week (I hope). Regards, Adriaan van Os --------- The following has been tested on Mac OS X.2.3 out-of-the-box. It might also work on Mac OS X.2 or X.2.2 (but I didn't test). (1) Get the gpc-20021128 and gcc-core-3.2.1 sources (2) Remove the space after "-D" in p/Make-lang.in (Frank Heckenbach) $(CC) -o $@ -c $(ALL_GPC_FLAGS) -DRTS_VERSION_CHECK="\"__GPC_RTS_VERSION_`cat $(RTSSRCDIR)/rts-version`__\"" $< (3) Patch p/parse.y (Frank Heckenbach) Try this (patch may need manual applying, since I've changed some other things in my copy meanwhile). *** p/parse.y.orig Fri Jan 3 09:44:04 2003 --- p/parse.y Fri Jan 3 09:49:25 2003 *************** *** 792,799 **** tree name = get_module_destructor_name (current_module); const char *save_filename = start_dummy_file_name (); context = build_nt (CALL_EXPR, name, no_parameters (), NULL_TREE); ! if (!start_function (chainon (build_tree_list (NULL_TREE, static_id), ! build_tree_list (NULL_TREE, void_type_node)), context, NULL_TREE, 0)) YYERROR1; store_parm_decls (); --- 792,798 ---- tree name = get_module_destructor_name (current_module); const char *save_filename = start_dummy_file_name (); context = build_nt (CALL_EXPR, name, no_parameters (), NULL_TREE); ! if (!start_function (build_tree_list (NULL_TREE, void_type_node), context, NULL_TREE, 0)) YYERROR1; store_parm_decls (); (4) Patch stddef.h (Andreas Tobler). The patch can be found at http://gcc.gnu.org/ml/gcc/2002-08/msg01681.html. --- gcc-04072002/gcc/ginclude/stddef.h Wed Jan 9 13:28:06 2002 +++ gccsrc/gcc/gcc/ginclude/stddef.h Thu Jul 4 18:37:27 2002 @@ -242,6 +242,7 @@ #ifndef _WCHAR_T_ #ifndef _BSD_WCHAR_T_ #ifndef _BSD_WCHAR_T_DEFINED_ /* Darwin */ +#ifndef _BSD_RUNE_T_DEFINED_ /* Darwin */ #ifndef _WCHAR_T_DEFINED_ #ifndef _WCHAR_T_DEFINED #ifndef _WCHAR_T_H @@ -278,6 +279,7 @@ #ifdef _BSD_RUNE_T_ #if !defined (_ANSI_SOURCE) && !defined (_POSIX_SOURCE) typedef _BSD_RUNE_T_ rune_t; +#define _BSD_RUNE_T_DEFINED_ #define _BSD_WCHAR_T_DEFINED_ #if defined (__FreeBSD__) /* Why is this file so hard to maintain properly? In constrast to @@ -295,6 +297,7 @@ #endif #ifndef __cplusplus typedef __WCHAR_TYPE__ wchar_t; +#endif #endif #endif #endif (5) Create a build directory and run configure with the right options (as described in the gpc docs) (6) Now, type "make bootstrap" instead of "make". This will build a gcc-3.2.1 and a gpc-3.2.1 compiler. The first stage of the bootstrap uses the gcc compiler that came with Mac OS X.2.3.

1 0

Dropping gcc-3.1.1
by Frank Heckenbach 11 Jan '03

11 Jan '03

As I wrote some weeks ago, I'd like to drop the gcc-3.1.1 support since 3.2.1 seems to work at least as well (and much better on some systems). Dropping gcc-3.1.1 currently just means removing the diff file, but it makes it easier to maintain whenever there are changes in the diff (and I suppose there'll be some when the debug info problems will be fixed). So, that's your last chance to raise any objections. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

5 6

about gpc
by Mehdi Khaldi 10 Jan '03

10 Jan '03

I have to migrate a pascal application to a 64-bit solaris platform. I'd like to know if GPC generates 64-bit code programs, if GPC runs on a 64-bit solaris platform ? Thank You

1 0

Building gpc on Mac OS X.2
by Adriaan van Os 10 Jan '03

10 Jan '03

I have found a much simpler way to build gpc (with gcc-3.2.1) on Mac OS X, than what I did before. A summary is given below. I will put full instructions, together with binaries, on my website, somewhere next week (I hope). Regards, Adriaan van Os --------- The following has been tested on Mac OS X.2.3 out-of-the-box. It might also work on Mac OS X.2 or X.2.2 (but I didn't test). (1) Get the gpc-20021128 and gcc-core-3.2.1 sources (2) Remove the space after "-D" in p/Make-lang.in (Frank Heckenbach) $(CC) -o $@ -c $(ALL_GPC_FLAGS) -DRTS_VERSION_CHECK="\"__GPC_RTS_VERSION_`cat $(RTSSRCDIR)/rts-version`__\"" $< (3) Patch p/parse.y (Frank Heckenbach) Try this (patch may need manual applying, since I've changed some other things in my copy meanwhile). *** p/parse.y.orig Fri Jan 3 09:44:04 2003 --- p/parse.y Fri Jan 3 09:49:25 2003 *************** *** 792,799 **** tree name = get_module_destructor_name (current_module); const char *save_filename = start_dummy_file_name (); context = build_nt (CALL_EXPR, name, no_parameters (), NULL_TREE); ! if (!start_function (chainon (build_tree_list (NULL_TREE, static_id), ! build_tree_list (NULL_TREE, void_type_node)), context, NULL_TREE, 0)) YYERROR1; store_parm_decls (); --- 792,798 ---- tree name = get_module_destructor_name (current_module); const char *save_filename = start_dummy_file_name (); context = build_nt (CALL_EXPR, name, no_parameters (), NULL_TREE); ! if (!start_function (build_tree_list (NULL_TREE, void_type_node), context, NULL_TREE, 0)) YYERROR1; store_parm_decls (); (4) Patch stddef.h (Andreas Tobler). The patch can be found at http://gcc.gnu.org/ml/gcc/2002-08/msg01681.html. --- gcc-04072002/gcc/ginclude/stddef.h Wed Jan 9 13:28:06 2002 +++ gccsrc/gcc/gcc/ginclude/stddef.h Thu Jul 4 18:37:27 2002 @@ -242,6 +242,7 @@ #ifndef _WCHAR_T_ #ifndef _BSD_WCHAR_T_ #ifndef _BSD_WCHAR_T_DEFINED_ /* Darwin */ +#ifndef _BSD_RUNE_T_DEFINED_ /* Darwin */ #ifndef _WCHAR_T_DEFINED_ #ifndef _WCHAR_T_DEFINED #ifndef _WCHAR_T_H @@ -278,6 +279,7 @@ #ifdef _BSD_RUNE_T_ #if !defined (_ANSI_SOURCE) && !defined (_POSIX_SOURCE) typedef _BSD_RUNE_T_ rune_t; +#define _BSD_RUNE_T_DEFINED_ #define _BSD_WCHAR_T_DEFINED_ #if defined (__FreeBSD__) /* Why is this file so hard to maintain properly? In constrast to @@ -295,6 +297,7 @@ #endif #ifndef __cplusplus typedef __WCHAR_TYPE__ wchar_t; +#endif #endif #endif #endif (5) Create a build directory and run configure with the right options (as described in the gpc docs) (6) Now, type "make bootstrap" instead of "make". This will build a gcc-3.2.1 and a gpc-3.2.1 compiler. The first stage of the bootstrap uses the gcc compiler that came with Mac OS X.2.3.

1 0

Library problem with gpc based on gcc 3.2.1
by Martin Liddle 10 Jan '03

10 Jan '03

As part of my testing of our code compiled with gpc 20021128 based on gcc-3.2.1 I have passed some of the executables to an associate. The code was compiled (and runs) on a system running RedHat Linux 7.3. My associates system is running RedHat 7.2. He reports that attempting to run a program called manager.e fails with the message : manager.e: /lib/libc.so.6:version: "GCC_3.0" not found (required by manager.e) This is obviously a library problem. What do I need to do to fix it? -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

3 2

Re: Pascal in Mac OS X
by Adriaan van Os 10 Jan '03

10 Jan '03

Boris Herman wrote: > Hi > >>> I'm sure this has already been asked here but I can't seem to find >>> an answer in archives or FAQs. So - is there a way of using GPC >>> under Mac OS X? >> I am working on it, with help of Pascal Pignard and support from the >> GPC maintainers. >> I may summarize previous messages. My plans are: >> (1) Try to build GPC on Darwin (Mac OS X) -- done >> (2) Try to build the Hello program -- done >> > That may just as well be enough for me. I have a program that only > does heavy calculations, reads from text files and writes to files and > to console. Where could I get this compiler to try it out? I can put the binaries on my website (somewhere next week, I hope), with these provisions: (1) It is based on an alpha version of the gpc frontend (gpc-20021128) (2) It is based on a standard version of the gcc backend (gcc-3.2.1), so apple specific compiler options are not supported (3) It passes most of the gpc testsuite, but not all (which means there are known problems with the compiler) (4) It can be used with Mac OS 10.2 only (but a build for Mac OS 10.2.3 is planned) (5) It is entirely your risk to use it. Alternatively, you may prefer to build the compiler yourself. Regards, Adriaan van Os

1 0

Pascal in Mac OS X
by Boris Herman 09 Jan '03

09 Jan '03

Hello I'm sure this has already been asked here but I can't seem to find an answer in archives or FAQs. So - is there a way of using GPC under Mac OS X? TIA, Boris

2 1

Rép : The Preprocessor
by Pascal 09 Jan '03

09 Jan '03

Hi Adriaan, I've try many times to port GPC to MAC OS X / Darwin without the succes I wished, before I fall in Ada language, more strict but more functionnal. Nevertheless I've modified 'gpcpp.c' the preprocessor source code in order to accept Mac Pascal directives. If you or any one want it let me know I will put it on my web site. Best , Pascal Pignard. http://perso.wanadoo.fr/blady Best > Frank Heckenbach wrote: > >> I.e., we might choose to implement them for compatibility's sake. >> Then again, how far is GPC compatible to CW in other respects? Is it >> reasonable to claim (or strive for) compatibility at all? > > Well, I don't mind writing different code, where compilers and > platforms are different. I am striving for the possibility to do so > within one conditionalized source code. One might call this the lowest > level of compatibility, the possibilty to write a conditional compiler > expression IFxx ELSExx ENDxx in a way that both compilers understand. > > In CodeWarrior Pascal, you have the choice between "Apple style" and > "BP style" conditional expressions (the latter not strictly BP, but > enhanced with Apple-like features) You can use either, but you can't > mix them in the same project, e.g. > > {$ifc condition} ... {$elsec} ... {$endc} > > or either > > {$if condition} ... {$else} ... {$endif} > > in all sources. > > Most Macintosh programmers traditionally will use "Apple style" > conditional expressions, since they are used in Apple's Pascal > Interfaces to MacOS. I, for one, am lucky to maintain my own Pascal > Interfaces to MacOS, so for me the choice is free. Also, I am free to > make any changes to those Interfaces, needed for GPC. > > To put it in a nutshell, I will be very grateful if GPC supports > > {$if condition} ... {$else} ... {$endif} > > and it would be nice if > > {$ifc condition} ... {$elsec} ... {$endc} > > is supported also. The other items from the CodeWarrior Reference are > non-essential. > > Best regards, > > Adriaan van Os

3 2

Upper/lower case identifiers
by Wood David 09 Jan '03

09 Jan '03

Frank Heckenbach wrote: > As you probably know, GPC currently converts all identifiers to > first letter upper-case/rest lower-case. Since this is often not > nice, I plan to change this.... I support Pierre's concerns that it will affect c function interfaces. For example, I have Pascal code PROCEDURE xflush; EXTERNAL; Knowing that Pascal converts this to Xflush, that is the name of the c function it calls. If you are suggesting type conversion is no longer done, I presume this will remain as xflush and I could rename the c function. Alternatively I could use asmname. I also assume of course the basic case insensitivity of Pascal will still treat multiple declarations will differing case as identical. However, I don't really support compiler changes which force legacy code to be changed, regardless of whether there are new warnings or not. I can live with the change and update the code but it is an irritation to our small community number of code developers. If it goes ahead, the warning name is fine, I think it should default to off and a tristate switch would be preferable. Given that most Pascal built-in's such as ReadLn and WriteLn (or writeln or WRITELN!) are redefinable identifiers, are all these variations going to be flagged up as warnings. I see a long road ahead to get back to squeaky-clean code! Regards David Wood, QinetiQ Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

1 0

(2) gpc: Internal error: Illegal instruction (program gpc1)
by Adriaan van Os 07 Jan '03

07 Jan '03

Below is a report of an internal error in gpc for fjf664.pas. I can send in more information if needed. Regards, Adriaan van Os ---------- Last login: Mon Jan 6 18:20:47 on ttyp1 Welcome to Darwin! [G4:~] adriaan% cd test/testp [G4:~/test/testp] adriaan% gpc -v Reading specs from /usr/local/gpc321d2/lib/gcc-lib/powerpc-apple-darwin6.0/3.2.1/specs Configured with: /Users/adriaan/gpc-3.2.1/configure --enable-languages=pascal --prefix=/usr/local/gpc321d2 Thread model: single gpc version 20021128, based on gcc-3.2.1 [G4:~/test/testp] adriaan% make clean rm -f *.dat *.o *.s *.gpm *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.gpm todo/*.gpi todo/*.gpd todo/core [G4:~/test/testp] adriaan% make MASK="fjf664.pas" Running the GPC Test Suite. This may take a while ... rm -f *.dat *.o *.s *.gpm *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.gpm todo/*.gpi todo/*.gpd todo/core { gpc --version | head -1; gpc --print-search-dirs | grep install | head -1; hostname || echo "unknown host"; } | \ sed -e 's,^,Testing ,;N;s,\n.*gcc-lib[/\], (,;s,[/\].*,),;N;s,\n, (,;s,$,),' Testing gpc 20021128, based on gcc-3.2.1 (powerpc-apple-darwin6.0) (G4.local.) echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "fjf664.pas" | "./test_sum" TEST fjf664.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed awk: null file name in print or getline input record number 8, file source line number 14 make: *** [pascal.check-nomsg] Error 2 ********** Date/Time: 2003-01-06 18:22:39 +0100 OS Version: 10.2 (Build 6C115) Host: G4.local. Command: gpc1 PID: 3654 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7fff0 Thread 0 Crashed: #0 0x000dcacc in reset_used_flags (emit-rtl.c:2639) #1 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #2 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #3 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #4 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #5 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #6 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #7 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #8 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #9 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #10 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #11 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #12 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #13 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #14 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #15 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #16 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #17 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #18 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #19 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #20 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #21 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #22 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #23 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #24 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #25 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #26 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #27 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #28 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #29 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #30 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #31 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #32 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #33 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #34 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #35 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #36 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #37 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #38 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #39 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #40 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #41 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #42 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #43 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #44 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #45 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #46 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #47 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #48 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #49 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #50 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #51 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #52 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #53 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #54 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #55 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #56 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #57 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #58 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #59 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #60 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #61 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #62 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #63 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #64 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #65 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #66 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #67 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #68 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #69 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #70 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #71 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #72 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #73 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #74 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #75 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #76 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #77 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #78 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #79 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #80 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #81 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #82 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #83 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #84 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #85 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #86 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #87 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #88 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #89 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #90 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #91 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #92 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #93 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #94 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #95 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #96 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #97 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #98 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #99 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #100 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #101 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #102 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #103 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #104 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #105 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #106 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #107 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #108 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #109 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #110 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #111 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #112 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #113 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #114 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #115 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #116 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #117 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #118 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #119 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #120 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #121 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #122 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #123 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #124 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #125 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #126 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #127 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #128 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #129 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #130 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #131 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #132 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #133 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #134 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #135 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #136 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #137 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #138 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #139 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #140 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #141 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #142 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #143 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #144 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #145 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #146 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #147 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #148 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #149 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #150 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #151 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #152 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #153 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #154 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #155 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #156 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #157 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #158 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #159 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #160 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #161 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #162 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #163 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #164 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #165 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #166 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #167 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #168 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #169 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #170 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #171 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #172 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #173 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #174 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #175 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #176 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #177 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #178 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #179 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #180 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #181 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #182 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #183 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #184 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #185 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #186 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #187 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #188 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #189 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #190 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #191 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #192 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #193 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #194 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #195 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #196 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #197 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #198 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #199 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #200 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #201 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #202 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #203 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #204 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #205 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #206 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #207 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #208 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #209 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #210 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #211 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #212 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #213 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #214 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #215 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #216 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #217 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #218 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #219 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #220 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #221 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #222 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #223 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #224 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #225 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #226 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #227 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #228 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #229 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #230 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #231 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #232 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #233 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #234 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #235 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #236 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #237 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #238 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #239 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #240 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #241 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #242 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #243 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #244 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #245 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #246 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #247 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #248 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #249 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #250 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #251 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #252 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #253 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #254 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #255 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #256 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #257 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #258 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #259 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #260 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #261 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #262 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #263 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #264 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #265 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #266 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #267 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #268 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #269 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #270 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #271 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #272 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #273 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #274 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #275 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #276 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #277 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #278 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #279 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #280 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #281 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #282 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #283 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #284 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #285 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #286 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #287 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #288 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #289 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #290 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #291 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #292 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #293 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #294 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #295 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #296 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #297 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #298 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #299 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #300 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #301 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #302 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #303 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #304 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #305 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #306 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #307 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #308 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #309 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #310 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #311 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #312 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #313 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #314 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #315 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #316 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #317 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #318 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #319 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #320 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #321 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #322 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #323 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #324 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #325 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #326 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #327 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #328 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #329 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #330 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #331 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #332 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #333 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #334 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #335 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #336 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #337 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #338 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #339 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #340 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #341 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #342 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #343 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #344 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #345 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #346 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #347 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #348 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #349 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #350 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #351 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #352 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #353 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #354 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #355 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #356 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #357 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #358 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #359 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #360 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #361 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #362 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #363 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #364 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #365 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #366 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #367 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #368 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #369 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #370 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #371 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #372 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #373 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #374 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #375 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #376 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #377 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #378 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #379 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #380 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #381 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #382 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #383 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #384 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #385 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #386 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #387 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #388 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #389 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #390 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #391 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #392 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #393 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #394 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #395 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #396 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #397 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #398 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #399 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #400 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #401 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #402 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #403 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #404 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #405 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #406 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #407 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #408 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #409 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #410 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #411 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #412 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #413 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #414 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #415 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #416 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #417 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #418 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #419 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #420 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #421 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #422 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #423 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #424 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #425 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #426 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #427 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #428 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #429 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #430 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #431 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #432 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #433 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #434 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #435 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #436 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #437 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #438 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #439 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #440 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #441 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #442 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #443 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #444 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #445 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #446 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #447 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #448 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #449 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #450 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #451 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #452 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #453 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #454 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #455 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #456 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #457 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #458 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #459 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #460 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #461 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #462 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #463 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #464 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #465 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #466 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #467 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #468 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #469 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #470 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #471 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #472 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #473 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #474 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #475 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #476 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #477 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #478 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #479 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #480 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #481 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #482 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #483 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #484 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #485 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #486 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #487 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #488 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #489 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #490 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #491 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #492 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #493 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #494 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #495 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #496 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #497 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #498 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #499 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #500 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #501 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #502 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #503 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #504 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #505 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #506 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #507 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) #508 0x000dcc24 in reset_used_flags (emit-rtl.c:2687) PPC Thread State: srr0: 0x000dcacc srr1: 0x0000d930 vrsave: 0x00000000 xer: 0x00000000 lr: 0x000dcac0 ctr: 0x000dcba0 mq: 0x00000000 r0: 0x000dcc24 r1: 0xbff80050 r2: 0x0080c010 r3: 0x00c61010 r4: 0x02f910d0 r5: 0x00002dd2 r6: 0x0000002c r7: 0x002ced18 r8: 0x0000004b r9: 0x002cfcb8 r10: 0x0000012c r11: 0x002c6d98 r12: 0x900044a0 r13: 0x002ced18 r14: 0x04de7000 r15: 0x04a42ea0 r16: 0x00000000 r17: 0x00dc61a0 r18: 0x002ced18 r19: 0x002ced18 r20: 0x00000000 r21: 0x002ced18 r22: 0x002ced18 r23: 0x000080a8 r24: 0x0033a790 r25: 0x00000002 r26: 0x00000000 r27: 0x02dee600 r28: 0x00296385 r29: 0x002ca4b8 r30: 0x002cc17c r31: 0x000dcac0

2 2

(1) gpc: Internal error: Illegal instruction (program gpc1)
by Adriaan van Os 06 Jan '03

06 Jan '03

Below is a report of an internal error in gpc for fjf434a.pas. The same problem can be reported for readg1.pas, readg2.pas, readg3.pas, readg4.pas, readg5.pas, readg6.pas, readg7.pas, readg8.pas, readg9.pas and readg10.pas I can send in more information if needed. Regards, Adriaan van Os ---------- Last login: Mon Jan 6 18:00:47 on ttyp1 Welcome to Darwin! [G4:~] adriaan% cd test/testp [G4:~/test/testp] adriaan% gpc -v Reading specs from /usr/local/gpc321d2/lib/gcc-lib/powerpc-apple-darwin6.0/3.2.1/specs Configured with: /Users/adriaan/gpc-3.2.1/configure --enable-languages=pascal --prefix=/usr/local/gpc321d2 Thread model: single gpc version 20021128, based on gcc-3.2.1 [G4:~/test/testp] adriaan% make clean rm -f *.dat *.o *.s *.gpm *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.gpm todo/*.gpi todo/*.gpd todo/core [G4:~/test/testp] adriaan% make MASK="fjf434a.pas" Running the GPC Test Suite. This may take a while ... rm -f *.dat *.o *.s *.gpm *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.gpm todo/*.gpi todo/*.gpd todo/core { gpc --version | head -1; gpc --print-search-dirs | grep install | head -1; hostname || echo "unknown host"; } | \ sed -e 's,^,Testing ,;N;s,\n.*gcc-lib[/\], (,;s,[/\].*,),;N;s,\n, (,;s,$,),' Testing gpc 20021128, based on gcc-3.2.1 (powerpc-apple-darwin6.0) (G4.local.) echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "fjf434a.pas" | "./test_sum" TEST fjf434a.pas: gpc: Internal error: Illegal instruction (program gpc1) Please submit a full bug report to <gpc(a)gnu.de>. failed awk: null file name in print or getline input record number 8, file source line number 14 make: *** [pascal.check-nomsg] Error 2 ********** Date/Time: 2003-01-06 18:03:26 +0100 OS Version: 10.2 (Build 6C115) Host: G4.local. Command: gpc1 PID: 2955 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffd0 Thread 0 Crashed: #0 0x000cb4c8 in ggc_mark_rtx_children_1 (ggc-common.c:317) #1 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #2 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #3 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #4 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #5 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #6 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #7 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #8 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #9 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #10 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #11 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #12 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #13 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #14 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #15 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #16 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #17 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #18 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #19 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #20 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #21 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #22 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #23 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #24 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #25 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #26 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #27 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #28 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #29 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #30 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #31 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #32 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #33 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #34 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #35 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #36 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #37 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #38 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #39 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #40 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #41 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #42 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #43 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #44 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #45 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #46 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #47 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #48 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #49 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #50 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #51 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #52 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #53 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #54 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #55 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #56 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #57 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #58 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #59 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #60 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #61 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #62 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #63 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #64 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #65 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #66 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #67 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #68 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #69 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #70 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #71 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #72 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #73 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #74 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #75 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #76 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #77 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #78 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #79 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #80 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #81 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #82 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #83 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #84 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #85 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #86 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #87 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #88 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #89 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #90 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #91 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #92 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #93 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #94 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #95 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #96 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #97 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #98 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #99 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #100 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #101 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #102 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #103 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #104 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #105 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #106 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #107 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #108 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #109 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #110 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #111 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #112 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #113 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #114 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #115 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #116 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #117 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #118 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #119 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #120 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #121 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #122 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #123 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #124 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #125 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #126 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #127 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #128 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #129 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #130 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #131 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #132 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #133 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #134 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #135 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #136 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #137 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #138 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #139 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #140 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #141 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #142 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #143 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #144 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #145 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #146 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #147 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #148 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #149 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #150 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #151 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #152 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #153 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #154 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #155 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #156 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #157 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #158 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #159 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #160 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #161 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #162 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #163 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #164 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #165 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #166 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #167 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #168 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #169 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #170 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #171 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #172 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #173 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #174 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #175 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #176 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #177 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #178 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #179 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #180 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #181 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #182 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #183 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #184 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #185 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #186 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #187 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #188 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #189 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #190 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #191 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #192 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #193 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #194 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #195 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #196 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #197 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #198 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #199 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #200 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #201 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #202 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #203 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #204 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #205 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #206 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #207 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #208 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #209 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #210 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #211 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #212 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #213 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #214 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #215 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #216 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #217 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #218 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #219 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #220 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #221 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #222 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #223 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #224 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #225 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #226 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #227 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #228 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #229 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #230 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #231 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #232 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #233 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #234 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #235 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #236 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #237 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #238 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #239 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #240 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #241 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #242 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #243 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #244 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #245 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #246 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #247 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #248 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #249 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #250 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #251 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #252 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #253 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #254 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #255 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #256 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #257 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #258 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #259 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #260 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #261 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #262 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #263 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #264 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #265 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #266 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #267 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #268 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #269 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #270 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #271 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #272 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #273 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #274 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #275 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #276 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #277 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #278 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #279 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #280 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #281 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #282 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #283 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #284 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #285 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #286 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #287 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #288 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #289 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #290 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #291 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #292 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #293 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #294 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #295 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #296 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #297 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #298 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #299 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #300 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #301 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #302 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #303 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #304 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #305 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #306 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #307 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #308 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #309 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #310 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #311 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #312 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #313 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #314 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #315 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #316 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #317 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #318 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #319 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #320 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #321 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #322 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #323 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #324 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #325 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #326 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #327 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #328 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #329 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #330 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #331 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #332 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #333 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #334 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #335 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #336 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #337 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #338 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #339 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #340 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #341 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #342 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #343 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #344 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #345 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #346 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #347 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #348 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #349 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #350 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #351 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #352 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #353 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #354 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #355 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #356 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #357 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #358 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #359 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #360 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #361 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #362 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #363 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #364 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #365 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #366 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #367 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #368 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #369 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #370 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #371 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #372 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #373 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #374 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #375 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #376 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #377 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #378 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #379 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #380 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #381 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #382 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #383 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #384 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #385 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #386 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #387 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #388 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #389 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #390 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #391 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #392 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #393 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #394 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #395 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #396 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #397 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #398 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #399 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #400 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #401 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #402 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #403 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #404 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #405 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #406 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #407 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #408 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #409 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #410 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #411 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #412 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #413 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #414 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #415 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #416 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #417 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #418 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #419 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #420 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #421 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #422 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #423 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #424 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #425 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #426 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #427 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #428 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #429 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #430 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #431 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #432 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #433 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #434 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #435 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #436 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #437 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #438 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #439 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #440 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #441 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #442 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #443 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #444 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #445 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #446 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #447 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #448 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #449 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #450 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #451 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #452 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #453 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #454 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #455 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #456 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #457 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #458 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #459 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #460 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #461 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #462 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #463 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #464 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #465 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #466 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #467 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #468 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #469 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #470 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #471 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #472 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #473 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #474 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #475 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #476 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #477 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #478 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #479 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #480 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #481 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #482 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #483 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #484 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #485 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #486 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #487 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #488 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #489 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #490 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #491 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #492 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #493 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #494 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #495 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #496 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #497 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #498 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #499 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #500 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #501 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #502 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #503 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #504 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #505 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #506 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) #507 0x000cb494 in ggc_mark_rtx_children (ggc-common.c:311) #508 0x000cb698 in ggc_mark_rtx_children_1 (ggc-common.c:396) PPC Thread State: srr0: 0x000cb4c8 srr1: 0x0000d930 vrsave: 0x00000000 xer: 0x20000000 lr: 0x000cb4b4 ctr: 0x000cb5b8 mq: 0x00000000 r0: 0x000cb494 r1: 0xbff80030 r2: 0x28000248 r3: 0x01448f30 r4: 0x00001000 r5: 0x00000000 r6: 0x00000000 r7: 0x00080000 r8: 0x012eb900 r9: 0xffffffe4 r10: 0x002e6558 r11: 0x012eb91c r12: 0x44044282 r13: 0x002c9070 r14: 0x002c9070 r15: 0x0033a770 r16: 0x002c9070 r17: 0x002c9070 r18: 0x002cdc6c r19: 0x002edc6c r20: 0x00000001 r21: 0x002e65e0 r22: 0x002e64d0 r23: 0x00000022 r24: 0x002cb4b4 r25: 0x002eb4b4 r26: 0x010a7220 r27: 0x01448f30 r28: 0x01448f30 r29: 0x01448f30 r30: 0x01448f48 r31: 0x000cb4b4

1 0

Rép : The Preprocessor
by Pascal 05 Jan '03

05 Jan '03

Hello Adriaan, I put my modified version of gpcpp.c on line on my web site - as promised: http://perso.wanadoo.fr/blady/creations.html#gpcpp Sorry for the French texts. Tell me if it helps you. As you know I am a fervent supporter of Pascal Language, and I will modestly support your work to port GPC on Mac OS X as it is a lack. However some great works has been done for about more than one year about Ada language on Mac OS X see in the text. I stop my work on GPC port as I fall in two problems: 1) the compiler refuse in some cases the last pass "Unable to generate reloads...", 2) the linker fails, I was told that Apple dynamic link processing is very different than Linux does that is for GNU GCC too. (see my web site http://perso.wanadoo.fr/blady/creations.html#portagegpc) Sorry for the French texts, a translator link may be found at home page. I think both problems are linked about dynamic adresses management. And as Apple or FSF (as you want) won't meet the same process it should be impossible. But it was before revison gcc 3, maybe now... If you have some contacts in Apple staff, you can ask them for that. Greetings for 2003, Pascal Pignard. http://perso.wanadoo.fr/blady > Being an optimist, I am currently trying to build GPC for Darwin (Mac > OS X) myself. I welcome the gpcpp.c changes. > > > Frank Heckenbach wrote: > > I.e., we might choose to implement them for compatibility's sake. > Then again, how far is GPC compatible to CW in other respects? Is it > reasonable to claim (or strive for) compatibility at all? > > > I will be pleased to discuss CodeWarrior Pascal, it's EBNF is at the > bottom of this message. My goals however, are rather pragmatic (unless > somebody else has more ambitious plans). > > (1) Try to build GPC on Darwin (Mac OS X) Done for Ada with gnat-osx > (2) Try to build the Hello program Done for Ada with gnat-osx > (3) Try to build a sample GUI program (for Mac OS X "Carbon") Done for Ada with gnat-osx > (4) Try to integrate GPC with Apple's "Project Builder" Done for Ada with gnat-osx > (4) Try to port a large (300.000 lines) program to GPC Done for Ada with gnat-osx > (5) Write a compatibilty-report for porting from CodeWarrior Pascal to > GPC Done for Ada with P2Ada > (6) Same for maintaining a common (conditionalized) source code for > CodeWarrior Pascal and GPC > (7) Filter out a handful of compiler features that would really assist > GPC development on Mac OS X (and porting from CodeWarrior). On this > list wil be UNIV parameters, I guess, but this is premature. > (8) Either talk to Nick Kledzik (who maintains Apple's Pascal > Interfaces) or maintain our own GPC Interfaces for Mac OS X > (9) Setup a GPC compatibility website for Mac OS X Done for Ada with gnat-osx > > I am willing to spend time on this all, except for working in C on the > compiler itself. Any help is welcome. > > Best regards, > > Adriaan van Os >

2 1

Building GPC with GCC-3.2.1 on Darwin
by Adriaan van Os 05 Jan '03

05 Jan '03

Here is a first report of my attempt to build GPC-20021128 with the GCC-3.2.1 backend on Mac OS X "Darwin". The GPC build is on a 1.1 GB 450 MHz PowerMac G4 running Mac OS X 10.2. Note: I am also trying to build GPC with an Apple-patched GCC backend (named "GCC3-1151"), but I will report about that separately. P r o b l e m 1 During Configure, conftest crashes, but the Configure process happily continues. This is not a GPC problem. The crash also appears if I try to build GCC-3.2.1 (without GPC). ********** Date/Time: 2002-12-24 14:40:01 +0100 OS Version: 10.2 (Build 6C115) Host: G4.local. Command: conftest PID: 3948 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x00088000 Thread 0 Crashed: #0 0x000026d4 in test_1 (configure:127) #1 0x00002a9c in main (configure:237) #2 0x00002298 in _start (crt.c:267) #3 0x00002118 in start PPC Thread State: srr0: 0x000026d4 srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x00000000 lr: 0x000026b8 ctr: 0x90015040 mq: 0x00000000 r0: 0x00000001 r1: 0xbffffb40 r2: 0x84000482 r3: 0x000025e0 r4: 0x00000000 r5: 0x00000000 r6: 0x90015040 r7: 0x00000000 r8: 0x00000000 r9: 0x00001000 r10: 0x00087000 r11: 0xa0004254 r12: 0x90015040 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0xbffffd70 r27: 0x00000008 r28: 0x00000001 r29: 0x000033a8 r30: 0xbffffd74 r31: 0x000025e0 P r o b l e m 2 The file "builtin-attrs.def" causes problems. This is not a GPC problem either: same problems if I try to build GCC (without GPC). Being a C ignoramus, I simply commented away the offending lines (in order to at least continue the build process). In file included from /Users/adriaan/gpcx/gcc/c-common.c:4110: /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:95: redefinition of `ATTR_PRINTF_1' /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: `ATTR_PRINTF_1' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:95: redefinition of `ATTR_FORMAT_PRINTF_1' /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: `ATTR_FORMAT_PRINTF_1' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:97: redefinition of `ATTR_PRINTF_2' /Users/adriaan/gpcx/gcc/builtin-attrs.def:96: `ATTR_PRINTF_2' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:97: redefinition of `ATTR_FORMAT_PRINTF_2' /Users/adriaan/gpcx/gcc/builtin-attrs.def:96: `ATTR_FORMAT_PRINTF_2' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:99: redefinition of `ATTR_PRINTF_3' /Users/adriaan/gpcx/gcc/builtin-attrs.def:98: `ATTR_PRINTF_3' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:99: redefinition of `ATTR_FORMAT_PRINTF_3' /Users/adriaan/gpcx/gcc/builtin-attrs.def:98: `ATTR_FORMAT_PRINTF_3' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:101: redefinition of `ATTR_SCANF_1' /Users/adriaan/gpcx/gcc/builtin-attrs.def:100: `ATTR_SCANF_1' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:101: redefinition of `ATTR_FORMAT_SCANF_1' /Users/adriaan/gpcx/gcc/builtin-attrs.def:100: `ATTR_FORMAT_SCANF_1' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:103: redefinition of `ATTR_SCANF_2' /Users/adriaan/gpcx/gcc/builtin-attrs.def:102: `ATTR_SCANF_2' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:103: redefinition of `ATTR_FORMAT_SCANF_2' /Users/adriaan/gpcx/gcc/builtin-attrs.def:102: `ATTR_FORMAT_SCANF_2' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:170:3: warning: style of line directive is a GCC extension /Users/adriaan/gpcx/gcc/c-common.c:4225:3: warning: style of line directive is a GCC extension In file included from /Users/adriaan/gpcx/gcc/c-common.c:4225: /Users/adriaan/gpcx/gcc/builtin-attrs.def:2:3: warning: style of line directive is a GCC extension In file included from /Users/adriaan/gpcx/gcc/c-common.c:4225: /Users/adriaan/gpcx/gcc/builtin-attrs.def: In function `c_init_attributes': /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:95: parse error before "_2" /Users/adriaan/gpcx/gcc/builtin-attrs.def:95: parse error before "_2" /Users/adriaan/gpcx/gcc/builtin-attrs.def:96: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:96: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:97: parse error before "_3" /Users/adriaan/gpcx/gcc/builtin-attrs.def:97: parse error before "_3" /Users/adriaan/gpcx/gcc/builtin-attrs.def:98: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:98: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:99: parse error before "_4" /Users/adriaan/gpcx/gcc/builtin-attrs.def:99: parse error before "_4" /Users/adriaan/gpcx/gcc/builtin-attrs.def:100: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:100: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:101: parse error before "_2" /Users/adriaan/gpcx/gcc/builtin-attrs.def:101: parse error before "_2" /Users/adriaan/gpcx/gcc/builtin-attrs.def:102: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:102: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:103: parse error before "_3" /Users/adriaan/gpcx/gcc/builtin-attrs.def:103: parse error before "_3" /Users/adriaan/gpcx/gcc/builtin-attrs.def:104: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:104: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:105: parse error before "_4" /Users/adriaan/gpcx/gcc/builtin-attrs.def:105: parse error before "_4" /Users/adriaan/gpcx/gcc/builtin-attrs.def:170:3: warning: style of line directive is a GCC extension /Users/adriaan/gpcx/gcc/c-common.c:4254:3: warning: style of line directive is a GCC extension In file included from /Users/adriaan/gpcx/gcc/c-common.c:4254: /Users/adriaan/gpcx/gcc/builtin-attrs.def:2:3: warning: style of line directive is a GCC extension In file included from /Users/adriaan/gpcx/gcc/c-common.c:4254: /Users/adriaan/gpcx/gcc/builtin-attrs.def: In function `c_common_insert_default_attributes': /Users/adriaan/gpcx/gcc/builtin-attrs.def:126: `ATTR_FORMAT_PRINTF_1_2' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:126: (Each undeclared identifier is reported only once /Users/adriaan/gpcx/gcc/builtin-attrs.def:126: for each function it appears in.) /Users/adriaan/gpcx/gcc/builtin-attrs.def:127: `ATTR_FORMAT_PRINTF_2_3' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:136: `ATTR_FORMAT_SCANF_1_2' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:137: `ATTR_FORMAT_SCANF_2_3' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:139: `ATTR_FORMAT_PRINTF_1_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:140: `ATTR_FORMAT_PRINTF_2_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:142: `ATTR_FORMAT_STRFTIME_3_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:150: `ATTR_FORMAT_PRINTF_3_4' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:151: `ATTR_FORMAT_PRINTF_3_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:152: `ATTR_FORMAT_SCANF_1_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:153: `ATTR_FORMAT_SCANF_2_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:166: `ATTR_FORMAT_STRFMON_3_4' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:170:3: warning: style of line directive is a GCC extension make[1]: *** [c-common.o] Error 1 make: *** [all-gcc] Error 2 P r o b l e m 3 A stament in the file stmt.c" causes problems. /Users/adriaan/gpcx/gcc/stmt.c:5170:21: attempt to use poisoned "calloc" The C source reads: if (size > 0 && size < 600000 /* We deliberately use calloc here, not cmalloc, so that we can suppress this optimization if we don't have enough memory rather than aborting, as xmalloc would do. */ && (cases_seen = (unsigned char *) really_call_calloc (bytes_needed, 1)) != NULL) Being a C ignoramus, I changed "really_call_calloc" into "xcalloc" (to at least continue the build process). P r o b l e m 4 The next problem seems to be GPC related. I guess that the GPC experts will be able to help here. The build process ends with the statement: cpp-precomp: could not open 'RTS_VERSION_CHECK="__GPC_RTS_VERSION_20021128__"' gcc -o p/util.o -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -I. -Ip -I/Users/adriaan/gpcx/gcc -I/Users/adriaan/gpcx/gcc/p -I/Users/adriaan/gpcx/gcc/config -I/Users/adriaan/gpcx/gcc/../include -DGPC -I/Users/adriaan/gpcx/gcc/p -D RTS_VERSION_CHECK="\"__GPC_RTS_VERSION_`cat /Users/adriaan/gpcx/gcc/p/rts/rts-version`__\"" /Users/adriaan/gpcx/gcc/p/util.c cpp-precomp: could not open 'RTS_VERSION_CHECK="__GPC_RTS_VERSION_20021128__"' make[1]: *** [p/util.o] Error 1 make: *** [all-gcc] Error 2 I can send in more information, make and configure files, etcetera. Regards, Adriaan van Os

2 8

"Common" variables?
by Silvio a Beccara 02 Jan '03

02 Jan '03

Hi all, maybe it's a dumb question, but I can't figure out the answer by looking in the archive. I have a main program which defines and initialises some variables (double, integer, string, arrays). It uses a series of units. I want the units to share the same, initialised variables. For instance, if the variable "rho" is set to 0.01 in the main program, the unit "force" must have the same 0.01 value for the variable "rho". Thanks to all, best regards Silvio a Beccara

2 1

[beebe@math.utah.edu: Re: Typos in gpc-20021111/p/doc/en/*.texi]
by Anja Gerwinski 31 Dec '02

31 Dec '02

Hello, this is one of the non-spam postings that got delayed. As I am not sure who is taking care of the .texi documentation, I am forwarding it to the list. Best wishes, Anja ----- Forwarded message from "Nelson H. F. Beebe" <beebe(a)math.utah.edu> ----- Date: Fri, 27 Dec 2002 09:54:18 -0700 (MST) From: "Nelson H. F. Beebe" <beebe(a)math.utah.edu> To: Anja Gerwinski <anja(a)44615166.theo-phys.uni-essen.de> Cc: beebe(a)math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Typos in gpc-20021111/p/doc/en/*.texi Thanks for the reponse about my postings to the GNU Pascal list. They report minor typos in the manuals. Copies are attached below: they probably only need to go to a single person who can make the corrections and update the archive; the whole gpc list need not be bothered with them. --------------- 1) 19-Dec "Nelson H. F Typos in gpc-20021111/p/doc/en/* (3401 chars) 2) 19-Dec "Nelson H. F Another typo: gpc-20021111/p/doc (1676 chars) Date: Thu, 19 Dec 2002 07:22:47 -0700 (MST) From: "Nelson H. F. Beebe" <beebe(a)math.utah.edu> To: gpc(a)gnu.de Cc: beebe(a)math.utah.edu Subject: Typos in gpc-20021111/p/doc/en/*.texi While browsing the info node for gpc from the gpc-20021111 release, I noted some typos (spelling and doubled words) in p/doc/en: unsing -> unsign orientate -> orient % egrep -n 'unsing|orientate' `find en -type f` internals.texi:385:object-orientated programming languages yet, a lot of effort has programming.texi:33:* OOP:: How object-orientated programming is implemented. programming.texi:1464:@item @t{MedInt} @tab @t{MedCard} @tab @t{MedWord} @tab @t{[unsinged] long int} @tab @t{32} programming.texi:1465:@item @t{LongInt} @tab @t{LongCard} @tab @t{LongWord} @tab @t{[unsinged] long long int} @tab @t{64} programming.texi:1489:and unsinged integer types. The type programming.texi:3287:@cindex object-orientated programming reference.texi:6860:ISO Pascal does not support Object-orientated programming. There Doubled words errors: gpcs.texi:1861: WriteLn ('Is is a spider?') ^^---should be "it" install.texi:357:To install a ZIP archive under DOS with @samp{PKunzip}, @samp{cd} the install.texi:358:the appropriate directory (usually @samp{\} for EMX, @samp{\DJGPP} for ^^^^---- delete this word reference.texi:2765:omitted, the sub-string will will range to the end of @var{S}. ^^^^----delete reference.texi:3764:@samp{Extend} is an ISO 10206 Extended extension. Borland Pascal reference.texi:3765:Pascal has @ref{Append} instead. ^^^^^^^----delete reference.texi:9598:@samp{Word}. On most platforms it is 16 bits wide and thus has a range of reference.texi:9599:of @samp{0..65535}. It is the same as @ref{ShortCard}. ^^^----delete reference.texi:10299:omitted, the sub-string will will range to the end of @var{S}. ^^^^----delete Date: Thu, 19 Dec 2002 12:14:11 -0700 (MST) From: "Nelson H. F. Beebe" <beebe(a)math.utah.edu> To: gpc(a)gnu.de Cc: beebe(a)math.utah.edu Subject: Another typo: gpc-20021111/p/doc/en/gpcs.texi In gpc-20021111/p/doc/en/gpcs.texi: gpcs.texi:191:The are times when you deal with large packages and you can't easily ^^^^---- Should be "There" ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe(a)math.utah.edu - - Department of Mathematics, 110 LCB beebe(a)acm.org beebe(a)computer.org - - 155 S 1400 E RM 233 beebe(a)ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- ----- End forwarded message -----

2 1

Questions about gpc syntax
by Artur Bac 29 Dec '02

29 Dec '02

Hello I've got few questions because I'm working on some C library port to GNU GPC. On the assumption that best reasult will be maintained if 1) There will not be any unit file but only original include files with orignal tree structure {$ifndef __NAME__} {$define __NAME__} {$include <sothing.inc>} works perfectly with GPC and also -llibname -L/usr/lib/.... -I/usr/include...... too 2) all macro definitions will be converted to macro definitions NOT to wrpaer functions to avoid not neccesery function jumps in generated code 3) all inlines, functions implemented in interface of headers will be keeped as they are without any new function wrappers all this as mentioned before i did but i found one thing strange for me Why this don't work : we've got an pointer array inside a redord field type ppointer = ^pointer; type our_rec = packed record ptr_data : ppointer; end; var some_array : ^our_rec; needed_pointer : pointer; imagine we got an array of pointers and some_array^.ptr_data points at this array when i try to acces elements in that way as it is in C ,freepascal needed_pointer := some_array^.ptr_data[2]^ {3rd element , pointer in array} i got an error something like '...trying to acces an array on somthing is not an array ...' BUT this works needed_pointer := (some_array^.ptr_data+2)^ In GPC manual http://www.gnu-pascal.de/gpc_120.html#SEC120 there is written GPC allows to increment, decrement, compare, and subtract pointers or to use them in `for' loops just like the C language. a: array [1 .. 7] of Char; p, q: ^Char; .......... for p := @A[1] Isn't nearly the same as my example ? Maybe this is a problem of latest snapshot of gpc i use with GCC 3.2.1 ? 20021128, based on gcc-3.2.1 Second problem I got in C function like that with variable number of arguments type name (arg,arg, ....) so i implemented it as function name (arg;arg; var add_arg_) : type But i can pass only one aditional argument Is possible to implement variable number of arguments for functions ? Or maybe i have to overload it with 2 or more similar functions ? but the way is function overloading allowed in GNU Gpc ? 3rd Question any ideas how to implement C++ library with classes inside ? PS: GPC is going to be the best Objective Pascal compiler .... Sincerelly Artur Bać

2 3

problems installing gnu pascal
by Frank Thomas Braun 27 Dec '02

27 Dec '02

I am using the PC version (DJGPP, MingWin) of the gcc (MS-DOS, Windows 95/NT/XP) for several years in lectures and for programming purposes. Never I found any severe problem or error. Formerly I wrote many Pascal programs and I would like to install a version of the GPC compiler to be able to recompile these program for Win32. I never was successful to complete this installation. After the recent installation of gcc 3.20 I found a new copy of gpc on the Simtel mirrors and tried another gpc installation. Download and unzipping of gpc together with gcc/djgpp (version gpc2953b.zip, 13.5.2002) produced a startable installation of gpc (the gpc command is working when either typing "gpc" alone or "gpc --verbose"), but I am not able to compile any program. ( "gpc lix.pas" results in the error message "gpcpp.exe: djgpp.ver: No such file or directory (ENOENT)", see attachment x.x or more verbose x.a) ). In a second try I fetched gpc directly from the site http://www.gnu-pascal.de/ in the file gpc-2.1.i586-pc-msdosdjgpp.zip. Installing this file together with the necessary gcc tools results in the same problem as above. (see attachment x.y and inst-p.bat) What is the reason of the error message gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) By the way I didn't succeed to install gpc with MingWin too. Compiling programs with "gpc lix.pas" results in "ld: cannot open crt2.o: No such file or directory" Could you please kindly help me solving the problem? Yours sincerely Frank Braun PS: Yes I read readme, news, install, faq, and bugs. Yes I wrote a similar gpc section like the gcc section in djgpp.env: ( [gpc] COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bin LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib;%DJDIR%/contrib/grx20/ lib ) res. ( [gcc] LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib [gpc] LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib ) Yes I tried getting the right files but the files mentioned in the documentation are sometimes no longer available. In these cases I used the next higher version or alternativly the newest version. i.e.: http://www.gnu-pascal.de/gpc_20.html says `v2/djdev203.zip' (C library) `v2gnu/bnu2951b.zip' (assembler, ...) `v2gnu/gcc2952b.zip' (gcc) `v2gnu/gdb418b.zip' (debugger) `v2gnu/mak379b.zip' (make) `v2gnu/txi40b.zip' The file install. says: - the C library, `v2/djdev201.zip', and - `binutils' (assembler, etc.), `v2gnu/bnu270b.zip'. I tried both djdev201/203. bnu2951b/270b is not available so I used bnu213b Frank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany Tel.: +49-941-943-4891 email: frank.braun(a)rz.uni-regensburg.de d:\PRIVAT\BILANZ\PROGRAM>gpc -v x.pas Using builtin specs. gpc version 2.1 (20020510), based on 2.95.3 20010315/djgpp (release) d:/djgpp/lib/gcc-lib/djgpp/2.953/gpcpp.exe -lang-pascal -v -famtmpfile=d:/djgpp /tmp\ccaaaaaa -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MI NOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__=2.1 -D__GPC_RELEASE__=2 0020510 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__ OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS __=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(ms dos) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D_ _i386__ -D__tune_pentium__ -imacros djgpp.ver -remap x.pas d:/djgpp/tmp\cc6uaS61 .i GNU Pascal Compiler PreProcessor version 2.1 (20020510), based on gcc-2.95.3 200 10315/djgpp (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: d:/djgpp/lang/pascal d:/djgpp/include /usr/local/include d:/djgpp/i586-pc-msdosdjgpp/include d:/djgpp/lib/gcc-lib/djgpp/2.953/include d:/djgpp/include End of search list. gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) d:\PRIVAT\BILANZ\PROGRAM>gpc GNU Pascal version 2.1 (20020510), based on gcc-2.95.3 20010315/djgpp (release). Copyright (C) 1987-2002 Free Software Foundation, Inc. GNU Pascal is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GNU Pascal is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. For more version information on components of the GNU Pascal compiler, especially useful when reporting bugs, type the command `gpc.exe --verbose'. Most used command line options: -c Compile or assemble the source files, but do not link. -o FILE Place output in file FILE. --automake Automatically (re)compile modules/units. -v Be verbose. The command line options are described in the online documentation. `info -f gpc invoking' describes them in detail. Report bugs to <gpc(a)gnu.de>. d:\PRIVAT\BILANZ\PROGRAM>gpc x.pas >x.y gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) d:\PRIVAT\BILANZ\PROGRAM>gpc GNU Pascal version 2.1 (20020510), based on gcc-2.95.3 20010315/djgpp (release). Copyright (C) 1987-2002 Free Software Foundation, Inc. GNU Pascal is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. GNU Pascal is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. For more version information on components of the GNU Pascal compiler, especially useful when reporting bugs, type the command `gpc.exe --verbose'. Most used command line options: -c Compile or assemble the source files, but do not link. -o FILE Place output in file FILE. --automake Automatically (re)compile modules/units. -v Be verbose. The command line options are described in the online documentation. `info -f gpc invoking' describes them in detail. Report bugs to <gpc(a)gnu.de>. d:\PRIVAT\BILANZ\PROGRAM>gpc x.pas gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) call un-inst rem unzip32 gpc2953b.zip < d:\djgpp\a.a rem unzip32 djdev201.zip < d:\djgpp\a.a unzip32 gpc-2.1.i586-pc-msdosdjgpp.zip < d:\djgpp\a.a unzip32 djdev201.zip < d:\djgpp\a.a unzip32 bnu213b.zip < d:\djgpp\a.a unzip32 gcc2952b.zip < d:\djgpp\a.a unzip32 gdb418b.zip < d:\djgpp\a.a unzip32 mak3791b.zip < d:\djgpp\a.a unzip32 txi40b.zip < d:\djgpp\a.a unzip32 mak3791b.zip < d:\djgpp\a.a

2 1

list maintainer wanted
by Anja Gerwinski 27 Dec '02

27 Dec '02

Hello, about a year ago I asked if someone was willing to become list maintainer, and Dieter Schmitz kindly took this unpaid job. Now that he has to focus on other things, he would like to pass it on. If you are willing to maintain the lists gpc and gpc-announce please contact me. Administration is possible either via a web interface or via commands sent by email. We are using Majordomo 2, and there is only a handful of commands you need to know, so administration is not difficult. Being list maintainer means that majordomo forwards you all non-subscriber posts to sort out if they are spam or genuine posts. Most of them are spam (several per day), but it is important to review them all because some are genuine posts. In the last months, a few genuine posts did not reach the list because Dieter was to busy to look at the consult messages. I apologize for this. Currently I am the maintainer again but I would be very glad if one of you could take this job. Thanks, Anja

1 1

Do not reply :-)
by Adam Naumowicz 24 Dec '02

24 Dec '02

writeln(output,Upcase('m')+'a'#114#114'y ',chr(88),'mas to all GPC users!');

1 0

Graphics library
by Tensegrity, Inc. 23 Dec '02

23 Dec '02

I developed a CADD (Computer Aided Design & Drafting) system using HP Workstation Pascal. This Pascal had a Device-independent Graphics Library (DGL) graphics package. Are there any graphics library packages available for gpcPascal? Regards, John M. Christy President - Tensegrity, Inc.

2 1

Bug? Identifier Integer sometimes fails
by Eike Lange 21 Dec '02

21 Dec '02

Hi Folks! The following program fails to compile: program Foo; var Integer: Integer = 2; Real: Integer = 3 ; { this works: Real, Integer: Integer = 3; } begin Integer := Real; Real := Integer end. Btw: using the decalaration as given in the comment works. Eike

10 77

[Fwd: Re: Bug? Identifier Integer sometimes fails]
by Maurice Lombardi 21 Dec '02

21 Dec '02

This was not sent to the list, but it was intended to ... I realized while reading the last message of Franck on the subject -------- Message d'origine -------- Objet: Re: Bug? Identifier Integer sometimes fails Date: Fri, 20 Dec 2002 19:23:13 +0100 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: cbfalconer(a)worldnet.att.net Références: <3E018128.27241.258BB6@localhost> <3E01B718.1040507(a)ujf-grenoble.fr> <3E01CF33.32301.1072E43@localhost> <200212192052.VAA26157(a)goedel.fjf.gnu.de> <3E032F09.9080500(a)ujf-grenoble.fr> <3E0338E3.E2F21BFE(a)yahoo.com> CBFalconer a écrit: > Maurice Lombardi wrote: > > ... snip ... > >>The only problem I see is the restriction by pascal to only one case >>variant in a record. I suppose C has no restriction on the number >>of union inside a struct. This can be solved only by some extra types. > > > Is this really so? There is the requirement that fixed components > precede variant components, but AFAIK there is no limitation on > nesting. > > Isn't the following legal? > > TYPE > x = RECORD > a : integer; > CASE b : char OF > 'B': (b1 : fubar); > 'C': CASE c1 : char OF > 'c': (c2 : foo); > END; (* CASE c1 *) > 'D': CASE d1 : char OF > 'd': (d2 : bar); > END; (* CASE d1 *) > END; (* CASE b *) > (* e : integer; WOULD BE ILLEGAL here *) > END; (* RECORD x *) > > The names have to be distinct, and the compiler must be able to > infer a fixed offset for any component name. This does not work. But nested record are possible to solve this problem. In fact the proper equivalent of union { .. ; .. } HighWord; is Highword: packed record case integer of '1': ( .. ); '2': ( .. ) end; (I missed previously the enclosing record, which was however written in the example ...) You can check on the following C and pascal more complex examples functionally equivalents to the original one -------------------------------------------------------------------- #include <stdio.h> #define WORD unsigned short #define BYTE char #define DWORD unsigned typedef struct _LDT_ENTRY { WORD LimitLow; WORD BaseLow; union { struct { BYTE BaseMid; BYTE Flags1; } Bytes; struct { DWORD BaseMid:8; DWORD Type:5; DWORD Dpl:2; DWORD Pres:1; } Bits; } HighWord; union { struct { BYTE Flags2; BYTE BaseHi; } Bytes; struct { DWORD LimitHi:4; DWORD Sys:1; DWORD Reserved_0:1; DWORD Default_Big:1; DWORD Granularity:1; DWORD BaseHi:8; } Bits; } HigherWord; } LDT_ENTRY,*PLDT_ENTRY,*LPLDT_ENTRY; int main(void) { // struct _LDT_ENTRY ldt; LDT_ENTRY ldt; // equivalent declarations ldt.HighWord.Bytes.BaseMid = 0xDE; ldt.HighWord.Bytes.Flags1 = 0xAD; ldt.HigherWord.Bytes.Flags2 = 0xBE; ldt.HigherWord.Bytes.BaseHi = 0xEF; printf("%d %d %d %d %d %d %d %d %d %d\n", ldt.HighWord.Bits.BaseMid, ldt.HighWord.Bits.Type, ldt.HighWord.Bits.Dpl, ldt.HighWord.Bits.Pres, ldt.HigherWord.Bits.LimitHi, ldt.HigherWord.Bits.Sys, ldt.HigherWord.Bits.Reserved_0, ldt.HigherWord.Bits.Default_Big, ldt.HigherWord.Bits.Granularity, ldt.HigherWord.Bits.BaseHi); return 0; } --------------------------------------------------------------------- -------------------------------------------------------------------- program teststruc; {$define DWORD cardinal} type LDT_ENTRY = packed record LimitLow: WORD; BaseLow: WORD; HighWord: packed record case integer of 1: (Bytes: packed record BaseMid: BYTE; Flags1: BYTE; end); 2: (Bits: packed record BaseMid: DWORD(8); C_Type: DWORD(5); Dpl: DWORD(2); Pres: DWORD(1); end) end; HigherWord: packed record case integer of 1: (Bytes: packed record Flags2: BYTE; BaseHi: BYTE end); 2: (Bits: packed record LimitHi: DWORD(4); Sys: DWORD(1); Reserved_0: DWORD(1); Default_Big: DWORD(1); Granularity: DWORD(1); BaseHi: DWORD(8) end) end; end; type PLDT_ENTRY = ^LDT_ENTRY; LPLDT_ENTRY = PLDT_ENTRY; var ldt:LDT_ENTRY; begin with ldt do begin with HighWord.Bytes do begin BaseMid:=$DE; Flags1 :=$AD; end; with HigherWord.Bytes do begin Flags2 :=$BE; BaseHi :=$EF; end; with HighWord.Bits do write (BaseMid,' ', C_Type,' ', Dpl,' ', Pres,' '); with HigherWord.Bits do writeln(LimitHi,' ', Sys,' ', Reserved_0,' ', Default_Big,' ', Granularity,' ', BaseHi); end; readln end. --------------------------------------------------------------------- Al this seems amenable to automatic translation. 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 -- 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

2 1

Re: gcc-3.2.1 and omit-frame-pointer
by Frank Heckenbach 19 Dec '02

19 Dec '02

The Chief wrote (in personal mail): > I have just intercepted a thread on the Mingw mailing lists - see > below. It seems that the problem that I reported with > "-fomit-frame-pointer" is a gcc bug. Fine (as far as I'm concerned, so I won't have to fix it ;-). I hope you don't mind me replying to the list. I'm doing so just to support my point that switching completely to gcc-3 (i.e., dropping gcc-2 support or doing all new development in the gcc-3) might still be a little risky ... > But David Bryan has experienced > similar problems without using that switch. So, there may well be a > problem with the code generation under gcc-3.2.1. Do they also seem backend-related? Otherwise, of course, I'd need a test case to tell more ... > [ Mingw list mail and C example of the bug skipped ] Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

2 2

Re: a compiler crash
by Emil Jerabek 19 Dec '02

19 Dec '02

On Fri, Dec 13, 2002 at 11:26:54AM -0500, CBFalconer wrote: > Emil Jerabek wrote: > > On Wed, Dec 11, 2002 at 02:47:31PM +0100, Emil Jerabek wrote: > > [...] > > > > > > Exactly the same thing happens also with some other variants of > > > the schema Foo definition: > > > > Sorry, this should be "Bar", not "Foo", of course. I've got > > confused myself by those stupid names ... > > > > > > > > Bar (U: Cardinal) = array [0 .. U] of Char; > > > Bar (L: Integer; U: Cardinal) = array [L .. U] of Char; > ^^^^^^ > These are different types, thus not a legal specification. Or am > I missing the point? (which may be that it causes a crash). This is arguable, different _integer_ types are compatible in many situations, where type identity is otherwise required. Cardinal is nonstandard, and exact rules for mixing of Integer and Cardinal are not stated anywhere in the GPC docs. But I understand there is a good reason not to allow the example above (another possibility would be to promote L and U to LongInt). Anyway, the point was that the compiler should _never_ crash, even if given an invalid input. Finally, a technical issue: I assume your reply was intended for the list. If it wasn't, I apologize for making it public. If it was, please make sure that you use a "List Reply" or "Reply All" or something similar, when replying to the list. (Or is it just a bug in your MUA?) Emil > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address! >

2 1

(no subject)
by Adriaan van Os 19 Dec '02

19 Dec '02

Frank Heckenbach wrote: > GPC currently uses a stand-alone preprocessor (gpcpp) that is > derived from the C preprocessor and shares many of its features. > > I plan to integrate it into the compiler which would follow gcc's > example (not so important, though), maybe make it a little faster > (not very much, I guess, since preprocessing in general doesn't take > very long), solve some problems (e.g., the `--needed-option' > ugliness, mostly on MIPS) and allow for further improvements. > > In the same process, I'd like to change some of the more obscure > aspects, thereby hopefully making the code much simpler and even > more powerful. This will not affect the BPish features of the > preprocessor (`{$ifdef}', `{$ifopt}' and `{$i ...}' (include)), and > the Pascal standards don't have a preprocessor, anyway, so I think > there are no compatibility concerns (except for > backward-compatibility to existing GPC versions). I think most the > features discussed below are known to few people at all and not used > much. Well, as much as I welcome Frank's suggestions for the preprocessor, there really are compatibilty-concerns. CodeWarrior Pascal has integrated preprocessor support, similar to what Frank suggests. I have included relevant parts of the CodeWarrior Pascal Compilers Reference in the text below. Regards, Adriaan van Os --------------- Using Compiler Directives <taken from the CodeWarrior® Pascal Compilers Reference> Every compiler directive must be enclosed within comment delimit- ers ({ and }, or (* and *)) and begins with a dollar sign ($). Only one directive may be within each pair of comment delimiters. CodeWarrior Pascal lets you compile sections of your source text conditionally by means of the $IFC, $ELSEC, and $ENDC and associ- ated directives. The $IFC directive is controlled by the value of a compile-time expression. You set such an expression using $SETC. Sections of source code controlled by these directives may be nested. The rules covering such nesting are the same as the rules for IF statements. See the Pascal Language Reference for more informa- tion about IF statements. You can form compile-time expressions out of compile-time variables or constants of type INTEGER or BOOLEAN. The final value of the ex- pression that controls a $IFC directive must be BOOLEAN. You can use all the Pascal operators in compile-time expressions except IN and @. If you use the operator /, the compiler will automatically change it to DIV. $DEFINE {$DEFINE id } Defines an identifier that may be tested and undefined with other directives. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. See also $IFDEF, $ELSE, $ENDIF. $DEFINEC {$DEFINEC id} {$DEFINEC id definition} {$DEFINEC id ( parameters )definition Defines an item, id. The $DEFINEC directive substitutes every occur- rence of id in the source code with its definition, definition. The iden- tifier, id, is not substituted when it appears in between comment de- limiters or a string literal. The definition part of a $DEFINEC directive can be any keyword, constant value, or statement that is legal in CodeWarrior Pascal. Multiple statements in the definition must be separated by semi-co- lons (;). The item id may have the same name of an already-declared proce- dure or function if id and the routine don't have the same number of parameters. If id is defined with parameters, every occurrence of a parameter is replace with the corresponding items in id's definition before id is substituted. Parameters must be enclosed in parentheses in the $DEFINE directive. Items defined in the INTERFACE part of a unit are accessible by the units or the program that use the unit. Items defined in the IMPLEMENTATION part of a unit are only accessible within the unit. An item defined without a definition and without parameters is still defined but has an empty definition. To remove the definition of an item defined with $DEFINEC, use the $UNDEFC directive. Listing 4.2 lists examples of using the $DEFINEC directive. Listing 4.2 $DEFINEC examples PROGRAM DefineExamples; {$DEFINEC EraseMe} {$DEFINEC two 2} {$DEFINEC PRINT(a) WriteLn(a);} begin WriteLn(two); EraseMe; PRINT('Hello, world!'); end. $ELIF {$ELIF comp-expr} This directive is equivalent to the $ELIFC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. $ELIFC {$ELIFC comp-expr} Marks the beginning of source text that is compiled only if the value of the comp-expr controlling its corresponding $IFC or $IFNOTC di- rective is false and its own comp-expr expression is true. This is a CodeWarrior Pascal-compatible directive. It may not be used in the same source code file as other Turbo-compatible direc- tives. See also $IFC, $ENDC, $SETC. $ELSE {$ELSE} This directive is equivalent to the $ELSEC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. $ELSEC {$ELSEC} Marks the beginning of source text that is compiled only if the value of the comp-expr controlling its corresponding $IFC or $IFNOTC di- rective is false. This is a CodeWarrior Pascal-compatible directive. It may not be used in the same source code file as other Turbo-compatible direc- tives. See also $IFC, $ELIFC, $ENDC, $SETC. $ENDIF {$ENDIF} This directive is equivalent to the $ENDC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. $ENDC {$ENDC} The $ENDC directive marks the end of a section of conditionally compiled source text, matching a $IFC or $IFNOTC directive. This is a CodeWarrior Pascal-compatible directive. It may not be used in the same source code file as other Turbo-compatible direc- tives. See also: $IFC, $IFNOTC, $ELSEC, $SETC. $ERROR {$ERROR comment} This directive is equivalent to the $ERRORC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. $ERRORC {$ERRORC comment} Forces a compiler error. A comment, comment, may optionally fol- low this directive. This is a CodeWarrior Pascal-compatible directive. It may not be used in the same source code file as other Turbo-compatible direc- tives. $IF {$IF comp-expr} {$IF OPTION(option-name) } {$IF OPTION option-name } This directive is equivalent to the {$IFC comp-expr} form of the $IFC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. See also $IFDEF, $ELSE, $ELIF, $ENDIF. $IFC {$IFC comp-expr} {$IFC DEFINED name} {$IFC OPTION(option-name) } {$IFC OPTION option-name } Compiles subsequent source code until the next $ELSEC or $ENDC directive, only if the boolean value of comp-expr is true. You may also write this directive in the form {$IFC DEFINED name}. This will act like {$IFC false} if name has not yet been de- clared with a $SETC directive; otherwise, it will act like {$IFC true}. You can also write this directive {$IFC OPTION( option-name} to test the current setting of compiler directives. For example, {$IFC OPTION (PROF)} acts like {$IFC true} if {$PROF+} had been specified prior to the $IFC. This is a CodeWarrior Pascal-compatible directive. It may not be used in the same source code file as other Turbo-compatible direc- tives. See also $IFNOTC, $ELIFC, $ELSEC, $ENDC, $SETC, $DEFINEC, $IFDEF {$IFDEF id} This directive is equivalent to the {$IFC DEFINED id} form of the $IFC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. See also $DEFINE, $UNDEF, $IFNDEF, $IF. $IFOPT {$IFOPT option-name} This directive is equivalent to the $IF OPTION(option-name) form of the $IF directive. See also $IF, $ELSE, $ELIF, $ENDIF, Checking Options on page 98 . This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. $IFNDEF {$IFDEF id } This directive is equivalent to the {$IFNOTC DEFINED id} form of the $IFNOTC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. See also $IFDEF. $IFNOTC {$IFNOTC DEFINED name} Compiles subsequent source code until the next $ELSEC or $ENDC directive, only if the boolean value of comp-expr is true. This directive will act like {$IFC true} if name has not yet been declared with a $SETC directive; otherwise, it will act like {$IFC false}. This is a CodeWarrior Pascal-compatible directive. It may not be used in the same source code file as other Turbo-compatible direc- tives. See also: $ELSEC, $ENDC, $IFC, $SETC, $DEFINEC. $MACRO {$MACRO id} {$MACRO id definition} {$MACRO id ( parameters )definition This directive is equivalent to the $DEFINEC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. $PRAGMA {$PRAGMA pragma state} This directive is equivalent to the $PRAGMAC directive. This is a Turbo Pascal-compatible directive. It may not be used in the same source code file as other CodeWarrior-compatible direc- tives. $PRAGMAC {$PRAGMA pragma state} Sets the state of a pragma. See Pragmas on page 60 for more infor- mation on using pragmas to control how source code is translated into object code. This is a CodeWarrior Pascal-compatible directive. It may not be used in the same source code file as other Turbo-compatible direc- tives. $SETC {$SETC id := comp-expr} Declares a compile-time variable named id and assigns it the value comp-expr. This directive may not be used with Turbo Pascal-compatible direc- tives. See also: $IFC, $ELSEC, $ENDC. $UNDEFC {$UNDEFC id} Undefines an identifier that was defined with the $DEFINEC direc- tive. Undefining a previously defined item tells the compiler not to substitute subsequent occurrences of id with its definition. Use this directive with the $IFC and $IFNOTC directives to control the compilation of source code. This is a CodeWarrior Pascal-compatible directive. It may not be used in the same source code file as other Turbo-compatible direc- tives. See also $DEFINEC, $IFC, $IFNOTC. ---------------

3 6

minor nit-pick
by Russell Whitaker 18 Dec '02

18 Dec '02

The program below works, but the array in the unit defaults to a zero-based array. unit bar; interface procedure show( a: array of integer ); implementation procedure show( a: array of integer ); var i : integer; begin for i := 1 to 4 do write( a[ i ]:7 ); writeln; end; end. program foo; uses bar; var a: array[1..5] of integer; i: integer; begin for i := 1 to 5 do a[i] := i; for i := 1 to 5 do write( a[i]:7 ); writeln; show( a ); end. Russ

4 3

Crt0.o
by b b 17 Dec '02

17 Dec '02

Hi guys, I have a problem with compiling my first Pascal program. This directly after my Installation of GNU pascal. The problem is: I installed the latest version of GNU Pascal compiler on my PC with windows XP Pro. I wrote my code in Emacs at the same PC. Then I used my DOS-prompt and went to the route of the file that contained my code and wrote the command: gpc <filename>.p and enter. D:\DOCUME~1\ADMINI~1\Desktop\...\Pascal\INLUPP~1>gpc Inlupp1.p I got first some errors in compilation. I made necessary changes in the code and run again. At this moment it should not give any fault and a specific *.exe file should be created. Instead I got this Answer from the compiler: D:\Djgpp\bin/ld.exe: cannot open crt0.o: No such file or directory (ENOENT) That was strange. As you know the Crt0.o is the standard run-time startup routine (crt0.o). Now, I checked under the Djgpp\bin and I could find the ld.exe file. I checked also the crt0.o file in Djgpp and exists in lib directory: D:\Documents and Settings\Administrator\Desktop\...\Pascal\Djgpp\lib I checked the property of crt0.o file. It was not empty and it had attribute archive. My question is when does this appear and what does it depend on ? Is it not that "\bin/ld.exe" should be "\bin\ld.exe" or that is not the problem what can be the reason ? Best Regards /b --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now

2 3

Re: Assignment from incompatible pointer
by Fredrik Ismyren 17 Dec '02

17 Dec '02

On Tue, 17 Dec 2002, Frank Heckenbach wrote: > No, they're two record types that look the same, > but are distinct types in Pascal. Just export the > types in the interface and don't declare them > again in the implementation. I see! Yes now it works. Thanks alot for this information. > PS: When you post sample code, please send > complete code. My compiler doesn't like `...', so > it's hard to test things. Yes I will Frank. Thanks again. // Fredrik - Sweden ____________________________________ Gratis epost med TJOHOOMAIL http://www.tjohoo.se

1 0

Assignment from incompatible pointer type
by Fredrik Ismyren 16 Dec '02

16 Dec '02

I'm using GPC 2.8.1 and I've got problems with the following manuever. Down in my procedure "DestroyPQueue" I try to assign the address from the left pointer to the local pointer pseg. I get: "Assignment from incompatible pointer type". They are created from the same type so I don't understand why this doesn't work. <---> module PriQueue interface; export PriQueue = ( PQueue, ... ); .. type ElementType = Integer; SegPek = ^TreeSeg; TreeSeg = record data : ElementType; left : SegPek; right : SegPek; end; PQueue = record root : SegPek; numberOfElements : Integer; end; .. procedure DestroyPQueue(var pq : PQueue); .. end. module PriQueue implementation; type ElementType = Integer; SegPek = ^TreeSeg; TreeSeg = record data : ElementType; left : SegPek; right : SegPek; end; .. procedure DestroyPQueue; var pseg : SegPek; begin pseg := pq.root^.left; { HERE'S THE PROBLEM } .. end; .. end. <---> ____________________________________ Gratis epost med TJOHOOMAIL http://www.tjohoo.se

2 1

Posting problems
by Fredrik Ismyren 16 Dec '02

16 Dec '02

Ping2! Why don't my bigger mails show up here? I signed on today. Do I have to wait for some days or what?

1 0

Ping!
by Fredrik Ismyren 16 Dec '02

16 Dec '02

Ping ping .. don't answer on this one.

1 0

Re: Crt0.o
by da Silva, Joe 16 Dec '02

16 Dec '02

You might like to look at my instructions for installing GPC for DOS : http://jds-freeware.hypermart.net/pascal/how2gpc.dos.txt Installing for XP should be similar, I expect. Note that the above document predates the availability of GPC to match GCC 3.X.X, but is otherwise fairly up-to-date. Joe. > -----Original Message----- > From: b b [SMTP:babakjohn2002@yahoo.com] > Sent: Sunday, December 15, 2002 9:36 AM > To: gpc(a)gnu.de > Subject: Crt0.o > > Hi guys, > > I have a problem with compiling my first Pascal program. This directly > after my Installation of GNU pascal. The problem is: > > I installed the latest version of GNU Pascal compiler on my PC with > windows XP Pro. I wrote my code in Emacs at the same PC. Then I used my > DOS-prompt and went to the route of the file that contained my code and > wrote the command: > > gpc <filename>.p and enter. > D:\DOCUME~1\ADMINI~1\Desktop\...\Pascal\INLUPP~1>gpc Inlupp1.p > > > > I got first some errors in compilation. I made necessary changes in the > code and run again. At this moment it should not give any fault and a > specific *.exe file should be created. > > Instead I got this Answer from the compiler: > > D:\Djgpp\bin/ld.exe: cannot open crt0.o: No such file or directory > (ENOENT) > > That was strange. As you know the Crt0.o is the standard run-time startup > routine (crt0.o). Now, I checked under the Djgpp\bin and I could find the > ld.exe file. I checked also the crt0.o file in Djgpp and exists in lib > directory: > > D:\Documents and Settings\Administrator\Desktop\...\Pascal\Djgpp\lib > > I checked the property of crt0.o file. It was not empty and it had > attribute archive. > > My question is when does this appear and what does it depend on ? > > Is it not that "\bin/ld.exe" should be "\bin\ld.exe" or that is not the > problem what can be the reason ? > > > > Best Regards /b > > > > _____ > > Do you Yahoo!? > Yahoo! Mail Plus > <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com> - Powerful. > Affordable. Sign up now > <http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com>

1 0

The preprocessor
by Frank Heckenbach 15 Dec '02

15 Dec '02

Hi, GPC currently uses a stand-alone preprocessor (gpcpp) that is derived from the C preprocessor and shares many of its features. I plan to integrate it into the compiler which would follow gcc's example (not so important, though), maybe make it a little faster (not very much, I guess, since preprocessing in general doesn't take very long), solve some problems (e.g., the `--needed-option' ugliness, mostly on MIPS) and allow for further improvements. In the same process, I'd like to change some of the more obscure aspects, thereby hopefully making the code much simpler and even more powerful. This will not affect the BPish features of the preprocessor (`{$ifdef}', `{$ifopt}' and `{$i ...}' (include)), and the Pascal standards don't have a preprocessor, anyway, so I think there are no compatibility concerns (except for backward-compatibility to existing GPC versions). I think most the features discussed below are known to few people at all and not used much. If you want to know about the dirty details of the C preprocessor, please read the info files `cpp' and `cppinternals'. Note that the C preprocessor does a lot of micro-optimizations. I think in Pascal we can get away without them since the preprocessor (in particular macros and complicated includes) are *much* less often used here than in C. (And again, I think preprocessing is quite fast compared to compilation that I doubt how much effect these optimizations have at all.) The C preprocessor takes some effort to prevent recursive macro calls, so, e.g., in `#define foo foo(x)', the macro foo will not call itself. This might be useful sometimes (e.g., when overriding a previously defined thing), but at the same time it limits the expressiveness of macros. (In the above example recursion would be pointless since it would be inifinite, but using parameters etc., useful cases can be constructed.) So I suggest the following: Allow recursive macro calls in general, but provide a way to suppress it explicitly, e.g. by prefixing the name with `\' (similar to how shells can prevent alias expansion). This could also work outside of macros: {$define foo bar} foo { yields `bar' } \foo { yields `foo' } \bar { yields `bar' } The latter should give a warning (or an error?). This leaves it standard-compliant. Since the stnandard doesn't have macros, each occurrence of `\' would be of the latter kind and therefore wrong (according to the standard which doesn't have `\' at all). Another obvious improvement would be to allow compiler directives within macros which is not possible in C. E.g., `{$define foo {$define bar baz}}' (with `--nested-comments') or `{$define foo (*$define bar baz*)}' (with `--mixed-comments') would define a macro that defines another macro when used. So, e.g., the following macro could compute a factorial (of a constant) at compile time: {$define FACTORIAL(N) {$if N < 0} {$error Negative argument of FACTORIAL} {$elif N <= 1} 1 {$else} (N * FACTORIAL (N - 1)) {$endif} } Or an automatic counter (similar to enum types -- those should be preferred when possible, of course, but in some situations it's not so easy): {$define DEF_REC(X, S, N) {$if N <= 0} {$define X S} {$else} DEF_REC (X, S + 1, N - 1) {$endif} } {$define COUNTER 0} {$define DEFCOUNTED(X) {$redefine \COUNTER COUNTER + 1} DEF_REC(X, 0, COUNTER) } DEFCOUNTED (a) { => 1 } DEFCOUNTED (b) { => 2 } DEFCOUNTED (c) { => 3 } Two other difficult areas in C (especially because they have different syntax in traditional (K&R) and ANSI C) are token concatenation and stringification. K&R: foo/**/bar "foo" This is clearly not suitable for Pascal since in Pascal a comment is clearly equivalent to whitespace, and for the second case (if `foo' is a macro argument, it would yield a string containing the contents of foo, not the 3 letters `f', `o', `o'), in Pascal, strings are clearly literal (whether delimited by "" in C, or '' in Pascal is a side-issue here). ANSI: foo##bar #foo These forms look quite artifical to me (and the latter one is also close, though maybe not directly conflicting, to the BP-style char constant syntax). I think it would be better (also easier to handle) to have some built-in "magic macros" with these effects (which is what in C is typically defined in a header to overcome the K&R vs. ANSI differences). The macros could be given sufficiently long names (e.g., `MACRO_CONCAT' and `MACRO_STRINGIFY') to avoid most conflicts or, if deemed necessary, be activated only within macro bodies (outside of them they're not very interesting, anyway). Since in standard and BP modes macros are disabled at all, they have no effect there, either. Similarly, one could have, e.g., `MACRO_EVAL' within a macro definition to substitute {$define FOO 1} {$define BAR FOO} {$define BAZ MACRO_EVAL(FOO)} {$redefine FOO 2} BAR { => 2 } BAZ { => 1 } This would, e.g., simplify the automatic counter from above: {$define COUNTER 0} {$define DEFCOUNTED(X) {$redefine \COUNTER COUNTER + 1} {$define X MACRO_EVAL(COUNTER)} } Again, I think this behaviour will actuall be simpler to implement than the C compatible behaviour (and much simpler than the current implementation which is overly complex for questionable optimizations (and consists of rather old code) ... Then, I don't like the `{$include <...>}' syntax (mostly because `<' and `>' have very unusual meanings there). In C, there might be a point in distinguishing between system and application headers (though I haven't seem many cases very it was really important, even in C), whereas in Pascal you don't have system headers (and typically few, if any) application headers. So one include mechanism should be enough, namely `{$include STRING}' (where STRING can be any regular string constant). (And, for compatibility's sake, the BP form `{$I foo}' which appends `.pas' automatically if necessary.) Going a step further, I'm also thinking about dropping the C syntax for compiler directives (`#foo'), in favour of the (also already existing) BP-compatible syntax (`{$foo}'). I suppose there will be some objections, but I thought I'd just ask, anyway ... The special meaning of `\'-newline also seems to be needed for `#' directives (since `{$}' directives can be multi-line naturally), so this could also be dropped then. And, finally, perhaps also dropping C operators in conditional expressions (`{$if foo && bar}' -> `{$if foo and bar}') ... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 4

a compiler crash
by Emil Jerabek 15 Dec '02

15 Dec '02

Hi, the following code program Foo; type Bar (U: Cardinal) = array [-1 .. U] of Char; function Baz (F: Bar): Char; begin Baz := F[-1] end; begin end. crashes the compiler: [~/pascal]% gpc -v Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.1.1/specs Configured with: ../gcc-3.1.1/configure --enable-languages=pascal Thread model: single gpc version 20021128, based on gcc-3.1.1 [~/pascal]% gpc crash.pas ../../gcc-3.1.1/gcc/p/gpc-typeck.c:1613:build_array_ref: failed assertion `!(TREE_CODE (index) == INTEGER_CST && TYPE_VALUES (TREE_TYPE (array)) && !int_fits_type_p (index, TYPE_VALUES (TREE_TYPE (array))))' crash.pas: In function `Baz': crash.pas:8: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. Exactly the same thing happens also with some other variants of the schema Foo definition: Bar (U: Cardinal) = array [0 .. U] of Char; Bar (L: Integer; U: Cardinal) = array [L .. U] of Char; GPC with 2.95.2 backend crashes hs well, in a slightly different place: [~/pascal]% gpc2 -v Reading specs from /usr/local/bin/../lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20021111, based on gcc-2.95.2 19991024 (release) [~/pascal]% gpc2 crash.pas /home/emil/dist/gpc-src/gcc-2.95.2/gcc/p/gpc-typeck.c:1860:build_array_ref: failed assertion `0' crash.pas: In function `Baz': crash.pas:8: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. Hope this helps. Emil

2 2

A little benchmark
by Waldek Hebisch 15 Dec '02

15 Dec '02

Recently Frank wrote that subranges are stored as integer to get better performance. So I decided to run a little silly benchmark to verify my suspitions. I used variations of the following program: program p1; type foo = record a : 0..127; b : -2000..2000; end; var t : array [1..1000000] of foo; i, j, s, sum : integer; begin {writeln(Sizeof(foo));} for i:=1 to 1000000 do begin t[i].a := 20; t[i].b := 1000; end; sum := 0; for j:=1 to 100 do begin s := 0; for i:=1 to 1000000 do begin s := s + t[i].b; end; sum := sum + s div 13678; end; writeln(sum) end . I decided to compare gpc (latest alpha with gcc-3.2.1, options -O3), p2c (with gcc-3.2.1, options -O3) and fpc-1.0.6 (options -Sd -O3 -Op3). All timings are real time on otherwise idle Duron-650. 'x' in fpc column means that fpc rejected the program. gpc p2c fpc p1 3.116s 1.802s 2.550s p2 2.178s 1.802s x p3 2.953s 2.073s 2.888s p4 2.959s 2.072s x p5 3.116s 2.852s 3.365s p11 1.239s 0.467s 1.652s p12 1.394s 0.467s x p13 2.165s 0.930s 2.397s p14 2.165s 0.930s x p15 1.239s 0.897s 1.720s p21 0.469s 0.467s 1.084s p22 0.623s 0.467s x p23 1.703s 1.007s 1.932s p24 1.702s 1.007s x p25 0.470s 0.916s 1.026s p1 is the program above, p2 has packed subranges as components of the record, p3 uses packed record, p4 uses packed record with packed subranges, in p5 the record has integer components. The series p11 to p15 uses array of 1000 elements so it entirely fits into the level 1 cache. Series p21 to p25 has inner for loop replaced by equivalent repeat until loop (otherwise identical to p11 .. p15) Now, some concusions: 1) When working set does not fit into cache smaller records give significantly better speed, 2) Other compilers give fastest code just when using subranges. 3) When working in the cache aligned subword acces seem to be as fast as fullword acces, while unaligned acces or bitfild acces (used by p2c for packed records) are slower. 4) gcc backend is doing something weird to the loops: C for loops gives good (IMHO not optimal) code, but it fails to optimize Pascal for loop (that way I timed variant with repeat until loop). You may say that this is only a single benchmark on a single machine. But I think that many programs spent a lot of time in similar loops, so it is representative. I admit that I wrote the benchmark to show my point, but I based it on properties shared (IMHO) but most modern machines (especially cheaper ones): main memory much slower then the CPU, slow unaligned acces, fast subword acces. Also, it does not measure performance of using subranges as indices and similar -- I belive that reading from memory is crucial as stores are much less frequent then loads and the compiler can use integer in computations anyway, just loads and stores are done differntly. Coming to gpc: it is probably too late to change the method to store subranges, but I think it is fair to say that the decision was made in the past and we are stuck with it rather then claim that it gives faster code. Also, the loop behavior is rather embarassing (well, I can guess why it works that way, but fixing it may be harder). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 1

New alpha
by Frank Heckenbach 14 Dec '02

14 Dec '02

Hi, I've uploaded a new alpha version. Most importantly, thanks to Waldek stabs debugging should now work (at least under Linux, haven't tested on other platforms yet). Also, coff debugging (DJGPP) might work ... Furthermore, the license of the documentation has changed to the GNU Free Documentation License (the counterpart of the GPL for manuals etc.). Thanks to Eike for doing the formalities. Besides, some changes according to recent bug reports and more cleanups have been made. The two makefiles (Make-lang.in and Makefile.in) have been merged (also for gcc-3 integration) -- I don't know if anyone cares, but perhaps those who build GPC in special ways ... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

6 15

Re: Bug? Identifier Integer sometimes fails
by david＠tcs01.demon.co.uk 13 Dec '02

13 Dec '02

In message <3DF8B460.10793.179D5AF@localhost> "Prof. A Olowofoyeku (The African Chief)" writes: > > This is fine. But please let us retain the ability to specify sizes > for data types. People often have to read files created by other > applications and sometimes require data structures of specific sizes, > and it should be possible to create a data structure of that size > without too many contortions. Can I add a 'me too' to that comment. The ability to read (and write) data files that are compatible with other applications is important to me. I have a lot of packed records with carefully chosen sub-range types and packing bits in them to be able to match exactly specific data files written in other Pascals, other languages, etc. -- David James mailto:david@tcs01.demon.co.uk or mailto:david@djames.org.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

Re: MinInt (was: Bug? Identifier Integer sometimes fails)
by da Silva, Joe 13 Dec '02

13 Dec '02

Please see below ... Joe. > -----Original Message----- > From: Frank D. Engel, Jr. [SMTP:fde101@yahoo.com] > Sent: Friday, December 13, 2002 12:45 AM > To: Frank Heckenbach; gpc(a)gnu.de > Subject: Re: Bug? Identifier Integer sometimes fails > > > > CONST > > > maxint = 32767; (* redefine *) > > > minint = -32768; > > > To be pedantic, you might want to write `MinInt = -MaxInt;' since > > the standard demands a symmetric range of Integer. > > Uh... > > '-MaxInt' would imply -32767..32767, which wastes a potential stored > value (and cannot accomidate interfacing with other languages, which do > not have this restriction). > > '-MinInt' would imply -32768 (yes, negative; run the negation in 2's > compliment and you will see what I mean). > > By 'symmetric,' do you mean that the Pascal standard actually calls for > the INTEGER type to have the same negative range as positive? > [Joe da Silva] That's right, Pascal does NOT assume two's complement integer representation, so the standard range for an integer is -maxint to +maxint. Indeed, much of the early work on Pascal was done on CDC machines that had a sign & magnitude integer representation, hence this really was the range for integers. Although these days, two's complement integer implementations are all you are likely to encounter, in theory you should avoid -maxint-1 for portability. This value is a non-standard integer value, or a non-standard language extension, if you like. You may use it in that knowledge. Note that NW was quite happy for Pascal implementations to have whatever non-standard extensions were appropriate, he and KJ were only seeking to define a common, minimalist language, that all implementations must support. > ===== > ======= > Frank D. Engel, Jr. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com

1 0

Smart recompilation, interfaces and implementation
by Nick Ioffe 12 Dec '02

12 Dec '02

Hi! We're converting large (about 300 modules) project from DEC-PASCAL to GPC. The problem is that building the project after changing some file is very time-consuming, since when I change module implementation the interface is recompiled as well. I keep both interface and implementation in the same file, so when the file is changed I've no way telling the make what have changed - interface or implementation , don't I? If there is an option then I can use --interface-only and --implementation-only options in gpc. Thus number of questions : 1. Is there any "normal" way (without keeping previous version of .pas) to tell what have been changed? 2. How do you handle such problems? 3. Is there any automatic tool which can keep and provide the makefile with dependency structure of modules? The obvious way of updating Makefile manualy with steps like moduleX: moduleX_interface, moduleY, moduleZ gpc --implementation-only ModuleX for each of 300 modules which has "thick" dependency sounds not good Thank you in advance, Nick

4 8

Some tests on gpc321 for DJGPP
by CBFalconer 12 Dec '02

12 Dec '02

I ran the following little tests. There are some comments in the source. In particular I am worrying about the use of field width specifications. 0 is illegal in ISO7185, legal in 10206. -ve are illegal in both, and not detected. I really have no great objections to this, but if it is not detected lets at least put it to good use. I recommend using -ve values to cause left justification in the field. I also consider the failure to stop compilation on the final '.' a serious fault. This feature makes the sources immune to the lack of line termination at the end of the source file, and allows appending useful commentary there. Some of my files end with ^Z (for EOF on CP/M or MsDos) and a two byte CCIT CRC checksum. This makes it extremely easy to detect corruption. Heeding the final '.' makes the system immune to the OS handling of EOF markers. BTW what is the effect, if any, of the -pedantic, -W, -Wall gcc options? Should we be using -gstabs+ (my practice) or just -g. Under DJGPP in particular. PROGRAM misctests(input, output); (* Compiled with --standard-pascal *) CONST maxi = 32767; mini = -32768; maxwd = 65535; TYPE integer = mini .. maxi; word16 = 0 .. maxwd; VAR ch : char; i, j : integer; BEGIN (* misctests *) writeln('Hello, World'); writeln('"', 'string in field of 25' : 25, '"'); writeln( '"1234567890123456789012345"'); writeln('Maxint = ', maxint : 0); writeln('Maxi = ', maxi : -20, ' Mini = ', mini : 1); (* disappointing that -ve field neither left justifies *) (* nor is flagged as an error *) (* My pref: 0 default, -ve for left just, +ve as usual *) writeln('Enter lines until eof'); WHILE NOT eof DO IF eoln THEN BEGIN writeln; write(input^, 'Enter: new line: ' : 6); (* This ^ should be a blank *) (* Check truncates *) readln; END ELSE BEGIN output^ := input^; put(output); get(input); END; writeln('Fld ActualFld'); writeln('=== ======...'); FOR i := -8 TO 8 DO writeln(i : 3, '"', maxi : i, '"'); i := maxi - 4; (* FOR j := maxi - 3 TO maxi + 3 DO BEGIN *) (* now throws a constant out of range error gpc321 *) (* which is definite progress towards range checks *) FOR j := -3 TO +3 DO BEGIN i := succ(i); write(i : 6); (* should crash *) END; writeln; writeln(' Should have crashed here after 32767'); END. (* misctests *) (* ^ Nothing should count after this period *) (* However gpc throws errors down here *) (* unless commented out *) -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

4 7

Re: Translation Scheme
by da Silva, Joe 12 Dec '02

12 Dec '02

Hmmm ... Do you perhaps want a P4 P-Code to 386 translation scheme instead? I'm assuming here that P4000 is some derivative of the P4. Since you already have a front-end, it may be easier to translate it's output to 386 as a separate program, instead of modifying the existing "front-end". Perhaps someone here may know of existing code to perform such a translation or at least know where to find decent documentation of the P4 P-Code (BTW, if so, I may be interested too;-). Joe. > -----Original Message----- > From: a2782(a)dis.ulpgc.es [SMTP:a2782@dis.ulpgc.es] > Sent: Thursday, December 12, 2002 10:56 AM > To: gpc(a)gnu.de > Subject: Translation Scheme > > Didn\'t you go to school? :) Weren\'t you ordered to make a simple > compiler which accepted a Pascal subset and generated machine code? > > I will tell you why do I want this translation scheme. I am involved in > a project in which one of its steps is taking a compiler of a language > called \'LC99\' (it is very close to Pascal or Algol) which actually > generates P-Code (from Pascal compiler P4000) and change it in order to > make it generates i386 code. It\'s the first time I make a pure back-end > (I\'ve been always working on front-ends, which make me happier :). I am > not interested in optimizations, because my project has only academical > purposes (it\'s a visualizator of memory implemented over GDB). > > Of course, implementation of GPC (front-end+Tree+RTL+back-end) crashes > with I want to get (lex,parser,semant-->code). I knew it. But I thought > any of you had some experience in something like this. > > Many thanks to Marcel, Frank Heckenbach, Waldek Hebisch, Russell > Whitaker, Maurice Lombardi and The African Chief (who has a Pascal-to- > 386 compiler which may be helpful to me). Thanks indeed to Joe da > Silva ;P. > > Ciao!

4 4

Delphi compatibility
by Prof. A Olowofoyeku (The African Chief) 12 Dec '02

12 Dec '02

Hi all Newer versions of Delphi (IIRC, from v4.0 onwards) permit a somewhat C-like procedure/function call - e.g., if you have these routines: function foo : integer; procedure bar; You can call them like this; i := foo; // GPC expects this bar; // -- ditto -- j := foo (); // Delphi accepts, but GPC doesn't bar(); // -- ditto -- I thing that it would be nice if GPC could support the addition of the brackets, but there may well be strong reasons for not doing so (for one, it is un-Pascalish). I also do not know whether it would be easy or difficult to implement. I fully appreciate that there are many other things that are far greater priorities - but if it could be done easily then should it? I find that many Delphi programmers are increasingly doing this (probably those who came from a C/C++ background) and so it gets a bit cumbersome to deal with them when trying to port free Delphi code to GPC. Any comments? Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

13 33

Re: New alpha
by da Silva, Joe 12 Dec '02

12 Dec '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, December 11, 2002 3:47 PM > To: gpc(a)gnu.de > Subject: Re: New alpha > -------- snip -------- > Of course, if you really want to, you can "bite the bullet" and try > integration right now. But I'm quite sure it will be much more work > in total than is doing it in the proper order, and it will be > technically dubious solutions (both from the GCC and the GPC > viewpoint, in different areas). > > OTOH, I don't see any big advantage in hurrying it. It may be easier > for distribution makers (so I see your POV, Matthias), but then > again, I suppose you have your build scripts in place for the > current situation, and changing them to a cleaner (in this regard) > style now or later doesn't make a big difference. I don't know about > the "simtel distribution" Chuck mentioned -- it's no problem today > to make distributions in any form (in source, if wanted, including > the GCC sources, already patched possibly; sure, the archive would > be a little bigger, some 15 MB instead of 2 MB, but from my > impression, most Internet users won't even notice the diffrence > today ;-). > > Actually I wonder where this "panic" about gcc integration comes > from. Since some time, I keep hearing these requests every other > week. GPC has been developed for years without such an integration, > and I doubt it would have been essentially better if it was > integrated -- maybe even worse; currently, when there are severe > backend problems (such as the `goto' bug in 2.95 on Solaris/Sparc), > there is the recourse to try another GCC version; if it was > integrated and tied to one GCC version, we'd depend on that version > [Joe da Silva] The advantage of integration is that it will give GPC vastly more exposure to potential users and give them the confidence to try it. For the same reason, this must not be done until it is really ready, otherwise it will just give rise to lots of queries and bug reports, which will slow down further progress. Just MHO. > ... > > Finally, if all that doesn't convince you, I'll put it in a more > selfish way. The main reason why I do GPC development is that I also > use GPC myself, and it's both useful and interesting to improve the > tools I'm using. GCC integration doesn't provide any direct > advantage to my work using GPC, so I don't feel like putting any > unnecessary work in it (which would be caused by hurrying it). > > So, everyone who wants to actually help the GCC integration, just > pick your job from the list above (or another one I may have > missed). So far only Waldek (with the "port" for gcc-3) and Eike > (with the manual license change to FDL, which was another > requirement) have done so (and I have done some things WRT the > Makefiles and in the code which I found also useful independently of > the GCC integration ;-). > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html > GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 > 1707

1 0

Translation Scheme
by a2782＠dis.ulpgc.es 11 Dec '02

11 Dec '02

Didn\'t you go to school? :) Weren\'t you ordered to make a simple compiler which accepted a Pascal subset and generated machine code? I will tell you why do I want this translation scheme. I am involved in a project in which one of its steps is taking a compiler of a language called \'LC99\' (it is very close to Pascal or Algol) which actually generates P-Code (from Pascal compiler P4000) and change it in order to make it generates i386 code. It\'s the first time I make a pure back-end (I\'ve been always working on front-ends, which make me happier :). I am not interested in optimizations, because my project has only academical purposes (it\'s a visualizator of memory implemented over GDB). Of course, implementation of GPC (front-end+Tree+RTL+back-end) crashes with I want to get (lex,parser,semant-->code). I knew it. But I thought any of you had some experience in something like this. Many thanks to Marcel, Frank Heckenbach, Waldek Hebisch, Russell Whitaker, Maurice Lombardi and The African Chief (who has a Pascal-to- 386 compiler which may be helpful to me). Thanks indeed to Joe da Silva ;P. Ciao!

1 0

Re: Translation Scheme
by da Silva, Joe 11 Dec '02

11 Dec '02

Is this a joke? If not, I suggest you find out what "compiler" means! <G> Joe. > -----Original Message----- > From: a2782(a)dis.ulpgc.es [SMTP:a2782@dis.ulpgc.es] > Sent: Wednesday, December 11, 2002 10:31 AM > To: gpc(a)gnu.de > Subject: Translation Scheme > > Hi to all! > > Has anyone a Translation Scheme from Pascal to Intel 80386 code? Or > does anyone know how to get it? > > Thanks in advance.

9 11

gcc-3.2.1_gpc-20021128 16#80000000 difference
by Martin G C Davies 11 Dec '02

11 Dec '02

First, Frank, thanks for the advice on using Initialize to work around my file problem - works a treat. Now I have bumped into a difference (I have an easy workaround for me real code but I thought people might be interested). Build and run the program below. program mgcd_program; var num : integer ; begin num := -2147483648 ; if num = 16#80000000 then writeln( 'equal' ) else writeln( 'not equal' ) end. When I build with Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 2.1 (20020510), based on gcc-2.8.1 I get the output "equal". When I build with Reading specs from /ClearCase_01/mgcd/gcc-3.2.1_gpc-20021128_install.dir/lib/gcc-lib/sparc-sun- solaris2.6/3.2.1/specs Configured with: /ClearCase_01/mgcd/gcc-3.2.1/configure --prefix=/ClearCase_01/mgcd/gcc-3.2.1 _gpc-20021128_install.dir Thread model: posix gpc version 20021128, based on gcc-3.2.1 I get the output "not equal". The C program:- main() { int num = -2147483647 - 1 ; if ( num == 0x80000000 ) printf( "equal\n" ) ; else printf( "not equal\n" ) ; } always returns "equal". Anyway, clearly there is an inconsistency between the GPC versions. Cheers, Martin G C Davies

3 5

Re: Type extension
by Frank Heckenbach 11 Dec '02

11 Dec '02

Frank D. Engel wrote (by private mail, but from the content I suppose it was meant for the list; excuse me if I'm wrong): > How about addition, since in 'subclassing' we would be adding fields: > > TYPE > base = NIL + RECORD > i : INTEGER; > j : INTEGER > END; > > child = base + RECORD > x : REAL; > y : REAL > END; > > otherchild = base + NIL; > > hotdog = NIL + (x : INTEGER; y : REAL); > > cheesedog = hotdog + (t, q : CHAR); > > > Or something similar (prob. the first three preferred; the latter two > are a wild shortcut idea). At first sight, it's certainly a little strange ... BTW, apart from the syntax, the topic reminds me of another thing. For some time, I've had the idea of extensible enum types (unlike with records, there's currently no alternative in GPC, except using integer constants, of course). Even if you have no "forks", that would be useful across modules (where you can't always declare the largest type first, and the other ones as subranges). The situation would be a little different from records -- you could assign a value of a small type to a larger one, not vice versa. You wouldn't need `is' and `as', simple comparisons and assignments will do. I don't know if any dialect has something like this. If not, and we'd make up something new, maybe we could use a common (or similar) syntax with extensible records ... Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

5 7

off topic
by Russell Whitaker 11 Dec '02

11 Dec '02

Hi Today is my 70th birthday. Suspect I'm the oldest subscriber on the list. Russ

2 1

Translation Scheme
by a2782＠dis.ulpgc.es 10 Dec '02

10 Dec '02

Hi to all! Has anyone a Translation Scheme from Pascal to Intel 80386 code? Or does anyone know how to get it? Thanks in advance.

1 0

makefile and crt
by mattias/spikboll 10 Dec '02

10 Dec '02

Hello, I have written a small app for school that uses a small module (written by me) and crt. It compiles fine with --automake, but I need to have a Makefile. My problem is that I don't know how to tell make to find crt.pas & co. should I move crt.pas, gpc.pas and all files they depend on into the build directory? /Mattias Ãstergren -- mattias Ã¶stergren | /"\ compsci student | \ / ASCII Ribbon Campaign gÃ¤vle, sweden | X No HTML in e-mail http://spikboll.net | / \

3 4

bug? writing to stdout from c
by Christopher Ferrall 09 Dec '02

09 Dec '02

I get a segmentation fault when writing to stdout or stderr inside a GPC module called from a C program. I guess I have to set something manually that would be set automatically by the pascal main that isn't set by a c main, but I can't find any reference to this problem in the documentation. --Chris Ferrall ---------------------- C main --------------------- #include <stdio.h> extern Bug(); main () { Bug(); } ---------------------- Pascal module ---------------- module bug; uses GPC ; procedure bug; External; procedure bug; var f : text; begin rewrite(f,'cstring.txt'); writeln(f,'writing to text file okay '); close(f); (* Either of the following commands will cause a segmentation fault *) writeln('writing to standard output not okay'); writeln(StdErr,'writing to stderr not okay'); end; end.

2 1

short bunch of questions
by Francois Schoubben 06 Dec '02

06 Dec '02

hello, I'm using gpc on sparc-solaris for 2 mounths... I have a few questions i can't locate in the documentation i found (so RTFM welcome if you point me the so-called FM :-) ). 1. range check and buffer overflow check are in the todo list (7 in planned feature - misc)... But where is the implementation? nowhere? working on? alpha? beta? implemented but option not documented (yes, i'm dreaming a bit ;-) )? 2. with the crt unit, i can't have the accents (é,è and so on)... My students speeks french, so they find it's strange to eat pTt0 and not pâté :) ). Is it possible to display accent (they have xterm and dtterm ) or no way? 3. again with the crt unit, i can't display colors in xterm. Is it normal? It works in dtterm, but the default color is... black (xterm is white, and by default, it is gray). 4. to solve these problems, i tried to compile crt with -DX11, as said in the doc... I had to install pdcurs24 (from the libs directory) but once done, the -DX11 says me that he can't find the xpanel.h (indeed, it doesn't exists on this package, panel.h exists...) the error is: ---- In file included from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/units/crtx.c:35: /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/units/crtc.c:62: xpanel.h: No such file or directory ---- Thanks for answers... -- Francois Schoubben FUNDP - Namur - Belgium

2 1

Hewlett Packard Pascal compatibility
by John W. Hardy 06 Dec '02

06 Dec '02

A friend of mine wrote an extensive CAD program using HP-Pascal back in the mid 1980s. The program was used exclusively on HP workstations. HP had two variations of Pascal. One was a standalone operating environment, the other worked under HPUX. The CAD program was developed under the workstation version. My friend would like to move this program to the PC world. One approach is "P2C" which converts HP-Pascal code to C. I just discovered GPC and would like to know if it is fairly compatible with HP-Pascal. I'm sure there would be a ton of rewriting that would be necessary whether the P2C or GPC approach is taken, but I would like to get a general idea of GPC compatibility. Thank you very much. John Hardy

6 9

gpc-20021128 (based on gcc-3.2.1): Mingw binaries available
by Prof. A Olowofoyeku (The African Chief) 05 Dec '02

05 Dec '02

Hi all I have put Mingw binaries of the latest gpc snapshot on the gpc web site. This binary package is based on gcc-3.2.1, RC1 (Mingw special), recently released by the Mingw people. You can find the gpc binary here: http://www.gnu-pascal.de/contrib/chief/win32/gcc-3.x/ Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

1 0

Re: Delphi compatibility
by Prof. A Olowofoyeku (The African Chief) 05 Dec '02

05 Dec '02

On 24 Nov 2002, 13:02:36 Martin Liddle wrote: >>On that question the silence of other members of this list has been >>deafening. I can only assume that this is because no-one else is >>interested in Delphi compatibility. If so, then it renders any >>debate moot. If not, then it would be good to hear what others >>think. > >This is free software. The people doing the work are free to do >whatever they want. That is merely to state the obvious - but it is a sad day when this is considered an appropriate response to a question about whether and to what extent a certain feature should be added to GNU software. I didn't think that GNU was about the dictatorship of the maintainers. I doubt that Frank himself would consider the statement: "I do the work, so I can do anything I please" to be sound reasoning or an appropriate response. >Personally I have been happy with Frank's priorities. So have I - and so have (one must assume) most people on this list. That does not dispense with the need sometimes to discuss (and agree or disagree on) important issues. If an issue is important to one person, then it is important and discussion thereon should not be stifled because it irritates, bores, or disinterests others. >I'd much sooner he spent his time working on the compiler than >engage in endless debates on this list. No-one wants to engage in endless debates - and there comes a time when any particular debate must end, and I was the one who brought that one to an end (since it started with a question that I raised). One major difference between liberal and autocratic societies lies in the free flow of information and ideas in the former - even ideas that might be controversial or unpopular. The day that legitimate discussion on difficult or controversial questions becomes stifled or unwanted on this list is the day that I will say goodbye. >For the record, Delphi compatibility would be of some minor interest >to us. This is what I was asking about. And this is the response that answers that question. It is clear that there is little desire here for Delphi compatibility. So be it. At least we now have a clear idea on how people feel about it (presumably those who are silent are not interested). So we can forget about Delphi compatibility, and life can go on. Frank, you're now officially "off the hook", and you can concentrate your efforts on features that people do want ;-). I guess this also signals doom for my "Delphi compatibility" units, which can perhaps quietly disappear. This is not necessarily a bad thing, because I have long been dubious as to whether anyone other than me is using them. I still intend of course to continue to develop them for my own purposes, so those who are interested in them will be able to get updates. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

3 4

Definition files for KATE
by Silvio a Beccara 04 Dec '02

04 Dec '02

Hi all, I use Kate (for KDE) to edit GPC programs. Since not all of the keywords of GPC are listed in the definition file for colour evidentiation for Pascal, I was wondering whether someone has written a complete definition file for GPC. Thanks, best wishes Silvio a Beccara - University of Trento, Italy

3 2

GPC on OS X
by Lance Boyle 04 Dec '02

04 Dec '02

Has anyone moved gpc onto Mac OS X and integrated it with Project Builder? Lance

1 0

Kdevelop
by Silvio a Beccara 02 Dec '02

02 Dec '02

Hello everybody, I've recently seen the Kdevelop environment, which seems quite interesting. Is there a (simple) way of using it with GPC? Thanks, best wishes Silvio a Beccara

1 0

text variable interface problem with gpc-20021111
by Martin G C Davies 30 Nov '02

30 Nov '02

Hi, Testing gpc-20021111 I have hit a problem trying to remove duplicate variables. I've produced a cut-down example and the two sources are:- mgcd_module.pas =============== module mgcd_module interface; export mgcd_module = all; var statfile : text; end. module mgcd_module implementation; end. mgcd_program.pas ================ program mgcd_program; import mgcd_module; #if __GPC_RELEASE__ < 20021111 var statfile : text; #endif begin rewrite(statfile, 'mgcd.statfile'); writeln(statfile, 'some stats'); end. I build and run with the command sequence:- gpc -c mgcd_module.pas gpc -c mgcd_program.pas gpc mgcd_program.o mgcd_module.o a.out and I get a core dump with gpc-20021111. I used to get a core dump with earlier versions until I used the kludge of the duplicate variable - but this is now illegal. The underlying problem appears to be something to do with file data structures not being initialized. Thus the above works with:- gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 2.1 (20020510), based on gcc-2.8.1 but fails with:- gpc -v Reading specs from /ClearCase_01/mgcd/gcc-3.1.1_gpc-20021111_install.dir/lib/gcc-lib/sparc-sun- solaris2.6/3.1.1/specs Configured with: /ClearCase_01/mgcd/gcc-3.1.1/configure --prefix=/ClearCase_01/mgcd/gcc-3.1.1 _gpc-20021111_install.dir : (reconfigured) /ClearCase_01/mgcd/gcc-3.1.1/configure --prefix=/ClearCase_01/mgcd/gcc-3.1.1 _gpc-20021111_install.dir Thread model: posix gpc version 20021111, based on gcc-3.1.1 Hopefully someone can tell me how I can solve/workaround this problem. Martin G C Davies

3 2

gpc-20021128, gcc-3.2.1
by Russell Whitaker 29 Nov '02

29 Nov '02

Hi Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.2.1/specs Configured with: ../gcc-3.2.1/configure --enable-languages=pascal Thread model: posix gpc version 20021128, based on gcc-3.2.1 1. applied patch manually ( as usual ): ok 2. gpc check with -g 72 fail 3. gpc check with -gstabs 0 fail Russ

1 0

Re: Type extension
by Adriaan van Os 27 Nov '02

27 Nov '02

> Seriously, what would be the benefit of adding it? Compatibility for > some existing code, or the guarantee that such records will not > contain any methods, or anything else? Nothing more than a clarification (not wanting OOP methods, but the type extension only) > I currently don't see an easy way out. Unless someone has a > suggestion, I think that kills it (i.e., there must be a syntactic > difference between "inheritable" and normal records). You are right, there must be a be a syntactic difference between "inheritable" and normal records. So, what about: T = EXTENSIBLE RECORD x, y: INTEGER END T0 = RECORD (T) z: REAL END T1 = RECORD (T) w: LONGREAL END Regards, Adriaan van Os

2 1

Probs with variant records
by Wood David 26 Nov '02

26 Nov '02

I've had this happen with DEC Pascal too. Limiting accessible record components seems useful, but in your example, what if aType changes from Circle to Rect. Does a previously set value for Radius become inaccessible? If aType returns to Circle, is the value erased or is the previous value accessible once again? Regards David Wood -----Original Message----- From: Eike Lange [mailto:eike.lange@uni-essen.de] Sent: Tuesday, November 19, 2002 9:11 AM To: Subject: Probs with variant records Hi Folks! I'm not sure wether it's a feature or a bug but I've read, that setting a case selector in variant records makes some variants unavailable from this point. The following program demonstrates, that setting a case selector allows further overwriting of unselected variants: program Fail3; type TGeoType = (Circle, Rect); TGeometry = record X, Y: Integer; case aType: TGeoType of Circle: (Radius: Integer); Rect: (Width, Height: Integer) end; var Geometry: TGeometry; begin with Geometry do begin X := 10; Y := 20; aType := Rect; Radius := 30; Width := 40; Height := 50 end end. Version: ======== Reading specs from /usr/local/bin/../lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20021111, based on gcc-2.95.2 19991024 (release) Eike The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

4 3

Type extension
by Adriaan van Os 26 Nov '02

26 Nov '02

The variable-records discussion on this list has revealed the difficulties of checks on variable records. As a sidebar, I recall that Niklaus Wirth has replaced variant records later (in Oberon) with the much more powerful notion of type extensions. Type extensions can easily be checked, both compile-time and run-time. Adriaan van Os ------------------- [taken from a document by Niklaus Wirth, entitled "From Modula to Oberon"] Type extension The most important addition is the facility of extended record types. It permits the construction of new types on the basis of existing types, and establishes a certain degree of compatibility between the new and old types. Assuming a given type T = RECORD x, y: INTEGER END extensions may be defined which contain certain fields in addition to the existing ones. For example TO = RECORD (T) z: REAL END Ti = RECORD (T) w: LONGREAL END define types with fields x, y, z and x, y, w respectively. We define a type declared by T' = RECORD (T) <field definitions> END to be a (direct) extension of T, and conversely T to be the (direct) base type of T'. Extended types may be extended again, giving rise to the following definitions: A type T' is an extension of T, if T'= T orT' is a direct extension of an extension of T. Conversely, T is a base type of T', if T = T' or T is the direct base type of a base type of T'. We denote this relationship by T' -> T. The rule of assignment compatibility states that values of an extended type are assignable to variables of their base types. For example, a record of type TO can be assigned to a variable of the base type T. This assignment involves the fields x and y only, and in fact constitutes a projection of the value onto the space spanned by the base type. It is important to allow modules which import a base type to be able to declare extended types. In fact, this is probably the normal usage. This concept of extensible data type gains importance when extended to pointers. It is appropriate to say that a pointer type P' bound to T' extends a pointer type P, if P is bound to a base type T of T', and to extend the assignment rule to cover this case. It is now possible to form data structures whose nodes are of different types, i.e. inhomogeneous data structures. The inhomogeneity is automatically (and most sensibly) bounded by the fact that the nodes are linked by pointers of a common base type. Typically, the pointer fields establishing the structure are contained in the base type T, and the procedures manipulating the structure are defined in the same (base) module as T. Individual extensions (variants) are defined in client modules together with procedures operating on nodes of the extended type. This scheme is in full accordance with the notion of system extensibility: new modules defining new extensions may be added to a system without requiring a change of the base modules, not even their recompilation. As access to an individual node via a pointer bound to a base type provides a projected view of the node data only, a facility to widen the view is necessary. It depends on the ability to determine the actual type of the referenced node. This is achieved by a type test, a Boolean expression of the form t IS T' (or p IS P') If the test is affirmative, an assignment t':=t(t'of typeT') or p':= p(p'of type P') should be possible. The static view of types, however, prohibits this. Note that both assignments violate the rule of assignment compatibility. The desired assignment is made possible by providing a type guard of the form t' := t(T') (p' := p(P')) and by the same token access to the field z of a TO (see previous examples) is made possible by a type guard in the designator t (TO).z. Here the guard asserts that t is (currently) of type TO. In analogy to array bound checks and case selectors, a failing guard leads to program abortion. Whereas a guard of the form t(T) asserts that t is of type T for the designator (starting with) t only, a regional type guard maintains the assertion over an entire sequence of statements. It has the form WITH t: T DO StatementSequence END and specifies that t is to be regarded as of type T within the entire statement sequence. Typically, T is an extension of the declared type of t. Note that assignments to t within the region therefore require the assigned value to be (an extension) of type T. The regional guard serves to reduce the number of guard evaluations. As an example of the use of type tests and guards, consider the following types Node and Object defined in a module M: TYPE Node = POINTER TO Object; Object = RECORD key, x, y: INTEGER; left, right: Node END Elements in a tree structure anchored in a variable called root (of type Node) are searched by the procedure element defined in M. PROCEDURE element(k: INTEGER): Node; VAR p: Node; BEGIN p:= root; WHILE (p # NIL) & (p.key # k) DO IF p.key < k THEN p:= p.left ELSE p:= p.right END END; RETURN p END element Let extensions of the type Object be defined (together with their pointer types) in a module M 1 which is a client of M: TYPE Rectangle = POINTER TO RectObject; RectObject = RECORD (Object) w, h: REAL END; Circle = POINTER TO CircleObject; CircleObject = RECORD (Object) rad: REAL; shaded: BOOLEAN END After the search of an element, the type test is used to discriminate between the different extensions, and the type guard to access extension fields. For example: p:= M.element(K); IF p # NIL THEN IF p IS Rectangle THEN ... p(Rectangle).w ... ELSIF (p IS Circle) & ~p(Circle) shaded THEN ... p(Gircle).rad ... ELSIF ... The extensibility of a system rests upon the premise that new modules defining new extensions may be added without requiring adaptations nor even recompilation of the existing parts, although components of the new types are included in already existing data structures. The type extension facility not only replaces Modula's variant records, but represents a typesafe alternative. Equally important is its effect of relating types in a type hierarchy. We compare, for example, the Modula types TO' = RECORD t: T; z: REAL END; TV = RECORD t: T; w: LONGREAL END which refer to the definition of T given above, with the extended Oberon types TO and T1 defined above. First, the Oberon types refrain from introducing a new naming scope. Given a variable rO of type TO, we write rO.x instead of rO.t.x as in Modula. Second, the types T, TO', and T1' are distinct and unrelated. In contrast, TO and T1 are related to T as extensions. This becomes manifest through the type test, which asserts that variable rO is not only of type TO, but also of base type T. The declaration of extended record types, the type test, and the type guard are the only additional features introduced in this context. A more extensive discussion is provided in [2]. The concept is very similar to the class notion of Simula 67 [3], Smalltalk [4], Object Pascal [5], C++ [6], and others, where the properties of the base class are said to be inherited by the derived classes. The class facility stipulates that all procedures applicable to objects of the class be defined together with the data definition. This dogma stems from the notion of abstract data type, but it is a serious obstacle in the development of large systems, where the possibility to add further procedures defined in additional modules is highly desirable. It is awkward to be obliged to redefine a class solely because a method (procedure) has been added or changed, particularly when this change requires a recompilation of the class definition and of all its client modules. We emphasise that the type extension facility - although gaining its major role in connection with pointers to build heterogeneous, dynamic data structures as shown in the example above - also applies to statically declared objects used as variable parameters. Such objects are allocated in a workspace organized as a stack of procedure activation records, and therefore take advantage of an extremely efficient allocation and deallocation scheme. In Oberon, procedure types rather than procedures (methods) are connected with objects in the program text. The binding of actual methods (specific procedures) to objects (instances) is delayed until the program is executed. The association of a procedure type with a data type occurs through the declaration of a record field. This field is given a procedure type. The association of a method - to use Smalltalk terminology - with an object occurs through the assignment of a specific procedure as value to the field, and not through a static declaration in the extended type's definition which then "overrides" the declaration given in the base type. Such a procedure is called a handler. Using type tests, the handler is capable of discriminating among different extensions of the record's (object's) base type. In Smalltalk, the compatibility rules between a class and its subclasses are confined to pointers, thereby intertwining the concepts of access method and data type in an undesirable way. In Oberon, the relationship between a type and its extensions is based on the established mathematical concept of projection. In Modula, it is possible to declare a pointer type within an implementation module, and to export it as an opaque type by listing the same identifier in the corresponding definition module. The net effect is that the type is exported while all its properties remain hidden (invisible to clients). In Oberon, this facility is generalized in the sense that the selection of the record fields to be exported is arbitrary and includes the cases all and none. The collection of exported fields defines a partial view - a public projection - to clients. In client modules as well as in the module itself, it is possible to define extensions of the base type (e.g. TextViewers or GraphViewers). Of importance is also the fact that non-exported components (fields) may have types that are not exported either. Hence, it is possible to hide certain data types effectively, although components of (opaquely) exported types refer to them. -------------------

2 3

gpc supports gcc-3.2.1
by Russell Whitaker 25 Nov '02

25 Nov '02

Hi all Now that gcc-3.2.1 has just been released so downloaded it and tried it with gpc: 1. Patch for 3.1.1 works with some comlaints about offsets: expr.c: function.c: hunk 2 4858 offset 2 hunk 2 314 offset 1 hunk 4 4910 offset 2 hunk 3 5491 offset 1 hunk 6 5038 offset 2 hunk 4 5510 offset 1 stor-layout.c: tree.c: hunk 3 1569 offset 27 hunk 3 4745 offset 59 hunk 5 1704 offset 27 hunk 5 4788 offset 59 hunk 7 4826 offset 59 tree.h hunk 2 2495 offset 27 2. Compiled with no problem. Installed with no problem. Compiled "hello.pas", it runs. 3. Ran test suite "as is". Got 165 errors, most of these refered to "dwarf2out.c:7572", some to "dwarf2out.c:5055" and a few seg faults. Suspect if you could figure what went wrong at those two dwarf2out locations you'd have it made. 4. Re-ran test suite with -g0. No errors. Russ

3 2

Probs with variant records
by Eike Lange 25 Nov '02

25 Nov '02

Hi Folks! I'm not sure wether it's a feature or a bug but I've read, that setting a case selector in variant records makes some variants unavailable from this point. The following program demonstrates, that setting a case selector allows further overwriting of unselected variants: program Fail3; type TGeoType = (Circle, Rect); TGeometry = record X, Y: Integer; case aType: TGeoType of Circle: (Radius: Integer); Rect: (Width, Height: Integer) end; var Geometry: TGeometry; begin with Geometry do begin X := 10; Y := 20; aType := Rect; Radius := 30; Width := 40; Height := 50 end end. Version: ======== Reading specs from /usr/local/bin/../lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20021111, based on gcc-2.95.2 19991024 (release) Eike

6 16

Re: Delphi compatibility
by Markus Gerwinski 25 Nov '02

25 Nov '02

Marco van de Voort wrote: > Ever wondered that this might be simply to avoid problems with the RAD scanning part, > and the fact that the syntax highlighting is done by the compiler itself? > > You are so obsessed with putting a C stamp on Delphi that you miss the obvious :-) Just didn't know this particular problem... vi doesn't give me syntax highlighting anyway. ;-) But yes, since I was forced to work with Delphi for a year, I might be a little bit obsessive about it.

1 0

Probs with recursive operator
by Eike Lange 25 Nov '02

25 Nov '02

Hi Folks! The following operator calls itself recursive: program Operator1; operator + (a, b: Integer) = c: Integer; begin WriteLn ('Play it again, Sam.'); c := 2 * a + b end; begin WriteLn ('2 + 3 = ', 2 + 3) end. Is there a way to tell my new operator, which '+' should be used in the operator's body? I know, I could cast or use other types in the operator's body, but the code would become bloated. Are user-defined operators intended to be used with user-defined types only? Eike

2 1

GPC with Emacs 21
by Florian Lindner 21 Nov '02

21 Nov '02

Hello, I'm looking for a tutorial or How-To for using GPC with Emacs 21 and pascal-mode. Thx, Florian

2 1

Re: Probs with variant records
by Emil Jerabek 21 Nov '02

21 Nov '02

On Wed, Nov 20, 2002 at 11:37:16AM -0500, CBFalconer wrote: > Emil Jerabek wrote: > > On Tue, Nov 19, 2002 at 04:55:47PM -0500, CBFalconer wrote: > > > "J. David Bryan" wrote: > > > > On 19 Nov 2002 at 12:00, CBFalconer wrote: > > > > [...] > > > > > > Now, where is the compiler going to get the values of minval and > > > maxval? To do so it would have to read a, and translate that > > > somehow into minval and maxval at run time. Where are those > > > tables stored? Nothing insists that a be a valid initialized > > > value before storing something in onebyte. Remember, onebyte and > > > twobyte have the same offsets. They can store different > > > subranges. a may have been set in another procedure far, far > > > away. > > > > Don't understand this. The problem was to check that the component > > accessed is valid, which is as simple as ``r.a = 1?'' in your > > example. Anyway the range check which you seem to be talking about > > is also easy: the code stores something into r.twobyte, > > hence the value should be range-checked against the definition > > of twobyte, i.e. minval = -5 and maxval = 512. These bounds are > > known at compile time, and they have nothing to do with the current > > value of r.a. > > Sorry, no, that is not the problem. The problem is to check the > storage into twobyte, IN ISOLATION. To check that such storage is > possible requires READING the a value. There is no guarantee that > a has already been initialized, AFAIK. At run time, even if a can > be read, there is no place to find the twobyte limits. The > compiler tables have long been discarded. To use them would > require storing them (or a subset) in the object code, and could > take a great deal of space. Consider a record type with 100 Checking that an assignment to the twobyte variant is legal does require reading the value of a, and I can't imagine any useful run-time check which wouldn't need to read some value :-) Once again, range check on the _value_ which is assigned to rcd.twobyte is an independent problem, and it needs only to know the bounds for the twobyte variant, not the whole (possibly large) table of such bounds for other variants. But maybe J. Bryan's last two posts explain this more clearly. > variants. The table must consist of at least 100 each minima and > maxima. This is done all over again for each potential variant > record type. Code has to be generated to access and index that > table for every store into a variant item. We would probably also > need to maintain a value for a outside it's normal range to > indicate it has not been set, which forbids access to any variant. > > It gets worse. The variants may be arrays of different sizes of > differently sized components. Now we have to check the index > value against some table and then check against the component > limits. We do this at run-time, without the benefit of compiler > symbol tables. Or the variants may have variants. > > Note again the fact that the 'a' need not have been initialized > when the twobyte storage is done. > > This would be Microsoftian code bloat. I am not saying it is > impossible, just that it is neither trivial nor really practical. > Range (or any other run-time) checking is always a code bloat. Its purpose is to assist debugging, and then it doesn't matter much that the code is huge and slow. > Let's do the easy stuff first. Range checking of indices and > subranges, thinking of characters and booleans as subranges of > integers. That will uncover most of the errors. > > BTW, I believe something similar has already arisen in the usage > of variant 10206 strings, where there is a need to store a > capacity for each variant. In this case gpc has chosen to > allocate completely separate storage areas for each variant, just > to get the effect of such a table. I have other ideas on this, > which don't belong in this thread. > > > > > > In addition, the compiler knows that it is storing a twobyte > > > value. If it got it from something of appropriate type it knows > > > it need not do a check on this store, and can totally elide the > > > CHK operation. No such efficiencies if we have to read and > > > translate the a value first. > > > > > > Without that check the only differences for storing onebyte and > > > twobyte are the (known at compile time) values of minval and > > > maxval, and quite possibly the operand of STI, which specifies the > > > size of the thing to be written. > > > > > > In other words full checking here is a monstrous can of worms. > > > > > > Checking that the variant selector is in range never enters into > > > it (except when storing that value at some other time). The names > > > > Yes, it does. Here, the ``range'' was 1 .. 1, but the ISO 10206 > > standard permits a general range (or list of ranges) in such a situation. > > I am not really familiar with the 10206 spec, much more familiar > with 7185, so I'll take your word on the otherwise usage and the > range ranges. That just makes the problem more intractable. Yes. But I think this feature is rarely used in practice, it's probably included in the standard just to make the syntax of variant records parallel to case statements. Emil > Permitting them in the variant CASE means they need to be > available in the executable code CASE, but the converse does not > necessarily apply. Which is not germane anyhow. > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address! >

1 0

Bug with Card
by Eike Lange 20 Nov '02

20 Nov '02

Hi Folks! The following program does not work: program Fail1; var MySet: Set of Char = ['b', 'a', 'r']; begin WriteLn (Card (MySet)); { works } WriteLn (Card (['f', 'a', 'i', 'l'])) { fails } end. GPC-Version: ============ gpc 20021111, based on gcc-2.95.2 19991024 (release) Error: ====== ../../../gcc-2.95.2/gcc/p/rtscall.c:333:actual_set_parameters: failed assertion 'TREE_CODE (TREE_TYPE (TREE_TYPE (val))) != VOID_TYPE' fail1.pas: In main program: fail1.pas:8: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. Eike

3 2

Bug? Comparison between Const and Real fails
by Eike Lange 20 Nov '02

20 Nov '02

Hi Folks! The following comparision between a const and a Real value does not work as expected: program Fail2; const ConstSize = 1.2; var VarSize: Real = 1.2; begin if ConstSize <> VarSize then begin WriteLn (ConstSize - VarSize : 0 : 20); WriteLn ('Fails') end else WriteLn ('Works') end. Output: ======= 0.00000000000000004445 Fails Version: ======== Reading specs from /usr/local/bin/../lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20021111, based on gcc-2.95.2 19991024 (release) Eike

2 3

Re: gpc-20021111 supports gcc-3.1.1
by Waldek Hebisch 19 Nov '02

19 Nov '02

Maurice Lombardi wrote: >That was part of the solution. With this patch it goes up to the compilation >of strings.pas. It dies with > >------------------------------------------------------------------ > >../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes >-Wmissing-declarations -g -O2 --unit-path=/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts >--automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat >/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.11'" >/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts/string.pas >gpc1.exe: internal error: Segmentation violation >Please submit a full bug report, >with preprocessed source if appropriate. >See <URL:http://www.gnu-pascal.de/todo.html> for instructions. >make.exe[3]: *** [string.o] Error 1 >make.exe[3]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gcc/p/rts' >make.exe[2]: *** [pascal.rts] Error 2 >make.exe[2]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gcMaurice Lombardi wrote: >That was part of the solution. With this patch it goes up to the compilation >of strings.pas. It dies with > >------------------------------------------------------------------ > >../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes >-Wmissing-declarations -g -O2 --unit-path=/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts >--automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat >/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.11'" >/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts/string.pas >gpc1.exe: internal error: Segmentation violation >Please submit a full bug report, >with preprocessed source if appropriate. >See <URL:http://www.gnu-pascal.de/todo.html> for instructions. >make.exe[3]: *** [string.o] Error 1 >make.exe[3]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gcc/p/rts' >make.exe[2]: *** [pascal.rts] Error 2 >make.exe[2]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gc >make.exe[1]: *** [stage2_build] Error 2 >make.exe[1]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gcc' >make.exe: *** [bootstrap] Error 2 > I was able to reproduce the problem in cross-compiler targetting djgpp. Looks like another bug with debug info. Try re-making with 'CFLAGS=-O2'. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 3

Re: Probs with variant records
by Wood David 19 Nov '02

19 Nov '02

Hi, I've tried Eike's example with DEC Pascal (no errors) and looked at the ref. manual. This notes that a variant must be the last component of the record (which it is). It also makes sense as the allocated memory can then be set to the biggest variant. There is also a run-time diagnostic (%PAS-F-REFINAVAR) which should pick up any attempt to read from or write to an inactive record variant. However, it is clear that this isn't happening - it should. GPC should as well. Experimenting with the data, I find that they do share memory - as soon as Width is assigned, Radius takes this value (if the types match). If Radius is a real, the value becomes scrambled. Run-time checking should be available, as the only benefit of variants is to either save memory or pick-up on erroneous data combinations. However, just like array bounds checking, it may be an undesirable overhead for which there should be appropriate compiler options. Dave Wood. The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

1 0

gpc driver
by Prof A Olowofoyeku (The African Chief) 18 Nov '02

18 Nov '02

Hi all Is anyone else interested in having environment variables for the GPC driver to cover things like "unit-path", etc.? I think that being able to set things like that (in addition to GxC_EXEC_PREFIX and LIBRARY_PATH, etc.) might be very useful to people who don't want to (or who don't know how to) use Makefiles, or who don't want very long command lines, or whatever other reason. I personally would like to be able to set something like: UNIT_PATH OBJECT_PATH, etc. I might well patch the GPC driver for Mingw to do just that - but I just thought I might not be the only one who might find something like this useful, and if so, then perhaps this could be added to the main GPC sources. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

5 14

Bug in lexer
by CBFalconer 18 Nov '02

18 Nov '02

The following source (cut down already) PROGRAM pprt(input, output); (* Nils Goesche <ngo(a)cartan.de> wrote in comp.programming 0 is defined as the empty set -- denoted {} 1 is defined as the set that contains 0 -- {0} = {{}} 2 is defined as the set containing 0 and 1 -- {0, 1} = {{}, {{}}} and so on. (Mathematicians will note that to have this ``definitionÂ´Â´ make sense, you'll first have to introduce the notion of an inductive set and the infinity axiom -- but I think this is enough to explain the idea behind the construction). Now, the programming problem is to produce a nice, pretty printed definition of a natural number n. *) VAR n : integer; (* 1----------------1 *) PROCEDURE prettyprt(n : integer); BEGIN (* prettyprt *) END; (* prettyprt *) (* 1----------------1 *) BEGIN (* pprt *) REPEAT write('Value to display: '); readln(n); IF n >= 0 THEN prettyprt(n); writeln; UNTIL n < 0; END. (* pprt *) results in the following error from gpc > [1] c:\p\pprt>gpc -v pprtx.p > Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.953/specs > gpc version 20020910, based on 2.95.3 20010315/djgpp (release) > c:/djgpp/lib/gcc-lib/djgpp/2.953/gpcpp.exe -lang-pascal -v -famtmpfile=c:/djgpp > /tmp\ccaaaaaa -fstandard-pascal -D__STANDARD_PASCAL__ -fmixed-comments -undef -D > __GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__=2 > .1 -D__GPC_RELEASE__=20020910 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN > __=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -Dunix -Di386 -DGO32 > -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 > -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asy > stem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i38 > 6) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/lib/gcc-lib/d > jgpp/2.953/djgpp.ver -remap pprtx.p c:/djgpp/tmp\ccSv07U1.i > GNU Pascal Compiler PreProcessor version 20020910, based on gcc-2.95.3 20010315/ > djgpp (release) (80386, BSD syntax) > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > c:/djgpp/i586-pc-msdosdjgpp/include > c:/djgpp/lib/gcc-lib/djgpp/2.953/include > c:/djgpp/include > End of search list. > pprtx.p:32: unterminated string or character constant > pprtx.p:10: possible real start of unterminated constant I suspect something in the quoted comment line 10 is driving it up the wall, such as a "'". gpc is being run through an alias that supplies --standard-pascal. Are you trying to have the lexer do too much at once? Once a comment is started nothing except *) (or maybe } or EOF) should close it. I took the isolated ' out of the comment, and the error changed. So I think there is enough to annoy it in there. It compiles through rhide150b though! Also PascalP has no problem. -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

3 3

GPC with Emacs
by Florian Lindner 17 Nov '02

17 Nov '02

Hello, I'm looking for a tutorial or How-To for using GPC with Emacs 21 and pascal-mode. Thx, Florian

1 0

Dropping some predefined symbols
by Frank Heckenbach 16 Nov '02

16 Nov '02

Hi, as you might know, GPC predefines some symbols depending on the dialect options given on the command-line, e.g., `__BORLAND_PASCAL__' if `--borland-pascal' was given, so programs/units can check the dialect in `{$ifdef}' directives. Actually, I'm not sure if it's used at all -- generally it's better to write a program/unit for one specific dialect and, especially in case of units, put the respective dialect option (`{$gnu-pascal}' if the default is wanted) at the top, so it doesn't matter if the main program is compiled with a different dialect. However, the main problems with those symbols are that the internal handling is a little ugly and, what's more, that the symbols don't change when the dialect is changed via a compiler directive. E.g., the following program writes 3 times 'BP' if compiled with `--borland-pascal' and 3 times 'GPC' if not (unlike what one might expect): program Foo; begin {$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif} {$gnu-pascal} {$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif} {$borland-pascal} {$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif} end. Of course, it would be possible to change the behaviour, but this will take some effort and it would be rather obscure having the dialect options change the defines (e.g., what if the symbol corresponding to the previous dialect was defined manually, should it still be unset?). However, there's already an alternative that works well, that's `{$ifopt}'. The following program outputs what one would expect. program Foo; begin {$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif} {$gnu-pascal} {$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif} {$borland-pascal} {$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif} end. `{$ifopt}' has been supported for quite some time, at least before GPC 2.1, so programs will not require a new GPC version or a GPC version conditional when changed to `{$ifopt}'. Therefore, to avoid confusion about the behaviour of the symbols (and to clean up GPC as always), I'd like to drop them. Any objections? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 1

Re: gpc-20021111 supports gcc-3.1.1
by Frank Heckenbach 16 Nov '02

16 Nov '02

Prof A Olowofoyeku (The African Chief) wrote: > I am building the snapshot at the moment for Mingw (gcc-2.93-8). The > build process halted with errors relating to undefined "sys_siglist" in > gpc.c. I checked up on this, and had to comment out the declaration > below: > "#define strsignal(N) (sys_siglist[(N)])" > > Under Mingw strsignal() is defined in libiberty.h, In gcc-2.95.3 (I assume your 2.93 was a typo) the declaration in libiberty is commented out. Does Mingw use some special patches to libiberty.h? If so, what do they look like? If they `#define strsignal', it should be enough to put an `#ifndef strsignal' around the definition in gpc.c. Or does it provide an external declaration? Try the following: --- /home/gpc/orig/gpc.c Wed Nov 6 07:35:25 2002 +++ /home/gpc/p/gpc.c Thu Nov 14 00:38:03 2002 @@ -125,17 +125,21 @@ #define PEXECUTE_LAST 2 #define PEXECUTE_SEARCH 4 #define PEXECUTE_VERBOSE 8 +#ifndef HAVE_STRSIGNAL +#define strsignal(N) (sys_siglist[(N)]) +#endif #endif #if defined (EGCS) && !defined (EGCS97) +/* If the system doesn't provide strsignal, we get it defined in + libiberty but no declaration is supplied. */ +#if !defined (HAVE_STRSIGNAL) && !defined (strsignal) +extern const char *strsignal PARAMS ((int)); +#endif #undef _ #define _(String) String #endif #ifndef HOST_BIT_BUCKET #define HOST_BIT_BUCKET "/dev/null" -#endif - -#ifndef HAVE_STRSIGNAL -#define strsignal(N) (sys_siglist[(N)]) #endif #ifdef GCC_2_95_3 > but it seems that > the configure script doesn't look there. I suppose not. Since libiberty.h is distributed with gcc, it can assume it knows what's in there. Or is for some reason another libiberty.h (system-wide installed) used instead of the one that comes with gcc? That might be a bug in the build process. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

4 7

installation problem with gcc 3.1.1
by Emil Jerabek 16 Nov '02

16 Nov '02

Hi, after building gpc 20021111 with the 3.1.1 backend (on Linux/IA32) I've installed it by "make pascal.install-with-gcc". The compiler then wouldn't compile even a trivial "program p; begin end.", collect2 died with a complain that it can't find libgcc_eh (sorry, I'm writing this on another machine, and I don't recall the exact error message). libgcc_eh.a was actually built, and moving it to the destination directory solved the problem, so I assume the trouble is in the above mentioned target in the Makefile. Emil

2 1

gpc-20021111 supports gcc-3.1.1
by Frank Heckenbach 16 Nov '02

16 Nov '02

Hi, I've uploaded a new alpha (gpc-20021111) to http://gnu-pascal.de/alpha/ It contains large changes compared to the previous version, as can be seen from the size of the diff file (if you've always fetched the diffs and were going to sometime get a fresh tarball in order to have a "reference point", now might be a good time ;-). The most important change is that GPC now works with gcc-3.1.1 (i.e., with the backend sources of gcc-3.1.1; the version of GCC used to compile GPC itself should not matter), thanks to Waldek Hebisch's patches. However, please note that this port is very new, and has not been tested as much as the gcc-2.x based GPC's. Thw two code generation bugs I mentioned in a recent mail have been fixed. There's only one new known bug with gcc-3.1.1 (fjf341b.pas), but it is a compile-time problem and only occurs in a very special situation. I'll try to fix it soon, but I didn't want to furter delay this release because of it. Debug info generation with gcc-3.1.1 is partially broken. The dwarf debug info format doesn't work yet. Since it's now the default under, e.g., Linux, you might want to try `-gstabs' (use the stabs format which was the default with gcc-2.x). Debug info for object methods also doesn't work yet, so if you use objects, you'll probably have to compile without debug info for now. If you need GPC in a production environment, we recommend not to use GPC based on gcc-3.1.1 yet. But we'd welcome if you like to help testing with gcc-3.1.1. In this case, please don't report any bugs related to debug info (for now). In particular, if you run the test suite, add `EXTRA_TEST_PFLAGS=-g0' on the test make command line (because otherwise, debug info is turned on by default when testing). I expect that most new bugs will be compiler crashes on wrong input programs (instead of in in addition to proper error messages). Please report them (as well as any other bugs, of course). You might want to try configuring GPC with `--enable-checking' (both for gcc-2.95.x and gcc-3.1.1). This will enable additional internal checks which make the compiler (not the generated code) a little slower, but may detect possible problems earlier and better. The compiler will abort with internal errors (usually tree check errors) then. Please also report such cases. The rest of the changes of this GPC release are mostly internal cleanups, in connection with the gcc-3 port and to generally make the compiler more robust -- though they might cause a few minor new problems in the short term, but that's what alphas are for. If you can, please test it with your code and report any new problems so we can fix them soon. There are also some changes in the automake mechanism again (thanks to Marten Jan de Ruiter for analysis and code). They should make it substantially faster in situations with many units where most of them are already up to date. I hope the changes don't break anything, but those who use automake in complex projects might want to test it carefully. As announced, I dropped the syntax `type foo = procedure (Integer, Real)' (i.e., without parameter names). If anyone had used it and gets errors now, just add the parameter names, and put a `;' in place of the `,'. Also, many obsolete and C-ish features from the preprocessor have been dropped. I suppose most of them were unknown to almost all GPC users, anyway, and I hope the change won't affect anyone. Those interested can find the details in the ChangeLog (entry of 2002-09-29 under gpcpp.c). Another possibly incompatible change is that GPC will now reject duplicate variable declarations (not yet for routines; I'll also do this, but it will be more complicated due to interfaces, `forward' declarations etc.). Of course, the new behaviour is according to (and even demanded by) the standard. It should only affect those who used "header files" in a C-ish way by which every "module" gets "external" declarations of its own variables. But since GPC has been supporting two real mechanisms for modularization (EP modules and BP units) for a long time, this should be no big issue, I hope. For a long time, it was not possible to build GPC when the `p' directory is a symlink in the gcc directory. This is now possible. Furthermore, GPC no more modifies the Makefiles depending on the GCC version. So it is now possible to use the same GPC source tree for building with several GCC versions at the same time (provided you use a separate build directory which is strongly recommended, anyway). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

3 4

Environment Variables within Code.
by Andrew McCall 15 Nov '02

15 Nov '02

Hi, Is it possible to access environment variables within gpc code, for example $USER ? -- Thanks, Andrew McCall Internet/Linux System Administrator I.C.T. Division Oldham MBC Civic Centre West Street Oldham OL1 1UU Tel : 0161 911 3990 Fax : 0161 911 3998 Email : it.andrew.mccall(a)oldham.gov.uk ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.oldham.gov.uk **********************************************************************

5 4

problem when compiling gpc20021111 with gcc-2.95.3 under djgpp
by Maurice Lombardi 13 Nov '02

13 Nov '02

Hi, Doing the build as usual, compilation dies at stage 2 when compiling the rts: --------------------------------------------------------------------------- c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/xgpc -Bc:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/ -Bc:/djgpp/i586-pc-msdosdjgpp/bin/ -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 --unit-path=/dev/c/djgpp/b/gnu/gcc-2.953/gcc/p/rts --automake --print-needed-options "/dev/c/djgpp/b/gnu/gcc-2.953/gcc/p/rts/endian.pas" 2> "needed-options" || true if grep -v '^--' "needed-options" > /dev/null; then echo "needed-options: `cat "needed-options"`" >&2; rm -f "needed-options"; false; else true; fi needed-options: gpcpp.exe: usage: c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/gpcpp.exe [switches] input output make.exe[2]: *** [needed-options] Error 1 make.exe[2]: Leaving directory `c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/p/rts' make.exe[1]: *** [pascal.rts] Error 2 make.exe[1]: Leaving directory `c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc' make.exe: *** [all-gcc] Error 2 --------------------------------------------------------------------------- there have been many changes in gpcpp.c The only djgpp-related patch in the p directory now fails. it was ---------------------------------------------------------------------------- --- gpcpp.c.orig Thu Mar 29 16:56:24 2001 +++ gpcpp.c Thu Mar 29 17:22:06 2001 @@ -2480,6 +2480,21 @@ default_len = strlen (default_prefix) - 7; default_prefix[default_len] = 0; } + +#ifdef __DJGPP__ + for (p = include_defaults; p->fname; p++) { + if (strncmp(p->fname,"$DJDIR",6)==0) { + char * djdir = getenv("DJDIR"); + if (djdir) { + char * nwname = (char *) xmalloc (strlen(djdir)+strlen(p->fname)-5); + strcpy (nwname, djdir); + strcat (nwname, p->fname+6); + p->fname=nwname; + } + } + } +#endif + /* Search "translated" versions of GNU directories. These have /usr/local/lib/gcc... replaced by specd_prefix. */ if (specd_prefix != 0 && default_len != 0) ----------------------------------------------------------------------------- It was used to make known the djgpp root directory for includes, but all this part has been changed. I have rerun the offending instruction with addition of the -v option. result is ------------------------------------------------------------------------------ Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.953/specs gpc version 20021111, based on gcc-2.95.3 20010315/djgpp (release) c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/gpcpp.exe -v -I. -isystem c:/djgpp/b/gnu /gcc-2.953/build.djg/gcc/include -isystem c:/djgpp/i586-pc-msdosdjgpp/bin/includ e -famtmpfile=c:\djgpp\tmp\ccFZUxzs.gpa -funit-path=/dev/c/djgpp/b/gnu/gcc-2.953 /gcc/p/rts -fautomake -fprint-needed-options -fdelphi-comments -D__GNU_PASCAL__ -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__ =2.1 -D__GPC_RELEASE__=20021111 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDI AN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -Dunix -Di386 -DGO3 2 -DDJGPP=2 -DMSDOS -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ - D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) - Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -W -Wall -Wpointer-arith -Wwrite-strin gs -Wmissing-prototypes -Wmissing-declarations -Acpu(i386) -Amachine(i386) -Di38 6 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/b/gnu/gcc-2.953/build .djg/gcc/djgpp.ver -remap /dev/c/djgpp/b/gnu/gcc-2.953/gcc/p/rts/endian.pas c:\d jgpp\tmp\ccaPFVYK.i GNU Pascal Compiler PreProcessor version 20021111, based on gcc-2.95.3 20010315/ djgpp (release) (80386, BSD syntax) gpcpp.exe: usage: c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc/gpcpp.exe [switches] in put output [exited with 1] ------------------------------------------------------------------------------ Any hint ? 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

2 2

Re: gpc-20021111 supports gcc-3.1.1
by Frank Heckenbach 13 Nov '02

13 Nov '02

Matthias Klose wrote: > attached are the testsuite results for a gcc-3.2.1 (prerelease) based > gpc, built for i386-linux: As I said, debug info is broken with gcc-3. Please test with `-g0'. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Calling Pascal routines from C
by Markus Gerwinski 12 Nov '02

12 Nov '02

Hi folks, I'm currently trying to call a Pascal routine from within a C program. To this mail I attached a few sources demonstrating the way I'm trying to do so. Compiling them with gpc -c foo.pas gcc footest.c -o footest leads to an error message "undefined reference to `Bar'". What am I doing wrong? Thanks in advance Markus

5 11

Writing applications working with DB in GPC
by Nick Ioffe 11 Nov '02

11 Nov '02

Hi! Is there any packages to communicate with DB in GPC. The DB is SQL compatible, ORACLE prefferable. Thank you in advance, Nick

2 1

Is there a Graph unit?
by Waldek Hebisch 10 Nov '02

10 Nov '02

One of the first thing newcomers from TP want is Graph unit. Is there such thing for GPC (using X11 for output)? I have fetched GRX from the web site, but as I understand it is not compatible with TP Graph unit. On the web site there is also C library for BGI emulation. Is there a Pascal interface to it? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 2

what's the status of gcc-3 based gpc?
by George Shapovalov 09 Nov '02

09 Nov '02

Hi guys. First I would like to thank everybody involved for the really nice and hard work on making this compiler rock! Frank: you may remember, that I am a developer for Gentoo Linux (http://www.gentoo.org). Recently we announced the availablity of gcc-3.2 based profile (we skipped 3.1 series as the ABI was changed once again, though gcc guys promised to stabilize it now. We'll see :)). The gcc-2.95.x based profiles are supported still and will be supported for quite some time to come (and this is one of the niciest features of source based distro in play), so we still have the working version of gpc available. Nonetheless, our gcc-3.2 based profile is quite stable at the moment and I would be interested in getting gpc to play nicely along. Therefore I would like to ask about the present state of the gpc development on the gcc-3 backend. I am thinking about creating the ebuild for the gcc-3 based gpc to let interested users sample and test it. The ebuild will have a "for testing" status - i.e it will not be considered stable, until you decide to make a release. We will soon have an ability to support cvs based ebuilds (that is it gets built from the present cvs code). Such ebuilds never get stable status, but are perfectly fit for this purpose. Meanwhile I can do snapshot based ebuild and periodically update it (this is generally as easy as just renaming it, provided the build procedure does not change). Please let me know what do you think about this and where I can get the source. I tried to search the site, however I was unable to easily find the gcc-3 based source (and the 20020910 snapshot says it does not support gcc-3). George >As an aside: As you may have read, Waldek Hebisch and I are working >on the port to gcc-3 (it's not completely stable yet, but partially >usable). One of the major drawbacks of gcc-2 is the internal memory >management system ("obstacks") which has caused us many toubles in >GPC. This bug, again, was related to obstacks, so in fact your test >worked already with the gcc-3 based GPC. However, I've now fixed the >real problem so it also works with obstacks (which was also >necessary to fix a related problem I discovered while debugging it >(fjf704.pas) and to made the code cleaner, anyway). > >Frank

2 1

BUG? empty else
by Eike Lange 08 Nov '02

08 Nov '02

Hi Folks! The following program compiles without warnings: { 2.1 (20020510), based on gcc-2.95.2 19991024 (release) } program bug; var i: Integer = 1; begin if i = 1 then WriteLn ('is 1') else if i = 2 then { do nothing } else { do nothing } end. Eike

4 14

Random number generator
by Wood David 07 Nov '02

07 Nov '02

Andrew McCall was looking for a random number generator. I use this bit of code which I like because it is integer based and so gives the same answers on different machines. I think it originally came from Numerical Recipes in Pascal: VAR { These need to be global / static } random_seed : INTEGER; { General purpose random seed } random_source : ARRAY [0..15] OF INTEGER:= (0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0); { 16 integers used by randgen to construct pseudo-random numbers } FUNCTION randgen( VAR random_seed : INTEGER ): DOUBLE; VAR i, x : integer; BEGIN IF random_seed < 0 THEN { Setup seed array } BEGIN random_seed:= -random_seed; FOR i:= 0 TO 15 DO BEGIN random_seed:= (UINT(random_seed)*2416 + 374441) MOD 1771875; random_source[i]:= TRUNC(random_seed*0.5643738); END; END; x:= random_source[15]+random_source[0]; x:= x MOD 1000000; FOR i:= 0 TO 14 DO random_source[i]:= random_source[i+1]; random_source[15]:= x; randgen:= x*0.000001; END; It's actually two random number generators in one! If you call it first with a negative integer random seed it sets up the array of 16 integers (in random source). These are used to generate the random number between 0 and 1 to 6 decimal places. This is a non-repeating sequence of 1 million random numbers. It also returns a new positive random seed which can be negated later on and used to generate another different non-repeating sequence of 1 million random numbers. Regards David Wood QinetiQ, Farnborough, Hants The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

4 4

Re: Questions about coding...
by da Silva, Joe 06 Nov '02

06 Nov '02

Well, one final oversight to deal with ... To be inclusive of 0, you need to change "iGuess > 0" to "iGuess >= 0". Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Wednesday, November 06, 2002 9:35 PM > To: gpc(a)gnu.de > Subject: Re: Questions about coding... > > Andrew McCall wrote: > > > > Well, I have just been getting used to programming in Pascal again, > > and I thought I would write the age-old number guessing game. It > > all works, well it *should* but I seem to be having problems with > > some logic in an if statement: > > > > if (iGuess > 0) or (iGuess < 101) then > > { do my code } > > > > I thought this bit of code should detect if iGuess is inbetween 0 > > and 100, but it doesn't seem to work! Can anyone tell me why? > > Try 'and'. The above is synonymous with 'true'. > > Set your outgoing line length wrap to something well under 80. I > use 65. > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address! > >

1 0

Gpc won't compile under solaris x_86...
by Juha Korkiakangas 06 Nov '02

06 Nov '02

hi, I'm trying to compile gpc-20020910 with gcc-2.95.1 on Solaris_x86 but I get two different error-message depending what make I'm using. I'm not getting any error messages when running configure with options --enable-languages=pascal. ----with gmake----------------- ../.././xgpc -B../.././ -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /export/home/juha/gcc-2.95.1/gcc/p/rts/rts-version`'" --unit-path=/export/home/juha/gcc-2.95.1/gcc/p/rts --automake --print-needed-options "/export/home/juha/gcc-2.95.1/gcc/p/rts/endian.pas" 2> "needed-options" || true if grep -v '^--' "needed-options" > /dev/null; then echo "needed-options: `cat "needed-options"`"; rm -f "needed-options"; false; else true; fi /export/home/juha/gpc-build/gcc/xgcc -B/export/home/juha/gpc-build/gcc/ -B/usr/local/i386-pc-solaris2.8/bin/ -I/usr/local/i386-pc-solaris2.8/include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /export/home/juha/gcc-2.95.1/gcc/p/rts/rts-version`'" /export/home/juha/gcc-2.95.1/gcc/p/rts/rts.c /export/home/juha/gcc-2.95.1/gcc/p/rts/rts.c: In function `_p_StatFS': /export/home/juha/gcc-2.95.1/gcc/p/rts/rts.c:1387: warning: passing arg 2 of `statvfs64' from incompatible pointer type /export/home/juha/gpc-build/gcc/xgcc -B/export/home/juha/gpc-build/gcc/ -B/usr/local/i386-pc-solaris2.8/bin/ -I/usr/local/i386-pc-solaris2.8/include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /export/home/juha/gcc-2.95.1/gcc/p/rts/rts-version`'" /export/home/juha/gcc-2.95.1/gcc/p/rts/file.c /export/home/juha/gpc-build/gcc/xgcc -B/export/home/juha/gpc-build/gcc/ -B/usr/local/i386-pc-solaris2.8/bin/ -I/usr/local/i386-pc-solaris2.8/include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /export/home/juha/gcc-2.95.1/gcc/p/rts/rts-version`'" /export/home/juha/gcc-2.95.1/gcc/p/rts/rts-va.c ../.././xgpc -B../.././ -c -g -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /export/home/juha/gcc-2.95.1/gcc/p/rts/rts-version`'" --unit-path=/export/home/juha/gcc-2.95.1/gcc/p/rts --automake `cat needed-options` /export/home/juha/gcc-2.95.1/gcc/p/rts/rtsc.pas <implicit code>:22: Internal compiler error in `output_type', at dwarfout.c:4366 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gmake[2]: *** [rtsc.o] Error 1 gmake[2]: Leaving directory `/export/home/juha/gpc-build/gcc/p/rts' gmake[1]: *** [pascal.rts] Error 2 gmake[1]: Leaving directory `/export/home/juha/gpc-build/gcc' gmake: *** [all-gcc] Error 2 --------------with make------------------- /export/home/juha/gpc-build/gcc/xgcc -B/export/home/juha/gpc-build/gcc/ -B/usr/local/i386-pc-solaris2.8/bin/ -I/usr/local/i386-pc-solaris2.8/include -DIN_GCC -g -O2 -I./include -I. -I/export/home/juha/gcc-2.95.1/gcc -I/export/home/juha/gcc-2.95.1/gcc/config -I/export/home/juha/gcc-2.95.1/gcc/../include \ -aux-info SYSCALLS.c.X -S -o tmp-SYSCALLS.s SYSCALLS.c rm -f SYSCALLS.c tmp-SYSCALLS.s src=`cd /export/home/juha/gcc-2.95.1/gcc && pwd` && \ cd /export/home/juha/gcc-2.95.1/gcc/p/rts && make -f /export/home/juha/gcc-2.95.1/gcc/Makefile.in srcdir=. SCRIPTDIR="$src/p/script" SHELL="/bin/sh" CFLAGS="-g -O2" AR="ar" AR_FLAGS="cr" RANLIB="true" RANLIB_TEST="[ -f true ] || ( [ "i386-pc-solaris2.8" = "i386-pc-solaris2.8" ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] )" RTSFLAGS="" DESTDIR="../.." generated-files make: Fatal error in reader: /export/home/juha/gcc-2.95.1/gcc/Makefile.in, line 116: Unexpected end of line seen Current working directory /export/home/juha/gcc-2.95.1/gcc/p/rts *** Error code 1 make: Fatal error: Command failed for target `/export/home/juha/gcc-2.95.1/gcc/p/rts/configure' Current working directory /export/home/juha/gpc-build/gcc *** Error code 1 make: Fatal error: Command failed for target `all-gcc' --------------------snip----------- Any ideas? mvh/Juha Korkiakangas jmakor(a)nada.kth.se

3 2

Questions about coding...
by Andrew McCall 06 Nov '02

06 Nov '02

Hi All, After years of missing THINKS Pascal on the Mac, I thought I would give gpc a quick try! It seems pretty cool too! The first question I wanted to ask is about this list - can I ask coding questions here, or is it purley for actual gpc development? -- Thanks, Andrew McCall Internet/Linux System Administrator I.C.T. Division Oldham MBC Civic Centre West Street Oldham OL1 1UU Tel : 0161 911 3990 Fax : 0161 911 3998 Email : it.andrew.mccall(a)oldham.gov.uk ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.oldham.gov.uk **********************************************************************

4 6

Re: Questions about coding...
by Tom Verhoeff 06 Nov '02

06 Nov '02

>Well, I have just been getting used to programming in Pascal again, and I thought I would write the age-old number guessing game. It all works, well it >*should* but I seem to be having problems with some logic in an if statement: > >if (iGuess > 0) or (iGuess < 101) then > { do my code } > >I thought this bit of code should detect if iGuess is inbetween 0 and 100, but >it doesn't seem to work! Can anyone tell me why? Your if-condition is True for any value of iGuess, because you use 'or' instead of 'and'! >Also is there a random number generator in gpc? I have hardcoded the value for >this program, I want to play with it being random too :) Yes, though I don't know the details. Tom

1 0

mail tools released
by Frank Heckenbach 06 Nov '02

06 Nov '02

This is the announcement of the first public release of the mail tools. The mail tools are a set of programs to do various things with email, mostly in batch mode. The most important ones are `Semail' to send mails and `prmail' to process received mails (both written in GNU Pascal). The package also contains some generally useful units for GNU Pascal for sending and processing email, together with some demo programs, and some generally useful scripts related to mail handling. The mail tools are free software (GPL, LGPL). The current version of the mail tools can be found at <http://gnu-pascal.de/contrib/frank/programs.html>. Nicola Girardi Frank Heckenbach -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 3

Pointer type initializer
by Couperin 06 Nov '02

06 Nov '02

Hello, I tried to reduce a program I couldn''t compile. You'll see it below. I'm wondering if I made a mistake or if it's really a bug. I found that the problem comes from : P_Vecteur = ^T_Vecteur = Nil; (Everything is fine if I suppress the "= Nil".) In other programs, this declaration doesn't cause any problem, even if P_Vecteur is the argument of a procedure (and here there is no problem until the last procedure). Is it something I should avoid ? Here is the output of GPC : ./temp24_u2.pas: In procedure `Diffvecteurs': ./temp24_u2.pas:29: initial value is of wrong type gpc1.exe: c:/djgpp/bin/gpc.exe exited with status 1 or it may say also : ./temp24_u2.pas: In procedure `Diffvecteurs': ./temp24_u2.pas:29: incompatible types in initialization ./temp24_u2.pas:29: initial value is of wrong type gpc1.exe: c:/djgpp/bin/gpc.exe exited with status 1 and from time to time : Exiting due to signal SIGSEGV General Protection Fault at eip=00172911 ... (GNU Pascal v 2.1 alpha (20020910) with DJGPP, on WindowsME) ****************************** Program temp24; Uses temp24_u2; Begin End. ****************************** Unit temp24_u2; Interface Type P_Vecteur = ^T_Vecteur = Nil; T_Vecteur(N:Cardinal) = Array [1..N] Of LongReal; Implementation Procedure AddVecteurs(Resultat,A,B:P_Vecteur); Var Taille : Integer; Tampon : P_Vecteur; Procedure Addition(Resultat,AA,BB:P_Vecteur); Var I : Integer; Begin For I := 1 To Taille Do Resultat^[I] := AA^[I] + BB^[I] End; Begin End; Procedure DiffVecteurs(Resultat,A,B:P_Vecteur); Var Taille : Integer; Tampon : P_Vecteur; Procedure Soustraction(Resultat,AA,BB:P_Vecteur); Var K : Integer; Begin For K := 1 To Taille Do Resultat^[K] := AA^[K] - BB^[K] End; Begin End; Begin End. ****************************** -- "Couperin"

2 1

Pascal bug?
by rossati＠libero.it 05 Nov '02

05 Nov '02

Vale The test on array of char seem not works for array of four char. Here there is a simple source, whit five test and where one is falling: program Prx; var a5: array[1..5] of char := '01960'; b5: array[1..5] of char := '01959'; a4: array[1..4] of char := '1960'; b4: array[1..4] of char := '1959'; as: string(4) := '1960'; bs: string(4) := '1959'; begin writeln('Test array of char'); if a5 <= '01959' then writeln('failed! array 5 - costant'); if a5 <= b5 then writeln('failed! array 5'); if a4 <= '1959' then writeln('failed! array 4 - costant'); {above the falling test?} if a4 <= b4 then writeln('failed! array 4'); if as <= bs then writeln('failed! string'); end. The work session is: C:\fsf\pascal>uname -a MS-DOS X6J0B4 8 00 pc C:\fsf\pascal>gpc -v Reading specs from c:/fsf/lib/gcc-lib/djgpp/2.952/specs gpc version 20001101, based on 2.95.2 19991024 (release) C:\fsf\pascal>gpc prx.pas C:\fsf\pascal>a Test array of char failed! array 4 C:\fsf\pascal> Best regards G. Rossati

5 6

Re: GPC error messages
by Tom Schneider 05 Nov '02

05 Nov '02

Frank: > > Here is a bad chunk of code: > > > > ri := ri + > > end; > > > > This is what GPC has to say about it: > > > > ridi.p:1531: parse error before `End' > > > > Here is what the Sun Pascal compiler has to say about it: > > > > pc0: WorkShop Compilers 4.2 01/04/00 Pascal 4.2 patch 104632-11 > > Fri Nov 1 02:52:33 2002 ridi.p: > > 1531 end; > > E 18480----------------^--- Inserted identifier > > > > I always find the Sun display much easier to interpret instantly. It > > would be nice to have GPC show the line and show the point of the > > error. > > GPC's error messages (which follow the same standard as most GNU > programs) are more targeted towards automatic parsing. Yes, that's good. > If run call > GPC from a user interface that supports it (e.g., PENG ... excuse > the little plug ;-), Noted! > but I guess also RHIDE, Emacs, etc.), it will > show the source position. > > But if you prefer working on the command-line, here's a little > script to convert the message format. You have to pipe the error > messages through it, e.g. > > sh/bash: > > gpc <options> foo.pas 2>&1 | gnumsg2spc > > csh/tcsh: > > gpc <options> foo.pas |& gnumsg2spc > > DJGPP: > > redir -eo gpc <options> foo.pas | sh gnumsg2spc Thanks for the explanation. I was not able to locate gnumsg2spc on the web with google though. Where is it? > Another issue is that GPC's messages don't include the column > position. Unfortunately, that's hard to achieve with the current > design of the preprocessor and lexer. But a reimplementation of > those is planned, and then it will be possible I hope. Great! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

2 1

GPC error messages
by toms＠ncifcrf.gov 01 Nov '02

01 Nov '02

Folks: Here is a bad chunk of code: ri := ri + end; This is what GPC has to say about it: ridi.p:1531: parse error before `End' Here is what the Sun Pascal compiler has to say about it: pc0: WorkShop Compilers 4.2 01/04/00 Pascal 4.2 patch 104632-11 Fri Nov 1 02:52:33 2002 ridi.p: 1531 end; E 18480----------------^--- Inserted identifier I always find the Sun display much easier to interpret instantly. It would be nice to have GPC show the line and show the point of the error. The Sun compiler is not supported and so will go away eventually and at that point I will rely on GPC so having strong diagnostics will help. Thanks, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

2 1

Re: BUG? empty else
by da Silva, Joe 01 Nov '02

01 Nov '02

Agreed. This is not a bug. This reminds me of the "case" statement in Pascal 6000 (CDC). If you wanted to prevent a crash of your program, when an expression (variant-selector) was not matched by any case-constant-list, you HAD TO include an empty "otherwise" clause. BTW, when I reported this behaviour (ie. crash) as a bug, I was told that since a non-match was undefined, it was acceptable for the program to terminate with a run-time error (which is what it normally did). Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Friday, November 01, 2002 2:35 AM > To: gpc(a)gnu.de > Subject: Re: BUG? empty else > > Eike Lange wrote: > > > > The following program compiles without warnings: > > > > { 2.1 (20020510), based on gcc-2.95.2 19991024 (release) } > > program bug; > > > > var > > i: Integer = 1; > > > > begin > > if i = 1 then > > WriteLn ('is 1') > > else if i = 2 then > > { do nothing } > > else > > { do nothing } > > end. > > Not a bug. Terrible program structure, leading to much confusion, > but valid. The null statement is specifically permitted. You > will often see such things as: > > WHILE whatever DO (* nothing *); > > With if/else if/else chains, a useful rule is to put the short > clauses first (if possible) and make the final else the longest > clause. i.e.: > > IF something THEN BEGIN > (* lots of code *) > END > ELSE BEGIN > (* a few lines *) > END; > > is inferior to: > > IF NOT something THEN BEGIN > (* a few lines *) > END > ELSE BEGIN > (* lots of code *) > END; > > for readability reasons. You can look up from any code and find > the controlling statement easily. This applies to most > languages. The compiler should normally be able to optimize away > any extra code generated. > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address! > >

2 1

Archive moved
by Frank Heckenbach 29 Oct '02

29 Oct '02

The archive of this list has moved to http://gnu-pascal.de/crystal/gpc/en/ Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Debugging Pascal-code...
by Preben Mikael Bohn 29 Oct '02

29 Oct '02

Hi all... I am now trying to debug my code... However I have a problem with gdb... I have the following code: program hello; var testingint : integer; str : string; begin testingint := 432; str := 'Hello... '; writeln(str, testingint); end. I compile it with gpc -g -O0 --automake hello.pas --executable-file-name And run gdb with "gdb hello" I set a breakpoint at the start using "b hello.pas:6" and run it with "r". It stops fine, and when I have executed the next line (using "n") I try to print testingint using "print Testingint". But here I simply get "$1 = void"... What am I doing wrong here??? It prints out Str nicely (as a _p_schema-type, but I can live with that)... Best regards Preben ===== Computers are like airconditioners: They stop working properly if you open windows. __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

2 1

Bug in GPC?
by Preben Mikael Bohn 28 Oct '02

28 Oct '02

Hi all, I have a *really* strage problem. In my main program I have the following code snippet: ... if ((currentEpoch <= endDate) and (currentEpoch >= startDate)) then begin err := computeResiduals( corrections, filters, gsObs, observationIndices, gsPos, gpsPos, currentEpoch, residuals, estimatedClocks, errorSats); ... This works fine. If I add a writeln such as this: ... if ((currentEpoch <= endDate) and (currentEpoch >= startDate)) then begin writeln('xxx'); err := computeResiduals( corrections, filters, gsObs, observationIndices, gsPos, gpsPos, currentEpoch, residuals, estimatedClocks, errorSats); ... then my function "computeResidual" suddenly fails????? What is going on? Does anyone have an idea? It should be noted that "computeResidual" does not read from stdin or anything... My gpc runs on linux ans is version 2.1 (20020510) based on gcc-2.95.2 19991024 (release). Best regards Preben __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

2 1

Conformant array curiosity
by Wood David 25 Oct '02

25 Oct '02

Hi, I've been using conformant arrays in procedure declarations for ages, but recently I was given a troublesome module which had a number of procedure declarations, each with conformant parameters. When compiling the exported procedure, it actually caused our DEC Pascal compiler to crash (the stack dump suggesting it was whilst trying to build a conformant expression). Trying our faithful gpc 2.1 compiler, I got about 50 polite error messages "prior parameter's size depends on xyz" where xyz is a conformant array bound. However I can't figure out what has triggered this error. Can anyone shed any more light on how this may occur? Regards David Wood QinetiQ, Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

2 1

GPC on Darwin
by Adriaan van Os 22 Oct '02

22 Oct '02

As I am new on this discussion list, I have included some information about myself at the bottom of this message to introduce myself. My field of interest is GPC for Darwin (Darwin is Apple’s open-source kernel of MacOS X, based of FreeBSD 4.4 UNIX). I gathered the following relevant information: - the first version of GCC that fully supports Darwin is GCC 3.1 - GPC 2.1 is based on GCC 2.95 - GPC-20020910 alpha/beta has patches (diffs) for GCC 3.0 Consequently, my questions are: - has anyone on this list tried to build GPC for Darwin ? - has anyone on this list tried to build GPC for GCC 3.1 ? Regards, Adriaan van Os gpc(a)microbizz.nl --------------------------------------- About myself I run a small software company in The Netherlands named Microbizz. You are invited to laugh about my website at www.microbizz.nl. Currently, I am working mainly on CAD software and application toolboxes. Pascal is my language of choice. I have worked with the following Pascal compilers: DEC-10 (1978) DEC-10 Pascal Apple II UCSD Pascal Apple IIgs TML Pascal ORCA Pascal CPM Turbo Pascal 1.0 MS-DOS Turbo Pascal 3.0 upto 6.0 Windows Delphi Macintosh Turbo Pascal Think Pascal Apple Pascal for MPW Language Systems Pascal for MPW MetroWerks Pascal CodeWarrior Pascal Darwin See forward to work with GPC. What I most liked about what I learned from GPC was it’s ability to pass local procedures as actual parameters !!

4 4

procedure parameter defaults
by Nick Ioffe 22 Oct '02

22 Oct '02

Hi! In ADA and Vax Pascal there is a way of specifying default parameters: procedure a (x : integer := 10; y : string := 'abcdefg'); and to call a with specific argument: Var var1 : integer; var2 : string; Begin var1 := 5; var2 := 'hello'; a ( x := var1); a; a ( y := var2); a (var1, var2); 2 questions: 1. is there any way of doing so in GPC 2. if answer to #1 is "no" is it possible to include it in todo list Thank you in advance, Nick

2 1

Wishlist: asmname for constants
by Eike Lange 20 Oct '02

20 Oct '02

Hi Folks! Porting a library to a GNU Pascal Unit sometimes means putting a variable instead of a constant. Like this: foo.c: --------- int _c_konstant = DEFINED_CONSTANT_IN_C; --------- foo.pas: ----------- unit Foo; interface {!! Treat them as constant !!} var Konstant: Integer; asmname '_c_konstant'; external; implementation {$L foo.c} end. ----------- Doing it this way means a lack of using these "constants" in a "case" statement. It would be nice to have a feature like: const Konstant = _c_konstant; or similar. -- Eike Lange

3 7

Compiling GPC sources...
by Orlando Llanes 19 Oct '02

19 Oct '02

I've been trying unsuccessfully over the years to compile GPC, but still can't do it :( What _exactly_ do I have to do in order to compile GPC? See ya! Orlando

3 2

Re: IDE mingw?
by Eike Lange 18 Oct '02

18 Oct '02

Hi! On Tue, Oct 15, 2002 at 07:30:36PM +0100, Prof A Olowofoyeku (The African Chief) wrote: > > Is there an IDE available for mingw32? > Yes. Look in http://www.gnu-pascal.de/contrib/chief/ Thank you! This is exactly what I think the students want ;-) Eike

1 0

Building an h8300-hitachi-hms cross-compiler under i686-pc-cygwin 32
by Hansen, John 17 Oct '02

17 Oct '02

I've tried to build a h8300-hitachi-hms cross-compiler to no avail under cygwin. Does anybody know if it is even possible? It dies when it tries to build the RTS (integer constant too large). Does anyone have pre-built binaries? Thanks, John Hansen

2 1

IDE mingw?
by Eike Lange 16 Oct '02

16 Oct '02

Hi! During our astronomy seminar at the university Essen/Germany, we need to do some programming work and I'd like to hand out a CD with GPC. Most of the students are using windows and are used to play with an Integrated Development Environment. Is there an IDE available for mingw32? Is there a _simple_(!!) install skript and a package available for GPC and mingw32? (just pressing "install" and all is fine?) Eike

4 4

Another problem with strings
by Nick Ioffe 07 Oct '02

07 Oct '02

Hi! I'm trying to use the shared memory with GPC. The service I've written in C to map into the shared memory region accepts void **pointer_to_set_arg. I declare: type xyz_str_type = record id : integer; name : string(80); end; xyz_ptr_type = ^xyz_str_type; var xyz_ptr : xyz_ptr_type; xyz_str : xyz_str_type; tmp_ptr : pointer; ... in code I do: exp_shm_map (..., Add(tmp_ptr),...); xyz_ptr := xyz_ptr_type (tmp_ptr); xyz_ptr^.str := xyz.str; writeln (xyz_ptr^.str); In other program I just print the xyz_ptr^.str after I map into an existing shared memory region. The problem is that it doesn't work. I get nothing printed. But when I write xyz_ptr^ := xyz; everything works. It seems that something is done when new String variable is allocated. Some kind of initialization! Is there any way to overcome the diffculty without using the xyz strcuture allocated explicitly? Thank you, Nick

2 1

Dropping `--standard-pascal', `foo = procedure (Integer, Real)'
by toms＠ncifcrf.gov 04 Oct '02

04 Oct '02

Frank: I'm running gpc version 20000707, based on 2.95.2 19991024 (release) with set standard = "--standard-pascal" gpc $standard \ --transparent-file-names \ --no-mixed-comments \ -O$optimization \ -Wall \ $program.p -o $program (these are part of a script, ftp://ftp.ncifcrf.gov/pub/delila/gpcc ) I really like being able to compile original version (classic?) Pascal and I plan to switch to gpc (or p2c if gpc fails) in the future when Sun gives up on Pascal. So you wrote: | in the course of cleaning up GPC, I plan to drop the following | obsolete "features". | | - `--standard-pascal[-level-1]' (and the corresponding compiler | directives). GPC has `--classic-pascal[-level-1]' now to | distinguish it better from Extended Pascal (which also is a | standard). | ... | If you have any objections against removing them, please respond | soon. So would this make it impossible for me to compile "original" or "classical" Pascal? I don't know what the [-level-1] stuff is. Or how do I change my script Is there a web page that describes EVERY option now? However, I agree with Chuck Falconer that it should be easy to have the standard! Thanks, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

3 3

SDL for GPC
by Eike Lange 04 Oct '02

04 Oct '02

Hi Folks! I've written some SDL units for GPC. They are quite incomplete but usable (as far as you only need video output). "Simple DirectMedia Layer is a cross-platform multimedia library designed to provide fast access to the graphics framebuffer and audio device." See http://www.libsdl.org for more details. Furthermore, SDL_gfx is included in the package, just to have some graphics primitives. You'll find the unit at http://www.gnu-pascal.de/contrib/eike/ (sdlgpc-date.tar.gz) Have fun. Eike

1 0

Re: Dropping `--standard-pascal', `foo
by da Silva, Joe 30 Sep '02

30 Sep '02

I certainly don't object to identifying explicit ISO standards by their respective numbers, as you suggest. OTOH, we shouldn't have a myriad of ways of doing (specifying) the same thing. As you are no doubt aware, my concern with the "--standard-pascal" flag is that it infers that there is only one standard for Pascal. This is unfortunate, since the Extended Pascal Standard is just as much a standard, yet far too few people are even aware of it! Unless you (well, CBF actually;-) want to argue that "Extended Pascal" is not really Pascal, then use of the "--standard-pascal" flag is ambiguous at best. Anyway, if there is too much resistance to dropping the ambiguous "--standard-pascal" flag, we should at least discourage it's use in the documentation. For example, we could say something like : "--standard-pascal ... synonym for --classic-pascal". Joe. > -----Original Message----- > From: Tom Verhoeff [SMTP:wstomv@win.tue.nl] > Sent: Monday, September 30, 2002 5:33 PM > To: gpc(a)gnu.de > Subject: Re: Dropping `--standard-pascal', `foo > > >CBFalconer wrote: > > > >> Frank Heckenbach wrote: > >> > > >> > in the course of cleaning up GPC, I plan to drop the following > >> > obsolete "features". > >> > > >> > - `--standard-pascal[-level-1]' (and the corresponding compiler > >> > directives). GPC has `--classic-pascal[-level-1]' now to > >> > distinguish it better from Extended Pascal (which also is a > >> > standard). > >> > > >> > - The syntax `type foo = procedure (Integer, Real)' (i.e., without > >> > parameter names). > >> > > >> > If you have any objections against removing them, please respond > >> > soon. > >> > >> I strongly disagree. The very words "standard Pascal" > >> intrinsically reference ISO 7185, and "Extended Pascal" correlates > >> directly with the verbiage in ISO 10206. Without these > >> directives/flags the user is left groping about in the > >> documentation to find the appropriate magic incantations for > >> proper validation. > > > >I don't think typing `--standard-pascal' is any easier to use than > >`--classic-pascal' (in fact, it's even one letter more to type ;-). > >I'm also not sure whether someone new to GPC would guess > >`--standard-pascal' without looking in the manual (e.g., Invoking > >GPC -> GPC Options where the most common options are listed, > >including `--classic-pascal'). > > > >Just in case you misunderstood me here: I'm not going to remove the > >ISO 7185 support. I just want to remove one of the two equivalent > >switches to activate it. > > I do not think that the number of key strokes matters here. > Neither standard-pascal nor classic-pascal are unambiguous terms > (though they would do if documented properly). > > May I propose to call the option iso7185-pascal. The same number > of key strokes as classic-pascal, but, in my humble opinion, > unambiguous. > > Tom > -- > E-MAIL: T.Verhoeff at TUE.NL | Fac. of Math. & Computing Science > PHONE: +31 40 247 41 25 | Eindhoven University of Technology > FAX: +31 40 245 17 33 | PO Box 513, NL-5600 MB Eindhoven > http://www.win.tue.nl/~wstomv/ | The Netherlands >

2 1

Re: Dropping `--standard-pascal', `foo
by Tom Verhoeff 30 Sep '02

30 Sep '02

>CBFalconer wrote: > >> Frank Heckenbach wrote: >> > >> > in the course of cleaning up GPC, I plan to drop the following >> > obsolete "features". >> > >> > - `--standard-pascal[-level-1]' (and the corresponding compiler >> > directives). GPC has `--classic-pascal[-level-1]' now to >> > distinguish it better from Extended Pascal (which also is a >> > standard). >> > >> > - The syntax `type foo = procedure (Integer, Real)' (i.e., without >> > parameter names). >> > >> > If you have any objections against removing them, please respond >> > soon. >> >> I strongly disagree. The very words "standard Pascal" >> intrinsically reference ISO 7185, and "Extended Pascal" correlates >> directly with the verbiage in ISO 10206. Without these >> directives/flags the user is left groping about in the >> documentation to find the appropriate magic incantations for >> proper validation. > >I don't think typing `--standard-pascal' is any easier to use than >`--classic-pascal' (in fact, it's even one letter more to type ;-). >I'm also not sure whether someone new to GPC would guess >`--standard-pascal' without looking in the manual (e.g., Invoking >GPC -> GPC Options where the most common options are listed, >including `--classic-pascal'). > >Just in case you misunderstood me here: I'm not going to remove the >ISO 7185 support. I just want to remove one of the two equivalent >switches to activate it. I do not think that the number of key strokes matters here. Neither standard-pascal nor classic-pascal are unambiguous terms (though they would do if documented properly). May I propose to call the option iso7185-pascal. The same number of key strokes as classic-pascal, but, in my humble opinion, unambiguous. Tom -- E-MAIL: T.Verhoeff at TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25 | Eindhoven University of Technology FAX: +31 40 245 17 33 | PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands

1 0

Re: Dropping `--standard-pascal', `foo
by Tom Schneider 29 Sep '02

29 Sep '02

> Removing [--standard.pascal] invalidates who knows > how many existing scripts and makefiles. Exactly. Why break old code? > If anything I would recommend retaining the present directives and > adding "ISO7185-0", "ISO7185-1" and "ISO10206". However I don't > expect that to happen. So this is purely my vote against deleting > the present directives. I would vote for this!! But please leave the old definitions and clarify what they are precisely using ISO numbers. That information is not in the info gpc documentation (first few pages). > Source that is valid under 7185-0 should be valid everywhere (in > the best of all possible worlds, Dr. Pangloss). I want to > encourage such as far as possible. Use of any extensions beyond > that causes portability problems somewhere or other. Absolutely!! > The message from Dr. Thomas Schneider <mailto:toms@ncifcrf.gov> is > indicative of the problems that deletion would cause. He > obviously does not have an info installation, or it is obsolete, > or he is unaware of it. I was aware of it but don't think to use it. I find it awkward and complex compared to web pages, man pages, help flags, xman ... Thanks for the tip. > He may be using scripts set up by > personnel who have long since moved on. I write the scripts myself but prefer not to have to muck with them. We could upgrade to the latest version but I try to stick to the standard so if it is supported I don't have to keep running to stay in place. If you drop --standard.pascal that will break the copies of my compile script that other people have. This would force me to make a variant of the script that figures out the version of gpc and then calls gpc the right way so that it does not bomb! How silly. > Hidebound people such as > myself view with horror any changes to installed software, > especially any lack of backward compatibility. Agreed. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

1 0

Dropping `--standard-pascal', `foo = procedure (Integer, Real)'
by Frank Heckenbach 28 Sep '02

28 Sep '02

Hi, in the course of cleaning up GPC, I plan to drop the following obsolete "features". - `--standard-pascal[-level-1]' (and the corresponding compiler directives). GPC has `--classic-pascal[-level-1]' now to distinguish it better from Extended Pascal (which also is a standard). - The syntax `type foo = procedure (Integer, Real)' (i.e., without parameter names). If you have any objections against removing them, please respond soon. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 3

objects as value parameters ?
by Michael Behm 27 Sep '02

27 Sep '02

Hello everbody, I coded a procedure which takes an object as a value parameter procedure AnyThing (var v: ObjTyp); where type ObjTyp = object .... The compiler returns the error "object must not be a value parameter" - this is pretty clear to me, but I can do it in Borland Pascal (at least with 6.0). Also, I used the --borland-pascal option Is there some possibility ? Thank you, best regards, Michael ===== HÃ¶hlenforschung in Ãsterreich: www.xploration.at.tt __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de MÃ¶chten Sie mit einem GruÃ antworten? http://grusskarten.yahoo.de

3 2

GPC on OS X (possibly OT)
by Lance Boyle 26 Sep '02

26 Sep '02

First, please let me apologize if this is an inappropriate post to this list. I've been watching the list for several days and it looks like it's for the development team, and perhaps my question is more appropriate for other Pascal lists. I'll be brief. Can I use the GPC compiler with the GCC which is distributed with Macintosh OS X, version 10.2.x? Many thanks for any responses. Jerry Bauck Tempe, Arizona, USA

1 0

CRT, xterm and no output from program.
by Martin Rusko 26 Sep '02

26 Sep '02

Hello all, I will try describe my problem in short: {<program name=hello.pas>} program hello; uses crt; begin clrscr; writeln; writeln; writeln("Hello Dolly"); end. {</program>} Then will I compile this code with: gpc -o hello.e --automake hello.pas !!!Main problem!!!: When running $ ./hello.e under xterm in X Windows, it just blinks and NOTHING is written into screen. $ ./hello.e > err.log 2>&1 produces me this: ^[(B^[)0^[[?1049h^[[1;24r^[[m^O^[[4l^[[?7h^[[39;49m^[[?1h^[=^[[39;49m^[[37m^[[40m^[[37m^[[40m^[[H^[[2J^[[m^O^[[39;49m^[[37m^[[40m^[[?1h^[=^[[?25h^[[39;49m^[[37m^[[40m^[[37m^[[40m^[[H^[[2J Hello Dolly^M ^[[m^O^[[39;49m^[[37m^[[40m^[[39;49m^[[24d^[[K^[[24;1H^[[?1049l^M^[[?1l^[> It behaves just fine and as expected when I change TERM variable from xterm to linux or vt100. But it is not solution, for me. ;-( System is: Debian Woody (stable) running on sparc64 (Sun Ultra 1) Relevant packages: stable libncurses5 5.2.20020112a-7 stable libncurses5-dev 5.2.20020112a-7 stable ncurses-bin 5.2.20020112a-7 stable ncurses-base 5.2.20020112a-7 stable ncurses-term 5.2.20020112a-7 stable gpc-2.95 1:2.95.4-7 Any help, tips will be very appreciated. Thanks. mARTin -- Martin Rusko PhD student Department of Automation and Measurement Faculty of Mechanical Engineering Slovak University of Technology -- E-mail: rusko(a)sunsite.mine.nu Web: http://sunsite.mine.nu/~rusko -- motto: We are Microsoft! Resistance is futile. Open your source code and prepare for assimilation.

3 6

max/memavail
by Michael Behm 24 Sep '02

24 Sep '02

hello together, i have the following questions: i've been working with borland pascal under DOS for quite a long time, and now i changed to gpc under Solaris 8 on a SUN Blade 1000. i've to admit that i don't know much of UNIX itself. when i use the functions Max/MemAvail, the program seems to halt (it doesn't crash, just waits until i destroy via ctrl-c). i suppose that MaxAvail/MemAvail does only make sense under DOS - i don't know if there is anything like a heap in UNIX. are there any similiar functions (which work) in gpc/UNIX ? how can i determine the space which is free for a single pointer variable ? what is the heap-system (if there is one) in UNIX ? with GetMem, can i address the whole memory (which is 1 GByte) ? a lot of questions, i know, but i hope somebody can help me. thank you, and best wishes, michael ! ===== HÃ¶hlenforschung in Ãsterreich: www.xploration.at.tt __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de MÃ¶chten Sie mit einem GruÃ antworten? http://grusskarten.yahoo.de

2 1

Re: Dev+GNU Pascal [Was Re: Installation problem gpcpp.exe no such]
by Prof. A Olowofoyeku (The African Chief) 21 Sep '02

21 Sep '02

On 18 Sep 2002 at 9:21, I wrote: > On 18 Sep 2002 at 0:57, Frank Heckenbach wrote: [...] > > But something else (I still don't really understand the story): > > Searching of gpcpp does not use the unit-path. The path is > > hard-coded while building GPC, so if it is installed in the same > > directory, no option is needed to find it. Otherwise it can be set > > with a `-B' option or an environment variable GPC_EXEC_PREFIX. Is > > that what the IDE sets for the "bin directory"? > > This is an example of output of the "compile log" window: > "c:\dev_gpc\bin\gpc --automake c:\dev_gpc\examples\untitled1.pas > -oc:\dev_gpc\examples\untitled1.exe -fno-inline -fno-io-checking > -fno-stack-checking -O1 -march=i386 -mcpu=i386 > -funit-path=c:\dev_gpc\units -Bc:\dev_gpc\lib\ -Bc:\dev_gpc\lib\gcc- > lib\ -Bc:\dev_gpc\bin\" > > So the necessary "-B" switches are there - and I cannot see why there > should be a problem. I have now checked the compile log again, and I can see that the entire command line contains about 273 characters. Perhaps we have come across a DOS limitation here? I seem to remember that DOS (or command.com) has some limits in respect of how long a command line can be (128 characters?). If this is the problem, then I don't know what one can do about it. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

4 14

Automake problems - excessive compilation times
by Marten Jan de Ruiter 20 Sep '02

20 Sep '02

Since I threw away everything I tried to repeat the problem. I will try to explain what I did using a log: % which gpc /dutw54/deruiter/system/bin/gpc % mv /dutw54/deruiter/system/bin/gpc /dutw54/deruiter/system/bin/gpc.hide % rehash % which gpc /usr/tm/bin/gpc % gpc --version 2.95.2 19991024 (release) % make_clean % time make_fem >& /dev/null 169.390u 15.880s 4:31.73 68.1% 0+0k 0+0io 257172pf+0w % make_clean % mv /dutw54/deruiter/system/bin/gpc.hide /dutw54/deruiter/system/bin/gpc % which gpc /dutw54/deruiter/system/bin/gpc % gpc --version 20020910, based on gcc-2.95.2 19991024 (release) % make_clean %time make_fem > & ! make_log 1502.410u 434.950s 46:40.99 69.1% 0+0k 0+0io 11139770pf+0w % mv make_log make_log_first % time make_fem > & ! make_log 0.170u 0.090s 18:11:58.94 0.0% 0+0k 0+0io 4003pf+0w % grep gpcpp make_log_first | wc 43327 2166121 70806935 % grep gpcpp make_log | wc 177116 8855798 287544862 % grep gpcpp make_log | cut -f49 -d\ >make_log_gpcpp % grep gpcpp_first make_log | cut -f49 -d\ >make_log_first_gpcpp % ls -l make_log* -rw-r--r-- 1 deruiter staff 377521106 Sep 20 09:53 make_log -rw-r--r-- 1 deruiter staff 93209349 Sep 19 15:00 make_log_first -rw-r--r-- 1 deruiter staff 1043211 Sep 20 09:53 make_log_first_gpcpp -rw-r--r-- 1 deruiter staff 2388112 Sep 20 09:55 make_log_gpcpp make_clean is a script that removes all the object and gpi files make_fem builds the executable. So, I hid the new binary to use the old compiler, made sure that the old compiler was used, and nothing was compiled, and managed to obtain a executable in 4:31.73 ( Then I trew everything away, restored the new compiler, and obtained an executable in 46:40.99, which is considerably longer After moving the log file only, I tried to compile again (overnight!), without succes. I interrupted the process after 18:11:58.94 The last lines tell that gpcpp was invoked 43327 times in the first run, that yielded an executable, and 177116 times in the interrupted last. The 48-th arguments, that are the unit file names, are selected and put in the _gpcpp files Since I do not want to flush the entire gpc mailinglist with (hundreds of) megabytes of log files, I do not include the logfiles to this mail, but I hope I can highlight some of the output, that points in the right direction. More commands follow: % head -50 make_log > make_log.firstlines % head -200 make_log_first_gpcpp > make_log_first_gpcpp.firstlines % head -200 make_log_gpcpp > make_log_gpcpp.firstlines % cat -n make_log_first_gpcpp | grep NODES | head -40 > make_log_first_gpcpp_NODES % cat -n make_log_gpcpp | grep NODES | head -40 > make_log_gpcpp_NODES The attachment make_log.firstlines shows the first lines of the logfile, hopefully showing all that is used invoking the compilation. The other attachments show that NODES/*/*.p are compiled in one row of invocations of gpcpp, in the `clean' invocation of make_fem, namely line 18-29, whereas when all units are already compiled and available, then all dependencies are checked and double checked, so that the invocations are 6 apart, and cover 51 to 117. Hoping this helps to pinpoint the problem, regards, Marten Jan

1 0

Installation problem gpcpp.exe no such file or directory
by Pekka Mustonen 20 Sep '02

20 Sep '02

This is making me mad. It says that the file isn't there, but it is !! I've checked maybe 100 times, and the file is there !The path is correct, but GPC keeps telling me that the file is not there ! This is unbelievable. I'm using win98 and DEV+Gnu Pascal 1.9.2

5 12

Extended Pascal language restriction or GPC bug?
by S. Achterop IWI-120 3932 20 Sep '02

20 Sep '02

Hello here! The code below yields the following error on (e.g.) gpc version 20020910, based on gcc-2.95.4 20011002 (Debian prerelease) v.p: In procedure `Getfilename': v.p:8: prior parameter's size depends on `Fext' v.p:8: prior parameter's size depends on `Fext' If the second parameter of the activation of set_suffix is set to the variable "fextt", then it compiles normally. HOWEVER, if getfilename is removed from the interface, such that getfilename is completely local to IMPLEMENTATION, and apart from the structuring by modules the program is exactly the same, it ALSO compiles normally. AND, if for instance the TYPE IsoString is changed to a fixed array, no schemata, all is well ALSO. The question is, is using the second parameter as below ALLOWED according to the Extended Pascal report? 1 If so, this is a gpc bug. 2 If NOT, I can't find it in the Extended Pascal report. (Somehow I can see the need for this restriction, and I can live with it, I just can find it. Actually I started reading the report but stranded in the, for me, too complex formulation :) ) Does anyone on the list know the answer, is it 1 or 2? Regards, Sietse {************************************} MODULE msge INTERFACE; EXPORT msge = ( IsoString, getfilename); TYPE IsoString (Capacity : Integer) = array [1 .. Capacity + 1] of Integer; PROCEDURE getfilename (VAR fnm: IsoString; fext: IsoString); END. MODULE msge IMPLEMENTATION; VAR fextt : IsoString(30); PROCEDURE set_suffix (VAR fnm: IsoString; fext: IsoString); BEGIN END; PROCEDURE getfilename; BEGIN set_suffix (fnm, fext); END; END. {************************************}

2 1

Re: gpc 2.1 and rhide
by Per Persson 19 Sep '02

19 Sep '02

>From: Frank Heckenbach <frank(a)g-n-u.de> > >Per Persson wrote: > > > I have a question regarding gpc and rhide under Linux: > > I have been using gpc-20000913 under Red Hat Linux 6.2 and 7.1 together >with > > rhide 1.4.9-1 (which I got from a rpm-file :rhide-1.4.9-1.i386.rpm I > > downloaded..) > > This version of rhide has been somewhat buggy but very useful for >debugging > > purposes. > > Now, when I upgraded to gpc 2.1 the debugging does not work at all any > > longer. > > I can not watch an expression while stepping through the code as I >could > > before. > > I have tried different combinations of upper case and lower case in the > > specification > > of the watch but nothing seems to work. > >There was a bug with debug info in 2.1 which has been fixed in the >newer alphas. I don't know if that's the reason for your problems, >but you might want to try those. > >Frank OK gpc-20020910 works Thanks Per > _________________________________________________________________ MSN Hotmail Ã¤r vÃ¤rldens populÃ¤raste e-posttjÃ¤nst. Skaffa dig ett eget konto du ocksÃ¥: http://www.hotmail.com

1 0

internal compiler error with GPC on debian
by S. Achterop IWI-120 3932 19 Sep '02

19 Sep '02

L.S. On a Debian system (woody) with gpc version: 20020410, based on gcc-2.95.4 20011002 (Debian prerelease) the code below yields the following: home/doko/packages/gcc/2.95/x/gcc-2.95-2.95.4.ds11/src-native/gcc/p/module.c:3384:create_gpi_files: failed assertion `itab->interface_name_node' bug.p:11: Internal compiler error: bug.p:11: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. The problem goes away if the IMPORT is removed. Any pointers? CODE: ==================================== MODULE A; EXPORT A = ( B ); { removing the next 2 lines resolves the issue. } IMPORT StandardOutput; PROCEDURE B; END; PROCEDURE B; BEGIN END; END. ========================================= Thanks in advance, Sietse Achterop (University of Groningen, The Netherlands, computing science department) PS. On other systems (e.g. Suse with version 2.95.3 20010315 (SuSE) ) there are no problems.

2 1

Automake problems - excessive compilation times
by Marten Jan de Ruiter 18 Sep '02

18 Sep '02

L.S. I was happy to notice that the memory leak in the file-io is fixed, after I succesfully compiled and installed gpc version 20020910, based on gcc-2.95.2 19991024 (release). However, currently I am compiling a FE program using the automake option, and it turns out that the build is recursively. Creating a log file (using gpc -v and editing a bit) yields the following result: 1 /tmp/ccAHxoUT.i 2 ch_const.p 3 general.p 4 NODES/nodes.p 5 MATERIAL/constitution.p 6 NODES/nodes.p 7 MATERIAL/constitution.p 8 ELEMENTS/elements.p 9 NODES/nodes.p 10 MATERIAL/constitution.p 11 NODES/nodes.p 12 MATERIAL/constitution.p 13 ELEMENTS/elements.p 14 global.p 15 NODES/nodes.p 16 NODES/SCAL/scalnode.p ... The main program uses the units ch_const, general, initnode, ... where initnode uses nodes, constitution, elements, ... whele elements uses nodes, constitution, ... Looking at the log file, NODES/nodes.p is compiled multiple times due to the recursive nature of automake. That this really is a problem can be seen from the fact that, according to top, the size of gpc1 is 611M, and running for 2920min, whereas a previous version of gpc only took minutes. However, that previous version creates a memory leak. More figures on the size of the problem: gpcpp has been invoked more than 250000 times, resulting in 213 units that are compiled. The source of the problem is the recursion. Take the following worst case scenario: unit 1. unit 2 uses unit 1 unit 3 uses unit 1,2 unit 4 uses unit 1,2,3 unit 5 uses unit 1,2,3,4 .... the program uses unit 1....n Compilation takes 1 step for unit 1, 2 for unit 2 (namely 1 for unit 1 and 1 for unit 2), 4 for unit 3 ( namely 1 for unit 1, 2 for unit 2,1 for unit 3), 8 for unit 4 (namly 1 for unit 1, 2 for unit 2, 4 for unit 3 and 1 for unit 4) By induction, the program requires 2^n steps. Now 250000 is negligible compared to 2^(more than 213), so my whining on the compilation effort should be taken with a bit of salt. The situation could be far worse ;-) This recursion scenario makes sure that the object files of the units are always based on the latest versions of the source. Anyway, I would like to suggest the following method (which I hope is easy to implement, and I hope I did not overlook some problem scenario) Basically, it boiles down to pruning the recursive branches that are done earlier. Create an empty list of up-to-date object files for each unit that is required do: procedure create_object_file * verify that the units it requires are on the list, if not, call create_object_file for that unit * compile the unit. In this case, compilation of unit 5 takes considerable less steps: 1 for unit 1, 2 for unit 2 (1 to see unit 1 is up to date, 1 for unit 2), 3 for unit 3 (2 to see unit 1 and 2 are up to date, 1 for unit 3), 4 for unit 4 (3 to see unit 1,2 and 3 are up to date, 1 for unit 4), and 1 for unit 5. This requires 5 unit compilations, and 6 `up to date'-checks in the list. Thus n(n+1)/2 + 1 steps are required to compile the program, of which n+1 compilations and n(n-1)/2 `up to date' checks. The savings are in the fact that an `up to date' check of, e.g., unit 4 does not require the `up to date' checks of its dependencies, since it is already in the `up to date' list after its compilation. Based on these considerations, only 22792 steps would be required, whereas now more than 250000 gpcpp invocations occurred. Regretfully, I do not have the time to start hacking around in gpc myself, so I hope you have some use for these comments. For the time being, I just compile the units in exactly the sequence as they occur in the logfile, and build without automake ;-) Regards, Marten Jan de Ruiter Structural Optmimzation and Computational Mechanics group, Delft University of Technology

2 1

[Fwd: 20020910]
by Maurice Lombardi 17 Sep '02

17 Sep '02

There has been a crash of our mail system this week-end and the following message never arrived to the list -------- Message d'origine -------- Objet: 20020910 Date: Fri, 13 Sep 2002 19:31:16 +0200 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: gpc <gpc(a)gnu.de> Hi all While trying to compile the 20020910 alpha snapshot for DJGPP I have obtained the following error message c:/djgpp/b/gnu/gcc-2.953/gcc/p/rts/configure: line 2651: syntax error near unexpected token `GPC_MSG_CHECKING(for' c:/djgpp/b/gnu/gcc-2.953/gcc/p/rts/configure: line 2651: `GPC_MSG_CHECKING(for pw_gecos in struct passwd,if struct passwd in <pwd.h> contains a pw_gecos field)' make.exe[1]: *** [p/rts/Makefile] Error 2 make.exe[1]: Leaving directory `c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc' make.exe: *** [all-gcc] Error 2 GPC_MSG_CHECKING has been changed betwen 0905 and 0910 in p/rts/configure.in by the following -------------------------------------------------------------------------------------- # The second parameter is used by make-acconfig-h.m4 -AC_DEFUN(GPC_MSG_CHECKING,[AC_MSG_CHECKING([$1])]) +ifdef([GPC_MSG_CHECKING],,[AC_DEFUN([[GPC_MSG_CHECKING]],[AC_MSG_CHECKING([$1])])]) --------------------------------------------------------------------------------------- It seems that you want to define it only if it is not already defined. I am lost with all those [] quoting. I have tried to simple quote by applying the following diff on the 20020910 sources (where the previous one has already been applied): ----------------------------------------------------------------------------- --- configure.in.orig 2002-09-13 00:40:32.000000000 +0000 +++ configure.in 2002-09-13 00:42:16.000000000 +0000 @@ -52,7 +52,7 @@ AC_SUBST(with_shared) AC_DEFUN(GPC_DEFINE,[AC_DEFINE(translit($1, [abcdefghijklmnopqrstuvwxyz ], [ABCDEFGHIJKLMNOPQRSTUVWXYZ_]))]) # The second parameter is used by make-acconfig-h.m4 -ifdef([GPC_MSG_CHECKING],,[AC_DEFUN([[GPC_MSG_CHECKING]],[AC_MSG_CHECKING([$1])])]) +ifdef([GPC_MSG_CHECKING],,[AC_DEFUN([GPC_MSG_CHECKING],[AC_MSG_CHECKING([$1])])]) # Checks for header files AC_HEADER_STDC ---------------------------------------------------------------------------- Then everything works OK. Is this just an error while uploading or some subtle difference between autoconf 2.13 you use and autoconf 2.50 I use ? I need to run DJGPP autoconf to regenerate the configure scripts to take into account some DJGPP peculiarities. 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 -- 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

2 1

gpc 2.1 and rhide
by Per Persson 15 Sep '02

15 Sep '02

Hello! I have a question regarding gpc and rhide under Linux: I have been using gpc-20000913 under Red Hat Linux 6.2 and 7.1 together with rhide 1.4.9-1 (which I got from a rpm-file :rhide-1.4.9-1.i386.rpm I downloaded..) This version of rhide has been somewhat buggy but very useful for debugging purposes. Now, when I upgraded to gpc 2.1 the debugging does not work at all any longer. I can not watch an expression while stepping through the code as I could before. I have tried different combinations of upper case and lower case in the specification of the watch but nothing seems to work. (The gpc 2.1 compiler pass all test in the test directory of the gpc-distribution (except 3 with are omitted) ) Does anybody know of a version of rhide which work reasonable well with gpc2.1 and RH ? Thanks Per _________________________________________________________________ Skicka snabbmeddelanden till dina vÃ¤nner online med MSN Messenger: http://messenger.msn.se

3 2

gpc with gcc 3.1.1
by Waldek Hebisch 09 Sep '02

09 Sep '02

I am trying to make gpc work with gpc 3.1.1. Currently gpc1 compiles and links (I omitted gcpp, runtime and the 'gpc' driver). About 80% of testsuite works, but the remaining bugs still make compiler unuseable: -- gcp1 crashes trying to use gpc unit -- sometimes arrays and records are mislayed -- record layout functions complain about function declarations in objects. Of course, a bunch of minor bugs also shows up. I have a few questions about getting my work into mainline: -- is there anybody working on the same thing (the disscusion few months ago suggested that nobody)? -- should I try to resolve remaning bugs before I submit a patch? -- is gpc supposed to compile with other C compilers or only with gcc? More specific questions will follow (I spent last week offline). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

5 8

GPC Documentation in Spanish
by Francisco Javier Fernandez 09 Sep '02

09 Sep '02

Hola! As I mentioned last july, I'm now dealing with the lingüistics department at my University to participate in the translation of GNU-Pascal's docs to Spanish. Around these two weeks I suppose to have new from them, but until then I'm preparing the work to enroll some folks within. As we saw that the docs are in texinfo format, we are going to propose you a migration to Docbook format which is the actual standard in electronic documentation. From these sources it is easy to obtain HTML, pdf, textinfo, dvi etc.. ¿Do you think this is factible? Yours , Francisco J. Fernandez -- I

2 1

GPC according to GNU
by marcov＠stack.nl 08 Sep '02

08 Sep '02

(Subject is just kidding, just wanted to warn you, I stumbled onto this when I threw "Pascal" into Savannah's search engine) :-) GPC= Guile Pascal Compiler, and is hosted on GNU Savannah :-) http://savannah.gnu.org/projects/gpc/

1 0

gpc-20020905
by Frank Heckenbach 07 Sep '02

07 Sep '02

Hi, I've uploaded a new GPC snapshot to http://gnu-pascal.de/alpha/ I've labelled this alpha, though it's probably not less stable than GPC 2.1, but I've done less thorough testing than with 2.1 and the betas. It contains mostly minor changes that have accumulated since May, no big news. This is the list of new features since 2.1: @item new built-in procedure @samp{Assert}; new switches @samp{--[no]-assert} (also @samp{@{$C+@}}, @samp{@{$C-@}} for Delphi compatibility) (fjf665*.pas) (D) @item new function @samp{ProcessGroup} @item StringUtils: new function @samp{QuoteEnum} @item new built-in constants @samp{GPC_Function}, @samp{GPC_PrettyFunction} @item TFDD: new unit @item gpc-run: new options @samp{-e FILE} and @samp{-E FILE} (redirect/append standard error) Bugs fixed: @item 20020904: comparisons between signed and unsigned integers sometimes give wrong results (eike2.pas, fjf664.pas) @item 20020903: @samp{IOSelect} fails with file handles >= 8 on some systems (e.g., Solaris) (fjf663.pas) @item 20020831: GPC creates wrong debug info for many built-in types <200208280012.g7S0CWj07637@@mail.bcpl.net> @item 20020827: comparisons of @samp{packed} subrange variables don't work right (martin4[ab].pas) @item 20020824: operators defined in units don't always work (maur11.pas) @item 20020824: object methods that contain an ISO style procedural argument forget the implicit @samp{with Self do} (fjf662a.pas) @item 20020615: @samp{if Pass[i] in 'A'..'Z'} makes GPC crash (miklos6.pas) @item 20020603: compiling a program (not a unit or module) with @samp{--interface-only} or @samp{--syntax-only} segfaults (waldek1.pas) @item 20020603: @samp{--nested-comments} fails without @samp{-Wall} (waldek2.pas) @item 20020514: spurious warning with @samp{for} loops using a @samp{ByteCard} counter (toby1.pas) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html

1 0

Re: Sharing variables between modules
by Nick Ioffe 06 Sep '02

06 Sep '02

> Nick Ioffe wrote: > > > I declare public variables in module interface and then > > try to use them. > > > > The problem is that while integer variables work perfectly > > all other kinds of variables (at least files and strings) > > don't work at all. > > > > May somebody explain me what is going on? > > Why integer is defined ok, but string has problem? > > It's a known problem: > > : the capacity of strings declared in interfaces of modules is not > : initialized (daj3.pas, sven14c.pas, nick1.pas) > > Actually, it affects those types that require some automatic > initialization which are schemata (including strings), files and > objects. > > It only happens with modules, not with units. I'll try to fix it > when I get to it, but it's not trivial and will require some other > cleaning up of the module mechanism ... > > Frank > Hi! Thank you for all your responses. I'm sorry for bringing back the known problem. Here're 2 more strange behaviours with interface vs. implementation global variables definitions. May be they will help you to find out what is wrong in modules initialization. Problem I: I slightly change the previous expample - declare my_str_var in both mod1 module interface and implementation, in mod2 implementation and in my_main global var definitions block. What happens is that although each variable should be local for the module (at least that is what the common sense tells me) all the variables behave like there're the same variable. I've checked it with debugger and it points to the same address in all modules. the source is as follows: ---------------mod1.pas------------------- module mod1 interface; export mod1 = all; Type mystr = string(7); Var my_str_var : mystr; procedure mSet (str_arg : mystr); end. module mod1 implementation; Var my_str_var : mystr; procedure mSet (str_arg : mystr); begin writeln ('mod1 mset str_arg:',str_arg,'.'); my_str_var := str_arg; writeln ('mod1 mset my_str_var:',my_str_var,'.'); end; end. ---------------mod2.pas-------------------- module mod2 interface export mod2 = all; import mod1; procedure sSet (str_arg : mystr); function sGet : mystr; end. module mod2 implementation; import mod1 Var my_str_var : mystr; procedure sSet (str_arg : mystr); begin writeln ('mod2 sset str_arg:',str_arg,'.'); my_str_var := str_arg; writeln ('mod2 sset my_str_var:',my_str_var,'.'); end; function sGet : mystr; begin sGet := my_str_var; end; end. -----------------------my_main.pas------------------- program my_main (input,output); import mod1; import mod2; Var another_str : mystr := '7654321'; my_str_var : mystr; begin sSet ('0123456'); writeln ('1. my_main another_str:',another_str,'.'); another_str := sGet; writeln ('2. my_main another_str:',another_str,'.'); my_Str_var := 'abcdefg'; another_str := sGet; writeln ('2. my_main another_str:',another_str,'.'); mSet ('nick io'); another_str := sGet; writeln ('2. my_main another_str:',another_str,'.'); end. -------------------------------------------------------- The run results are: mod2 sset str_arg:0123456. mod2 sset my_str_var:0123456. 1. my_main another_str:7654321. 2. my_main another_str:0123456. 3. my_main another_str:abcdefg. mod2 sset str_arg:nick io. mod2 sset my_str_var:nick io. 4. my_main another_str:nick io. ============================================================= Problem II. As we've seen in problem I repeating the declaration in module implementation solves the problem of accessing the strings. Now I need to declare the array of string: -----------------mod3_1.pas------------------------- module mod3 interface; export mod3 = all; Var my_buff : array [1..10] of String(80); procedure pBuff; end. module mod3 implementation; Var my_buff : array [1..10] of String(80); procedure pbuff; var int ii; begin for ii:=1 to 10 do writeln (my_buff[ii]); end; end. ------------------------------------------------ When I compile it I get the following errors: mod3.pas:15: redeclaration of 'My_buff' mod3.pas:10: previous declaration of 'Mybuff' then I change the source as follows: -----------------mod3_2.pas------------------------- module mod3 interface; export mod3 = all; Type my_buff_type = array [1..10] of String(80); Var my_buff : my_buff_type; procedure pBuff; end. module mod3 implementation; Var my_buff : my_buff_type; procedure pbuff; var int ii; begin for ii:=1 to 10 do writeln (my_buff[ii]); end; end. ------------------------------------------------ Now everything compiles good. Why? What is the difference? Sincerely, Nick

2 1

Comparision Cardinal/Integer Bug?
by Eike Lange 05 Sep '02

05 Sep '02

Hi Folks! I don't know whether it's a feature or a bug, I didn't find it on the list of known bugs so here is my report: Comparisions between Cardinal and Integer may fail, if the Integer value is negative. Version: 2.1 (20020510), based on gcc-2.95.2 19991024 (release) program testcase; var aCard: Cardinal; aInt: Integer; begin aCard := 1; aInt := -1; { "FAIL" } if (aCard > aInt) then WriteLn ('OK') else WriteLn ('FAIL'); { "FAIL" } if (aCard > -1) then WriteLn ('OK') else WriteLn ('FAIL'); { just for completness: "OK" } if (1 > -1) then WriteLn ('OK') else WriteLn ('FAIL') end. BTW: The gcc C fontend does the same. Eike

2 1

Sharing variables between modules
by Nick Ioffe 04 Sep '02

04 Sep '02

Hi! I've encountered some strange problem using GPC built from may on HPuix 11.00. I declare public variables in module interface and then try to use them. The problem is that while integer variables work perfectly all other kinds of variables (at least files and strings) don't work at all. See the following small modules: ---------------mod1.pas------------------- module mod1 interface; export mod1 = all; Type mystr = string(7); Var my_str_var : mystr; my_int_var : integer; end. module mod1 implementation; to begin do writeln ('Load mod1'); end. ---------------mod2.pas-------------------- module mod2 interface export mod2 = all; import mod1; procedure sSet (str_arg : mystr); function sGet : mystr; procedure iSet (int_arg : integer); procedure iGet : integer; end. module mod2 implementation; import mod1 procedure sSet (str_arg : mystr); begin writeln ('mod2 sset str_arg:',str_arg,'.'); my_str_var := str_arg; writeln ('mod2 sset my_str_var:',my_str_var,'.'); end; procedure iSet (int_arg : integer); begin writeln ('mod2 sset int_arg:',int_arg,'.'); my_int_var := int_arg; writeln ('mod2 sset my_int_var:',my_int_var,'.'); end; function sGet : mystr; begin sGet := my_str_var; end; function iGet : integer; begin iGet := my_int_var; end; end. -----------------------my_main.pas------------------- program my_main (input,output); import mod1; import mod2; Var another_str : mystr := '7654321'; another_int : integer := 361; begin sSet ('0123456'); writeln ('1. my_main another_str:',another_str,'.'); another_str := sGet; writeln ('2. my_main another_str:',another_str,'.'); iSet (19); writeln ('1. my_main another_int:',another_int,'.'); another_int := iGet; writeln ('2. my_main another_int:',another_int,'.'); end. -------------------------------------------------------- Well, after I compile all 3 files and run the my_main what I get is: mod2 sset str_arg:0123456. mod2 sset my_str_var:. 1. my_main another_str:7654321. 2. my_main another_str:. mod2 iset int_arg:19. mod2 iset my_int_var:19. 1. my_main another_int:361. 2. my_main another_int:19. After I copied the my_str_var definition to implementation as well I get the following result: mod2 sset str_arg:0123456. mod2 sset my_str_var:0123456. 1. my_main another_str:7654321. 2. my_main another_str:0123456. mod2 iset int_arg:19. mod2 iset my_int_var:19. 1. my_main another_int:361. 2. my_main another_int:19. The strange is that after I moved my_str_var definition from mod1 implementation to my_main var definitions nothing changed. May somebody explain me what is going on? Why integer is defined ok, but string has problem? BTW as I stated earlier I have problem similar to string problem with File variables and any structures containing string fields. Thank you in advance. P.S. If the example doesn't compile - it is because of typos. I run GPC on system which is not connected to Internet, and the Internet computer doesn't have floppy. P.P.S I'd like to thank all of you who'd found out the problem with debuger. Nick

2 1

Cannot display variables with GDB
by J. David Bryan 04 Sep '02

04 Sep '02

When debugging GPC 2.1 programs with GDB, I am unable to print the values of variables that are of the "standard" types. Variables of user-defined types appear to print OK. I am using the Chief's "i486-mingw32" port from: http://www.gnu-pascal.de/contrib/chief/win32/mingw32/ ...but I have observed the same problem in a Mingw version that I built myself. Test case: program gdbtest (output); var i : integer; r : real; c : char; e : (enum1, enum2); s : 0..10; t : string (12); begin i := 3; r := 3.14159; c := 'Q'; e := enum2; s := 4; t := 'test string'; writeln (i, r, c, s, t); end. To reproduce: D:\>gpc -v Reading specs from /mingw/lib/gcc-lib/mingw32/2.95.3-6/specs gpc version 2.1 (20020510), based on 2.95.3-6 (mingw special) D:\>gpc -o gdbtest.exe -g gdbtest.pas D:\>gdb gdbtest.exe GNU gdb 5.1.1 (mingw experimental) Copyright 2002 Free Software Foundation, Inc. [...] This GDB was configured as "mingw32"... (gdb) b gdbtest.pas:18 Breakpoint 1 at $4012c2: file gdbtest.pas, line 18. (gdb) r Starting program: D:/gdbtest.exe Breakpoint 1, pascal_main_program () at gdbtest.pas:18 18 writeln (i, r, c, s, t); (gdb) p i $1 = void (gdb) p r $2 = void (gdb) p c $3 = void (gdb) p e $4 = Enum2 (gdb) p s $5 = 4 (gdb) p t $6 = 'test string' (gdb) c Continuing. [program prints "3 3.141590000000000e+00Q4test string" as expected] Note that the first three variables (of standard types "Integer", "Real", and "Char") print void values in the debugger. I have also tried this with GDB 4.18 and observe the same problem. Could someone please confirm whether these results are reproducible across platforms or are specific to the ix86-mingw32 platform? Thanks! -- Dave Bryan

4 11

Sharing variables between modules
by Wood David 04 Sep '02

04 Sep '02

Hi, Re. Nick Ioffe's problem with global file and string definitions at module level not being visible, I have been having to work around that problem for some years with my Linux gpc installation (by using local definitions). Regards David Wood, QinetiQ Farnborough. The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

1 0

gpc with gcc 3.1.1 - progress report
by Waldek Hebisch 04 Sep '02

04 Sep '02

Currently gpc with GCC 3.1.1 is getting almost useable. Remaining problems: -- DWARF2 routines in GCC can not handle FILES and abort the compiler (however a null program do compile with debugging on) -- not all data used by front end is properly marked, and compiler may crash after garbage collection. -- with garbage collection disabled it passes most tests, 7 are skipped and 14 fails. -- exponentiation is unimplemented (gcc-3.1.1 has no EXPON_EXPR). one should probably copy code from g77, but since none of the test needed exponentiation I just postponed it. At least 3 of failing tests (ian5a.pas, ian5b.pas, fjf73.pas) look like bugs already present in the current version -- they fail in tree checks, I wonder if anybody run the tests with tree checks in compiler enabled? Frank: how can I get your recent changes? I began to clean my changes and want to send a patch in few days. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 1

2025

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