- Gpc - gnu.de

Compilation succeeded, but uses GPC don't work
by Paul Dufresne 06 Mar '21

06 Mar '21

Ok, I'd like to report that with the patch you sent me privately, I was able to compile https://github.com/hebisch/gpc=20 combined with ftp://ftp.gnu.org/gnu/gcc/gcc-3.4.6/gcc-core-3.4.6.tar.bz2 using Ubuntu 20.10 compiler: was to say default but: gcc (GCC) 9.3.1 20200430 (for GNAT Community 2020 20200818) paul@jacko:~/gpc$ gpc --version gpc 20070904, based on gcc-3.4.6 paul@jacko:~/gpc$ /usr/local/bin/gcc --version gcc (GCC) 3.4.6 I did had to edit p/doc/hr/gpc.texi to begins: -------------------------------------------------- \input texinfo @setfilename gpc-hr.info @documentencoding iso-8859-2 @settitle GNU Pascal priru<E8>nik. @c We use Latin 2 charset for hr_HR language. @set charset iso-8859-2 ----------------- and p/doc/es/gpcs.texi to begins: ----------------------- \input texinfo @setfilename gpcs.info @documentencoding iso-8859-1 @settitle Est<E1>ndar de Codificaci<F3>n GNU Pascal @c Copyright (C) 2001-2006 Free Software Foundation, Inc. @c @c Authors: Frank Heckenbach <mailto:frank@pascal.gnu.de> @c Peter Gerwinski <mailto:peter@gerwinski.de> @c Nicola Girardi <mailto:nicola@g-n-u.de> @c @c Remember to update this when you save @set lastupdate 2006-02-02 @direntry * Est<E1>ndares de Codificaci<F3>n Pascal: (gpcs). Est<E1>ndares de codificaci<F3>n GNU Pascal. @end direntry ----------------------------- So I moved @documentencoding before @settitle when it was using some special characters... but I now see emacs did transform the characters in the document too. And now I can: paul@jacko:~/gpc$ rm a.out hello paul@jacko:~/gpc$ gpc -o hello ../gpc2/gcc-3.4.6/gcc/p/demos/hello.pas paul@jacko:~/gpc$ ls -lh total 548K -rwxrwxr-x 1 paul paul 546K mar 6 14:21 hello paul@jacko:~/gpc$ ./hello Hello, world. paul@jacko:~/gpc$ gpc ../gpc2/gcc-3.4.6/gcc/p/demos/readdirdemo.pas ../gpc2/gcc-3.4.6/gcc/p/demos/readdirdemo.pas:31: erreur: module/unit interface `GPC' could not be imported paul@jacko:~/gpc$ LANG=C gpc ../gpc2/gcc-3.4.6/gcc/p/demos/readdirdemo.pas ../gpc2/gcc-3.4.6/gcc/p/demos/readdirdemo.pas:31: error: module/unit interface `GPC' could not be imported paul@jacko:~/gpc$ Will need to figure out what to do to make that working.

2 3

../../gpc1/gcc-3.4.6/gcc/unwind-dw2.c:1031: error: dereferencing pointer to incomplete type
by Paul Dufresne 06 Mar '21

06 Mar '21

paul@jacko:~/gpc1-build$ LANG=C make make[1]: Entering directory '/home/paul/gpc1-build/libiberty' make[2]: Entering directory '/home/paul/gpc1-build/libiberty/testsuite' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/paul/gpc1-build/libiberty/testsuite' make[1]: Leaving directory '/home/paul/gpc1-build/libiberty' make[1]: Entering directory '/home/paul/gpc1-build/intl' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/paul/gpc1-build/intl' make[1]: Entering directory '/home/paul/gpc1-build/gcc' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[1]: Circular libgcc.a <- pascal dependency dropped. make \ CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long " \ CONFIG_H="tconfig.h ../../gpc1/gcc-3.4.6/gcc/../include/ansidecl.h" TM_H="tm.h ../../gpc1/gcc-3.4.6/gcc/config/i386/biarch64.h ../../gpc1/gcc-3.4.6/gcc/config/i386/i386.h ../../gpc1/gcc-3.4.6/gcc/config/i386/unix.h ../../gpc1/gcc-3.4.6/gcc/config/i386/att.h ../../gpc1/gcc-3.4.6/gcc/config/dbxelf.h ../../gpc1/gcc-3.4.6/gcc/config/elfos.h ../../gpc1/gcc-3.4.6/gcc/config/svr4.h ../../gpc1/gcc-3.4.6/gcc/config/linux.h ../../gpc1/gcc-3.4.6/gcc/config/i386/x86-64.h ../../gpc1/gcc-3.4.6/gcc/config/i386/linux64.h ../../gpc1/gcc-3.4.6/gcc/defaults.h insn-constants.h insn-flags.h" \ INCLUDES="-I. -I. -I../../gpc1/gcc-3.4.6/gcc -I../../gpc1/gcc-3.4.6/gcc/. -I../../gpc1/gcc-3.4.6/gcc/../include " \ MAKEOVERRIDES= \ -f libgcc.mk all make[2]: Entering directory '/home/paul/gpc1-build/gcc' for d in libgcc 32 libgcc/32; do \ if [ -d $d ]; then true; else /bin/sh ../../gpc1/gcc-3.4.6/gcc/mkinstalldirs $d; fi; \ done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /home/paul/gpc1-build/gcc/xgcc -B/home/paul/gpc1-build/gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gpc1/gcc-3.4.6/gcc -I../../gpc1/gcc-3.4.6/gcc/. -I../../gpc1/gcc-3.4.6/gcc/../include -fexceptions -c ../../gpc1/gcc-3.4.6/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o ../../gpc1/gcc-3.4.6/gcc/unwind-dw2.c: In function `uw_frame_state_for': ../../gpc1/gcc-3.4.6/gcc/unwind-dw2.c:1031: error: dereferencing pointer to incomplete type make[2]: *** [libgcc.mk:236: libgcc/./unwind-dw2.o] Error 1 make[2]: Leaving directory '/home/paul/gpc1-build/gcc' make[1]: *** [Makefile:1228: libgcc.a] Error 2 make[1]: Leaving directory '/home/paul/gpc1-build/gcc' make: *** [Makefile:23375: all-gcc] Error 2 paul@jacko:~/gpc1-build$ "The “dereferencing pointer to incomplete type” error commonly occurs in C when one tries to dereference a type (usually a struct) that is: not declared at all. declared, but not defined. The error in the first bullet point occurs because C cannot find the struct that is being dereferenced. The reason for this could be that the struct may not have been declared, or that the user made a typographical error in the struct’s name" from: https://www.educative.io/edpresso/resolving-the-dereferencing-pointer-to-in… At this stage, it seems to use generated xgcc to compile itself... a bit weird it get errors at this stage to me. Will investigate a bit more later.

2 2

/usr/include/linux/errno.h:1:23: asm/errno.h: No such file or directory
by Paul Dufresne 06 Mar '21

06 Mar '21

I fixed the following with: (On Ubuntu) sudo apt-get install gcc-multilib paul@jacko:~/gpc1-build$ LANG=C make make[1]: Entering directory '/home/paul/gpc1-build/libiberty' make[2]: Entering directory '/home/paul/gpc1-build/libiberty/testsuite' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/paul/gpc1-build/libiberty/testsuite' make[1]: Leaving directory '/home/paul/gpc1-build/libiberty' make[1]: Entering directory '/home/paul/gpc1-build/intl' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/paul/gpc1-build/intl' make[1]: Entering directory '/home/paul/gpc1-build/gcc' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' cd ../../gpc1/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" GPC_DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/home/paul/gpc1/gcc-3.4.6/gcc/p/rts' make[1]: Circular libgcc.a <- pascal dependency dropped. /home/paul/gpc1-build/gcc/xgcc -B/home/paul/gpc1-build/gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gpc1/gcc-3.4.6/gcc -I../../gpc1/gcc-3.4.6/gcc/. -I../../gpc1/gcc-3.4.6/gcc/../include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \ -c ../../gpc1/gcc-3.4.6/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from /usr/include/bits/errno.h:26, from /usr/include/errno.h:28, from ../../gpc1/gcc-3.4.6/gcc/tsystem.h:85, from ../../gpc1/gcc-3.4.6/gcc/crtstuff.c:62: /usr/include/linux/errno.h:1:23: asm/errno.h: No such file or directory make[1]: *** [Makefile:1273: crtbegin.o] Error 1 make[1]: Leaving directory '/home/paul/gpc1-build/gcc' make: *** [Makefile:23375: all-gcc] Error 2 paul@jacko:~/gpc1-build$ LANG=C make

1 0

parse error: GTY must be specified before identifier
by Paul Dufresne 06 Mar '21

06 Mar '21

I am trying to build with the most recent of gcc that I found that still use gcc-core: ftp://gnu.mirror.iweb.com/gcc/gcc-4.6.4/gcc-core-4.6.4.tar.bz2 ftp://gcc.gnu.org/pub/gcc/infrastructure/gmp-4.3.2.tar.bz2 ftp://gcc.gnu.org/pub/gcc/infrastructure/mpfr-2.4.2.tar.bz2 ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz But I get: [...] | ^~~~~~~~~~ gengtype-lex.c: In function ‘yylex’: gengtype-lex.c:364:15: warning: this statement may fall through [-Wimplicit-fallthrough=] /home/jakub/gcc-4.6.4/gcc-4.6.4/gcc/gengtype-lex.l:130:1: note: in expansion of macro ‘YY_DO_BEFORE_ACTION’ /home/jakub/gcc-4.6.4/gcc-4.6.4/gcc/gengtype-lex.l:127:1: note: here gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gpc2/gcc-4.6.4/gcc -I../../gpc2/gcc-4.6.4/gcc/build -I../../gpc2/gcc-4.6.4/gcc/../include -I../../gpc2/gcc-4.6.4/gcc/../libcpp/include -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber/bid -I../libdecnumber \ -o build/gengtype-parse.o ../../gpc2/gcc-4.6.4/gcc/gengtype-parse.c In file included from ../../gpc2/gcc-4.6.4/gcc/gengtype-parse.c:21: ../../gpc2/gcc-4.6.4/gcc/gengtype.h: In function ‘set_lang_bitmap’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype.h:101:3: note: in expansion of macro ‘gcc_assert’ 101 | gcc_assert (inpf); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-parse.c: In function ‘typedef_decl’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-parse.c:820:3: note: in expansion of macro ‘gcc_assert’ 820 | gcc_assert (token () == TYPEDEF); | ^~~~~~~~~~ gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gpc2/gcc-4.6.4/gcc -I../../gpc2/gcc-4.6.4/gcc/build -I../../gpc2/gcc-4.6.4/gcc/../include -I../../gpc2/gcc-4.6.4/gcc/../libcpp/include -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber/bid -I../libdecnumber \ -o build/gengtype-state.o ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c In file included from ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:27: ../../gpc2/gcc-4.6.4/gcc/gengtype.h: In function ‘set_lang_bitmap’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype.h:101:3: note: in expansion of macro ‘gcc_assert’ 101 | gcc_assert (inpf); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘type_lineloc’: ../../gpc2/gcc-4.6.4/gcc/system.h:656:61: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 656 | #define gcc_unreachable() (fancy_abort (__FILE__, __LINE__, __FUNCTION__)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:46:7: note: in expansion of macro ‘gcc_unreachable’ 46 | gcc_unreachable (); | ^~~~~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/system.h:656:61: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 656 | #define gcc_unreachable() (fancy_abort (__FILE__, __LINE__, __FUNCTION__)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:59:7: note: in expansion of macro ‘gcc_unreachable’ 59 | gcc_unreachable (); | ^~~~~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘write_state_fileloc’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:556:7: note: in expansion of macro ‘gcc_assert’ 556 | gcc_assert (floc->file != NULL); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘write_state_fields’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:585:3: note: in expansion of macro ‘gcc_assert’ 585 | gcc_assert (nbpairs == nbfields); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘write_state_lang_struct_type’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:827:7: note: in expansion of macro ‘gcc_assert’ 827 | gcc_assert (UNION_OR_STRUCT_P (hty)); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:828:7: note: in expansion of macro ‘gcc_assert’ 828 | gcc_assert (hty->u.s.lang_struct == current); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:831:7: note: in expansion of macro ‘gcc_assert’ 831 | gcc_assert (strcmp (homoname, hty->u.s.tag) == 0); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘write_state_gc_used’: ../../gpc2/gcc-4.6.4/gcc/system.h:656:61: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 656 | #define gcc_unreachable() (fancy_abort (__FILE__, __LINE__, __FUNCTION__)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:901:7: note: in expansion of macro ‘gcc_unreachable’ 901 | gcc_unreachable (); | ^~~~~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘write_state_typedefs’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:1030:3: note: in expansion of macro ‘gcc_assert’ 1030 | gcc_assert (nbpairs == nbtypedefs); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘write_state_variables’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:1082:3: note: in expansion of macro ‘gcc_assert’ 1082 | gcc_assert (nbpairs == nbvars); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘record_type’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:1249:3: note: in expansion of macro ‘gcc_assert’ 1249 | gcc_assert (slot); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘read_state_fileloc’: ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:1683:3: note: in expansion of macro ‘gcc_assert’ 1683 | gcc_assert (floc != NULL); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/system.h:636:55: warning: ISO C does not support ‘__FUNCTION__’ predefined identifier [-Wpedantic] 636 | ((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0)) | ^~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:1684:3: note: in expansion of macro ‘gcc_assert’ 1684 | gcc_assert (srcdir != NULL); | ^~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c: In function ‘read_state_files_list’: ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:2344:34: warning: comparison of constant ‘4’ with boolean expression is always false [-Wbool-compare] 2344 | if (!state_token_kind (t0) == STOK_RIGHTPAR) | ^~ ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:2344:34: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../../gpc2/gcc-4.6.4/gcc/gengtype-state.c:2344:11: note: add parentheses around left hand side expression to silence this warning 2344 | if (!state_token_kind (t0) == STOK_RIGHTPAR) | ^~~~~~~~~~~~~~~~~~~~~~ | ( ) gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gpc2/gcc-4.6.4/gcc -I../../gpc2/gcc-4.6.4/gcc/build -I../../gpc2/gcc-4.6.4/gcc/../include -I../../gpc2/gcc-4.6.4/gcc/../libcpp/include -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber/bid -I../libdecnumber \ -DBASEVER="\"4.6.4\"" -DDATESTAMP="\"\"" \ -DREVISION="\"\"" \ -DDEVPHASE="\"\"" -DPKGVERSION="\"(GCC) \"" \ -DBUGURL="\"<http://gcc.gnu.org/bugs.html>\"" -o build/version.o ../../gpc2/gcc-4.6.4/gcc/version.c gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o build/gengtype-state.o build/version.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a /bin/bash ../../gpc2/gcc-4.6.4/gcc/../move-if-change tmp-gi.list gtyp-input.list echo timestamp > s-gtyp-input build/gengtype \ -S ../../gpc2/gcc-4.6.4/gcc -I gtyp-input.list -w gtype.state ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:210: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:222: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:277: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:295: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:309: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:518: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:598: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:841: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/gpc.h:1439: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/declarations.c:171: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/declarations.c:3673: parse error: GTY must be specified before identifier ../../gpc2/gcc-4.6.4/gcc/p/module.c:285: parse error: GTY must be specified before identifier make[3]: *** [Makefile:3825 : s-gtype] Erreur 1 make[3] : on quitte le répertoire « /home/paul/gpc-build2/gcc » make[2]: *** [Makefile:5498 : all-stage1-gcc] Erreur 2 make[2] : on quitte le répertoire « /home/paul/gpc-build2 » make[1]: *** [Makefile:19609 : stage1-bubble] Erreur 2 make[1] : on quitte le répertoire « /home/paul/gpc-build2 » make: *** [Makefile:877 : all] Erreur 2 paul@jacko:~/gpc-build2$ After fixing those errors (not knowing what I do but obeying to the compiler) I get: GENERATOR_FILE -o build/genpreds \ build/genpreds.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/read-md.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a build/genpreds -h ../../gpc2/gcc-4.6.4/gcc/config/i386/i386.md > tmp-preds.h /bin/bash ../../gpc2/gcc-4.6.4/gcc/../move-if-change tmp-preds.h tm-preds.h echo timestamp > s-preds-h rm -f tmp-all-tree.def echo '#include "tree.def"' > tmp-all-tree.def echo 'END_OF_BASE_TREE_CODES' >> tmp-all-tree.def echo '#include "c-family/c-common.def"' >> tmp-all-tree.def ltf="../../gpc2/gcc-4.6.4/gcc/p/p-tree.def"; for f in $ltf; do \ echo "#include \"$f\""; \ done | sed 's|../../gpc2/gcc-4.6.4/gcc/||' >> tmp-all-tree.def /bin/bash ../../gpc2/gcc-4.6.4/gcc/../move-if-change tmp-all-tree.def all-tree.def echo timestamp > s-alltree gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gpc2/gcc-4.6.4/gcc -I../../gpc2/gcc-4.6.4/gcc/build -I../../gpc2/gcc-4.6.4/gcc/../include -I../../gpc2/gcc-4.6.4/gcc/../libcpp/include -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber/bid -I../libdecnumber \ -o build/gencheck.o ../../gpc2/gcc-4.6.4/gcc/gencheck.c gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gencheck \ build/gencheck.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a build/gencheck > tmp-check.h /bin/bash ../../gpc2/gcc-4.6.4/gcc/../move-if-change tmp-check.h tree-check.h echo timestamp > s-check build/genpreds -c ../../gpc2/gcc-4.6.4/gcc/config/i386/i386.md > tmp-constrs.h /bin/bash ../../gpc2/gcc-4.6.4/gcc/../move-if-change tmp-constrs.h tm-constrs.h echo timestamp > s-constrs-h gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gpc2/gcc-4.6.4/gcc -I../../gpc2/gcc-4.6.4/gcc/build -I../../gpc2/gcc-4.6.4/gcc/../include -I../../gpc2/gcc-4.6.4/gcc/../libcpp/include -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber -I../../gpc2/gcc-4.6.4/gcc/../libdecnumber/bid -I../libdecnumber \ -o build/gencondmd.o build/gencondmd.c In file included from ../../gpc2/gcc-4.6.4/gcc/function.h:25, from build/gencondmd.c:25: ../../gpc2/gcc-4.6.4/gcc/p/p-tree.def:43:14: error: redeclaration of enumerator ‘NAMESPACE_DECL’ 43 | DEFTREECODE (NAMESPACE_DECL, "namespace_decl", "d", 0) | ^~~~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/tree.h:39:49: note: in definition of macro ‘DEFTREECODE’ 39 | #define DEFTREECODE(SYM, STRING, TYPE, NARGS) SYM, | ^~~ ../../gpc2/gcc-4.6.4/gcc/tree.def:363:14: note: previous definition of ‘NAMESPACE_DECL’ was here 363 | DEFTREECODE (NAMESPACE_DECL, "namespace_decl", tcc_declaration, 0) | ^~~~~~~~~~~~~~ ../../gpc2/gcc-4.6.4/gcc/tree.h:39:49: note: in definition of macro ‘DEFTREECODE’ 39 | #define DEFTREECODE(SYM, STRING, TYPE, NARGS) SYM, | ^~~ In file included from ../../gpc2/gcc-4.6.4/gcc/function.h:25, from build/gencondmd.c:25: ../../gpc2/gcc-4.6.4/gcc/tree.h:3130:11: warning: identifier ‘thread_local’ conflicts with C++ keyword [-Wc++-compat] 3130 | unsigned thread_local : 1; | ^~~~~~~~~~~~ In file included from build/gencondmd.c:33: ../../gpc2/gcc-4.6.4/gcc/recog.h:287:5: warning: this use of "defined" may not be portable [-Wexpansion-to-defined] 287 | #if HAVE_DESIGNATED_INITIALIZERS | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ make[3]: *** [Makefile:3847 : build/gencondmd.o] Erreur 1 make[3] : on quitte le répertoire « /home/paul/gpc-build2/gcc » make[2]: *** [Makefile:5498 : all-stage1-gcc] Erreur 2 make[2] : on quitte le répertoire « /home/paul/gpc-build2 » make[1]: *** [Makefile:19609 : stage1-bubble] Erreur 2 make[1] : on quitte le répertoire « /home/paul/gpc-build2 » make: *** [Makefile:877 : all] Erreur 2 paul@jacko:~/gpc-build2$ ========================================================================= paul@jacko:~/gpc2/gcc-4.6.4/gcc/p$ diff -u gpc.h.orig gpc.h --- gpc.h.orig 2021-02-28 15:12:28.881046603 -0500 +++ gpc.h 2021-02-28 15:25:41.684525601 -0500 @@ -206,7 +206,7 @@ often the same). */ #define PERMANENT_STRING(S) (IDENTIFIER_POINTER (get_identifier (S))) -struct tree_inn GTY(()) +struct GTY(()) tree_inn { struct tree_common common; struct interface_table_t * GTY((skip(""))) table; @@ -218,7 +218,7 @@ typedef enum { IMPORT_USES, IMPORT_QUALIFIED, IMPORT_ISO } import_type; -struct tree_import GTY(()) +struct GTY(()) tree_import { struct tree_common common; gpi_int qualified; @@ -273,7 +273,7 @@ #define KW_WEAK 32 #define KW_INFORMED 64 -struct predef GTY(()) +struct GTY(()) predef { const char *idname; const char *rts_idname; @@ -291,7 +291,7 @@ #define PD_ACTIVE(PD) ((PD) && (PD)->user_disabled < (!co->pascal_dialect || (co->pascal_dialect & (PD)->dialect))) /* Language-dependent contents of an identifier. */ -struct lang_identifier GTY(()) +GTY(()) struct lang_identifier { struct tree_identifier ignore; tree value; @@ -303,12 +303,12 @@ int spelling_column; }; -union lang_tree_node - GTY((desc ("((TREE_CODE (&%h.generic) == IDENTIFIER_NODE) || (TREE_CODE (&%h.generic) == INTERFACE_NAME_NODE) || (TREE_CODE (&%h.generic) == IMPORT_NODE)) ? TREE_CODE (&%h.generic) : 0"), +union GTY(()) lang_tree_node + ((desc ("((TREE_CODE (&%h.generic) == IDENTIFIER_NODE) || (TREE_CODE (&%h.generic) == INTERFACE_NAME_NODE) || (TREE_CODE (&%h.generic) == IMPORT_NODE)) ? TREE_CODE (&%h.generic) : 0"), chain_next ("(union lang_tree_node *) TREE_CHAIN (&%h.generic)"))) { union tree_node GTY ((tag ("0"), desc ("tree_node_structure (&%h)"))) generic; - struct lang_identifier GTY ((tag ("IDENTIFIER_NODE"))) identifier; + struct GTY(()) lang_identifier ((tag ("IDENTIFIER_NODE"))) identifier; struct tree_inn GTY ((tag ("INTERFACE_NAME_NODE"))) interface; struct tree_import GTY ((tag ("IMPORT_NODE"))) import; }; @@ -514,7 +514,7 @@ (see EP 6.10.2). Used in CONST_DECL nodes. */ #define PASCAL_CST_PRINCIPAL_ID(decl) DECL_LANG_FLAG_7 (decl) -struct lang_decl GTY(()) +struct GTY(()) lang_decl { tree info1; tree info2; @@ -594,7 +594,7 @@ /* Set if the variants of a record have initializers. Used in RECORD_TYPE nodes. */ #define PASCAL_TYPE_INITIALIZER_VARIANTS(type) TYPE_LANG_FLAG_5 (type) -struct lang_type GTY(()) +struct GTY(()) lang_type { int code; tree info; @@ -837,7 +837,7 @@ /* options.c */ -typedef struct string_list GTY(()) +typedef struct GTY(()) string_list { struct string_list *next; char *string; @@ -1435,7 +1435,7 @@ typedef enum { LF_UNIT, LF_COMPILED_UNIT, LF_OBJECT, LF_COMPILED_OBJECT } locate_file_t; #define MODULE_T_FIRST_TREE_FIELD imports -struct module GTY(()) +struct GTY(())module { tree imports; /* TREE_LIST of IMPORT_NODEs of imported interfaces for this module. */ tree exports; /* TREE_LIST of interfaces exported from this module paul@jacko:~/gpc2/gcc-4.6.4/gcc/p$ ========================================================================================== paul@jacko:~/gpc2/gcc-4.6.4/gcc/p$ diff -u declarations.c.orig declarations.c --- declarations.c.orig 2021-02-28 15:12:42.077046333 -0500 +++ declarations.c 2021-02-28 15:27:17.724422309 -0500 @@ -167,7 +167,7 @@ for the main level of statements. - one (transparent) for each structured statement, see pushlevel_expand */ -struct binding_level GTY(()) +struct GTY(()) binding_level { /* A chain of declarations. These are in the reverse of the order supplied. */ tree names; @@ -3669,7 +3669,7 @@ } #ifdef GCC_3_3 -struct language_function GTY(()) +struct GTY(()) language_function { int unused; }; paul@jacko:~/gpc2/gcc-4.6.4/gcc/p$ =================================================================================== paul@jacko:~/gpc2/gcc-4.6.4/gcc/p$ diff -u module.c.orig module.c --- module.c.orig 2021-02-28 15:12:50.693045920 -0500 +++ module.c 2021-02-28 15:28:06.812307424 -0500 @@ -281,7 +281,7 @@ /* A table holding the nodes imported from all GPI files together with their UIDs, so duplicates can be identified. */ -struct interface_table_t GTY(()) +struct GTY(()) interface_table_t { tree interface_name; tree module_name; paul@jacko:~/gpc2/gcc-4.6.4/gcc/p$ =================================================================

2 4

[../../gpc/gcc-3.4.4/gcc/p/Make-lang.in:634 : p/declarations.o] Erreur 1
by Paul Dufresne 01 Mar '21

01 Mar '21

Hi! Just tried to compiled gpc. Used http://www.gnu-pascal.de/alpha/gpc-20050331-minimal.tar.bz2 and http://www.gnu-pascal.de/alpha/gcc-core-3.4.4.tar.bz2 Using: paul@jacko:~/gpc-build$ gcc --version gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0 And got: [...] In file included from ../../gpc/gcc-3.4.4/gcc/p/declarations.c:29: ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘pushdecl_import’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1062:3: note: in expansion of macro ‘gcc_assert’ 1062 | gcc_assert (!PASCAL_DECL_WEAK (x)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1076:30: warning: comparison between ‘enum tree_code’ and ‘enum pascal_tree_code’ [-Wenum-compare] 1076 | if (old && TREE_CODE (old) == OPERATOR_DECL && TREE_CODE (x) == OPERATOR_DECL) | ^~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1076:64: warning: comparison between ‘enum tree_code’ and ‘enum pascal_tree_code’ [-Wenum-compare] 1076 | if (old && TREE_CODE (old) == OPERATOR_DECL && TREE_CODE (x) == OPERATOR_DECL) | ^~ In file included from ../../gpc/gcc-3.4.4/gcc/p/declarations.c:29: ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘declare_label’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1142:3: note: in expansion of macro ‘gcc_assert’ 1142 | gcc_assert (!EM (label)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘lookup_name’: ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1324:31: warning: comparison between ‘enum tree_code’ and ‘enum pascal_tree_code’ [-Wenum-compare] 1324 | if (t && (TREE_CODE (t) == OPERATOR_DECL && PASCAL_BUILTIN_OPERATOR (t))) | ^~ In file included from ../../gpc/gcc-3.4.4/gcc/p/declarations.c:29: ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘get_unique_identifier’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1490:3: note: in expansion of macro ‘gcc_assert’ 1490 | gcc_assert (*template >= 'a' && *template <= 'z'); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘check_identifier’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1557:7: note: in expansion of macro ‘gcc_assert’ 1557 | gcc_assert (DECL_INITIAL (decl)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘lookup_c_type’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:70:71: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 70 | #define gcc_unreachable() (assert_fail ("unreachable code", __FILE__, __PRETTY_FUNCTION__, __LINE__)) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1625:3: note: in expansion of macro ‘gcc_unreachable’ 1625 | gcc_unreachable (); | ^~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘make_real’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1636:3: note: in expansion of macro ‘gcc_assert’ 1636 | gcc_assert (r > 0); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1638:3: note: in expansion of macro ‘gcc_assert’ 1638 | gcc_assert (TREE_TYPE (res) == double_type_node); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘init_decl_processing’: ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1816:3: error: ‘set_word_size’ undeclared (first use in this function); did you mean ‘set_mem_size’? 1816 | set_word_size = set_alignment = TYPE_PRECISION (long_unsigned_type_node); | ^~~~~~~~~~~~~ | set_mem_size ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1816:3: note: each undeclared identifier is reported only once for each function it appears in ../../gpc/gcc-3.4.4/gcc/p/declarations.c:1817:3: error: ‘set_words_big_endian’ undeclared (first use in this function) 1817 | set_words_big_endian = 0; | ^~~~~~~~~~~~~~~~~~~~ In file included from ../../gpc/gcc-3.4.4/gcc/p/declarations.c:29: ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘find_duplicate_fields’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2082:9: note: in expansion of macro ‘gcc_assert’ 2082 | gcc_assert (dup); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘declare_routine’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2419:3: note: in expansion of macro ‘gcc_assert’ 2419 | gcc_assert (!EM (d)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘build_operator_heading’: ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2530:34: warning: implicit conversion from ‘enum pascal_tree_code’ to ‘enum tree_code’ [-Wenum-conversion] 2530 | placeholder_decl = build_decl (OPERATOR_DECL, name, void_type_node); | ^~~~~~~~~~~~~ In file included from ../../gpc/gcc-3.4.4/gcc/p/declarations.c:29: ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘start_routine’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2714:9: note: in expansion of macro ‘gcc_assert’ 2714 | gcc_assert (IDENTIFIER_IS_BUILT_IN (TREE_VALUE (dir), p_attribute)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2753:3: note: in expansion of macro ‘gcc_assert’ 2753 | gcc_assert (!EM (decl)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2798:7: note: in expansion of macro ‘gcc_assert’ 2798 | gcc_assert (!DECL_RTL_SET_P (parm)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2824:5: note: in expansion of macro ‘gcc_assert’ 2824 | gcc_assert (!resvar); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2851:11: note: in expansion of macro ‘gcc_assert’ 2851 | gcc_assert (TREE_CODE (v) == COMPONENT_REF); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘finish_routine’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:74:101: warning: right-hand operand of comma expression has no effect [-Wunused-value] 74 | #define abort_confused() (error ("confused by previous errors, bailing out"), exit (FATAL_EXIT_CODE), 0) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:2952:5: note: in expansion of macro ‘abort_confused’ 2952 | abort_confused (); | ^~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘declare_types’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:3110:9: note: in expansion of macro ‘gcc_assert’ 3110 | gcc_assert (!EM (decl)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘shadow_one_level’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:3129:3: note: in expansion of macro ‘gcc_assert’ 3129 | gcc_assert (TYPE_SIZE (TREE_TYPE (element)) && !PASCAL_TYPE_UNDISCRIMINATED_SCHEMA (TREE_TYPE (element))); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘declare_variables’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:3451:11: note: in expansion of macro ‘gcc_assert’ 3451 | gcc_assert (!init); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:3578:7: note: in expansion of macro ‘gcc_assert’ 3578 | gcc_assert (!EM (d)); | ^~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c: In function ‘new_string_by_model’: ../../gpc/gcc-3.4.4/gcc/p/gpc.h:68:68: warning: ISO C does not support ‘__PRETTY_FUNCTION__’ predefined identifier [-Wpedantic] 68 | ((void) ((expression) ? 0 : (assert_fail (#expression, __FILE__, __PRETTY_FUNCTION__, __LINE__), 0))) | ^~~~~~~~~~~~~~~~~~~ ../../gpc/gcc-3.4.4/gcc/p/declarations.c:3659:7: note: in expansion of macro ‘gcc_assert’ 3659 | gcc_assert (isstring); | ^~~~~~~~~~ make[1]: *** [../../gpc/gcc-3.4.4/gcc/p/Make-lang.in:634 : p/declarations.o] Erreur 1 make[1] : on quitte le répertoire « /home/paul/gpc-build/gcc » make: *** [Makefile:23375 : all-gcc] Erreur 2 paul@jacko:~/gpc-build$ So isstring is undefined?

3 6

p/module.c:294: option `length' may not be applied to arrays of atomic types
by Paul Dufresne 28 Feb '21

28 Feb '21

No need to have a gcc with gcc-core... With gcc 7.5.0 I get: -o build/gengtype.o ../../gpc3/gcc-7.5.0/gcc/gengtype.c g++ -std=gnu++98 -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gpc3/gcc-7.5.0/gcc -I../../gpc3/gcc-7.5.0/gcc/build -I../../gpc3/gcc-7.5.0/gcc/../include -I../../gpc3/gcc-7.5.0/gcc/../libcpp/include \ -o build/gengtype-lex.o ../../gpc3/gcc-7.5.0/gcc/gengtype-lex.c gengtype-lex.c: In function ‘int yy_get_next_buffer()’: gengtype-lex.c:1343:18: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare] gengtype-lex.c:2150:3: note: in expansion of macro ‘YY_INPUT’ gengtype-lex.c: In function ‘yy_buffer_state* yy_scan_bytes(const char*, yy_size_t)’: gengtype-lex.c:2658:17: warning: comparison of integer expressions of different signedness: ‘int’ and ‘yy_size_t’ {aka ‘long unsigned int’} [-Wsign-compare] /space/rguenther/gcc-7.5.0/gcc-7.5.0/gcc/gengtype-lex.l: In function ‘int yylex(const char**)’: gengtype-lex.c:365:15: warning: this statement may fall through [-Wimplicit-fallthrough=] /space/rguenther/gcc-7.5.0/gcc-7.5.0/gcc/gengtype-lex.l:117:1: note: in expansion of macro ‘YY_DO_BEFORE_ACTION’ /space/rguenther/gcc-7.5.0/gcc-7.5.0/gcc/gengtype-lex.l:113:1: note: here gengtype-lex.c:365:15: warning: this statement may fall through [-Wimplicit-fallthrough=] /space/rguenther/gcc-7.5.0/gcc-7.5.0/gcc/gengtype-lex.l:134:1: note: in expansion of macro ‘YY_DO_BEFORE_ACTION’ /space/rguenther/gcc-7.5.0/gcc-7.5.0/gcc/gengtype-lex.l:131:1: note: here g++ -std=gnu++98 -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gpc3/gcc-7.5.0/gcc -I../../gpc3/gcc-7.5.0/gcc/build -I../../gpc3/gcc-7.5.0/gcc/../include -I../../gpc3/gcc-7.5.0/gcc/../libcpp/include \ -o build/gengtype-parse.o ../../gpc3/gcc-7.5.0/gcc/gengtype-parse.c g++ -std=gnu++98 -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gpc3/gcc-7.5.0/gcc -I../../gpc3/gcc-7.5.0/gcc/build -I../../gpc3/gcc-7.5.0/gcc/../include -I../../gpc3/gcc-7.5.0/gcc/../libcpp/include \ -o build/gengtype-state.o ../../gpc3/gcc-7.5.0/gcc/gengtype-state.c g++ -std=gnu++98 -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gpc3/gcc-7.5.0/gcc -I../../gpc3/gcc-7.5.0/gcc/build -I../../gpc3/gcc-7.5.0/gcc/../include -I../../gpc3/gcc-7.5.0/gcc/../libcpp/include \ -DBASEVER="\"7.5.0\"" -DDATESTAMP="\"\"" \ -DREVISION="\"\"" \ -DDEVPHASE="\"\"" -DPKGVERSION="\"(GCC) \"" \ -DBUGURL="\"<https://gcc.gnu.org/bugs/>\"" -o build/version.o ../../gpc3/gcc-7.5.0/gcc/version.c g++ -std=gnu++98 -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/gengtype \ build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o build/gengtype-state.o build/version.o ../build-x86_64-pc-linux-gnu/libiberty/libiberty.a LC_ALL=C ; export LC_ALL ; \ gawk -f ../../gpc3/gcc-7.5.0/gcc/opt-gather.awk ../../gpc3/gcc-7.5.0/gcc/ada/gcc-interface/lang.opt ../../gpc3/gcc-7.5.0/gcc/brig/lang.opt ../../gpc3/gcc-7.5.0/gcc/fortran/lang.opt ../../gpc3/gcc-7.5.0/gcc/go/lang.opt ../../gpc3/gcc-7.5.0/gcc/lto/lang.opt ../../gpc3/gcc-7.5.0/gcc/p/lang.opt ../../gpc3/gcc-7.5.0/gcc/c-family/c.opt ../../gpc3/gcc-7.5.0/gcc/common.opt ../../gpc3/gcc-7.5.0/gcc/config/fused-madd.opt ../../gpc3/gcc-7.5.0/gcc/config/i386/i386.opt ../../gpc3/gcc-7.5.0/gcc/config/gnu-user.opt ../../gpc3/gcc-7.5.0/gcc/config/linux.opt ../../gpc3/gcc-7.5.0/gcc/config/linux-android.opt > tmp-optionlist /bin/bash ../../gpc3/gcc-7.5.0/gcc/../move-if-change tmp-optionlist optionlist echo timestamp > s-options gawk -f ../../gpc3/gcc-7.5.0/gcc/opt-functions.awk -f ../../gpc3/gcc-7.5.0/gcc/opt-read.awk \ -f ../../gpc3/gcc-7.5.0/gcc/opth-gen.awk \ < optionlist > tmp-options.h /bin/bash ../../gpc3/gcc-7.5.0/gcc/../move-if-change tmp-options.h options.h echo timestamp > s-options-h /bin/bash ../../gpc3/gcc-7.5.0/gcc/../move-if-change tmp-gi.list gtyp-input.list echo timestamp > s-gtyp-input build/gengtype \ -S ../../gpc3/gcc-7.5.0/gcc -I gtyp-input.list -w tmp-gtype.state ../../gpc3/gcc-7.5.0/gcc/p/module.c:294: option `length' may not be applied to arrays of atomic types make[3]: *** [Makefile:2573 : s-gtype] Erreur 1 make[3] : on quitte le répertoire « /home/paul/gpc-build3/gcc » make[2]: *** [Makefile:4548 : all-stage1-gcc] Erreur 2 make[2] : on quitte le répertoire « /home/paul/gpc-build3 » make[1]: *** [Makefile:23803 : stage1-bubble] Erreur 2 make[1] : on quitte le répertoire « /home/paul/gpc-build3 » make: *** [Makefile:934 : all] Erreur 2 paul@jacko:~/gpc-build3$ This time, I don't understand what the compiler wants me to do.

1 0

RE: ISO7185 compliance
by scott andrew franco 25 Feb '21

25 Feb '21

1 0

ISO7185 compliance
by Paul Isaacs 22 Jan '21

22 Jan '21

Thanks to everyone who responded. I am trying to write a compliant 7185 compiler from 7185 compliant source. The problem arose because my compiler produced an error on the construct described when it compiled itself. I think that ( b )^.Field1 is a compliant work around because the expression will be treated as a variable access. I am using the 7185 spec rather than 10206 because it is much smaller and within a single person's scope. Also the compiler is intended for embedded systems where there is less need for advanced features. UsingÂ the 7185 spec as a base grammar will allow for grammar additions, such a interrupt directives, to be added to a well specified grammar as small tweaks. As well, 7185 is specified as a single source file so there is no need for a link editor to stitch together various pieces of object code to produce an executable. Without need for a linker, the complier becomes much more portable. There are many more embedded CPU chips than larger scale CPUs with operating systems. Regards, Paul Isaacs

2 1

ISO7185 compliance
by Paul Isaacs 22 Jan '21

22 Jan '21

Hello: gpc --classic-pascal compiles the following without error: procedure test; type Â xHandleÂ Â Â Â Â Â Â Â Â Â Â Â = ^xRecord; Â xRecordÂ Â Â Â Â Â Â Â Â Â Â Â = record Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â field1Â Â : integer; Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â end; var Â aÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â : integer; Â function bÂ Â Â Â Â Â Â Â Â : xHandle; Â var Â cÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â : xHandle; Â begin Â bÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â := c; Â end; begin Â aÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â := b^.field1; end; Is this 7185 compliant? The right hand side of the assignment is a 6.7.3 function-designator rule : Â Â Â Â Â function-designator = function-identifier [ actual-parameter-list ] . followed by "^." I can not see how the grammar permits the following pointer and record accesses. Thank you, Paul Isaacs

3 2

Trouble setting up Pascal
by Peter Williams 03 Nov '20

03 Nov '20

Greetings from a new member of your mailing list. I have used Gnu Pascal for some time on a Windows 10 64-bit environment. I decided to try it on a Linux Mint 20 Cinnamon machine with x86_64 processor I downloaded gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz to /home/peter/software and installed using: cd / tar xzf /home/peter/software/gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz I tried the simplest of programs: Hello.c: program hello; begin writeln ('Hello Pascal world'); readln end. and compiled by gpc -o Hello Hello.pas to get, to my dismay, not as on Windows but on Linux: peter@peter-Akoya-E6237:~/Pete/Pascal$ gpc -o Hello Hello.pas /tmp/ccnPqfBD.s: Assembler messages: /tmp/ccnPqfBD.s:15: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:19: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:20: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:21: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:22: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:23: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:24: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:25: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:35: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:36: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:37: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:38: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:50: Error: invalid instruction suffix for `pop' /tmp/ccnPqfBD.s:66: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:73: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:80: Error: invalid instruction suffix for `pop' /tmp/ccnPqfBD.s:88: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:92: Error: invalid instruction suffix for `pop' /tmp/ccnPqfBD.s:103: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:108: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:110: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:112: Error: invalid instruction suffix for `push' /tmp/ccnPqfBD.s:123: Error: invalid instruction suffix for `pop' peter@peter-Akoya-E6237:~/Pete/Pascal$ What am I doing wrong? Can you please advise? -- Peter Williams petesweet27rr(a)gmail.com

5 7

Re: Plan to Update GPC
by Schneider, Thomas (NIH/NCI) [E] 04 Sep '20

04 Sep '20

Scott: > >I don't understand the difference between p4 and p5. I see p6 > >is under development. If I try it, should I use: > > Pascal-P4 is a Pascal subset. Pascal-P5 is full ISO 7185. Pascal-P6 > is an extended Pascal. P5 is 1.3, so yes, pascal-p5_1_3.tar.gz. Ok, thanks! I got https://sourceforge.net/projects/pascalp5/files/pascal-p5_1_3.tar.gz/downlo… There is no mention of macOS in the README. The README says: > The full instructions for running and setting up the P5 compiler/interpreter > have all been incorporated into the document: > > doc/the_p5_compiler.docx > > Which is a Microsoft Word document, 2007 or later. it is also available in the > formats: > > doc/the_p5_compiler.pdf Adobe Portable Document Format. > doc/the_p5_compiler.html Web page format. > doc/the_p5_compiler.doc Word 1997-2003 format. > > Please consult one of these documents for full instructions on how to use P5. But that's not true. The doc/ diretory only contains: The_Programming_Language_Pascal_1973.pdf basic.docx iso7185rules.html the_p5_compiler.docx The_Programming_Language_Pascal_1973.pdf is great to have a copy of! I used libreoffice to convert to pdf: /Applications/LibreOffice.app/Contents/MacOS/soffice -env:UserInstallation=file:///tmp/schneidt.lico --headless --convert-to pdf basic.docx > 2 Beta software warning > p5 Basic is beta software at this time (version <1). > It should not be considered reliable for production use. Oh my. Looks like your documentation may be out of date. Is this still beta despite version > 1? Convert the other docx: /Applications/LibreOffice.app/Contents/MacOS/soffice -env:UserInstallation=file:///tmp/schneidt.lico --headless --convert-to pdf the_p5_compiler.docx This one is dated August 29, 2014 and on page 14 it says: > Is P5 a sueable compiler for real applications? I would assert that > it is not. That's no good! > ./setpath > ./configure > make % ./setpath ./setpath: Permission denied. You have the windows setpath.bat but have not set the permissions on setpath correctly. % chmod u+x setpath egg 320% ./configure ./configure: Command not found. % chmod a+rx configure % ls -l configure -rwxr-xr-x 1 schneidt admin 6469 Jan 5 2018 configure* % ./configure ./configure: Command not found. % This is really weird. Please set it up to work on macOS. Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

4 13

Re: Plan to Update GPC
by Schneider, Thomas (NIH/NCI) [E] 18 Aug '20

18 Aug '20

Scott: > I fixed up the line endings and put the archive back in Pascal-p5_1_3.tar.gz. > > It works better,but there is still something wrong with it, and it only happens > on the linux version. > > I'll look into it. I'm glad you are making progress. Do you think this will work on macOS? Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

2 1

running p5c (was Re: Plan to Update GPC)
by Thomas Schneider 17 Aug '20

17 Aug '20

Gale/Scott: > > egg 320% ./configure > > ./configure: Command not found. > > > > % chmod a+rx configure > > % ls -l configure > > -rwxr-xr-x 1 schneidt admin 6469 Jan 5 2018 configure* > > % ./configure > > ./configure: Command not found. > > % > > > > This is really weird. > > Are you running MacOS 10.15? > > The default shell was changed from bash to zsh. I don't know if a clean install of 10.15 gives you just zsh and NO bash but if that is the case then the: > > #!/bin/bash > > in the configure script file can't find a working bash shell to orrectly execute the script. > > To check, open up Terminal and type in and execute the command "bash" [without the ""'s]. If you have a bash shell installed you'll get something like: > > bash-3.2$ > > or some variation of that depending on the version of bash installed. A great point. I'm not running Apple macOS 10.15 yet on the machine I'm doing this. So bash is there. I looked on my 10.15 machine and it gives a warning about "The default interactive shell is now zsh." but does run bash 3.2. So that's not the problem. I figured it must be deeper into the code. Then, using vim to look at the configure file I discovered that it is a dos file. I used my very handy wtch program https://alum.mit.edu/www/toms/delila/wtch.html to find out "what characters are in a file". This program shows the characters being used. It has saved me many many times over the years. It confirmed that the file lines have control-M on them. Apparently a line with just a control-M gets interepreted by bash as a weird command that it cannot find. I removed all control-Ms (with my 'no-m' or 'nom' script, http://users.fred.net/tds/lab/ftp/nom) Now the no-m copy nomconfigure runs: % nomconfigure *** No flip was found flip does not exist, has PATH been set up? attempting to make it nomconfigure: ./bin/make_flip: /bin/bash^M: bad interpreter: No such file or directory *** Unable to make flip *** No ip_pascal was found So there are other errors. p5c is not ready for use on macOS. Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

3 2

Re: Plan to Update GPC
by Schneider, Thomas (NIH/NCI) [E] 16 Aug '20

16 Aug '20

Scott: > Yes, I use 64 bit GPC, my P5 site contains instructions to install it and a binary. The latter is because > the online .tz is missing, so I just provide the binary. It also needs some setup fixes these days. Wait, what??? I need a Pascal compiler that runs on macOS. GPC no longer works on macOS. If P5 depends on GPC, then I can't use it! Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

1 0

Re: Plan to Update GPC
by Schneider, Thomas (NIH/NCI) [E] 16 Aug '20

16 Aug '20

Scott: I'm just looking for Pascal compilers that run on macOS. My programs follow the original compilers in which the files listed at the top of the program are directly read and written to by the Pascal program. GPC used to do this. P2C (which I maintain apparently) translates to C and then provides this. I don't know what ISO that corresponds to. > For your second point, I assume you are talking about the > Pascal-P1-P6 thing? (not sure I understand your point about "name > change breaks the code") I write scripts that call compilers with the parameters needed to compile my programs. If the name of the compiler changes then the scripts break. For example, if the Unix 'ls' command were named ls763 and then a new version were named ls764 lots of code would break. > Can Pascal-P be used on the Mac? Well, actually yes. Pascal-P6 > includes sufficient tooling to port without GPC (see the interpreter > written in C). I don't really push that capability because P6 is > still in development, and also because interpreters are not really > my thing (yes, I know that sounds funny). I like compilers. To me > interpreters are more of a fun toy than not, although I note that > there is a group pushing interpreters as "VM"s for professional use. > Pascal-P5 has actually been written up as such. Again, not bad, just > not my thing. Ok, maybe when P6 is stablized and GPC independent it can be used to compile on macOS. > I should mention there is a branch from P5 known as P5c that that > changed the compiler into a Pascal to C translator that accomplishes > porting in a different way. You would have to look into that > yourself, I'm not really up to speed on that. That's interesting, thanks. https://sourceforge.net/projects/pascal-p5c/ Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

5 7

Re: Plan to Update GPC
by Schneider, Thomas (NIH/NCI) [E] 15 Aug '20

15 Aug '20

Scott: > > FPC certainly qualifies as a cross platform OS, and I believe it > > runs well on MacOS?? > > It does run, but because they have a legacy of bells and whistles it > doesn't comple vanilla Pascal from 1982 (ISO 7185?) > " > I'd like some more details on that. I have very extensive testing > services with Pascal-P5, and FPC passes, or did pass, my ISO 7185 > tests. It's been a while. For my program to directly access files in the local diretory I have a script that adds assignments. These are non-standard as I understand it (that is, they would differ by differenting operating systems). There were some special compiler directives. They were incorporating things and maybe the latest version (which I have not gotten) is easier to compile with. I would have to dig around to find more details. > You can also just compile your stuff with Pascal-P5. As mentioned, > it is perhaps the most rigorous test of ISO 7185 compliance you will > find today. I see I have a directory for P4. Apparently I played with it in 2015 according to my notes. This is from my notes [2015 Nov 17]: > http://homepages.cwi.nl/~steven/pascal/p4c.tar.gz > Lots of errors. FUBAR. I also have a directory for p5c ... and we communicated in 2016! You asked if it would be ok to put copies of my code online (yes). You mentioned: https://sourceforge.net/projects/pascalp5/ I don't understand the difference between p4 and p5. I see p6 is under development. If I try it, should I use: https://sourceforge.net/projects/pascalp5/files/pascal-p5_1_3.tar.gz/downlo… > You sound like a pretty advanced user of ISO 7185 Pascal, we should > keep in touch. I'm not particularly 'advanced' - I just have a large legacy of Pascal programs that I use for understanding a fundamental theory of biology. > I am at samiam(a)moorecad.com. Ok. Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

2 1

Re: Plan to Update GPC
by Schneider, Thomas (NIH/NCI) [E] 13 Aug '20

13 Aug '20

> Hmm, is this your work https://sourceforge.net/p/pascalp5/ ? What is this? I looked into the README and it says: "You need a working gpc implementation." I'm looking for a replacement for GPC on macOS since GPC no longer works there. How would pascalp5 be useful for anything if it depends on GPC which doesn't work on macOS? Also, why is the name of the program changing instead of a version number? This will break code everytime you change the name! Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

2 2

Plan to Update GPC
by Kevan Hashemi 13 Aug '20

13 Aug '20

Dear GPC Collaborators, PROBLEM: MacOS 10.15 does not run 32-bit binaries. My application uses 30k lines of GPC code. The MacOS GPC is 32-bit only. MY FAILURE ON MACOS: The current GPC is compatible with the back-end of GCC 3.4.6 only. The procedure on all platforms is to compile gcc3.4.6 with the GPC sources. With a variety of C-compilers on MacOS (CLANG, GCC-4.9, GCC-5, and GCC-8), I can produce the two cross-compiler executables xgcc and xgpc. These are x86_64 executables. They both compile "Hello World", but they produce only 32-bit objects. When I pass "-m64", they say "Sorry: 64-bit not compiled in". I try building GCC 3.4.6 alone with: config --target=x86_64-apple-darwin make But I get, "Configuration x86_64-apple-darwin16.7.0 not supported". When I apply the same procedure to the GCC 4.9.4 sources, the build proceeds. The GCC 3.4.6 sources support 64-bit targets on Linux, so I was hoping it could do the same on MacOS. I have examined the GCC literature and the contents of gcc/config, but I still don't know what file should be present to provide x86_64 support on apple-darwin. Unless someone tells me otherwise, I'm going to assume that getting the 64-bit MacOS GPC out of GCC 3.4.6 is impossible. Translating all my beautiful, reliable GPC code into another language does not sound like fun. Porting GPC to a newer version of GCC, such as GCC 8, is a possibility, but I understand that the GCC back-end team has a history of being uncooperative with the GPC team. Another solution is to port GPC to LVVM so we can use the CLANG compilers. The LVVM strategy seem like a good one to me: produce platform-independent code that then gets compiled and assembled. If I understand correctly, a CLANG front-end will work on any platform. I would like to hear your advice. I have to solve this problem. I have allocated one thousand hours of my time to get it done. If there is a way to revive GPC with that amount of labor, I'll do it. Best, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net

13 34

Re: Plan to Update GPC
by Kevan Hashemi 17 May '20

17 May '20

Dear Waldek, I'm copying the list here, because John Ries is working on the same compile. I have not made any progress in the last week. I spent some time marvelling at magnitude of the changes made by the GCC maintainers in the GCC generic trees code between GCC 4.3.5 and 4.9.4. Attempting to compile GPC in GCC-4.3.5 with a GCC 4.9.4 host compiler, I reported: >> I get 859 duplicate symbol errors like this while compiling gpc1 >> object: >> >> duplicate symbol _default_binds_local_p_1 in: p/varasm.o >> libbackend.a(varasm.o) >> >> They are all of the same form: libbackend.a(xxx.o) conflicts with >> p/xxx.o I remove libbackend.a from the step and get missing >> symbols. To which you replied: > That seems to be incompatible behaviour of linker. 'libbackend.a' is > a library and objects provided by GPC are supposed to effectively > replace corresponding library objects. In other words linker is > supposed to take object from command line and ignore corresponding > object from 'libbackend.a'. On Linux with GNU linker it works as > intended. The default linker on MacOS is the clang linker. There is no binutils port of "as" or "ld" to MacOS. There's that old CTools "as" and "ld" available. I don't know how to force the build to use the CTools linker. > One possible workaround is to tell linker that libbackend.a is a > library replacing 'libbackend.a' by something like '-L. -lbackend'. > Another possiblity is to make unconditional modification to backend > files and skip GPC versions. I have spent a few hours looking at the configure and makefile scripts, trying various flags and options, but my experiments don't work, which has served to show me how little I understand. I edit a makefile and it will be re-written, because I edited the wrong file. My greatest achievement was to persuade the entire build to use the CTools "as", only to find that this assembler won't compile the 64-bit code generated by GCC 4+. >> I remove the duplicating p/xxx.o files and the step works. I >> re-start the build, and it proceeds farther, until xgcc is >> compiling fibheap.c, which aborts with; >> ../../../gcc-4.3.5/libiberty/fibheap.c:258: error: ‘LONG_MIN’ >> undeclared (first use in this function). In that file there is a >> line: >> #define FIBHEAPKEY_MIN LONG_MIN You asked: > So important question is which compilation > works and which fails? Consulting my notes above, the error occurs when xgcc is building fibheap.c. > Second, LONG_MIN comes from standard header > "limits.h". So this looks like typical example of confusion with > location of header files. That would not surprize me. I have 99 copies of limits.h on my hard drive, between various versions of GCC that I have installed, and the SDKs. Best, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net

1 0

Failure to build GPC under Linux
by John Ries 16 May '20

16 May '20

The error messages are: ../../gcc-4.3.5/gcc/toplev.c:545:1: error: redefinition of ‘floor_log2’ 545 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:177:1: note: previous definition of ‘floor_log2’ wa s here 177 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ ../../gcc-4.3.5/gcc/toplev.c:580:1: error: redefinition of ‘exact_log2’ 580 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:183:1: note: previous definition of ‘exact_log2’ wa s here 183 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ There is probably a GCC flag to allow such duplicate definitions, but I haven't found it yet (apparently, it isn't -Wnoduplicate-decl-specifier). I'm using the GCC 4.3.5 codebase and building with GCC 9.3.1 under Fedora 31 (x86_64). I'm running configure as follows: SRCDIR=../gcc-4.3.5 export CFLAGS ="-fkeep-inline-functions -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -Wmissing-format-attribute \ -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common \ -Wnoduplicate-decl-specifier" $SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal The definition of CFLAGS was my attempt to allow the code to compile. It made no difference. Any ideas as to how to proceed would be greatly appreciated. John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885

3 6

GPC with GCC 4.9.4
by Kevan Hashemi 08 May '20

08 May '20

Dear Waldek, > with GCC-4.3.5. Look at README, for 4.3.5 you need to use '--disable-mapped-location'. I can't get GCC-4.3.5 to compile on MacOS without figuring out a bunch of small modifications. I have GCC-4.9.4 from Home Brew, and that installation applies patches automatically before building. So I started with GCC 4.9.4. The patches for GCC-4.3.5 mostly work, but I had to skip half of them. The patch appears to be Makefile.def and Makefile.in edits. The build proceeds well, with correct identification of the host, build, and target as x86_64-apple-darwin16.7.0. In the libiberty directory, I have 64-bit objects. First error is when going through gpc.h, where it says several times: ../.././gcc/p/gpc.h:290: parse error: GTY must be specified before identifier That's because the newer GCC requires that you provide an "identifier" for each GTY type definitions. The existing "tree_inn" structure is: struct tree_inn GTY(()) I add the identifier "tree_in_gty" like this: struct tree_inn GTY(()) tree_in_gty And do so for all other instances in gpc.h, declarations.c, module.c, and plant.c. Now compilation proceeds to: ../.././gcc/p/plant.c:47: undefined type `varray_type' There is a missing file "varray.h", which appears in GCC-3.4.6, but not in GCC-4.9.4. I'll look into the varray.h problem. Best, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net

1 0

Re: Plan to Update GPC
by Kevan Hashemi 08 May '20

08 May '20

Dear Waldek, Thanks for your letter. Somehow I did not get it directly, but found it on-line after Paul mentioned it to me. >> MY FAILURE ON MACOS: The current GPC is compatible with the >> back-end of GCC 3.4.6 only. > No. While little used GCC 4.1.2 port is finished and should work > well. That must have been a fair amount of work, moving from 3.4.6 to 4.1.2. I understand the GCC middle end changed dramatically between 3 and 4. > First step would be to find out earliest GCC which supports 64-bit > Mac OS as target. How can I tell that it supports MacOS 64-bit? > It is possible that GCC-4.3.5 will do, attempting to build gets > beyond "Configuration x86_64-apple-darwin16.7.0 not supported" Ah, so that's the way you tell. You try it and see. > (full build requires Apple tools so I can not check if it works). I have the Command Line Tools (CLT). ASIDE ON CLT (NOT PARTICULARLY IMPORTANT): Building on MacOS, the clang assembler will perform the first build, which produces the xgcc and xgpc compilers. After that, the clang assembler fails because it does not recognise the ".stabs" debug directives produced by xgcc, which is GCC 3.4.6. All the xgcc compilation is done with the debug "-g" flag. The "-g" option is so deeply embedded into the GPC build that I could not get rid of it, even after removing the string "-g" from every file I could find it in. I must have missed the one critical, originating occurance. If I instead use the CTools version of the GNU Assmbler that is provided with CLT, that assembler fails to compile xgcc in the first place, because it cannot compile 64-bit instructions like "movq %xmm0,%rax", where a 128-bit register is moved into a 64-bit register (it complains when it should take the top or bottom 64 bits). So we need one assembler for the host and one for the target. I tried all manner of messing about with environment variables, but could not persuade the build to use two different assemblers for the xgcp and gpc builds. In the end, I let the build fail, edited the gcc makefile, re-configured the gcc makefile, and re-started. But the code produced by the second stage was 32-bit and could not be linked to the 64-bit libraries. If we build on GCC-4, I will be able to use the same assembler, the CLANG assembler, for the entire build. > Anyway, I would suggenst trying http://github.com/hebisch/gpc with GCC-4.3.5. Look at README, for 4.3.5 you need to use '--disable-mapped-location'. Thank you. I have the zip archive. Will start on it soon. Best, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://www.bndhep.net

1 0

Building gpc for Centos 7
by Martin Liddle 25 Jun '19

25 Jun '19

Following on from the "Installing on Debian Stretch" thread, I wondered if anybody had experience of building gpc for Centos 7 (64 bit only). The default gcc version is 4.8.5. I have read Waldek's very helpful reply in the previous thread but before I plunge myself into a world of pain, I wondered if anybody else had trodden the same path? -- Martin Liddle, Tynemouth Computer Services, Chesterfield, Derbyshire, UK. www.tynecomp.co.uk

2 3

Installing on Debian Stretch?
by Ken Linder 24 Jun '19

24 Jun '19

Hello all, Thought I would try installing the most recent version of GPC on my Debian Stretch machine. I downloaded gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz and expanded it as specified here: https://www.gnu-pascal.de/gpc/Binary-Distributions.html#Binary-Distributions It doesn't matter what options I use when trying to run the GPC compiler. I always get the following error: -bash: /usr/local/bin/gpc: No such file or directory I think something is missing somewhere, just not certain what. So the simple question before digging in: Has anyone successfully installed the 2.1 compiler on Debian Stretch? If so, was there something additional that needs to be done? Thanks all -Ken

6 11

Is GPC dead?
by Thomas Schneider 12 Jun '19

12 Jun '19

It's been some years since GPC failed to compile on macOS. Is there any hope that someone knowledgeable will get this going again or is Pascal a dead language that we best abandon? Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

6 5

status of GNU Pascal on macOS
by Thomas Schneider 28 Mar '19

28 Mar '19

Some time ago the GNU Pascal compiler stopped working on macOS. Is there any effort to get it going again? Thanks, Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Biological Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://alum.mit.edu/www/toms

1 0

compiling gpc units
by Paul Isaacs 15 Nov '18

15 Nov '18

Hello, I have compiled and installed gpc but don't know how to compile the gpc units in the gcc/p directory. What am I missing? Thanks, Paul Isaacs

2 1

for loop
by Paul Isaacs 18 Feb '18

18 Feb '18

Hello all, GPC 20060325 based on gcc-3.4.4 for i:= -1 to -1 do writeln( i ); produces: -1 0 Is this correct? Thanks, Paul Isaacs

3 3

GNU Pascal Compiler
by Gayle Lee Fairless 09 Aug '17

09 Aug '17

Is there a Debian package for stretch Version 9.1.0 ?

2 1

Can I Install GPC on MacOS10.12?
by Kevan Hashemi 26 Jul '17

26 Jul '17

Greetings, I updated my MacOS 10.7.5 machine to 10.12.6. My gpc installation is still on my hard drive. I'm trying to get it to work. No luck so far. I know that Gale and others have listed what needs to be fixed in order to compile GPC on MacOS 10.12. Is it possible to install and run Adriaan's 10.6 binaries on 10.12? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

3 5

strict productions
by Paul Isaacs 01 Mar '17

01 Mar '17

Hello, Is the 10206 spec not strict? 6.8.6.2 Indexed-function-accesses An indexed-function-access shall denote a component of the value of a function-access possessing an array-type or a string-type. indexed-function-access = array-function `[' index-expression { `,' index-expression } `]' j string-function `[' index-expression `]' . array-function = function-access . But: 6.8.6 Function accesses function-access = entire-function-access | component-function-access | substring-function-access . component-function-access = indexed-function-access | record-function-access . entire-function-access = function-designator . And: 6.8.5 Function-designators function-designator = function-name [ actual-parameter-list ] According to the productions an indexed-function-access => array-function => function-access=>indexed-function -access Therefore, the only exit is via entire-function-access. But this would lead to a sentence of the form: x( a,b,c)[ 6,7,8 ] being valid and it is not. From: 6.8.6.2 Indexed-function-accesses An indexed-function-access shall denote a component of the value of a function-access possessing an array-type or a string-type. But this would be an identifier and the function-access productions do not indicate identifiers. Are the productions not strict? Does function-access include identifiers? Regards, Paul Isaacs

3 10

10206 productions re-write
by Paul Isaacs 24 Feb '17

24 Feb '17

Hello, Is the following rewrite correct? variable-access = entire-variable | component-variable | identified-variable | buffer-variable entire-variable = variable-identifier component-variable = indexed-variable | field-designator identified-variable = pointer-variable, '^' buffer-variable = file-variable, '^' indexed-variable = array-variable, `,', index-expression, < `,', index-expression > `]' field-designator = record-variable, ` .', field-specifier | field-designator-identifier array-variable = variable-access record-variable = variable-access pointer-variable = variable-access file-variable = variable-access field-specifier = field-identifier REWRITTEN variable access = entire variable | ( array variable, '[' index expression, < ',', index expression > ']' | record variable, '.' field specifier | field designator identifier | pointer variable, '^' | file variable, '^' | field specifier ), { '^' | '[' index expression, { ',', index expression }, ']' | '.', field specifier | field designator identifier } Thanks, Paul Isaacs

3 4

Two Dimensional Arrays
by Peter 14 Feb '17

14 Feb '17

Hi, Does anyone know the syntax for initializing a dynamic array of more than one dimension? type {$ifdef __GPC__} tMSet (n:CWord) = Array [1..n, 1..n] Of double; {$else} tMSet = Array Of Array Of double; var MSet : tMSet; {$endif} pMSet : ^tMSet; ........ {$ifdef __GPC__} new (pMset, n, n); {$else} SetLength (Mset, n, n); pMSet := @Mset; {$endif} The above works in FPC, but fails in GPC on the "new" with "error: `New' applied to this schema requires 1 discriminant value" This general approach works fine for 1D arrays. Regards, Peter B

2 3

10206 lexical ambiguity
by Paul Isaacs 24 Jan '17

24 Jan '17

Hello, Am I correct that, without semantic type tie-ins, that the production new-ordinal-type = enumerated-type | subrange-type ; is ambiguous because (a) could be both an enumerated type and the expression for the lower bound of a subrange? Regards, Paul Isaacs

5 9

function-pointer
by Paul Isaacs 23 Jan '17

23 Jan '17

Hello, From ISO spec: production: expression can be variable-access variable-access can be function-identified-variable function-identified-variable is pointer-function '^' pointer-function is function-access function-access can be entire-function-access entire-function-access is function-designator function-designator is function-name But: function test : boolean; begin test := false; end; procedure test1; begin if test^; end; generates the error "invalid type of argument of '^'" function-identified-variable only appears on the rhs of the variable access production. The expression test^ seems lexically correct. I know I am wrong. But where? How is function-identified-variable used? I really can't understand 6.8.6.4 Function-Identified-Variables of the spec. It sounds like a function-identified-variable is the return value of a pointer function. Is test^ a pointer function? Regards, Paul Isaacs

1 1

Re: type-inquiry
by Waldek Hebisch 22 Jan '17

22 Jan '17

I wrote: > > Paul Isaacs wrote: > > > > On 22/01/17 11:09 AM, Waldek Hebisch wrote: > > > It seems that if you want you can replace type-inquiry by explicit > > > definition. > > > > Hello Waldek, > > > > Thanks for the reply. I just assumed, incorrectly, that type-inquiry was > > a reflective construct of some sort. > > It _is_ a reflective construct. Just most of time you can live > without it. Maybe an example: > > var a : record i : integer end; > > Note that if you write: > > var b : record i : integer end; > > then b will be of different type than a (because each 'record' > introduces entirely new type). You can solve the problem > using named type: > > type t = record i : integer end; > var a : t; > > var b : t; > > Or you can use type-inquiry: > > var b : typeof(a); > > If you can modify declaration of 'a' you probably prefer > first version. But in real life you may be unable to > modify declaration of 'a'... > > Note: in GPC 'typeof' is only implemented for object types > (which are absent in Extended Pascal) so this does not work. Oops. I should write: var b : type of(a); 'typeof' is a Borland Pascal stuff, 'type of' is Extended Pascal. Both are obscure enough that I confused them. -- Waldek Hebisch

1 0

type-inquiry
by Paul Isaacs 22 Jan '17

22 Jan '17

Hello, How is the production type-inquiry used? var p : integer; type q = type of p; How would it be possible that inquiring as to the type of p is useful? Under what circumstances would the type of p not be already known? Even if the type of p were not known, how would q be usable if its type were not fixed? The only reference I can find is in the GNU-Pascal Manual. function CompilerAssert( condition : boolean, result : Anytype ) : type of Anytype; What would be returned? Unless Anytype is restricted to types that CompilerAssert is aware of. Regards, Paul Isaacs

3 4

program parameters
by Paul Isaacs 19 Jan '17

19 Jan '17

Hello, Are program parameters tied in any way to command line parameters? Is it possible to set BindingType.Name from the command line using a program parameter? program( a ... var a : bindable Text; b : BindingType; begin b := Binding( a ); Bind( a, b ); where b.Name has been set from the command line. Thank you, Paul Isaacs

3 3

Re: Gpc Digest, Vol 43, Issue 19
by Oscar Flor 16 Jan '17

16 Jan '17

Thanks You very much Peter... El 16/1/2017 8:00, <gpc-request(a)gnu.de> escribió: > Send Gpc mailing list submissions to > gpc(a)gnu.de > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.g-n-u.de/mailman/listinfo/gpc > or, via email, send a message with subject or body 'help' to > gpc-request(a)gnu.de > > You can reach the person managing the list at > gpc-owner(a)gnu.de > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gpc digest..." > > > Today's Topics: > > 1. Re: rpm available for fedora (Peter) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 15 Jan 2017 17:10:55 +0000 > From: Peter <peter(a)pblackman.plus.com> > To: gpc(a)gnu.de > Subject: Re: rpm available for fedora > Message-ID: <52de0911-c796-8df9-e265-2c46a12ce673(a)pblackman.plus.com> > Content-Type: text/plain; charset=utf-8 > > On 13/01/17 15:16, Oscar Flor wrote: > > Hi Pals: > > > > I find on rpm.pbone rpm packages of gpc20070904 for 64 and 32 bits. I > > test it on Fedora 20 and works. I realize that this version of Fedora > > have the gcc 4.8 installed on it, thats have me to think that this is > > not used to compile gpc and make the rpm package. > > > > I will test on newest fedora releases to know if they still work. > > Meanwhile I will learn read about GCC and his tools to try to make a > > compile on newest vesions on GCC. > > > > Best Regards > > > > Oscar Flor > > > > Hi Oscar, > > The build process is well defined here > http://alignment.hep.brandeis.edu/Software/Pascal/Pascal. > html#Compiling%20from%20Sources > > > The Fedora source packages will likely contain extra patches to help > build (with 4.8) the version of GCC that GPC is based on. There may be > other fixes to the Autotools stuff too. > > > Regards, > Peter > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Gpc mailing list > Gpc(a)gnu.de > https://www.g-n-u.de/mailman/listinfo/gpc > > ------------------------------ > > End of Gpc Digest, Vol 43, Issue 19 > *********************************** >

1 0

rpm available for fedora
by Oscar Flor 15 Jan '17

15 Jan '17

Hi Pals: I find on rpm.pbone rpm packages of gpc20070904 for 64 and 32 bits. I test it on Fedora 20 and works. I realize that this version of Fedora have the gcc 4.8 installed on it, thats have me to think that this is not used to compile gpc and make the rpm package. I will test on newest fedora releases to know if they still work. Meanwhile I will learn read about GCC and his tools to try to make a compile on newest vesions on GCC. Best Regards Oscar Flor

2 1

Vectorizing
by Peter 12 Jan '17

12 Jan '17

I've managed to get some Pascal code to vectorize! See attached example. I used GNU Pascal version 20070904, based on gcc-4.3.6. (64bit) Earlier 4.3.x might work, please try it. Caveats; Array to vectorize must start with lower bound zero. Must use While loop (For loop did'nt work). 32 bit Integers not working, floats or 64bit Ints only. gpc -O3 -ftree-vectorizer-verbose=2 av.pas av.pas:19: note: LOOP VECTORIZED. av.pas:0: note: vectorized 1 loops in function. Regards, Peter

1 0

Inlining with gcc 4.x.x (Linux) ?
by Peter 12 Jan '17

12 Jan '17

I've built GPC 3.4.6 and 4.3.6 on Debian Stretch (64bit) Running benchmarks on a Perlin Noise routine I get 3.4.6 5.6 secs 4.3.6 11.0 secs !! The difference seems to be mainly down to a failure of 4.3.6 to inline. Call functions themselves may not take much time but I believe the real problem is that without the subroutines inlined, the main Noise function is no longer a leaf function, and therefore under register pressure. â¦..... a := Lerp (sx, u10, v10); b := Lerp (sx, u11, v11); d := Lerp (sy, a, b); Noise3 := Lerp(sz, c, d); End; This code produces with 3.4.6 { Hard to know where it starts without line numbers ! } addsd %xmm9, %xmm7 addsd %xmm3, %xmm2 subsd %xmm0, %xmm1 subsd %xmm7, %xmm2 mulsd %xmm14, %xmm1 mulsd %xmm14, %xmm2 addsd %xmm0, %xmm1 addsd %xmm7, %xmm2 subsd %xmm1, %xmm2 mulsd %xmm2, %xmm12 movsd %xmm12, %xmm0 addsd %xmm1, %xmm0 ret which is pretty lean & mean. However, with 4.3.6 I get movsd 112(%rsp), %xmm2 movsd 104(%rsp), %xmm1 movsd 48(%rsp), %xmm0 call _p__M0_S5_Lerp movsd 128(%rsp), %xmm2 movsd %xmm0, 152(%rsp) movsd 120(%rsp), %xmm1 movsd 48(%rsp), %xmm0 call _p__M0_S5_Lerp movsd 152(%rsp), %xmm1 movapd %xmm0, %xmm2 movsd 56(%rsp), %xmm0 call _p__M0_S5_Lerp movsd 40(%rsp), %xmm1 movapd %xmm0, %xmm2 movsd 64(%rsp), %xmm0 call _p__M0_S5_Lerp addq $240, %rsp popq %rbx popq %rbp popq %r12 popq %r13 popq %r14 popq %r15 ret ( Stack spills tend to be expensive on [my] AMD processor as the level 0/1 cache isn't that fast. Maybe I have broken my build of 4.3.6 Can anyone else conform the status of inlining on linux x86 with 4.x.x compilers? The simple example from the info file program InlineDemo; function Max (x, y: Integer): Integer; attribute (inline); begin if x > y then Max := x else Max := y end; begin WriteLn (Max (42, 17), ' ', Max (-4, -2)) end. Also does not work for me with 4.3.6. It still produces a call instruction. call _p__M0_S0_Max I recall also that inlining did not work with the official 4.1 Debian package. I was thinking of reporting this as a (Debian) bug a while back, but GPC was then removed from the archive, which made that moot. Going forward, I'm wondering which gcc version to base my builds on. 4.3.6 supports potentially a few more architectures, ARMel PowerPC SH4 and supports the -m32 switch, but a 100% slowdown on the CPU intensive stuff I use the compiler for is too much a penalty for me. >From further tinkering around, I notice that 3.4.6 often inlines even when not asked to do so, whereas 4.3.6 very rarely if ever inlines. Neither compiler seems to obey the inline attribute! Anyone any thoughts on this? Hoping of course that its an easy to fix typo type bug... Regards, Peter B

5 9

GNU Pascal is still kind of alive (was: Extended Pascal)
by Treutwein Bernhard 10 Jan '17

10 Jan '17

Thanks a lot Waldek for: >Actually, this list is out of date. Starting from gpc-20051104 >qualified module import and structured value initializers are supported. >Few other were supported earlier. Current statement (which >AFAICS corresponds to gpc-20051104) is: > >: The Extended Pascal features still missing from GPC >: are set types with variable bounds and discriminated ordinal schema as >: schema discriminants. > Please don't be insulted, I appreciate very much what you are doing for GNU Pascal, but I think your note gives a good impression of the major obstacles for newcomers to gpc. A lot of information is hidden behind the web sites in personal memories. I know of the following sites: http://www.gnu-pascal.de/gpc/h-index.html http://alignment.hep.brandeis.edu/Software/Pascal/Pascal.html http://www.microbizz.nl/gpc.html https://github.com/hebisch/gpc Maybe there are more. Some infos from the brains went to the mailing list and is available in the archive. But it is unclear to me (and I guess others also) which information is still relevant and which is out of date. This is a bit frustrating, but as long as we have only more or less hobbyists working on GNU Pascal, we are out of luck. I do not know who, how, and where the collected and hopefully current information could be concentrated, but I think it would be very good to have a central place ... Peter Gerwinski noted las march a vague chance to have some student working for her/his thesis on GNU Pascal ... -- Bernhard

7 7

RE: Update: Current GPC
by Treutwein Bernhard 10 Jan '17

10 Jan '17

Dear Waldek, [...] >If this is the case you should enable others to update the wiki. Oops. I just tried to edit the start page. As a signed in user, I am allowed to edit the page. @Oscar and @Ken: please try it also and go ahead if nobody objects -- Bernhard >-----Original Message----- >From: Treutwein Bernhard >Sent: Monday, January 09, 2017 1:56 PM >To: 'gpc(a)gnu.de' >Subject: Current GPC was: GNU Pascal is still kind of alive > >Dear Waldek, > >>> https://github.com/hebisch/gpc >>> >[...] >>At github there is updated manual (changes to earlier versions are >>small, but for example it contains up-to-date features list). > >Do I understand you correctly: > >https://github.com/hebisch/gpc is the current repository for >GNU Pascal source and documentation. > >If this is the case you should enable others to update the wiki. > >PS: I contacted Peter Gerwinski via PM if he is still watching >this mailing list and who/how somebody could be authorized >to update www.gnu-pascal.de. > >-- > Bernhard

1 0

Re: GPC compile on Mac OS X 10.10.5?
by Schneider 10 Jan '17

10 Jan '17

Adriaan: > >*I'm on the new Mac OS X 10.10.5 and I've lost my gpc compiler.* > > Sorry, were to busy to reply, but will > > Regards, > > Adriaan van Os 3/4 of a year later I'm still having trouble with various alternatives to GPC. Are you in a position to get back to this? I see at http://www.microbizz.nl/gpc.html that > If you need paid technical support, send an email to > gpc(a)microbizz.nl. Microbizz can help you port your software to GNU > Pascal and to Mac OS X How much might it be to get GPC going again on the Mac? Regards, Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

15 51

Current GPC was: GNU Pascal is still kind of alive
by Treutwein Bernhard 09 Jan '17

09 Jan '17

Dear Waldek, >> https://github.com/hebisch/gpc >> [...] >At github there is updated manual (changes to earlier versions are >small, but for example it contains up-to-date features list). Do I understand you correctly: https://github.com/hebisch/gpc is the current repository for GNU Pascal source and documentation. If this is the case you should enable others to update the wiki. PS: I contacted Peter Gerwinski via PM if he is still watching this mailing list and who/how somebody could be authorized to update www.gnu-pascal.de. -- Bernhard

1 0

list server not responding?
by Schneider 07 Jan '17

07 Jan '17

I'm getting both individual postings and a digest. I want to stop the digest. So I sent: > Date: Wed, 4 Jan 2017 18:30:25 -0500 > From: Schneider <schneidt(a)mail.nih.gov> > To: gpc-request(a)gnu.de > Subject: set help > User-Agent: Mutt/1.7.1 (2016-10-04) The response included: > set digest plain > set digest mime > set digest off > When the `digest' option is turned off, you will receive postings > immediately when they are posted. Use `set digest plain' if instead > you want to receive postings bundled into a plain text digest > (i.e. RFC 1153 digest). Use `set digest mime' if instead you want to > receive postings bundled together into a MIME digest. So I sent: > Date: Wed, 4 Jan 2017 18:43:31 -0500 > From: Schneider <schneidt(a)mail.nih.gov> > To: gpc-request(a)gnu.de > Subject: set digest off > User-Agent: Mutt/1.7.1 (2016-10-04) but I'm still getting the digest every day. Have I done this wrong somehow or is the server broken? Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research RNA Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

1 0

Running on a Mac
by Paul Isaacs 04 Jan '17

04 Jan '17

Hello, For Macs, Will gcc-3.4.4 and gpc20060325 compile and run on a current Mac? If not, will a cross compile of same run on a current Mac? Thanks, Paul Isaacs

3 3

GPC on Mac
by Schneider 18 Jul '16

18 Jul '16

Is there any progress to get the GPC compiler going again on the Mac? Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

1 0

Re: GPC compile on Mac OS X 10.10.5?
by Pascal 14 Jul '16

14 Jul '16

Hello Tom, If ever you consider a port to an another language, I suggest Ada. Ada is issued from Pascal with strong type checking and more. (www.ada2012.org) It is an ISO standard. I port all my Pascal programs to Ada since 2000 and I'm very happy with it. I used P2Ada: http://p2ada.sourceforge.net. I have some exemples on my web site (in French). Feel free to ask questions if you are interested in. Regards, Pascal. http://blady.pagesperso-orange.fr > Le 27 janv. 2016 à 22:08, gpc-request(a)gnu.de a écrit : > > Date: Wed, 27 Jan 2016 14:11:59 -0500 > From: Schneider <schneidt(a)mail.nih.gov> > To: <samiam(a)moorecad.com> > Cc: gpc(a)gnu.de > Subject: Re: GPC compile on Mac OS X 10.10.5? > Message-ID: <20160127191159.GA73206(a)FR-W-C132678.ncifcrf.gov> > Content-Type: text/plain; charset="us-ascii" > > Scott: > >> What was wrong with getting a p2c translation (just curious). You >> only have to do the translation once, then you code in C after that. > > I'm used to programming in Pascal, not C. Also, it's safer because of > the type checking. If I switched I could never go back. > >> I used p2c (I assume we are talking about the same one). Its a very >> picky tool that crashes when you look at it funny, but I was able to >> get satisfactory results. > > You are right about looking at it funny! One kind of bug(?) is that > it changes how it handles i/o for the input file in the middle of the > code. I haven't determined why but fortunately it's a rare problem. > > Tom > > Thomas D. Schneider, Ph.D. > Senior Investigator > National Institutes of Health > National Cancer Institute > Center for Cancer Research > Gene Regulation and Chromosome Biology Laboratory > Molecular Information Theory Group > Frederick, Maryland 21702-1201 > schneidt(a)mail.nih.gov > https://schneider.ncifcrf.gov (current link) > https://alum.mit.edu/www/toms (permanent link) >

2 1

found install-gpc-binary
by Schneider 13 Jul '16

13 Jul '16

I found the file at http://www.gnu-pascal.de/binary/install-gpc-binary Can any of the binaries at http://www.gnu-pascal.de/binary/ run on an amd64? Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

1 0

lost directory
by Schneider 13 Jul '16

13 Jul '16

I'm looking at http://www.gnu-pascal.de/stable/gpc-2.1.tar.gz The INSTALL file says: > - Run the script `install-gpc-binary', available from > `http://www.gnu-pascal.de/current/binary/'. but that link brings me to: http://www.gnu-pascal.de/alpha/binary/ which says: > Not Found > The requested URL /alpha/binary/ was not found on this server. so the documentation is out of date. Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

1 0

Source code repository
by Christos Kontas 07 Jul '16

07 Jul '16

Hello! I was trying to find any repository with the project's source code, but after too many attempts I found nothing. Although the source code of the project *is* available, yet I can't find the history of the project. Can somebody please point me to the correct direction? Thank you in advance! --- Christos Kontas, kontas(a)ceid.upatras.gr

2 2

binding to non-existent file
by Paul Isaacs 31 Mar '16

31 Mar '16

Hello, I am following the example from page 94 of the GNU pascal manual. bind( f,b); b := binding( f ); b.bound appears to be true even though the file does not exist although the example indicates otherwise. I have duplicated the example - it finds a non-existent file. Is the example wrong ( the same example is in the standard )? Regards, Paul Isaacs

2 1

Re: Problems when compiling "crtdemo.pas" SOLVED!
by mathias uhle 29 Mar '16

29 Mar '16

Hello Chief, hello Peter, defining Variables and exporting them DID WORK! I really have to thank you and I express, I do! I will now start my project, it is an old integrated development sytem for Motorola M6800 Microprocessors including an assembler and a simulator, first started in 1981. Thank you again (I learned a bit) Mathias Uhle -- mathias.uhle(a)tu-dortmund.de

2 2

Re: Problems when compiling "crtdemo.pas"
by mathias uhle 29 Mar '16

29 Mar '16

Well, befor the diverse compiling efforts I checked that ncurses was installed and found that: libncurses5, libncurses6,ncurses-devel and ncurses-utils were installed! Further a "find" revealed that there were copies of "panel.h" in /usr/include/ncurses /usr/include/ncurses6/ncurses /usr/include/ncurses6/ncursesw /usr/include/ncursesw So thas before I called for help I added now: libncurses5-32bit, ncurses6-32bit and ncurses-devel-32bit. althoug it is an 64-bit system. The effect on compilation was nil! I now copied "panel.h" into my testdirectory: no effect on compilation! Next try: put it into the source-directory of "crtc.c": no effect! GPC still complains not to find "panel.h" Feel a bit helpless. Mathias Uhle PS.: I tried even an strace gpc .... and searched the output for "panel.h": did find none -- Univ.-Prof. i.R. Dr.-Ing. Mathias Uhle mathias.uhle(a)tu-dortmund.de

2 1

Re: Problems when compiling "crtdemo.pas"
by mathias uhle 29 Mar '16

29 Mar '16

Hello, The following information I dare to send to the list as requested bei "The Chief": The used distribution is SuSE-linux 13.2 Harlequin, last updated 28th of March, 2016 CPU is Athlon 64 3200+, memory: 3G. uname -a says:Linux scaleo 3.16.7-35-desktop #1 SMP PREEMPT Sun Feb 7 17:32:21 UTC 2016 (832c776) x86_64 x86_64 x86_64 GNU/Linux I started the compilation in a separate directory with contents: -rw-r--r-- 1 senior users 34539 4. Sep 2007 crtdemo.pas -rw-r--r-- 1 senior users 4601 29. Mär 12:54 list-of-rpm.txt compilation command: gpc --automake -ocrt crtdemo.pas 2>&1 | tee errlist.txt contents of the directory after this: -rw-r--r-- 1 senior users 34539 4. Sep 2007 crtdemo.pas -rw-r--r-- 1 senior users 414287 29. Mär 13:03 crt.gpi -rw-r--r-- 1 senior users 36246 29. Mär 13:03 errlist.txt -rw-r--r-- 1 senior users 816896 29. Mär 13:03 gpc-all.gpi -rw-r--r-- 1 senior users 13138 29. Mär 13:03 gpc_bp.gpi -rw-r--r-- 1 senior users 851 29. Mär 13:03 gpc_cp.gpi -rw-r--r-- 1 senior users 30572 29. Mär 13:03 gpc_delphi.gpi -rw-r--r-- 1 senior users 851 29. Mär 13:03 gpc_ep.gpi -rw-r--r-- 1 senior users 872729 29. Mär 13:03 gpc.gpi -rw-r--r-- 1 senior users 1592 29. Mär 13:03 gpc.o -rw-r--r-- 1 senior users 4601 29. Mär 12:54 list-of-rpm.txt To keep the appended tar-file smaller I delete all .gpi files, hope that is ok.! The appended tar-file contains a list of the contents of the installed GPC- .rpm, generated by: rpm -qlp gpc-20070904-185.1.x86_64.rpm >list-of-rpm.txt That rpm-file was downloaded from: "https://openSUSEBuildService>Projects>home:TrevorBl>gpc>Binaries gpc-20070904-185.1.x86_64.rpm" Hope this is the needed information. Thank you so far, and sorry again: no c-knowledge, no c-experience Mathias Uhle -- Univ.-Prof. i.R. Dr.-Ing. Mathias Uhle mathias.uhle(a)tu-dortmund.de

2 3

Re: Problems when compiling "crtdemo.pas"
by Prof Abimbola Olowofoyeku 29 Mar '16

29 Mar '16

On 29 Mar 2016 at 12:37, mathias uhle wrote: > Hello Chief, > > thank you for that offer. I will prepare a tar-file with the details in > an hour or so and mail it to you. [...] Please post your error log to the GPC list. Also, you might first want to try compiling the program using "--autobuild" Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

Problems when compiling "crtdemo.pas"
by mathias uhle 29 Mar '16

29 Mar '16

Hello out there trying to compile the example-program "crtdemo.pas" produces an awful lot of errors for me. My problem is: I am by no means accustomed to "c". The purpose of my attempt is to transfer a very old program from Novell-Dos to SuSE 13.2 The program heavily relies on what is now ncurses. But even that is new to me. I just tried: gpc --automake -ocrt crtdemo.pas The running 64-Bit version of the GPC-compiler and the "crtdemo.pas" are from: "https://openSUSE Build Service > Projects > home:TrevorBl > gpc > Binaries > gpc-20070904-185.1.x86_64.rpm" This rpm installed properly and works fine with a wealth of my programs running on an old Athlon 64 3200+ Mem: 3G Any help possible? Mathias Uhle -- mathias.uhle(a)tu-dortmund.de

2 1

Re: function-identifier-variable
by Waldek Hebisch 29 Mar '16

29 Mar '16

Paul Isaacs wrote: > > As it is I was thinking function-access would be accessing a function, > not a return value. > Component-function-access with array and records was providing clues but > I just couldn't figure out the meaning. > > Am I correct in now thinking that 10206 will not provide any way to get > the address of a function the way that the @ extension does in gnu > pascal without the --extended-pascal restriction? In ISO Pascal you have variable parameters and procedural parameters. They allow you to do most things possible with address operator, but not all and in a different way. > I am chugging away writing a 10206 compliant compiler using GNU pascal > and suddenly thought that using extensions to enable the writing of a > compliant compiler was not a great way to advertise 10206. I recognize > that the extensions are there because they are useful - but - do they > also flag 10206 as a poor standard to use? Well, 10206 was deliberately limited. Practically, decent compiler should allow writing runtime library. But ISO 10206 misses extentions needed for writing functions like 'new'. This does not mean that this is poor standard, just that for some purposes you may need extentions. > I am hesitating to use extensions because the target of the compiler > will be embedded processors.They are problematic to debug so you want to > have the compiler produce code that is as bug free as possible. I though > that sticking to the standard would be the safest thing to do. > > The Arduino and Raspberry-pi users will be attracted to a compiler that > is safe but does not have a language as challenging to learn as ada. > > I was using the @ operator to jump back to a known place in the parse to > re-sync after a syntax error. I will use jumps if I have to but they are > far from handy. Some comments: - I would just abort parse after first syntax error, so no need to re-sync - @ operator alone is safe. One can even claim that it is less error prone than var parameters. What is unsafe is pointer arithmetic as typically done in C (one can implement safely C pointer arithmetic but due to slowness and incompatibility with common practice safe implementation it is almost unused). - For Arduino you will need extensions to access hardware and on Raspberry Pi you will need to access foreign libraries. -- Waldek Hebisch

1 0

Re: function-identifier-variable
by Waldek Hebisch 28 Mar '16

28 Mar '16

Paul Isaacs wrote: > > > Waldek, Professor, > > Thank you for the replies. > > "A pointer-function shall be a function-access possessing : a pointer-type." > > Howvever, I can't see how to generate a function-access possessing a > pointer-type: Just declare apropriate return type. Useful example would be complicated, but a useless one is: program pb; type pb = ^boolean; var pv : pb; function y : pb; begin y := pv end; {Main program} begin new(pv); pv^ := true; {Use y} if y^ then writeln("OK") end . -- Waldek Hebisch

1 0

function-identifier-variable
by Paul Isaacs 28 Mar '16

28 Mar '16

Hello; program test; { productions: assignment-statement : contains expression expression : contains simple-expression simple-expression : eventually works down to primary primary : contains variable-access variable-access : contains function-identifier-variable function-identifier-variable = pointer-function '^' pointer-function : contains entire-function-access entire-function-access = function-designator function-designator = function-name [ actual-parameter-list ] function-name : contains identifier } { compiled with: $PASCAL/local/bin/gpc --extended-pascal test.pas test.pas: In main program: test.pas:11: error: invalid type of argument of `^' } function y : boolean; begin y := false; end; var x : boolean; begin x := y^; { isn't " y" a function-identifier-variable ? } end. Where is the error in thinking? Thanks, Paul Isaacs

3 2

compiling gcc-3.4.4
by Paul Isaacs 20 Mar '16

20 Mar '16

Hello, For what its worth: To overcome an error compiling unwind-dw2, Instances of "struct siginfo" have to be changed to "siginfo_t" in gcc-3.4.4/gcc/config/i386/linux.h Regards, Paul Isaacs

1 0

Compiling
by Paul Isaacs 19 Mar '16

19 Mar '16

Hello, running: 3.16.0-4-686-pae GNU/Linux Trying to compile: downloaded gpc-20060325 gcc-3.4.4 did: ------------ Solved: Not finding includes in /usr/include/i386-linux-gnu Regards, Paul Isaacs

1 0

Compiling
by Paul Isaacs 19 Mar '16

19 Mar '16

Hello, running: 3.16.0-4-686-pae GNU/Linux Trying to compile: downloaded gpc-20060325 gcc-3.4.4 did: moved p dir to gcc-3.4.4/gcc cd gcc-3.4.4 ( did not use build directory to keep things simple ) ./configure --prefix=/home/Downloads --enable-languages=pascal make got : after responding to patch request checking how to run the C preprocessor... /lib/cpp checking for inline... inline checking for long long int... yes checking for __int64... no checking for built-in _Bool... yes checking size of void *... configure: error: cannot determine a size for void * Makefile:23329: recipe for target 'configure-gcc' failed make: *** [configure-gcc] Error 1 Internet search not helpful. any ideas? Thanks, Paul Isaacs

1 0

more gpc bootstrapping errors
by Treutwein Bernhard 18 Mar '16

18 Mar '16

thanks for the feedback until now. I reverted back to texinfo 4.13 from the TinyCore 4.x repostitory I completely removed my working directory and started from the scratch. Now the info files are generated, but I'm still getting errors, this time the errors are more obscure to me. In file included from ../gcc-3.4.6/gcc/gcov-io.h:240, from ../gcc-3.4.6/gcc/libgcov.c:51: ./auto-host.h:188:1: warning: "HAVE_DECL_GETOPT" redefined In file included from ../gcc-3.4.6/gcc/libgcov.c:37: ../gcc-3.4.6/gcc/tsystem.h:40:1: warning: this is the location of the previous definition rm -rf ./libgcov.a ar rc ./libgcov.a libgcc/./_gcov.o libgcc/./_gcov_merge_add.o libgcc/./_gcov_merge_single.o libgcc/./_gcov_merge_delta.o ranlib ./libgcov.a /mnt/sda5/TeX-GPC/GPC/work/gcc/xgcc -B/mnt/sda5/TeX-GPC/GPC/work/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../gcc-3.4.6/gcc -I../gcc-3.4.6/gcc/. -I../gcc-3.4.6/gcc/../include -fexceptions -c ../gcc-3.4.6/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o ../gcc-3.4.6/gcc/unwind-dw2.c: In function `uw_frame_state_for': ../gcc-3.4.6/gcc/unwind-dw2.c:1031: error: field `info' has incomplete type libgcc.mk:122: recipe for target 'libgcc/./unwind-dw2.o' failed make[2]: *** [libgcc/./unwind-dw2.o] Error 1 make[2]: Leaving directory '/mnt/sda5/TeX-GPC/GPC/work/gcc' Makefile:1228: recipe for target 'libgcc.a' failed make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory '/mnt/sda5/TeX-GPC/GPC/work/gcc' Makefile:23375: recipe for target 'all-gcc' failed make: *** [all-gcc] Error 2 Should I try to revert back also gcc? Which version would be preferred? I am currently using TinyCore 7, in version 6, there was gcc-4.9.1, version 5 had 4.7.2 and version 4 had 4.6.1. I don't really know what happens if I mix development tools from different version, but apparently most required tools are packaged in one pseudo-package. Here are the versions of the different tools I used this time: makeinfo (GNU texinfo) 4.13. gcc (GCC) 5.2.0 GNU bash, version 4.3.39(1)-release (i486-pc-linux-gnu) bzip2, a block-sorting file compressor. Version 1.0.6, 6-Sept-2010. sed (GNU sed) 4.2.2 GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.3-p4, GNU MP 6.0.0) m4 (GNU M4) 1.4.17 bison (GNU Bison) 3.0.4 flex 2.5.39 autoconf (GNU Autoconf) 2.69 GNU help2man 1.46.1 Regards and thanks in advance for any help -- Bernhard Treutwein

2 2

gp file not found
by Paul Isaacs 15 Mar '16

15 Mar '16

Hello, I have installed gp using: make prefix=$PASCAL/local CFLAGS=-I/usr/include/i386-linux-gnu install and adding $PASCAL/local/bin to PATH gp --version reports "GP version 0.61" However gp x.pas results in "x.pas: file not found" At line 2643 in gp.pas the error message literal is "file not found". The ":" after the file name is must be from MainSrcBase If I place two source files on the command line the expected error occurs. I am using Q4OS linux and the source file is present when I do an "ls". What am I doing wrong? Thanks, Paul Isaacs

1 0

Variable length argument types for libusb binding
by Paul Isaacs 15 Mar '16

15 Mar '16

Hello, I have written a gnu pascal binding for libusb. I would like to improve it by using schemata for the various variable length libusb function arguments. I can come close by generating the USB arg pointer dynamically as follows: UsbArgPtr := UsbPtr( addr( ArraySchemata[ 1 ] ) ) to generate a pointer to the array within the schemata. This process can be hidden within the thick binding but not the thin binding. I would like to be able to declare a type that points to this address for use as an argument type in the binding functions. Is this possible? Do schemata have other attributes as well as .Size that could be used? Thanks, Paul Isaacs

1 0

Re: Trapping RTS faults
by Paul Isaacs 15 Mar '16

15 Mar '16

On 14/03/16 03:49 PM, Gale Paeper wrote: > Adriaan has two links for downloading the Mac OS X tuned GPC build > from source code packages. Hello Gale, Finally clued that HFS was a compressed file. I will attempt to apply the patch to the gcc version but it may be above my pay grade. Thanks, Paul Isaacs

1 0

Trapping RTS faults
by Paul Isaacs 14 Mar '16

14 Mar '16

Hello, The Trap unit traps system faults but does not seem to catch RTS errors ( index out of range, etc. ). Is there a way to trap RTS faults so that something like ncurses can be closed down properly? Thanks, Paul Isaacs

2 2

gpc bootstrapping fails on makeinfo
by Treutwein Bernhard 13 Mar '16

13 Mar '16

Hi all, when I try to bootstrap gpc, on a TinyCore 7.0 Linux with the necessary extensions installed. I downloaded the source distribution from http://alignment.hep.brandeis.edu/Software/Pascal/gpc-20070904-build.tar.gz and followed the instructions given in http://alignment.hep.brandeis.edu/Software/Pascal/Pascal.html But make aborts with the following error (after quite some time workin and some warnings) during the attempt to create the info files: [...] make[2]: Entering directory '/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/rts' cd /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" generated-files make[2]: Entering directory '/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/rts' make[2]: Nothing to be done for 'generated-files'. make[2]: Leaving directory '/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/rts' [ -d "/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info" ] || /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/script/mkdir-p "/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info" LANG=en_GB LC_ALL=en_GB makeinfo --split-size=5000000 -I /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc -I /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/en -I /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/generated -o /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info/gpc.info gpc.texi could not open gpc.texi: No such file or directory /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/Make-lang.in:808: recipe for target '/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info/gpc.info' failed make[1]: *** [/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info/gpc.info] Error 1 make[1]: Leaving directory '/mnt/sda5/TeX-GPC/work/gcc' Makefile:23375: recipe for target 'all-gcc' failed make: *** [all-gcc] Error 2 tc@box:/mnt/sda5/TeX-GPC/work$ I'm neither an autoconf nor a make guru so I am lost. I have no idea how I could tell make/configure to skip the step for creation of the documentation. I guess that it is almost done, but I am not sure about that, I tried to install with sudo make pascal.install-with -gcc which did something, but also ended with errors, which look very similar to the errors I hadbefore: [...] make[1]: Nothing to be done for 'generated-files'. make[1]: Leaving directory '/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/rts' [ -d "/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info" ] || /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/script/mkdir-p "/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info" LANG=en_GB LC_ALL=en_GB makeinfo -I /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc -I /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/en -I /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/generated -o /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info/gpc.info gpc.texi could not open gpc.texi: No such file or directory /mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/Make-lang.in:808: recipe for target '/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info/gpc.info' failed make: *** [/mnt/sda5/TeX-GPC/work/gcc-3.4.6/gcc/p/doc/info/gpc.info] Error 1 Although gpc --version now works. But I cannot compile anything. Going to demos and trying gpc hello.pas -o hello yields gpc: installation problem, cannot exec gpc1: No such file or directory Here are the versions of the different tools used: $ bash --version GNU bash, version 4.3.39(1)-release (i486-pc-linux-gnu) ... $ bzip2 --version bzip2, a block-sorting file compressor. Version 1.0.6, 6-Sept-2010. ... $ sed --version sed (GNU sed) 4.2.2 ... $ awk --version GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.3-p4, GNU MP 6.0.0) ... $ m4 --version m4 (GNU M4) 1.4.17 ... $ bison --version bison (GNU Bison) 3.0.4 ... $ flex --version flex 2.5.39 ... $ autoconf --version autoconf (GNU Autoconf) 2.69 ... $ makeinfo --version texi2any (GNU texinfo) 6.0 ... $ help2man --version GNU help2man 1.46.1 Regards and thanks in advance for any help -- Bernhard Treutwein

4 4

Re: GPC source code errors
by Waldek Hebisch 10 Mar '16

10 Mar '16

Gale Paeper wrote: > > While trying to get a successful compilation of GPC on Mac OS X 10.11 using AppleĂ˘ÂÂs LLVM based tool chain, I discovered what looks to be a couple of source code errors in p/statements.c in the expand_pascal_assignment2 functionĂ˘ÂÂs code. That function is declared with a void return type so there shouldnĂ˘ÂÂt be any return statements returning a value anywhere within the body of the function but there are two uses of the CHK_EM macro which does expand to a return statement that potentially returns a value (a tree type). Trying to potentially return something into the void of a non-existant return isnĂ˘ÂÂt technically correct code and I havenĂ˘ÂÂt found a way to get the LLVM based clang compiler to accept it. > > IĂ˘ÂÂll note that you can get a gnu gcc version 5.2.0 compiler to accept the code when compiling with the -std=gnu89 command line option. > > The GPC source code version IĂ˘ÂÂm trying to get compiling is the Adriaan van OsĂ˘ÂÂs Mac OS X patched gcc 3.4.6 with the p directory replaced with Waldek HebischĂ˘ÂÂs git repositoryĂ˘ÂÂs (<https://github.com/hebisch/gpc>) p directory source code. The code fragment containing the error producing code starting around line 1231 in file p/statements.c (in expand_pascal_assignment2 functionĂ˘ÂÂs body) is: > > schema_source = undo_schema_dereference (source); > schema_target = undo_schema_dereference (target); > DEREFERENCE_SCHEMA (source); > DEREFERENCE_SCHEMA (target); > CHK_EM (source); > CHK_EM (target); The patch below should fix this: diff --git a/p/statements.c b/p/statements.c index 4904834..e0026b7 100644 --- a/p/statements.c +++ b/p/statements.c @@ -1232,8 +1232,8 @@ expand_pascal_assignment2 (tree target, tree source, int is_init) schema_target = undo_schema_dereference (target); DEREFERENCE_SCHEMA (source); DEREFERENCE_SCHEMA (target); - CHK_EM (source); - CHK_EM (target); + if (EM (source)||EM (target)) + return; /* Restricted types. @@@@ Maybe this needs further checking */ if (TREE_CODE (source) == CALL_EXPR && PASCAL_TYPE_RESTRICTED (TREE_TYPE (source))) -- Waldek Hebisch

5 9

Inverse ord
by Paul Isaacs 07 Mar '16

07 Mar '16

Hello Waldek, Thanks, I should have looked longer and more carefully. I am retired now but spent my working years with micro/embedded processors. I want to keep my mind alive so I am setting forth to write a 10206 compliant compiler for embedded backends. Pascal should be a good fit for Arduino and Raspberry-Pi experimentalists. It is not as obscure as C and not as complex and picky as ADA. I am currently writing a 10206 compliant parser to produce a stream of lexically correct terminals from Pascal source. If I ever complete the lexical analysis, I will move on to semantically checking the results and producing a stream of intermediate opcodes for a backend. I know that I will need to feed extra information through the parser ( e.g. an "interrupt" directive for an interrupt procedure and "peek" and "poke" procedures for hardware I/O ) so I am looking for ways to do that and still be 10206 compliant. Thus the language lawyer interest. Thanks for your time. Maybe someday I will be able to make a contribution to the contributions section of the gpc web site. Regards, Paul Isaacs

1 0

Thanks
by Paul Isaacs 07 Mar '16

07 Mar '16

Hello Gale and Waldek, Thank you for your extensive replies. I will change over to using "gp". I notice that "inverse ord" is mentioned in the spec as an addition. However, other than a single mention, the spec is silent on inverse ord. Was such a thing implemented? The Gnu Pascal manual does not include the word "inverse". I would like to do a binary search on a set of keywords whose value is specified in a "TokenTypes" enumeration. The range of the array that stores the keywords and their value is the enumeration. Is it possible to compute the enumeration that is midway between two other enumerations? In other words is it possible to find an enumeration from its "ord" value? Regards, Paul Isaacs

2 1

Importing
by Paul Isaacs 07 Mar '16

07 Mar '16

Hello, I noticed that imports done outside the interface-specification-part are not dependency checked by --automake. This creates problems for first time gnu pascal uses such as myself. I started placing imports outside the interface-specification-part to avoid circular dependencies and it took a while to understand that --automake was no longer finding the import dependencies. I also assumed that the reason for the, rather awkward, multiple interface capability was to get around the module circular dependency problem. Ada resorted to the kludgy 'limited with' workaround. Gnu pascal seems to have resorted to the import 'in' workaround. However, having filenames in the source code does not seem to me to be a good idea. Would "import modulename_interfacename" work? The first '_' character would take on special meaning but the change would be 10602 specification compliant and having the module name and interface name combined into one identifier would eliminate the need for file names in the source code. Regards, Paul Isaacs

3 2

GPC source code errors
by Gale Paeper 25 Feb '16

25 Feb '16

While trying to get a successful compilation of GPC on Mac OS X 10.11 using Apple’s LLVM based tool chain, I discovered what looks to be a couple of source code errors in p/statements.c in the expand_pascal_assignment2 function’s code. That function is declared with a void return type so there shouldn’t be any return statements returning a value anywhere within the body of the function but there are two uses of the CHK_EM macro which does expand to a return statement that potentially returns a value (a tree type). Trying to potentially return something into the void of a non-existant return isn’t technically correct code and I haven’t found a way to get the LLVM based clang compiler to accept it. I’ll note that you can get a gnu gcc version 5.2.0 compiler to accept the code when compiling with the -std=gnu89 command line option. The GPC source code version I’m trying to get compiling is the Adriaan van Os’s Mac OS X patched gcc 3.4.6 with the p directory replaced with Waldek Hebisch’s git repository’s (<https://github.com/hebisch/gpc>) p directory source code. The code fragment containing the error producing code starting around line 1231 in file p/statements.c (in expand_pascal_assignment2 function’s body) is: schema_source = undo_schema_dereference (source); schema_target = undo_schema_dereference (target); DEREFERENCE_SCHEMA (source); DEREFERENCE_SCHEMA (target); CHK_EM (source); CHK_EM (target); I’m not sure how long the code “error” has been around. I checked the gpc-20070904 sources and it is also in that version. I don’t have a working GPC at the moment so I don’t know what sort of ill formed Pascal source code would be needed to exercise the CHK_EM macro return statement’s code and what sort of ills would result if the code was exercised. The compiler version information on the compiler being used for the compiling stopping errors is: gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin15.3.0 Thread model: posix Note: Apple has got their tool chain wired up so that “gcc” invokes LLVM based clang. In case you want to see it I’ve included the gcc [really clang] and make diagnostic output below my signature. P.S. I think I’m getting close to seeing the light at the end of the tunnel of building a gcc-3.4.6 based GPC on the latest version of Mac OS X. The path to success looks to be using a real gnu based gcc and as for compiling and assembling to object code. At least for the fairly old code base of gcc-3.4.6, trying to use a LLVM based tool chain build path seems to be a never ending series of “close but no cigar” dead ends, issues, and headaches. Gale Paeper gpaeper(a)empirenet.com gcc -std=gnu99 -arch i386 -o p/statements.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-traditional -I. -Ip -I../../gcc-3.4.6/gcc -I../../gcc-3.4.6/gcc/p -I../../gcc-3.4.6/gcc/../include -DGPC -DGPC_UNITS_DIR=\"/usr/local/gpc346u4/gpc346u4/lib/gcc/i386-apple-darwin15/3.4.6/units\" -I../../gcc-3.4.6/gcc/p -DRTS_VERSION_CHECK="\"_p_GPC_RTS_VERSION_`cat ../../gcc-3.4.6/gcc/p/rts/rts-version`\"" ../../gcc-3.4.6/gcc/p/statements.c 4 warnings generated. warning: unknown warning option '-Wno-traditional' [-Wunknown-warning-option] In file included from ../../gcc-3.4.6/gcc/p/statements.c:29: In file included from ../../gcc-3.4.6/gcc/p/gpc.h:46: In file included from ../../gcc-3.4.6/gcc/p/gbe.h:151: ../../gcc-3.4.6/gcc/output.h:122:6: warning: '__format__' attribute argument not supported: asm_fprintf [-Wignored-attributes] ATTRIBUTE_ASM_FPRINTF(2, 3); ^ ../../gcc-3.4.6/gcc/output.h:112:53: note: expanded from macro 'ATTRIBUTE_ASM_FPRINTF' #define ATTRIBUTE_ASM_FPRINTF(m, n) __attribute__ ((__format__ (__asm_fprintf__, m, n))) ATTRIBUTE_NONNULL(m) ^ ../../gcc-3.4.6/gcc/p/statements.c:1235:3: error: void function 'expand_pascal_assignment2' should not return a value [-Wreturn-type] CHK_EM (source); ^~~~~~~~~~~~~~~ ../../gcc-3.4.6/gcc/p/gpc.h:155:36: note: expanded from macro 'CHK_EM' #define CHK_EM(t) do { if (EM (t)) return error_mark_node; } while (0) ^ ~~~~~~~~~~~~~~~ ../../gcc-3.4.6/gcc/p/statements.c:1236:3: error: void function 'expand_pascal_assignment2' should not return a value [-Wreturn-type] CHK_EM (target); ^~~~~~~~~~~~~~~ ../../gcc-3.4.6/gcc/p/gpc.h:155:36: note: expanded from macro 'CHK_EM' #define CHK_EM(t) do { if (EM (t)) return error_mark_node; } while (0) ^ ~~~~~~~~~~~~~~~ ../../gcc-3.4.6/gcc/p/statements.c:1342:1: warning: no previous prototype for function 'assign_string2' [-Wmissing-prototypes] assign_string2 (tree target, tree source, int is_init) ^ ../../gcc-3.4.6/gcc/p/statements.c:1342:47: warning: unused parameter 'is_init' [-Wunused-parameter] assign_string2 (tree target, tree source, int is_init) ^ 4 warnings and 2 errors generated. make[2]: *** [p/statements.o] Error 1 make[1]: *** [stage1_build] Error 2 make: *** [bootstrap] Error 2

1 0

RE: GPC compile on Mac OS X 10.10.5?
by samiam＠moorecad.com 28 Jan '16

28 Jan '16

2 1

RE: GPC compile on Mac OS X 10.10.5?
by samiam＠moorecad.com 27 Jan '16

27 Jan '16

2 1

RE: GPC compile on Mac OS X 10.10.5?
by samiam＠moorecad.com 27 Jan '16

27 Jan '16

1 0

Re: GPC compile on Mac OS X 10.10.5?
by Schneider 27 Jan '16

27 Jan '16

Scott: > On another subject entirely, Do you publish your programs, ie., are > they available somewhere? https://alum.mit.edu/www/toms/delila/delilaprograms.html Note that alum.mit.edu/www/toms points to the current location of my website, so if you use that it should always work even if my website moves again. > I'd be interested in large ISO 7185 compliant programs for compiler > testing. Strict ISO 7185 programs are kinda rare. The only exception is that some programs need the date and time. They all use a procedure called getdatetime which is compiler specific. I have several programs named time*.p for different compilers. They contain 'modules' for the time functions. Long ago I recognized that insertion methods were not standard in Pascal, so I wrote a program - 'module' https://alum.mit.edu/www/toms/delila/module.html - which can transfer chunks of text between Pascal programs. So I use module to transfer the time modules into a program and then they compile. Other than the time modules, I can't guarantee that they are all "strict ISO 7185 programs" but I try to stick to the original Wirth definition. So if you set aside the programs that contain 'getdatetime' it would be a pretty clean set. You could also use the timenul.p program to neuter any program. (That is, use module to transfer the modules of timenul.p into Delila programs that use time). Since you would like large programs, the biggest is probably delila.p - but it uses time modules. If you find bugs, I'd appreciate knowing about them. Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

1 0

RE: GPC compile on Mac OS X 10.10.5?
by samiam＠moorecad.com 27 Jan '16

27 Jan '16

4 6

RE: GPC compile on Mac OS X 10.10.5?
by samiam＠moorecad.com 27 Jan '16

27 Jan '16

3 2

RE: GPC compile on Mac OS X 10.10.5?
by samiam＠moorecad.com 26 Jan '16

26 Jan '16

2 1

Re: GPC compile on Mac OS X 10.10.5?
by Schneider 12 Jan '16

12 Jan '16

Adriaan: > >*I'm on the new Mac OS X 10.10.5 and I've lost my gpc compiler.* > Sorry, were to busy to reply, but will I'm struggling with this loss and am seriously considering abandoning the Mac entirely. Any chance you will get back to this? Thanks, Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

1 1

compiling gpc on Mac OS 10.10.5 Yosemite
by Schneider, Thomas (NIH/NCI) [E] 21 Nov '15

21 Nov '15

Dear GPCers: I recently was forced to upgrade to Yosemite and lost my GPC compiler. I tried to compile according to * GNU Pascal 3.4.6u4 compiler sources and double-clickable building script (for Mac OS X 10.3 - 10.6) (22.2 MB) and got: % build-gpc.command setenv GPC_BUILD_TOOLS 1 setenv GPC_BUILD_GP 1 setenv GPC_BUILD_GPC_SOURCES 1 setenv GPC_BUILD_GPC_CLEAN 1 setenv GPC_BUILD_GPC_CONFIGURE 1 setenv GPC_BUILD_GPC 1 setenv GPC_BUILD_GPC_DYLIB 1 setenv GPC_BUILD_GPC_CLEAN_CROSS 1 setenv GPC_BUILD_GPC_CONFIGURE_CROSS 1 setenv GPC_BUILD_GPC_CROSS 1 setenv GPC_BUILD_GPC_DYLIB_CROSS 1 setenv GPC_BUILD_GPC_DOCS 1 setenv GPC_BUILD_TESTSUITE 0 setenv GPC_BUILD_PACKAGE 0 setenv GPC_BISON bison-2.3 setenv GPC_FLEX flex-2.5.35 setenv GPC_HELP2MAN help2man-1.36.4 setenv GPC_SED sed-4.1.4 setenv GPC_GCC 3.4.6 setenv GPC_GCC_DIFF gcc-3.4.4.diff setenv GPC_SNAPSHOT gpc-20070904 setenv GPC_PDF gpc-20070904.pdf setenv GPC_RELEASE 346u4 setenv GPC_PACKAGE 3.4.6u4 setenv GPC_FPSAVE fpsave-20051224 setenv GPC_GP gp-0.61 setenv GPC_DIR /Developer/Pascal setenv GPC_GPC gpc346u4 setenv GPC_DYLIB 346u4 setenv GPC_CONTACT -- Please contact Adriaan van Os at <gpc(a)microbizz.nl> setenv GPC_OSX_VERSION `uname -r` uname -r switch ( 14.5.0 ) unset echo Unforeseen version of Mac OS X. -- Please contact Adriaan van Os at <gpc(a)microbizz.nl> ----- Adriaan has not responded for several days. I don't see how to get a binary. Has anyone migrated to 10.10.5? How do I do this? Thanks, Tom Schneider Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov http://schneider.ncifcrf.gov (current link) http://alum.mit.edu/www/toms (permanent link)

7 31

Re: GPC compile on Mac OS X 10.10.5?
by Schneider 14 Nov '15

14 Nov '15

Adriaan: > > >*I'm on the new Mac OS X 10.10.5 and I've lost my gpc compiler.* > > Sorry, were to busy to reply, but will I'm seriously hung without gpc ... Any chance you'll be able to fix it? Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 https://schneider.ncifcrf.gov (current link) https://alum.mit.edu/www/toms (permanent link)

1 0

GNU Pascal Compiler 64-bit version
by Gayle Lee Fairless 07 Oct '15

07 Oct '15

Has the 64-bit version of the GNU Pascal Compiler been done by your student? Some time ago I got the 32-bit version installed into RedHat Cygywin running under Windows. Thanks for the information! Sincerely, (Mr.) Gayle Lee Fairless fairless(a)ieee.org fairless(a)fsfe.org

4 3

finding recipe for x86_64 or x86 or Cygwin or MingW or whatever will work
by Gayle Lee Fairless 21 Jan '15

21 Jan '15

I installed Cygwin onto an Alienware M17x-R3 running Windows 7 and also downloaded various files from http://www.gnu-pascal.de/ to add Pascal to the list of compilers. gayle@weirdcat ~/Documents $ gcc --version gcc (GCC) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gayle@weirdcat ~/Documents I successfully ran the classic Hello World program under C. However I have been unable to install Gnu Pascal Compiler although I believe I have followed the instructions in the manual. I have tried both software installation and direct use of a binary file. I have gpc source files, too. I also downloaded the source files for gcc 3.2.3 and gcc 3.4.3 because the manual seems to indicate that I should compile against a version that produces a standard compiler. I have the gpc source file: gpc-20060325/. I got as far as the makeinfo file in the manual. Here is the tail of a verbose output from makeinfo: gayle@weirdcat ~/Documents $ tail verbosemakeinfo.txt checking for .preinit_array/.init_array/.fini_array support... no checking if mkdir takes one argument... no *** Configuration x86_64-unknown-cygwin not supported Reaping losing child 0x6000bba30 PID 9292 Makefile:23335: recipe for target 'configure-gcc' failed make: *** [configure-gcc] Error 1 Removing child 0x6000bba30 PID 9292 from chain. gayle@weirdcat ~/gpc-build $ gayle@weirdcat ~/Documents I have also attempted to install gcc-3.4.3 with the suffix modifier. The output from make with the -d and -i switches is also available. Should I specify a different host, target, etc.? What ingredients am I missing to complete the recipe? Thank you for your help and your time! Sincerely, (Mr.) Gayle Lee Fairless fairless(a)ieee.org fairless(a)fsfe.org

5 11

Re: gdb-patches RFA: Fix pascal behavior for class fields
by Prof Abimbola Olowofoyeku 10 Jan '15

10 Jan '15

On 8 Jan 2015 at 23:12, Pierre Muller wrote: > For gpc mailing list: [...] > > The problem is that GPC and Free Pascal support several > > pascal 'dialects'. But this requires command line options. > > > > The -Mobjfpc option is required for Free Pascal compiler > > to understand class type definition, but is rejected in default mode. > > > > I expect GNU GPC to also reject class in 'normal' mode... > > Maybe someone on the gpc mailing list knows if classes are supported > > by GPC and if it requires a special compiler option. > > > > Pierre Muller > > > > FYI: Here is the example code that is included in the bug report. > > > > $ cat ~/pas/test/test-class-pascal.pas > > > > type > > TA = class > > public > > x, y : integer; > > constructor Create; > > function check(b : TA) : boolean; > > destructor Done; virtual; > > end; > > > > constructor TA.Create; > > begin > > x:=-1; > > y:=-1; > > end; > > > > destructor TA.Done; > > begin > > end; > > > > function TA.check (b : TA) : boolean; > > begin > > check:=(x < b.x); > > end; > > > > > > > > var > > a, b : TA; > > > > begin > > a:=TA.Create; > > b:=TA.Create; > > a.x := 67; > > a.y := 33; > > a.check (b); > > end. Supply "--extended-syntax" and GPC will accept "class" (and if you are going to use "Result" then you will need to add "--implicit-result"). However, I do not believe that the "class" will be treated much differently from a bog-standard Borland Pascal "object" - for example, not having (or not calling) a constructor will not crash the program (as it should do, with Delphi-style classes). Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

2 2

Re: gdb-patches RFA: Fix pascal behavior for class fields
by Waldek Hebisch 10 Jan '15

10 Jan '15

> Pierre Muller wrote: > > > > It compiles if you put a 'program' statement at the beginning, and > > change a.check(b) to assign the function result, > I tried this, > but here is what I get after your changes: > $ gpc test-class-pascal.pas > test-class-pascal.pas:4: error: undeclared identifier `class' (first use in > this routine) > test-class-pascal.pas:4: error: (Each undeclared identifier is reported > only once > test-class-pascal.pas:4: error: for each routine it appears in.) > test-class-pascal.pas:6: error: undeclared identifier `x' (first use in this > routine) > test-class-pascal.pas:6: error: syntax error before `,' > > Pierre@d620-muller ~/pas/test > $ gpc --version > gpc 20050331, based on gcc-3.4.4 (cygming special, gdc 0.12, using dmd > 0.125) > Copyright (C) 2005 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Is it because I am using version 3.4.4? gcc version is not a problem. But your gpc is too old: classes are supported starting from gpc-20051104 (the next version after the one you tried). > The problem is that I did not find any system > with easy installation of GPC, AFAICS old Debian binaries should work on new systems. In 2012 Peter Blackman generated Debian/Ubuntu package (IIRC it was at launchpad). > Anyhow, by using objects instead of classes, I was able to compile the > modified program, > and it turns out that GPC is using 'Self' for the hidden > object name for stabs debugging, so that the problem probably does not apply > to > GPC compiled sources. > Classes are transformed by GPC into pointers to objects, so there is small difference. Attacheched is assembler output from gpc-20070904 using '-fextended-syntax -gstabs -O -S' as options. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

RE: gdb-patches RFA: Fix pascal behavior for class fields
by Pierre Muller 09 Jan '15

09 Jan '15

Hi Peter, > > The problem is that GPC and Free Pascal support several > > > > pascal 'dialects'. But this requires command line options. > > > > > > > > The -Mobjfpc option is required for Free Pascal compiler > > > > to understand class type definition, but is rejected in default mode. > > > > > > > > I expect GNU GPC to also reject class in 'normal' mode... > > > > Maybe someone on the gpc mailing list knows if classes are supported > > > > by GPC and if it requires a special compiler option. > > > > > > > > Pierre Muller > > > > > > > > FYI: Here is the example code that is included in the bug report. > > > > > > > > $ cat ~/pas/test/test-class-pascal.pas > > > > > > > > type > > > > TA = class > > > > public > > > > x, y : integer; > > > > constructor Create; > > > > function check(b : TA) : boolean; > > > > destructor Done; virtual; > > > > end; > > > > > > > > constructor TA.Create; > > > > begin > > > > x:=-1; > > > > y:=-1; > > > > end; > > > > > > > > destructor TA.Done; > > > > begin > > > > end; > > > > > > > > function TA.check (b : TA) : boolean; > > > > begin > > > > check:=(x < b.x); > > > > end; > > > > > > > > > > > > > > > > var > > > > a, b : TA; > > > > > > > > begin > > > > a:=TA.Create; > > > > b:=TA.Create; > > > > a.x := 67; > > > > a.y := 33; > > > > a.check (b); > > > > end. > > > > > > > > > > > > > > > > _______________________________________________ > > Gpc mailing list > > Gpc(a)gnu.de > > https://www.g-n-u.de/mailman/listinfo/gpc > > It compiles if you put a 'program' statement at the beginning, and > change a.check(b) to assign the function result, I tried this, but here is what I get after your changes: $ gpc test-class-pascal.pas test-class-pascal.pas:4: error: undeclared identifier `class' (first use in this routine) test-class-pascal.pas:4: error: (Each undeclared identifier is reported only once test-class-pascal.pas:4: error: for each routine it appears in.) test-class-pascal.pas:6: error: undeclared identifier `x' (first use in this routine) test-class-pascal.pas:6: error: syntax error before `,' Pierre@d620-muller ~/pas/test $ gpc --version gpc 20050331, based on gcc-3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Is it because I am using version 3.4.4? The problem is that I did not find any system with easy installation of GPC, and finally tested it on an old Cygwin installation which had GPC, but it's version 3.4.4 > ie as > > > VAR OK : Boolean; > ... > OK := a.check(b); > > > No special command line switches are needed. > > > > Program test; > > type > TA = > class > public > x, y : integer; > constructor Create; > function check(b : TA) : boolean; > destructor Done; virtual; > end; > > constructor TA.Create; > begin > x:=-1; > y:=-1; > end; > > destructor TA.Done; > begin > end; > > function TA.check (b : TA) : boolean; > begin > check:=(x < b.x); > end; > > var > a, b : TA; > OK : boolean; > > begin > a:=TA.Create; > b:=TA.Create; > a.x := 67; > a.y := 33; > OK := a.check (b); > end. Anyhow, by using objects instead of classes, I was able to compile the modified program, and it turns out that GPC is using 'Self' for the hidden object name for stabs debugging, so that the problem probably does not apply to GPC compiled sources. Thanks Peter Pierre Muller

1 0

gdb-patches RFA: Fix pascal behavior for class fields
by Pierre Muller 08 Jan '15

08 Jan '15

For gpc mailing list: this email comes as a follow-up of this bug report <https://sourceware.org/bugzilla/show_bug.cgi?id=17815> https://sourceware.org/bugzilla/show_bug.cgi?id=17815 The start of the thread can be found at: <https://sourceware.org/ml/gdb-patches/2015-01/msg00164.html> https://sourceware.org/ml/gdb-patches/2015-01/msg00164.html Pedro asked: > >> How about adding this to the test suite? > > > > > > The whole testsuite/gdb.pascal is almost empty, > > I never invested time to develop it :( > > > > At the time I started it, GPC (the GNU pascal compiler) > > was still active, but development apparently > > stopped since quite some time. > > > > I am unable to install GPC, which means that I cannot test it. > > Would a testsuite that supports only Free Pascal be acceptable? > > Do you actually mean, whether it's ok for a new > test (not test suite) to go in untested on GPC? It certainly is. > Better test on FPC than nowhere. :-) That is indeed what I meant. > AFAICS, the tests themselves don't really care which compiler > is in use other than for marking xfails; you just call > gdb_compile_pascal, > and that works with either. That's my impression from quickly > skimming testsuite/lib/pascal.exp. The problem is that GPC and Free Pascal support several pascal 'dialects'. But this requires command line options. The -Mobjfpc option is required for Free Pascal compiler to understand class type definition, but is rejected in default mode. I expect GNU GPC to also reject class in 'normal' mode... Maybe someone on the gpc mailing list knows if classes are supported by GPC and if it requires a special compiler option. Pierre Muller FYI: Here is the example code that is included in the bug report. $ cat ~/pas/test/test-class-pascal.pas type TA = class public x, y : integer; constructor Create; function check(b : TA) : boolean; destructor Done; virtual; end; constructor TA.Create; begin x:=-1; y:=-1; end; destructor TA.Done; begin end; function TA.check (b : TA) : boolean; begin check:=(x < b.x); end; var a, b : TA; begin a:=TA.Create; b:=TA.Create; a.x := 67; a.y := 33; a.check (b); end.

1 0

both too many and too few arguments
by Jay Michael 17 Dec '14

17 Dec '14

GNU Pascal version 20070904, based on gcc-3.4.5 (mingw special). >gpc jsm6.pas jsm6.pas: In main program: jsm6.pas:7: error: too many (>1) arguments to routine `noargproc' jsm6.pas:5: error: routine declaration jsm6.pas:7: error: too few (1) arguments to function `noargproc' I defined a procedure with no arguments. When I called it with two arguments, I got error messages saying both "too many" and "too few" arguments. What is the significance of the "1" in "too many (>1) arguments" and in "too few (1) arguments"?

2 1

mod operator in constants not allowed
by trevor 17 Oct '14

17 Oct '14

as title, I get a compile error when I use the mod operator in constant expressions. eg, with this program ... program pmod (Output); const c = 9 mod 5; { <<<< error } begin WriteLn ('9 mod 5 is ', c); end. { pmod } pmod.pas:3: error: constant has non-constant value I can rewrite the constant as c = 9 - 5*(9 div 5); { this is equivalent to 9 mod 5 } without problems. This seems strange to me - am I missing something? What makes it a non-constant? Many Thanks

2 2

Debian packages
by Peter 12 Sep '14

12 Sep '14

I have built some unofficial deb packages for gpc, based on version 20070904, gcc 3.4.6 They should work in modern version of Debian, Mint, Ubuntu etc. See;- https://launchpad.net/~ueter/+archive/ubuntu/gpc-3.4/+packages <https://launchpad.net/%7Eueter/+archive/ubuntu/gpc-3.4/+packages> Direct link for 64bit deb package which can be installed via gdebi;- https://launchpad.net/~ueter/+archive/ubuntu/gpc-3.4/+build/6360693 <https://launchpad.net/%7Eueter/+archive/ubuntu/gpc-3.4/+build/6360693> Any comments or feedback most welcome. My test results for 64 bit are as follows;- ---------------------------------------------------------------------- for this version of gpc on Debian jessie (x86_64): === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: asmtest.pas FAIL: fieldw.pas UNSUPPORTED: fjf165a.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5112 # of expected passes 5102 # of unexpected failures 7 # of unsupported tests 3 gpc version 20070904, based on gcc-3.4.6 ---------------------------------------------------------------------- Peter

1 0

Function return value register
by Rajat Singh 09 Jun '14

09 Jun '14

Hi, Is there a way to change the function return value coming in register d0 to come in reigster d7 ? I tried adding d7 in call_used_registers and updating macro's FUNCTION_VALUE and FUNCTION_VALUE_REGNO_P but it didnt work. I tried modifying hard_function_value function in explow.c but compilation failed at reload pass. I am trying to update the backend code for m68k.Any help is appreciated. Thanks and regards, Rajat Singh

3 2

Global variables - register allocated
by Rajat Singh 21 May '14

21 May '14

Hi, I am declaring the global variable outside a procedure. I want to know the register that is used by this global variable. VAR VAR1:INTEGER; attribute(name='VAR1'); When I tried to disassemble the object file, the global variables seems to be residing in the memory instead of a register. 80000130: 7005 moveq #5,%d0 80000132: 23c0 8000 21ec movel %d0,800021ec <VAR1> Can you please let me know how to identify the register which is used by this variable. Thanks, Rajat

2 4

Heap error 203
by Contestcen＠aol.com 15 May '14

15 May '14

You can ignore my previous question about Heap Error 203. I have discovered the variable ReturnNilIfGrowHeapFails which controls the behavior of New. It is not mentioned in the RTL manual, but it is mentioned in the Programmer's Guide. I had not read far enough in Chapter 8, which at first reading seemed to be entirely concerned with the sizes of the various data types. The description of New in the RTL manual simply states that New returns nil if space is not available. It does not say that this feature defaults to off, and has to be turned on by the program. Frank

2 1

Error 203 Heap is out of memory
by Contestcen＠aol.com 14 May '14

14 May '14

Is there any way to prevent an Error 203 when I call New and the heap is out of storage? The RTL manual says that New should return a nil pointer, but that doesn't seem to happen. Instead, my program terminates with a 203 error code. This happens with both {$S+} and {$S-} directives. I am running DOS under Windows 7. Frank

1 0

BitSets in GNU PASCAL
by Kavitha Manjunath 28 Apr '14

28 Apr '14

Hi, Is BitSet available in GPC. If not, can you please tell me how to add bitsets as part of GPC. Thanks. Regards Kavitha

2 1

Provide custom warnings for some directives
by Kavitha Manjunath 06 Mar '14

06 Mar '14

Hi, I would like to provide custom warnings for few directives in gnu pascal. Can you please help me how to achieve it? Thanks and Regards Kavitha

1 0

change SETGPC.BAT
by Jay Michael 25 Feb '14

25 Feb '14

SETGPC.BAT does not allow me to compile C using gpc: gpc tc.c -o tc As installed by dev_gnu_pascal-1.9.4.13.exe, SETGPC.BAT: set PATH=C:\prg\GPC\bin;%PATH% set C_INCLUDE_PATH=C:\prg\GPC\include set GCC_BASE=3.4.5 set GPC_EXEC_PREFIX=C:\prg\GPC\libexec\gcc\mingw32 set LIBRARY_PATH=C:\prg\GPC\lib;C:\prg\GPC\lib\gcc\mingw32\%GCC_BASE% set GPC_UNIT_PATH=C:\prg\GPC\lib\gcc\mingw32\%GCC_BASE%\units;C:\prg\GPC\units;C:\prg\GPC\units\winapi;C:\prg\GPC\units\objects;C:\prg\GPC\units\sysutils;C:\prg\GPC\units\objmingw I have been able to compile and link Pascal and C (one each) by only changing PATH. Separately, I succeeded by appending c:\prg\gpc\lib\gcc\mingw32\3.4.5\include to C_INCLUDE_PATH. (After running SETGPC.BAT) I don't know what to say is wrong. The lack of a trailing slash on GPC_EXEC_PREFIX results in a horrible mess in one of the attempted directories (C:/prg/GPC/libexec/gcc/mingw32mingw32/3.4.5/../../../../include/stddef.h) but appending a slash doesn't solve the real problem, because "libexec" is the wrong path to get to an include directory. Does GPC have different rules for the EXEC_PREFIX than GCC, so the lack of a trailing slash is not a mistake for GPC_EXEC_PREFIX? Does the setting of all of the variables other than PATH date back to a time before GPC did such an elaborate job of fabricating directory names? Or before GPC had the target and version wired in? Is it likely that all I need is to prepend GPC/bin to PATH? Or do you think I will need some of the other environment variables when I get around to trying to compile more substantial programs?

1 0

Compiling GPC on Msys
by Kevan Hashemi 21 Feb '14

21 Feb '14

Greetings, I'm trying to compile GPC from sources on Msys, within mingw on 32-bit Windows 7. Is this possible? The gcc-3.4.6/configure appears to work. It patches the GCC 3.4.6 for Pascal. I run the makefile, which proceeds for a while, with warnings like this: warning: structure 'reg_info_def' used but not defined Then the compile then fails with: cc1.exe: error: min-insn-modes.c: Invalid argument If any of this is familiar, or if I'm missing something obvious, please let me know. Ultimately, I'd like to be in a position to fix the GetMicroSecondTime routine, which does not work in Windows, and has not done so for years. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

2 1

Change Include in frontend
by Rajat Singh 15 Feb '14

15 Feb '14

Hi, I want to include the files using #include <filename> in GNU PASCAL instead of {$INCLUDE}. I am unable to trace where the changes has to happen. Thanks for help in advance. Regards, Rajat Singh

2 1

GNU PASCAL FRONT END Changes to mimic HP PASCAL m68k
by Kavitha Manjunath 15 Feb '14

15 Feb '14

Dear Team, Greeting for the day. I am a student working on GNU PASCAL Porting to adapt a version of HP PASCAL m68k for school purposes. I was trying to do the following on which I am stuck. Can you please provide me some insight and lead a path to achieve the same. Thanks a million in advance 1. I want to include the files using #include <filename> instead of {$INCLUDE}. I am unable to trace where the changes has to happen. Also all the directives in the similar way without the use of "{}". Request your help. Thanks once again. Regards Kavitha

1 0

Integer Size on 64-Bit
by Kevan Hashemi 14 Feb '14

14 Feb '14

Greetings, On Red Hat Linux 6.5 running on a 32-bit machine, I compile GPC to obtain a 32-bit Pascal compiler in which the integer type is 4 bytes long. I compile TclTk from sources and obtain an executable in which the C "int" type is 32 bits long. They work well together. On Red Hat Linux 6.5 running on a 64-bit machine, I compile GPC to obtain a 64-bit Pascal compiler in which the integer type is 8 bytes long. I compile TclTk from sources and obtain an executable in which the C "int" type is still 32 bits long. They do not work well together. I can edit my Pascal code to make all integer types a fixed length regardless of architecture. But I was wondering if there is a Pascal compiler directive that I can use to force the integer size to 32 bits on all platforms. Or perhaps there is a configure option when I compile GPC from its sources that will tell the compiler to make the integer type 32 bits. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

2 1

Compiling for Shared Libraries
by Kevan Hashemi 06 Feb '14

06 Feb '14

Dear GPC Users, I just compiled GPC from sources on both 32-bit and 64-bit Linux machines. On both machines, I'm running Scientific Linux 6.4, a derivative of Red Had Linux 6.4. The local C compiler is 4.4.7 in both cases. On the 32-bit machine, I can compile from Pascal to make objects, and link them with libgpc.a to make a shared library. But on the 64-bit machine I find that I must pass -fPIC to GPC to force it to compile position-independent code for the subsequent link. Even then, libgpc.a is position-dependent, so I can't link it into a shared library. So I edit the GPC build's Makefile: CFLAGS = -g -O2 -fPIC Now I build GPC again and re-install. The new libgpc.a is position-independent, and I can make my shared library. Does anyone know why the default on 64-bit is position-dependent, while on 32-bit it is position-independent? Is there an easier way to add a compiler option to the build process, other than editing the Makefile produced by the GCC_3.4.6 configure script? (For example, can I pass a compiler option into the configure script or into the makefile.) Anyway: I have adapted my compiler GPC instructions below, and I'll be adding more Linux binary install files in the coming weeks. http://alignment.hep.brandeis.edu/Software/Pascal/Index.html Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

3 3

GNU frontend modification
by Rajat Singh 03 Feb '14

03 Feb '14

Hi All, Greetings for the day !! I am trying to modify the GNU Pascal fronted. I have gone through GNU Pascal manual and GNU Pascal internals site and this is what I have understood. 1.Lexer - I need to modify pascal-lex.l file and using flex compile it to lex.yy.c file.Rename this file to pascal-lex.c 2. Parser - I need to modify parse.y file and using bison compile it to parse.c file. Now what I am supposed to do next, to make these changes reflect when I compile a pascal file ? Thanks a lot in advance. Thanks and regards, Rajat

2 1

gpc compiler failed on Mac OS X 10.9.1
by Thomas Schneider 03 Feb '14

03 Feb '14

I have Mac OS X 10.9.1 Maveric. Pacal programs compile but fail to run: % cat tst.p program h(output); begin writeln(output,'did'); end. % tst dyld: no valid entry point Trace/BPT trap but a previously compiles version does run: % tst2009 did http://www.microbizz.nl/gpc.html There I find: GNU Pascal 3.4.6u4 installer for Mac OS X 10.6 Intel native and PowerPC cross-compiler15.7 MB) The file gpc346u4-10.6-Intel.dmg is identical (by diff) with the one I already have installed. So what's wrong? How do I get it to compile correctly? Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Center for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov http://schneider.ncifcrf.gov/ (current link) http://alum.mit.edu/www/toms (permanent link)

3 11

Re-Install on OSX10.7
by Kevan Hashemi 28 Oct '13

28 Oct '13

Dear GPC, I am updating my installation instructions for GPC on all platforms. I just uninstalled all XCode files from my MacOS 10.7.5 system with: sudo /Developer/Library/uninstall-devtools -mode=all I re-started the OS. I have an installation of gpc, but I could not find an uninstall script for the files in /usr/bin, so I just downloaded Adriaan's "GNU Pascal 3.4.6u4 installer for Mac OS X 10.6 Intel native and PowerPC cross-compiler" and installed again. That package says "for MacOS 10.6 only" but I went ahead anyway. I have the following program: program p; begin writeln('Hello World'); end. And I try to compile with 'gpc', but I get this error: Kevan-Laptop:Build kevan$ gpc p.pas as: assembler (/usr/bin/../libexec/gcc/darwin/i386/as or /usr/bin/../local/libexec/gcc/darwin/i386/as) for architecture i386 not installed Installed assemblers are: /usr/bin/../libexec/gcc/darwin/ppc64/as for architecture ppc64 /usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64 /usr/bin/../local/libexec/gcc/darwin/m68k/as for architecture m68k /usr/bin/../local/libexec/gcc/darwin/hppa/as for architecture hppa /usr/bin/../local/libexec/gcc/darwin/sparc/as for architecture sparc /usr/bin/../local/libexec/gcc/darwin/m88k/as for architecture m88k /usr/bin/../local/libexec/gcc/darwin/i860/as for architecture i860 I always imagined that the assemblers were installed with the GCC that comes included with GPC, but I appear to be mistaken, because Kevan-Laptop:Pascal kevan$ find /Developer/Pascal/ -name as comes up with nothing. Meanwhile I do have: Kevan-Laptop:Pascal kevan$ find /usr -name as /usr/bin/as /usr/libexec/as /usr/libexec/gcc/darwin/ppc64/as /usr/libexec/gcc/darwin/x86_64/as /usr/local/libexec/gcc/darwin/hppa/as /usr/local/libexec/gcc/darwin/i860/as /usr/local/libexec/gcc/darwin/m68k/as /usr/local/libexec/gcc/darwin/m88k/as /usr/local/libexec/gcc/darwin/sparc/as In Adriaan's Readme.rtf file, it says, "The following utilities are installed with Xcode... as Apple/gnu assembler." I conclude that I must install XCode in order to compile with GPC. Which version of XCode should I install? Starting with XCode 4.0, PPC processors and OS 10.4 SDKs are not provided, although it will do 32-bit i386. I tried XCode 3.2 but it crashes on OS 10.7. The one that works for me is XCode 2.5, just using the command-line tools and SDKs. Is anyone else using GPC on MacOS 10.7 or later, and if so, are you able to use the PPC cross-compiler? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

1 0

--amtmpfile not given
by Jay Michael 15 Sep '13

15 Sep '13

On 11 Sep 2013 at 19:06, Stadelmann Josef wrote: > gpc: Internal GPC problem: internal option `--amtmpfile' not given > gpc1.exe: C:\dev_gpc\bin\gpc exited with status 1 > gpc1.exe: C:\dev_gpc\bin\gpc exited with status 1 Did you start using "gcc" instead of "gpc" to compile? Did you start using an uppercase extension on the source filename? Both of these produce "Internal GPC problem: internal option `--amtmpfile' not given". Neither of these produces any reference to gpc1.exe.

1 0

--amtmpfile not given
by Stadelmann Josef 12 Sep '13

12 Sep '13

what can I do in this case? it was compiling so nicely, and it was so fast, and then from one moment to the other, I don't know why, I get only one error. gpc: Internal GPC problem: internal option `--amtmpfile' not given gpc1.exe: C:\dev_gpc\bin\gpc exited with status 1 gpc1.exe: C:\dev_gpc\bin\gpc exited with status 1 exiting from Dev+GPC and ree-ntering the project is a no go either. the button: Build all AND the button: make project both buttons deliver the same error message. what can I do. Josef

2 1

Minimum Stack Size
by Kevan Hashemi 29 Jul '13

29 Jul '13

Dear GPC Users, I'm trying to force the operating system to give my Pascal code a 2-MByte stack so I can solve a problem with a recursive routine. I have tried: const {for recursive routines} minstacksize: cardinal = 2000000; attribute (name = '_stklen'); But that does not appear to work. Perhaps I am not trying hard enough. Am I on the right track? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

5 11

GPC for MinGW?
by Robert Hartmann 24 Jul '13

24 Jul '13

Hi list, If it is possible to integrate GPC into an actual MinGW-based GCC4 port, I like to get some hint. I would like to build in Msys (Windows XP), but if it easyer to build under Linux, well then I hope I could do it with Knoppix-Live-DVD. Best regards, Robert

3 3

64-Bit Compiler
by Kevan Hashemi 30 Jun '13

30 Jun '13

Dear GPC Maintainers, Is it possible to compile GPC from its existing sources to create a 64-bit Pascal compiler? I am vague on the back-end details of GPC, but it seems to me we would need a 64-bit version of GCC. My objective is to produce compiled code that will run on a 64-bit Scientific Linux machine that has no 32-bit libraries installed (I know this is an artificial situation, but the IT people at the international laboratory we work with are fond of artificial situations). Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

3 3

Re: variable type cast
by Jay Michael 17 May '13

17 May '13

Adriaan van Os wrote: > > Jay Michael wrote: >> >> gpc version 20070904, based on gcc-3.4.5 (mingw special) >> Given >> type INT16 = INTEGER attribute( size=16 ) ; >> type WORD16 = Cardinal attribute( size=16 ) ; >> var i16 : INT16 ; >> var w16 : WORD16 ; >> why does >> WORD16(I16) := W16 ; >> produce "error: invalid lvalue in assignment"? > > A bug in the compiler. GPC is too picky when it comes to typecasts. Do you have any idea why this case is rejected? The compiler accepted type winbool = boolean attribute( size = 32 ) ; var i : integer ; var wb : winbool ; integer(wb) := 1024 ; integer(wb) := -1 ; integer(wb) := i ; I thought BOOLEAN was an enumeration type. I thought an enumeration type was a second cousin to an unsigned integer. So I thought the only real difference in my case was that I was using 16-bit integers. I was prepared for the compiler to accept the code and insist on generating range checks that I don't want. I'm just puzzled that it wouldn't even accept what looks to me to be just like examples I see posted of "variable type cast".

1 0

variable type cast
by Jay Michael 15 May '13

15 May '13

gpc version 20070904, based on gcc-3.4.5 (mingw special) Given type INT16 = INTEGER attribute( size=16 ) ; type WORD16 = Cardinal attribute( size=16 ) ; var i16 : INT16 ; var w16 : WORD16 ; why does WORD16(I16) := W16 ; produce "error: invalid lvalue in assignment"?

4 4

Fwd: Re: variable type cast
by Maurice Lombardi 13 May '13

13 May '13

-------- Message original -------- Sujet: Re: variable type cast Date : Mon, 13 May 2013 09:11:11 +0200 De : Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> Pour : Jay Michael <jmichael_ll(a)yahoo.com> Le 13/05/2013 01:12, Jay Michael a écrit : > gpc version 20070904, based on gcc-3.4.5 (mingw special) > Given > type INT16 = INTEGER attribute( size=16 ) ; > type WORD16 = Cardinal attribute( size=16 ) ; > var i16 : INT16 ; > var w16 : WORD16 ; > why does > WORD16(I16) := W16 ; > produce "error: invalid lvalue in assignment"? First notice tht the other way around I16 := INT16(W16) ; works. Typecasts are C style unportable "extensions" which garble the "write once, compile everywhere" philosophy behind the strong typing principles of Pascal. There is certainly nothing about it in the standards, and I do not know at which point this "lvalue error" crept in first into C, and then into Pascal. Maurice -- Maurice Lombardi Laboratoire Interdisciplinaire de Physique, (ex Spectrometrie Physique) Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

for-loops and subrange types
by Jonas Maebe 29 Apr '13

29 Apr '13

Hi, Can anyone here offer some insights regarding the standard conformance of the test program submitted at http://bugs.freepascal.org/view.php?id=24318 ? (range.p) Both FPC and GPC cause the program to abort with a range check error, while the submitter is of the opinion that the for-loop should merely short-circuit and never executed instead. Jonas

5 10

Re: for-loops and subrange types
by Contestcen＠aol.com 27 Apr '13

27 Apr '13

This compatibility requirement seems to imply that the control variable need not be an integer type. Does this mean that Var letter: char; for letter := 'A' to 'Z' do is legitimate, or that the definers of the language expected that might eventually be allowed? Or does it merely mean that the magnitudes must match the range, so that Var num: smallint; for num := 20000 to 40000 do is illegal? In a message dated 4/26/2013 4:28:41 P.M. Eastern Daylight Time, jonas.maebe(a)elis.ugent.be writes: : The initial-value and the final-value of a sequence-iteration : of an iteration-clause of a for-statement shall be of a type : compatible with the type of control-variable of the for-statement. : The initial-value and the final-value shall be : assignment-compatible with the type possesed by the : control-variable if the statement of the for-statement : is executed.

2 1

GPC with gcc-4.[23]
by Waldek Hebisch 18 Apr '13

18 Apr '13

I did some work on updating gpc to newer gcc versions. You can find it at GitHub: https://github.com/hebisch/gpc This is experimental work. 4.2 and 4.3 ports (on "master" Git branch) are basically in "works for my purpose" state: on my machine compiler builds and passes test suite with small (but nonzero) number of failures. On 4.5.1 there is initial port to gcc-4.[45] -- this one is broken from user point of view and may be of some use only for people who want to seriously work on the compiler. Note that this is _not_ a release. There are relatively easy to fix but non working things (in particular some features of Makefiles are broken). Testing was limited to running testsute just for one configuration. I estimate that fixing easily fixable stuff and polishing things would take me about a week -- unfortunately I am busy with other things. So I decided to make the code available "as is". If there will be bug reports, I will look at them and there is reasonable chance that I will fix them. But otherwise I do not plan to work on gpc in near future. If you want to try the code note that there are changes to build process, look at toplevel README file. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

4 15

Re: GPC compiler crash
by Garth Fletcher 19 Feb '13

19 Feb '13

Just to clarify the differences a bit. Space for a global variable is allocated when the program starts, essentially from the "heap" - which is the collection of available memory. Space for variables allocated by New() or NewPtr() are also allocated from the heap. These allocations can be released by using Dispose. For example: type myDataType = array... {defines the size of the structure} in the main program var myData : myDataType; {allocates a global structure in the heap} however, within a procedure or function procedure myProc; var localdata : myDataType; {allocates a LOCAL structure in the Stack} The reasoning is simple - the structure is local to that procedure or function, so the intent is to allocate it only as long as the procedure is executing. The Stack was a reasonable way to handle such local structures so that exiting the procedure, unstacks anything that was placed on it when the procedure is called and thus releases that allocated memory. This is OK only as long as the structures are small... The right way to handle local large structures is to explicitly allocate them upon entry to the procedure and then DEallocate them before exiting the procedure. For example: type myDataTypePtr : ^myDataType; procedure myProc; var localdataP : myDataTypePtr; {allocates a POINTER (4 or 8 bytes) on the stack} begin localdataP := NewPtr(sizeOf(myDataType)); {this allocates the structure on the heap, with localdataP} { pointing to that allocated space} {use the structure via localdataP^ } dispose(localdataP); {release the allocated memory} end; There is another gotcha - the difference between passing arguments "by reference" versus "by value". The former uses the VAR prefix to indicate that the procedure will have direct access to the actual data structure. The latter indicates that the called procedure will be given a copy of the original structure, i.e., a LOCAL copy. procedure myCalledProc (VAR byRef : myDataType; byVal : myDataType); "VAR byRef" specifies a POINTER to the original data to be passed on the Stack. The compiler takes care of converting any access to byRef within the procedure into a byRef^ and also of creating the pointer. "byVal" specifies a LOCAL COPY of the data structure to be passed on the Stack, which causes overflow if the copy is too big In other words, calling myCalledProc (myData, myData) creates a pointer to myData and passes that on the stack as byRef it also creates a complete copy of myData and passes that on the Stack as byVal. For big structures the difference is huge... I hope the above clarifies more than it confuses... -- Garth Fletcher

4 5

Re: GPC compiler crash
by Prof A Olowofoyeku (The African Chief) 19 Feb '13

19 Feb '13

Thomas Schneider wrote: >When I set it to 2003001 it compiles but gives a segmention fault even >though it's global. Maybe there's a limitation to allocating that >way? > >Then I switched dataprism to be a pointer using 'dataprism: >^trisquare;' as you suggested and changed the calls to be 'dataprism^' >(a rather cute trick!) and ... it compiles but still gives me a >segmentation fault! Actually, I was able to reproduce this crash. It happened at the point of "dispose (dataprism)". I changed the memory allocation/deallocation calls, and all works well (with "trimax=8006000"): procedure themain(var da: text); var dataprism: ^trisquare; (* the data structure for diana *) begin getmem (dataprism, sizeof (trisquare)); writeln(output,' trimdiana -gpc bug',version:4:2); writeprism(da, dataprism^); freemem (dataprism, sizeof (trisquare)); end; begin writeln ('sizeof trisquare=', sizeof (trisquare) div 1024 div 1024, 'mb'); themain(da); end. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

3 5

GPC compiler crash
by Thomas Schneider 19 Feb '13

19 Feb '13

Folks: I discovered a program that crashes the GPC compiler, attached. Regards, Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Frederick National Laboratory for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt(a)mail.nih.gov http://alum.mit.edu/www/toms

4 15

Re: Understanding {$I-} {$I+} ioResult
by Prof. A Olowofoyeku (The African Chief) 26 Nov '12

26 Nov '12

On 26 Nov 2012 at 14:59, Baudouin Le Charlier wrote: > > Le 26 nov. 2012 à 12:39, Prof. A Olowofoyeku (The African Chief) a > écrit : > > > On 26 Nov 2012 at 9:10, Baudouin Le Charlier wrote: > > > > [...] > >>> This is a historical factor, and there was no need to duplicate > >>> features that Borland already documented well, and which were well > >>> known to Borland Pascal/Delphi programmers. > >> > >> I am not sure they are so well known since you did not explain to > >> me why (i.e. by which miracle) a program that stops abruptly (when > >> compiled with $I-), stops normally if you add a call to ioResult > >> *after* the io statement that makes the original program fail. I > >> doubt very much that this could be explained in the original > >> Borland documentation and also that this behavior should be well > >> known of Borland Pascal programmers. > > > > As I said, the Borland Pascal/Delphi help files are freely available > > on the net. If you want to use Borland Pascal/Delphi compatibility > > features in GPC, you would do well to study the Borland > > documentation on those features. > > > > This is from a 20 year old Borland Turbo Pascal help file: > > > > [--- excerpt begins ---] > > $I: Input/Output-Checking Switch > > Enables or disables the automatic code generation that checks the > > result of a call to an I/O procedure > > > > Syntax: $I+ or $I- > > Default: $I+ > > Type: Local > > Command-Line: /$I+ or /$I- > > Menu Command: Options|Compiler|I/O Checking > > > > Remarks > > If an I/O procedure returns a non-zero I/O result when the $I switch > > is on, the program terminates, displaying a run-time error message. > > > > > > When the $I switch is off, you must use the IOResult function to > > check for I/O errors. [--- excerpt ends ---] > > > > Please let us stop this meaningless debate now. > > To me, it is not meaningless. I sent you an example where gnu pascal > does not conform to the excerpt you just sent me : the program is > compiled with the switch off but nevertheless it stops with an error > message. And where in that code did you use the IOResult function to check for errors? Best regards, The Chief ------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com

2 1

Bus error when writing in a typed file
by Baudouin Le Charlier 26 Nov '12

26 Nov '12

Hi ! I am using a Mac OS X 10.6.8. I have downloaded GNU Pascal for Mac Os fromhttp://www.microbizz.nl/gpc.html. I have been using GNU Pascal for writing very simple programs for an introductory programming course and it worked fine until I wrote the following program for which I got a "bus error" when writing a first record in the file (at line 128). Notice that the program executes without errors when compiled with free pascal compiler. I should be happy if anyone can help me to solve this "problem". Baudouin Le Charlier

6 19

Re: running gpc on Mac OS X 10.7.4
by Thomas Schneider 06 Sep '12

06 Sep '12

Kevan: > I'm running GPC just fine on 10.7.4. I may have installed on an earlier > version of 10.7 and then upgraded. I installed the Mac OS X 10.6 Intel > version I found here: > > http://www.microbizz.nl/gpc.html > > What did you install? I hadn't installed, but I went to that page and installed from â¢ GNU Pascal 3.4.6u4 installer for Mac OS X 10.6 Intel native and PowerPC cross-compiler15.7 MB) It SAYS it's supposed to be ONLY for 10.6, but I went ahead anyway on 10.7. In /Developer/Pascal it installed cleanly and replaced directory gpc346u2 with gpc346u4. I can now compile: egg 18% cat h.p program helloworld (output); begin writeln(output,'hello world'); end. egg 19% gpc h.p ld: warning: -macosx_version_min not specified, assuming 10.7 ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in __start from /Developer/SDKs/MacOSX10.5.sdk//usr/lib/crt1.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie egg 20% a.out hello world Thanks, Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Frederick National Laboratory for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 http://alum.mit.edu/www/toms

2 1

collect2 no PATH override
by Jay Michael 03 Sep '12

03 Sep '12

I think "collect2" should honor all of the "where to find compiler components" switches fed to GPC. I think it would be helpful if GPC defaulted to acting as if it were run with "-B <directory containing gpc>" (unless the user provides a "-B" switch). The "collect2" in the binary distribution of gpc-2007-09-04 for Windows doesn't seem to make any effort to locate the "ld" it runs -- if there is no "ld" in the PATH, it prints ld-orig: No such file or directory I have been running GPC without putting GPC\bin in my PATH. It has been working. Then I discovered that when I installed Free Pascal, it took the liberty of updating my system-wide PATH. When I removed it from my PATH, running GPC\bin\gpc resulted in gpc: installation problem, cannot exec `as': No such file or directory Adding "-B GPC\bin" solves that, but has no effect on "collect2" finding "ld".

3 2

RangeCheckError from RuntimeError
by Jay Michael 03 Sep '12

03 Sep '12

My program was terminating with no runtime error message. When run in gdb, gdb told me it terminated with exit code 52 (I think octal). I had a Range Check Error. In gdb, I see that _p_RangeCheckError calls _p_RuntimeError. Then, _p_RuntimeError has code that might call _p_RangeCheckError. I didn't trace further -- gdb suddenly becomes unable to single-step, says "Unable to set breakpoint number -37". (The specific number changes if I keep trying to single-step. It's always negative.) I don't know how much better it would have been, but shouldn't _p_RuntimeError have been compiled with range checking suppressed? (I've found source for RangeCheckError and RuntimeError. I can't find source for CString2String -- is it an intrinsic function? It seems to have been inline coded in RuntimeError.)

3 2

MoveLeft / MoveRight special cases
by Jay Michael 03 Sep '12

03 Sep '12

The procedures MoveLeft and MoveRight start with a test for whether special case code will be useful/possible. procedure MoveLeft (const Source; var Dest; Count: SizeType); if (Count >= SizeOf (LongestCard)) and not (pDst - pSrc in [0 .. 2 * SizeOf (TWord) - 1]) then procedure MoveRight (const Source; var Dest; Count: SizeType); if (Count >= SizeOf (LongestCard)) and not (pSrc - pDst in [0 .. 2 * SizeOf (TWord) - 1]) then Procedure Move calls MoveRight when the address of the source is less than the source of the destination, so the difference will always be negative (except when source and destination are the same address), so the difference will never be in the range [0..2*SizeOf(TWord)-1]. Shouldn't those differences be reversed? Shouldn't the threshold be either SizeOf(LongestCard) in both clauses, or 2*SizeOf(TWord) in both clauses?

1 0

Re: Windows install
by Jay Michael 02 Sep '12

02 Sep '12

Trying to get the source corresponding to the 20070904 Windows distribution, I have downloaded and unpacked gpc-20070904.tar.bz2 mingw-gcc-core-3.4.5-20060117-2-src.tar.gz Between them, they don't seem to be the complete source of the binary distribution I have installed. I can't find any reference to "winmain", which I'm sure is involved in a Windows GUI application. The only version of "collect2" is in the "gcc" chain. It doesn't invoke "windres", and it certainly doesn't say "ld-orig" when it can't find "ld". What do I need to download to be in a position to build GPC under and for Windows?

2 1

running gpc on Mac OS X 10.7.4
by Schneider, Thomas (NIH/NCI) [E] 02 Sep '12

02 Sep '12

gpc folks: I have moved to a new Mac running OS X 10.7.4 and Gnu Pascal now doesn't work: % more h.p program helloworld (output); begin writeln(output,'hello world'); end. % gpc h.p ld: library not found for -lSystemStubs collect2: ld returned 1 exit status Any suggestions on how to fix this? Thanks, Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Frederick National Laboratory for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 http://alum.mit.edu/www/toms

3 6

schema pointer compatibility
by Jay Michael 22 Aug '12

22 Aug '12

Why isn't the address of an object of a schema type an acceptable value for a pointer to the (undiscriminated) schema type? type sptr_type = ^ string ; type sptr_array_type( n : integer ) = array [ 1 .. n ] of sptr_type ; type sptr_array_ptr_type = ^ sptr_array_type ; const s1 = 's1' ; const s2 = 's2' ; const s3 = 's3' ; const slist : sptr_array_type(3) = ( @s1, @s2, @s3 ) ; var slist_ptr : sptr_array_ptr_type = @slist ; t12.pas:23: error: assignment from incompatible pointer type I got the same error when I changed "slist" (the object of the discriminated schema type) from a "const" to a "var". I got the same error when I tried using an assignment statement: var slp : sptr_array_ptr_type ; ... slp := @slist ; If a discriminated instance of a schema type isn't quite the same type as the undiscriminated type, then when would I ever be able to use the address of an object as a value for a pointer to the undiscriminated type? (without coercion, that is)

3 2

Why no schema alias?
by Jay Michael 22 Aug '12

22 Aug '12

type LSTRING = STRING ; t3.pas:8: warning: missing string capacity -- assuming 255 Is there some other syntax to creating an alias of a schema type? On a related note, when I tried type LSTRING( Capacity : INTEGER ) = STRING( Capacity ) ; I got t3.pas:9: error: duplicate field `Capacity' on the attempted type declaration, and again each time I used the new type name. I tried "STRING( LSTRING.Capacity )" and "STRING( .Capacity )". No improvement. type LSTRING( N : INTEGER ) = STRING( N ) ; compiled, and worked almost as well as a true alias. It wouldn't let me pass a string literal as the actual argument to a "const x : LSTRING" parameter.

3 3

file extension case sensitive
by Jay Michael 22 Aug '12

22 Aug '12

The automatic selection of source language based on the extension of an input file seems to be case-sensitive. gpc 20070904, based on gcc-3.4.5 (mingw special) gpc JSM4.PAS gpc: Internal GPC problem: internal option `--amtmpfile' not given gpc JSM4.pas worked fine

2 1

automatic PChar wrong for output param
by Jay Michael 22 Aug '12

22 Aug '12

gpc 20070904, based on gcc-3.4.5 (mingw special) If an array of CHAR is used as the actual argument for a formal parameter declared as "x : PChar", a temporary STRING object is created, the actual argument is copied to the temporary, and the address of the temporary is passed to the subroutine. This is no good when the parameter is a pointer to an output buffer. Using "@s[1]" as the actual argument passes the right address, but if "s" is a STRING, the index "1" is checked, resulting in a RangeCheckError unless the STRING is initialized. I've accepted having to "SetLength" before reading or writing individual characters of the STRING. I didn't expect referring to a character of the STRING in order to get its address to be considered an "access" that would trigger a Range Check. (I planned to set the length of the STRING after the subroutine told me how many characters it had written to the buffer.)

1 0

Re: GPC git
by Waldek Hebisch 02 Aug '12

02 Aug '12

Prof A Olowofoyeku (The African Chief) wrote: > > On 25 Jul 2012 at 16:09, Waldek Hebisch wrote: > > > I wrote: > > > > > Hi Waldek > > > > > > Something is broken under Win32 (compiling with msys environment). > > > This is what I have noticed so far; > > > > > > 1. rts-config.inc is not installed when you run 'make pascal.install' > > > 2. make-lang.inc has "@true" in it. This results in a "command not > > > found" error > > > > > > I will report other problems as I isolate them - but there is a big > > > difference from the release version, in the file sizes when you run > > > 'make pascal.bindist' (about 500kb difference in the tarball size). I > > > will investigate further and will report back in due course. > > > > I have found the issues (under Win32, gcc-3.4.5 backend sources); > > > > 1. "@true" causes an error in 'pascal.install' and 'pascal.bindist', so > > I have removed it. > > > > 2. "rts-config.inc" does not get installed. I believe it is something to > > do with "TREE_GIMPLE_H" definitions. Since I don't fully understand > > TREE_GIMPLE_H, I have manually copied the code that installs the file to > > the relevant section. > > > > 3. The GPC info files are not built or installed. I am yet to find a > > solution to that. > > Solved: I found that the git p/doc/info/ does not contain the .info > files. It only contains a zero-byte file called ".git_is_stupid" ! > > Also, p/doc/generated/ does not contain "gpc-run.1". It also only > contains a zero-byte file called ".git_is_stupid". > > How do I update the git repository? Or will you do it yourself? Sorry, I forgot to mention this: git repository is supposed to contain only source files. So machine generated files like content of p/doc/info/ and p/doc/generated/ is omited. Building gpc should fill those directores with content. But for this you need appropriate tools, in particular 'texinfo' package. Look at the output of 'configure' in build log, if configure can not find needed tools it will print a message and skip building documentation. Git repository does not replace release tarballs -- simply it gives access to code between releases. Content is similar to what 'minimal' gpc tarballs used to contain. Concerning updating git repository: I probably could give write access to persons needing it (I would have to check github instructions). However, more popular method seem to be that developer use GitHub 'fork' feature to create own version and then ask maintainer of main repository to merge changes back to master version. Anyway, for documentation the only thing that needs updating is README -- it should clearly say that you need to have 'texinfo'. BTW: Please keep discussion on the mailing list. One, other folks may have similar problems and learn solution from archived message. Second, others may find good answer earlier. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 3

Re: GPC git
by Waldek Hebisch 01 Aug '12

01 Aug '12

Prof A Olowofoyeku (The African Chief) wrote: > > I wrote: > > > Hi Waldek > > > > Something is broken under Win32 (compiling with msys environment). This > > is what I have noticed so far; > > > > 1. rts-config.inc is not installed when you run 'make pascal.install' 2. > > make-lang.inc has "@true" in it. This results in a "command not found" > > error > > > > I have found the issues (under Win32, gcc-3.4.5 backend sources); > > 1. "@true" causes an error in 'pascal.install' and 'pascal.bindist', so > I have removed it. The line is now: echo "pascal.install done" ; @true Try: echo "pascal.install done" ; true that is remove '@' sign. Note: both lines start from a tab. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 7

string literal as const var parameter
by Jay Michael 24 Jul '12

24 Jul '12

gpc 20070904, based on gcc-3.4.5 (mingw special) I got a compilation error, "type mismatch", when I passed a string literal to a routine with a formal parameter of "const var s : string". In tests, this had been acceptable to the compiler. I find that whether it is acceptable seems to be a function of whether the call is preceded by another call (to a different routine), passing a string literal to (as?) a "const s : string" formal parameter. jsm1bad.pas gets a "type mismatch" compilation error. jsm1ok.pas compiles, links, and executes.

6 10

Re: unit/procedure same name, unhelpful error
by Waldek Hebisch 18 Jul '12

18 Jul '12

Jay Michael wrote: > some of the source when it issues a compilation error? Like > > jsm2.pas:5:jsm2m; > jsm2.pas:5:^---error: expression used as a statement > Currently no such option. > In the test case it's not much more informative than the line number. > In the original code, where the procedure had 5 or 8 arguments, it > would have focused me on the procedure that turned out to also be > a module name. (I spent a lot of time getting the error message=20 > backwards and trying to see if one of the arguments was being affected > by a preprocessor directive that changed it into a procedure call or > other statement where I needed an expression.) > > Does the compiler have enough information to reconstruct the=20 > source representation of the expression it thinks is being used as > a statement? I know there's no limit to how big that could be. > Again, I think it would help to know exactly which source is > upsetting the compiler. > Compiler keeps line numbers of expressions in the input. ATM compiler does not know position of offending item within the input line. Also, the expressions are transformed and what compiler have in hand may be quite different from user input. In principle printing compiler data in Pascal-like form could be of some use, but compiler have no routine for doing this. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Windows install
by Jay Michael 17 Jul '12

17 Jul '12

Where is the source corresponding to GPC 20070904? Where should I find the .gpi files for supplied units (like unit GPC)? If I install a binary distribution for Windows, is there a follow-up step that must be performed manually? (like compiling GPC.PAS) Where would I find documentation of the entry points provided by unit GPC? I downloaded and installed dev_gnu_pascal-1.9.4.13.exe I started with mingw-get-inst-20120426.exe -- It downloaded and installed whatever it wanted. From the size of dev_gnu_pascal-1.9.4.13.exe I had assumed it included the source of GPC, but I haven't been able to find it. In http://www.gnu-pascal.de/alpha, there is no gcc-core-3.4.5, and there is no gpc-20070904.

3 4

unit/procedure same name, unhelpful error
by Jay Michael 10 Jul '12

10 Jul '12

gpc 20070904, based on gcc-3.4.5 (mingw special) I got a compilation error, "expression used as a statement". When I finally realized I had a unit and a procedure in the unit with the same name, I changed one name and the error went away, so I'm guessing the duplication of name was somehow responsible. I am not asking to be allowed to name a unit the same as some entity within the unit. I am asking that the error message be changed to something that would have spared me thrashing around until I noticed that I had duplicated a name. Failing that, could someone explain how what I did was an "expression used as a statement"? >gpc -c -x Pascal jsm2m.int >gpc -c jsm2.pas jsm2.pas: In main program: jsm2.pas:5: error: expression used as a statement

2 1

Re: string literal as const var parameter
by Waldek Hebisch 10 Jul '12

10 Jul '12

> > > From: Waldek Hebisch <hebisch(a)math.uni.wroc.pl> > > Subject: Re: string literal as const var parameter > > To: "Jay Michael" <jmichael_ll(a)yahoo.com> > > Cc: gpc(a)gnu.de > > Date: Monday, July 9, 2012, 8:15 AM > > Jay Michael wrote: > > > > > > procedure enabler( const s : string ) ; > > > procedure rejecter( const var s : string ) ; > > > > > > enabler( 'lit2' ) ; > > > rejecter( 'literal' ) ; > > > > > > > > > Why did compiling the call to > > > "enabler" first result in the compiler > > > accepting the call to "rejecter"? > > > > Plain bug: compiler got wrong internal bookkeeping and > > compiling enabler overwrote info about parameter list > > of rejecter. > > > Is this bookkeeping error fixed by the patch > you posted? Is there a separate patch you did not > post? > The patch should fix both problems. gpc uses code generator from gcc -- the part taken from gcc is usually called backend. To compile Pascal program gpc first builds appropriate data structures describing (in machine-indpendent way) code which should be generated. Layout of such data structures is defined by backend. Also backend provides several functions which create and transform data structures. To save space and usualsy also execution time backend tries to share the same data structures between parts of program. Apparently in case ouf your program backend decided that it can use the same data structure to describe properties of parameters to 'enabler' and 'rejecter'. Previous gpc code called backed function 'build_type_variant' which allows backed to re-use its input argument if there are no change and it seems that backend decided that the change done by gpc is a no-op and reused the data. The patch uses 'build_type_copy' function which disalows sharing in this case. Conseqently, this elliminates sharing of parameter description between 'enabler' and 'rejecter' and prevents overwriting. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Re: string literal as const var parameter
by Jay Michael 09 Jul '12

09 Jul '12

procedure enabler( const s : string ) ; procedure rejecter( const var s : string ) ; enabler( 'lit2' ) ; rejecter( 'literal' ) ; Why did compiling the call to "enabler" first result in the compiler accepting the call to "rejecter"?

2 1

bug report disappeared
by Jay Michael 27 Jun '12

27 Jun '12

I submitted a bug report. It got bounced back to me, looking like I had CC'd myself. This morning, "The GPC Archives" had an entry for "June 2012", consisting of my bug report. Now, there is no entry for "June 2012", and so no sign of my bug report. Should I resubmit the bug report? Is it being processed? Has it been judged unacceptable?

2 1

rpm packages for gnu pascal now available
by trevor-b＠ovi.com 14 May '12

14 May '12

Hi for those who want to install gnu pascal on recent rpm based linux distributions, I have made rpm packages for openSuSE (various versions), fedora/centos & mandriva (most recent versions only). This is for gpc 20070904 find them on opensuse build service here ---> http://software.opensuse.org/package/gpc or go directly to my repository here ---> http://download.opensuse.org/repositories/home:/TrevorBl/ There are also subpackages for documentation, test results and a simple app wizard for kdevelop4. Test results vary a little - from 7 fails and 4 unsupported tests to zero fails & 2 unsupported (on centOS-6). (gmp-test result is unsupported for all distrubutions on open build service, but it passes fine on my system at home (OpenSuse 12.1) - does this mean I have missed some dependency in the rpm?) As always, comments and suggestions welcome. Best Regards, Trevor//

2 1

GCC 4.3.5-based GPC fails to compile under Fedora 16
by John L. Ries 22 Apr '12

22 Apr '12

I downloaded hebisch-gpc-8249f1b.tar.gz from https://github.com/hebisch/gpc and gcc-core-4.3.5.tar.bz2 from my friendly neighborhood mirror, extracted the source, created the soft links as instructed, applied the patch (gcc-4.3.5.diff) and configured as follows: ../gcc-4.3.5/configure --enable-languages=all --disable-mapped-location \ --program-suffix=435 After much compiling, I get the following: Checking multilib configuration for libgpc... mkdir -p -- x86_64-unknown-linux-gnu/libgpc Configuring in x86_64-unknown-linux-gnu/libgpc configure: WARNING: unrecognized options: --enable-multilib, --disable-mapped-location, --enable-languages, --with-target-subdir configure: creating cache ./config.cache configure: updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile configure: WARNING: unrecognized options: --enable-multilib, --disable-mapped-location, --enable-languages, --with-target-subdir cat: ../../../gcc-4.3.5/libgpc/../gcc/BASE-VER: No such file or directory make[2]: Entering directory `/usr/local/src/gcc/x86_64-unknown-linux-gnu/libgpc' /usr/local/src/gcc/./gcc/xgcc -B/usr/local/src/gcc/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -dumpmachine > alias_file 2>/dev/null for i in `/usr/local/src/gcc/./gcc/xgcc -B/usr/local/src/gcc/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include --print-multi-lib 2>/dev/null`; do \ dir=`echo $i | sed -e 's/;.*$//'`; \ flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \ make CFLAGS="-O2 -g -g -O2 ${flags}" MPREFIX=${dir} build ; \ done cat: ../../../gcc-4.3.5/libgpc/../gcc/BASE-VER: No such file or directory make[3]: Entering directory `/usr/local/src/gcc/x86_64-unknown-linux-gnu/libgpc' make[3]: *** No rule to make target `../../../gcc-4.3.5/libgpc/../gcc/p/rts/Makefile.in', needed by `p/rts/Makefile'. Stop. make[3]: Leaving directory `/usr/local/src/gcc/x86_64-unknown-linux-gnu/libgpc' cat: ../../../gcc-4.3.5/libgpc/../gcc/BASE-VER: No such file or directory make[3]: Entering directory `/usr/local/src/gcc/x86_64-unknown-linux-gnu/libgpc' make[3]: *** No rule to make target `../../../gcc-4.3.5/libgpc/../gcc/p/rts/Makefile.in', needed by `32/p/rts/Makefile'. Stop. make[3]: Leaving directory `/usr/local/src/gcc/x86_64-unknown-linux-gnu/libgpc' make[2]: *** [do_multidirs] Error 2 make[2]: Leaving directory `/usr/local/src/gcc/x86_64-unknown-linux-gnu/libgpc' make[1]: *** [all-target-libgpc] Error 2 make[1]: Leaving directory `/usr/local/src/gcc' make: *** [all] Error 2 The question is, how do I proceed... or more specifically, what is BASE_VER and how do I create it? config.log is attached. --------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

2 3

unexpected gpc command line behaviour
by trevor-b＠ovi.com 28 Feb '12

28 Feb '12

Hi, I've built gpc-20070904 for openSuSE 12.1 and the gpc command fails unless I type the full path name of gpc on the command line. For example, if I type gpc -- verbose hello.pas , gpc calls the assembler in 32 bit mode. Like this ... trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> gpc --verbose hello.pas Reading specs from /usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/specs Configured with: ./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --enable-languages=pascal --disable-mapped-location --enable-threads=posix --disable-nls --prefix=/usr/local/gpc --infodir=/usr/local/info --mandir=/usr/local/man Thread model: posix gpc version 20070904, based on gcc-3.4.6 /usr/local/gpc/lib/gcc/x86_64-suse-linux-gnu/3.4.6/gpc1 -quiet -v hello.pas -quiet -dumpbase hello.pas -mtune=k8 -auxbase hello -famtmpfile=/tmp/ccsijV8f.gpa -version -o /tmp/cclfaLHH.s GNU Pascal version 20070904, based on gcc-3.4.6 (x86_64-suse-linux-gnu) compiled by GNU C version 3.4.6. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Pascal Compiler PreProcessor version 20070904, based on gcc-3.4.6 as -V -Qy --32 -o /tmp/ccrX1Zh9.o /tmp/cclfaLHH.s GNU assembler version 2.21.1 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE 12.1) 2.21.1 /tmp/cclfaLHH.s: Assembler messages: /tmp/cclfaLHH.s:10: Error: bad register name `%rbp' /tmp/cclfaLHH.s:12: Error: bad register name `%rsp' /tmp/cclfaLHH.s:15: Error: bad register name `%rip)' /tmp/cclfaLHH.s:17: Error: `movabs' is only supported in 64-bit mode /tmp/cclfaLHH.s:20: Error: bad register name `%rip)' /tmp/cclfaLHH.s:22: Error: bad register name `%rip)' ... /tmp/cclfaLHH.s:67: Error: bad register name `%rbp)' On the other hand, when I call gpc using its full path name, everything works as expected ... trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> /usr/local/bin/gpc --verbose hello.pas Reading specs from /usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/specs Configured with: ./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --enable-languages=pascal --disable-mapped-location --enable-threads=posix --disable-nls --prefix=/usr/local/gpc --infodir=/usr/local/info --mandir=/usr/local/man Thread model: posix gpc version 20070904, based on gcc-3.4.6 /usr/local/gpc/lib/gcc/x86_64-suse-linux-gnu/3.4.6/gpc1 -quiet -v hello.pas -quiet -dumpbase hello.pas -mtune=k8 -auxbase hello -famtmpfile=/tmp/ccVD338Z.gpa -version -o /tmp/ccxCBcyY.s GNU Pascal version 20070904, based on gcc-3.4.6 (x86_64-suse-linux-gnu) compiled by GNU C version 3.4.6. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Pascal Compiler PreProcessor version 20070904, based on gcc-3.4.6 as -V -Qy -o /tmp/ccBkjEYW.o /tmp/ccxCBcyY.s GNU assembler version 2.21.1 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE 12.1) 2.21.1 ld --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/crtbegin.o -L/usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6 -L/usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/../../../../lib64 -L/usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccBkjEYW.o -lgpc -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/crtend.o /usr/lib/../lib64/crtn.o trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> ./a.out Hello, world. trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> Similar (but not identical) problem when I call gpc with no arguments: When I omit the full pathname, gpc fails because it tries to link an empty file ... trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> gpc --verbose Reading specs from /usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/specs Configured with: ./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --enable-languages=pascal --disable-mapped-location --enable-threads=posix --disable-nls --prefix=/usr/local/gpc --infodir=/usr/local/info --mandir=/usr/local/man Thread model: posix gpc version 20070904, based on gcc-3.4.6 ld --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/crtbegin.o -L/usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6 -L/usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/../../../../lib64 -L/usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 --no-warn-search-mismatch -lgpc -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/crtend.o /usr/lib/../lib64/crtn.o /usr/lib/../lib64/crt1.o: In function `_start': /home/abuild/rpmbuild/BUILD/glibc-2.14.1/csu/../sysdeps/x86_64/elf/start.S:109: undefined reference to `main' trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> With a full pathname, gpc prints some version info and exits (as expected) trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> /usr/local/bin/gpc --verbose Reading specs from /usr/local/gpc/lib64/gcc/x86_64-suse-linux-gnu/3.4.6/specs Configured with: ./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --enable-languages=pascal --disable-mapped-location --enable-threads=posix --disable-nls --prefix=/usr/local/gpc --infodir=/usr/local/info --mandir=/usr/local/man Thread model: posix gpc version 20070904, based on gcc-3.4.6 trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> Note: /usr/local/bin/gpc is a link: trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> file /usr/local/bin/gpc /usr/local/bin/gpc: symbolic link to `/usr/local/gpc/bin/gpc' trevor@linux-z54m:~/projects/gpc/gpc-20070904/p/demos> Also, trevor@linux-z54m:~/projects/gpc/gcc-3.4.6/gcc/p/test> uname -a Linux linux-z54m 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) x86_64 x86_64 x86_64 GNU/Linux trevor@linux-z54m:~/projects/gpc/gcc-3.4.6/gcc/p/test> Also, calling gpc (ie in short form, not using full pathname) from a shell script works as expected, so the test scripts work. Results copied below. I built gpc on openSuSE 11.3using the same build process (as far as I know) and there were no problems. OK, it's not a catastrophic failure, but I would like to fix it. Does anyone know what causes this, and what I need to do about it? Any ideas much appreciated. Test summary: === gpc Summary === # of tests 5111 # of expected passes 5102 # of unexpected failures 7 # of unsupported tests 2

1 1

Compile error with GNU Pascal
by Baudouin Le Charlier 28 Nov '11

28 Nov '11

Hi ! I am using a Mac OS X 10.6.8. I have downloaded GNU Pascal for Mac Os from http://www.microbizz.nl/gpc.html together with Apple’s Mac OS X assembler and linker (cctools-576) (binary). I got the following error : gp test.pas /usr/bin/ld: can't locate file for: -lcrt1.o collect2: ld returned 1 exit status I should be happy to know how to "fix" this "problem". Thanks in advance for help. Baudouin

2 3

is this a bug in GPC?
by Leo Brewin 29 Oct '11

29 Oct '11

Hi Troops, I've been using Adriaan's recent gpc (gpc436u1) on MacOSX 10.7.2 with Xcode 4.2 and I think I have found a bug. I've attached a rather odd but simple code that can produce a segmentation fault. This is what I get when running the code through gdb Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xc0000140 0x917a4a89 in longcopy () (gdb) where #0 0x917a4a89 in longcopy () #1 0x9178ec98 in memmove$VARIANT$sse3x () #2 0x000018c0 in Jack (l1=1, u1=4, x_beg=@0xbfffed10, l2=1, u2=4, x_end=@0xbfffecf0) at foo.p:25 #3 0x00001a05 in Jill () at foo.p:48 #4 0x00001a34 in main program () at foo.p:57 #5 0x00001aab in main (argc=1, argv=0xbfffeda0, envp=0xbfffeda8) at foo.p:1 (gdb) quit It seems that the crash occurs when starting up the procedure Mary. It looks like something to do with a copy of the two arrays x_beg and x_end. If I change the formal declarations to var arrays then the problem does not occur. So I have a workaround but it is not ideal. And almost any other change to the code seems to also remove the seg fault (e.g. use just one case in the case statement, set my_choice=1, make x_beg, x_end array[1..3], add a written anywhere etc.) Any thoughts or suggestions? Cheers Leo Brewin School of Mathematical Sciences Monash University // ----------------------------------------------------------------------------------- // compile this with gpc346u1 leads to a segmentation fault // gpc -o foo foo.p program Fred(input,output); var my_choice : integer; // the segmentation fault does not ocurr if the the following two arrayas are passed as var ... procedure Mary(x_beg : array[l1..u1:integer] of double; x_end : array[l2..u2:integer] of double); begin end; procedure Jack(var x_beg : array[l1..u1:integer] of double; var x_end : array[l2..u2:integer] of double); begin case my_choice of 1: Mary(x_beg,x_end); 2: Mary(x_beg,x_end); otherwise ; end; end; procedure Jill; var x_0 : array[1..4] of double; x_1 : array[1..4] of double; begin x_0[1]:=0.0e0; x_0[2]:=0.0e0; x_0[3]:=0.0e0; x_0[4]:=0.0e0; x_1[1]:=0.1e0; x_1[2]:=0.0e0; x_1[3]:=0.0e0; x_1[4]:=0.0e0; Jack(x_0,x_1); end; begin my_choice:=1; // no problem using this my_choice:=2; // will cause a seg fault Jill; end.

1 0

gpc in Mac OSX Lion
by Leo Brewin 25 Oct '11

25 Oct '11

Hi troops, Has anybody successfully compiled GPC under MacOSX Lion? I've tried doing so using Adriaan's sources (gpc346u4-sources.dmg) but I encountered the following errors (as listed below). Any help would be greatly appreciated. Cheers, Leo Brewin School of Mathematical Sciences Monash University stage1/xgcc -Bstage1/ -B/Users/leo/tmp-pascal/gpc346u4/i386-apple-darwin11/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -DHAVE_CONFIG_H -DGENERATOR_FILE -o genmodes \ genmodes.o errors.o ../libiberty/libiberty.a ld: warning: -macosx_version_min not specificed, assuming 10.7 Undefined symbols for architecture i386: "___bzero", referenced from: _htab_empty in libiberty.a(hashtab.o) ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status make[2]: *** [genmodes] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap] Error 2

2 2

Latest versions of gpc
by John Gordon Ollason 13 Oct '11

13 Oct '11

Greetings, Having upgraded to Fedora 15 I'd like to install gpc again, but I don't know where to look for the latest version. I have found a source for gpc-20070904 but I haven't yet managed to compile it. (Is that the latest version?) I suppose that by now the language must have lost most of its users, but I still, occasionally, write some Pascal code, and would like to be able to compile it. Thanks for any advice, John Ollason

4 5

Missing crt1
by Kevan Hashemi 15 Sep '11

15 Sep '11

Hi, I recently moved from MacOS 10.4 to 10.5 on my old PPC laptop. I re-installed GPC for MacOS 10.5 from the Microbizz site. When I try to compile a hello world program, I get the following error: gpc p.pas /Xcode2.5/usr/bin/ld: can't locate file for: -lcrt1.o collect2: ld returned 1 exit status The file crt1.o is sitting in /Xcode2.5/SDKs/MacOSX10.4u.sdk/usr/lib When I add the above directory to my PATH, I still have problems. My path is now: /usr/bin:/bin:/usr/sbin:/sbin:/Xcode2.5/usr/bin:/Xcode2.5/SDKs/MacOSX10.4u.sdk/usr/lib Do I have my path set up wrong? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

3 7

Ada translation using gpc.
by Pascal Pignard 09 Aug '11

09 Aug '11

Hello. I've object Pascal source codes I would like to translate in Ada. Though newP2Ada translator does good job for standard Pascal, it isn't object aware. Thus I've created objP2Ada, a new branch, which can parse object Pascal syntax. http://sourceforge.net/projects/p2ada But some nice features work partially as the parser has some limitations. What about to produce Ada code with modified gpc? Is there some interested people in helping gpc modification? I've got gpc source codes for Mac from http://www.microbizz.nl/gpc.html. Thanks to perfect building script from Adriaan, I was able to build completely gpc on Mac OS X 10.6. I've some ideas for translation of Pascal structures from my experience with objP2Ada. What would be the next steps with gpc? Regards, Pascal. http://blady.pagesperso-orange.fr

1 0

Compiler error output
by Adriaan van Os 01 Jul '11

01 Jul '11

Waldek Hebisch wrote: > I did some work on updating gpc to newer gcc versions. You can > find it at GitHub: Another issue I found is that in compiler error output, the line number is equal to 0 for most of the errors. program error (Output); procedure nonsense; begin xxx; end; yyy; begin zzz end. [P18:~/gpc/testgpc/adriaan] adriaan% gpc error.pas error.pas: In procedure `nonsense': error.pas:0: error: undeclared identifier `xxx' (first use in this routine) error.pas:0: error: (Each undeclared identifier is reported only once error.pas:0: error: for each routine it appears in.) error.pas: At top level: error.pas:9: error: syntax error before `yyy'

1 0

[Fwd: GCC 4.3.6 Released]
by Adriaan van Os 28 Jun '11

28 Jun '11

-------- Original Message -------- Subject: GCC 4.3.6 Released Date: Tue, 28 Jun 2011 15:05:50 +0200 (CEST) From: Richard Guenther <rguenther(a)suse.de> Reply-To: gcc(a)gcc.gnu.org To: gcc-announce(a)gcc.gnu.org CC: gcc(a)gcc.gnu.org The GNU Compiler Collection version 4.3.6 has been released. GCC 4.3.6 is a bug-fix release containing fixes for regressions and serious bugs in GCC 4.3.5. This release marks the end of the maintainance of the GCC 4.3 series. The release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!

1 0

Test
by Frank Heckenbach 27 Dec '10

27 Dec '10

Just a test, please ignore. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

Running a 32 bit binary built with GPC on a 64 bit system
by Martin Liddle 16 Nov '10

16 Nov '10

We build our executables using a 32 bit version of GPC (20070904 based on gcc-3.4.6) running on a 32 bit kernel. A customer has tried to run the executable on a 64 bit kernel (Fedora 14) and gets the error message: manager.e: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory Error 126 whilst executing manager. Press RETURN I would expect it to be possible to run a 32 binary on a 64 bit system. Is this correct and if so what additional steps might be required? -- Martin Liddle, Tynemouth Computer Services, 3 Kentmere Way, Staveley, Chesterfield, Derbyshire, S43 3TW. Web site: <http://www.tynecomp.co.uk>.

3 2

Inefficiency of `mod'
by Emil Jerabek 25 Oct '10

25 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

Re: Null characters in strings
by Morton, John 12 Sep '10

12 Sep '10

My thanks once again. Things are now gradually starting to come together. I should first clarify that we never manipulate the time field - it's the precise 32-bit bit pattern (time) that gets sent to the outside world that matters, not what gpc Pascal (or any language/compiler) actually uses to hold the 32 bit time field. I am not yet a gpc user and was unaware of the type casting approach. (My last Pascal experience was some years ago and that was on mainframe/mini-computers, not in the PC/Linux world. Since then I've worked in ADA and greatly liked that language.) Type casting is exactly the KISS approach I was looking/hoping for. In great preference to the fragile and potentially non-portable approaches of variant records or the parameter mapping "trick" at the library interface. Also new to me are the gpc bitwise operators, thanks for mentioning them. They will be a great help in rewriting parts of our code. Once I get "Hello World" working I'll be spending some time with the current gpc manual to see what else in gpc is new to me. I expect I will find other things in gpc that will be of immediate practical use to us. Hopefully the manual also covers how to create GPC makefiles that use individually compile multiple source files, persistent object files and a separate user controllable linker step. As surmised, the time taken to build a message is not (yet) time-critical. However "endian-ism" might (but shouldn't) become an issue. We do not manipulate the time and not care how the bytes are actually stored because it's only the bit pattern of the "4 byte time field" that matters when the message is sent. The current conceptual model (without type casting) is: GetSystemTime( X ) - return 32 bit time in X (as a 4 byte string) Y = X + rest-of-message - concatenate strings to get final message string SendMessage( Y ) - hardware sends the final message sting As revised to use type casting (using the types at the end of this message): GetSystemTime( Z ) - return the time in Z (Z is defined as 32 bits) X = Char4( Z ) - cast the 32 bit time to a 4 byte string Y = X + rest-of-message - concatenate strings to get final message string SendMessage( Y ) - hardware sends the final message string So why use a 4 byte string and not something else? Everything else in the application uses strings - which makes using a string the simplest way for us to handle the 32 bit time field. Comments? Improvements? Thanks. BTW, My viewpoint is that if something can be done in an easily understood (=KISS) manner using only standard gpc Pascal constructs (i.e. without "tricks" or "virtuous" (=often obtuse) coding) it is "pure" Pascal. By those standards only the second version is "pure" Pascal. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Frank Heckenbach Sent: September 7, 2010 08:03 PM To: gpc(a)gnu.de Subject: Re: Null characters in strings Morton, John wrote: > My thanks for confirming that writeln is not implemented using C's > printf function (I can't remember where I got that idea) and that gpc's > writeln can send all 256 characters (absolutely necessary to handle > binary time as a string). > > On reflection I realize I have misstated our problem. But I think I > also have a work-around for it. > > The issue is that the supplied library returns the time as a 32 bit > binary value. The problem is essentially how to coerce the 32 bits into > a corresponding 4 character gpc string. (BTW, they are the first 4 > bytes of every message sent by our application). > > I had hoped that the coercion (effectively a type cast) would be easy to > accomplish within Pascal. I then thought about variant records but that > did not seem feasible. > I have since realized that the conversion could be done where we define > the interface to the external routine. In the Pascal function > definition use a 4 character fixed length string for the time field and > have the linker map that string to the corresponding 32 bit value field > used by the library (probably by using pass-by-address, possibly > pass-by-value). > Not a pure Pascal approach but a practical one - as long as you are well > aware of the pitfalls. (In the "pure" approach the Pascal interface > parameter would be a 32 bit unsigned value that gets converted/mapped by > Pascal to the corresponding 4 byte string). The only "pure" Pascal approach would be converting the value to single bytes using "div"/"mod" (GPC also supports bitwise "and" and "shl"/"shr") and then to characters using "Chr". If it's not time-critical, this might actually be worth considering, since it avoids endianness issues. With GPC, also type-casting should work. Something like this: program Foo; type Card32 = Cardinal attribute (Size = 32); Char4 = array [1 .. 4] of Char; var a: Card32; b: Char4; begin b := Char4 (a); a := Card32 (b); end. Variant records are sometimes abused(!) for this purpose, but I don't recommend it. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Re: Null characters in strings
by Morton, John 08 Sep '10

08 Sep '10

My thanks for confirming that writeln is not implemented using C's printf function (I can't remember where I got that idea) and that gpc's writeln can send all 256 characters (absolutely necessary to handle binary time as a string). On reflection I realize I have misstated our problem. But I think I also have a work-around for it. The issue is that the supplied library returns the time as a 32 bit binary value. The problem is essentially how to coerce the 32 bits into a corresponding 4 character gpc string. (BTW, they are the first 4 bytes of every message sent by our application). I had hoped that the coercion (effectively a type cast) would be easy to accomplish within Pascal. I then thought about variant records but that did not seem feasible. I have since realized that the conversion could be done where we define the interface to the external routine. In the Pascal function definition use a 4 character fixed length string for the time field and have the linker map that string to the corresponding 32 bit value field used by the library (probably by using pass-by-address, possibly pass-by-value). Not a pure Pascal approach but a practical one - as long as you are well aware of the pitfalls. (In the "pure" approach the Pascal interface parameter would be a 32 bit unsigned value that gets converted/mapped by Pascal to the corresponding 4 byte string). Anyone have any thoughts on this? Have I have missed a simpler approach? John. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Frank Heckenbach Sent: September 3, 2010 05:16 PM To: gpc(a)gnu.de Subject: Re: Null characters (& string Morton, John wrote: > We have encountered an unexpected implementation issue with gpc, one > that probably affects all languages implemented using C/C++: The > mapping of Pascal writeln (etc.) statements to "equivalent" C/C++ string > handling code. Others have replied already, but I can confirm that GPC does not use printf etc. internally to implement WriteLn, if that's what you mean. > Stated more generally, is there a pure gpc Pascal way to send > ("writeln") strings that can contain any/all of the 256 8 bit characters > (especially the null) - an approach that does not require retyping our > string definitions? Of course, any such way is not pure Pascal in the sense of ISO Pascal or so. Text files (WriteLn) are not really meant for binary data, though it works with GPC, and is as portable as GPC is, and probably works with some other compilers as well. The official Pascal way would be a "file of Char" (though ISO Pascal doesn't even guarantee that the NUL character is part of the character set), where you'd need to read/write every character individually. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Null characters (& string implementation) in gpc
by Morton, John 03 Sep '10

03 Sep '10

We have encountered an unexpected implementation issue with gpc, one that probably affects all languages implemented using C/C++: The mapping of Pascal writeln (etc.) statements to "equivalent" C/C++ string handling code. We have not found a pure (Pascal-only) way to use gpc writeln (etc.) statements to send strings that must include null characters (in our case as part of a 4 byte binary time). The problem is that the implementation of the mapped C/C++ function prematurely terminates a message at the null, preventing the message from being transmitted properly. The impact on us is that whenever any byte of the time rolls over a service outage results - with the length of the outage depending upon which byte rolls over. We have since kluged a way around the issue but would much prefer a pure Pascal (=portable) solution. In our case the message must be sent as one complete entity, meaning separating the string into multiple "writeln" statements is not possible. (This would be an awkward approach if/when (multiple) nulls can appear anywhere in the string). Stated more generally, is there a pure gpc Pascal way to send ("writeln") strings that can contain any/all of the 256 8 bit characters (especially the null) - an approach that does not require retyping our string definitions? Any ideas out there about how to do this? Thanks.

4 3

Re: Null characters (& string implementation) in gpc
by Morton, John 03 Sep '10

03 Sep '10

Bonjour Maurice, I can't test gpc until I build "Hello world" (or "bug") so your results are great news for us. Our problem may have something to do with the FAA library and the way we had to link it to our code. More likely it's because we have a quite old version of gpc and the problem we encountered was fixed in a subsequent release. We'll see if the problem disappears after we rebuild our application using the new version of gpc (once I get it going). Merci. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Maurice Lombardi Sent: September 3, 2010 01:29 PM To: gpc(a)gnu.de Subject: Re: Null characters (& string implementation) in gpc Le 03/09/2010 17:23, Morton, John a écrit : > We have not found a pure (Pascal-only) way to use gpc writeln (etc.) > statements to send strings that must include null characters (in our > case as part of a 4 byte binary time). The problem is that the > implementation of the mapped C/C++ function prematurely terminates a > message at the null, preventing the message from being transmitted > properly. > I do not understand. The following test program works as expected: program bug; var s: string[255] = 'hello >'+chr(0)+'< world'; begin writeln(s); end. there is an unprintable character between the two > < and redirecting the output to a file which can be examined with a binary editor shows that this character is indeed a null. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Why GPC? (was: GPC linker errors - help needed)
by Morton, John 02 Sep '10

02 Sep '10

Quite reasonable questions. And No, you didn't miss anything. Yes, we need to use static libraries/objects that we can place under configuration control. And static linking is mandatory for us. That's why I have used "rpm2cpio" to extract the 3 objects from "glibc-devel" that are used by gpc. Now I just have to figure out how to get gpc to use these 3 files and how to split gpc into separate compile and link phases and also get gpc to place the object files into their own permanent folder. Once that is done I should be able to rebuild our application on RHEL 5.4. Any hints here would be greatly appreciated. I agree with your point about commercial software but the choice of O/S, compiler, etc. was determined by the FAA, not us. They also provide us with a special purpose library that we must use (link to) when interfacing to their systems. That library pretty much forces us to use gpc and/or other gnu-based tools/compilers (gcc, gnat, etc). Gpc is being used for compatability to the library and because that is what was used to port our Pascal interface code (originally developed for HPUX in the mid 90s) to 32-bit RHEL. The reason behind behind what we are doing is that the FAA is moving a system we use to 64-bit RHEL5.4. The nature and importance of this system means we must move in lockstep with them. Part of our effort requires porting (for the second time) the existing code and development tools. While the current 32-bit executable should run without problems on RHEL5.4 we will have to maintain and upgrade this software for many years. BTW, I hope everyone understands that I have to play Devil's Advocate and think of the worst possible outcome that would occur if all the holes in the "Swiss Cheese" model line up. I only handle one of many slices; if any other slice blocks the hole in my layer then there is no safety issue. -----Original Message----- From: Hiltibidal, Rob [mailto:Rob.Hiltibidal@argushealth.com] Sent: September 1, 2010 05:10 PM To: Morton, John Subject: RE: GPC linker errors - help needed I think I missed something here... Why not use static libraries at this point? In all honesty if its safety/life-critical systems why not use commercial software that is supportable?

1 0

Re: GPC linker errors - help needed
by Morton, John 01 Sep '10

01 Sep '10

The reality of working with safety/life-critical systems means it very dangerous for us to use shared libraries. I understand the point about dependencies and the concerns expressed about extracting object files. But in my world the concerns are precisely opposite. It is safe to extract/use an object file (which can be properly controlled) and extremely unsafe to use a shared library (because other applications may "update" the library). BTW, Extracting the objects from the library shouldn't matter. If the object files were created as expected, all external references/definitions that they need will be satisfied during the link phase. Besides, if the object files do have dependency problems the application will not link - which is much, much safer than the standard situation. In my world a change to a shared library automatically destroys application certification - and the change can make every application that uses that library dangerous to the public. My problem right now is the dependency tree prevents the installation of "glibc-devel". However it looks like I can use the RPM "--nodeps" option to force Red Hat's "glibc-devel" package to install on my system. A better approach seems to be to use "rpm2cpio" (see http://www.rpm.org/max-rpm/s1-rpm-miscellania-rpm2cpio.html) to do the extractions. Has anyone tried this tool? If the "rpm2cpio" approach doesn't work we will probably have to force the install and handle the "glibc-devel" package like any other non-gpc library, see below. To meet our safety requirements we will have to place copies of the 3 object files - and all other non-gpc items (shared files/libraries, tools, etc.) used to build the application - into non-shared (= non-standard) locations, then instruct the linker to look for these files in their new location. And everything involved (including all gpc components) will be placed under configuration control. The end result is that our installation of gpc would become "Stand-Alone" and immune to changes to shared software. This also seems to be the easiest way to make use of the "shared" files while still meeting our safety (and other) requirements. Critically for us, this approach also ensures that several years from now that nothing has changed and that we can recreate an absolutely identical executable of our application, starting from nothing. The necessity to override standard locations with non-standard ones is another reason why it is important for gpc compiles to be separated into totally separate compile and link phases (e.g. two command files, normally invoked automatically, one after another). I suspect separating the gpc command into two separate compile and link command files is more complicated than just putting the commands (displayed by gpc -v) into separate files. For instance I don't see "hello.o" being passed to the "collect2" (the linker?) command and there also is the issue of how to handle/pass the temp files used by gpc. Does anyone have any experience in doing this? Thanks. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 27, 2010 05:04 PM To: GNU Pascal mailing list Subject: Re: GPC linker errors - help needed On 27 Aug 2010, at 22:24, Morton, John wrote: > As expected "glibc.i686" was preinstalled. I tried installing the i386 > and x86_64 Red Hat rpms for "glibc-devel". Both rpms reported some > unsatisfied dependencies. To make a long story short, in both cases the > geometric growth of the dependency tree looks like it will eventually > force all of the gcc C compiler to be installed. > Maybe it's my non-C background but this hidden 3 file dependency (upon > C) seems unreasonable given that all that gpc needs (see output below) > is for those object files to be visible to the ld linker (assuming these > object files are not dependent upon other files). I would strongly recommend to simply install all dependencies. While things *may* work fine with just those files, they may just as well not for one reason or another. You can only make things more difficult for yourself by trying to circumvent the the dependencies of those packages. Jonas

1 0

GPC linker errors - help needed
by Morton, John 28 Aug '10

28 Aug '10

As expected "glibc.i686" was preinstalled. I tried installing the i386 and x86_64 Red Hat rpms for "glibc-devel". Both rpms reported some unsatisfied dependencies. To make a long story short, in both cases the geometric growth of the dependency tree looks like it will eventually force all of the gcc C compiler to be installed. Maybe it's my non-C background but this hidden 3 file dependency (upon C) seems unreasonable given that all that gpc needs (see output below) is for those object files to be visible to the ld linker (assuming these object files are not dependent upon other files). Here is what I'd like to do: - Place copies of the 3 object files (crt1.o, crtl.o, ctrn.o) into their own folder or my application folder (or in "/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6" since that folder already contains other "crt" files such as "crtbegin.o") then set up the linker search path appropriately. - Separate the gpc compile and link steps (using makefiles for each phase). - Compile each of the 70+ source files that make up our application separately then pass a makefile (i.e. a list of the corresponding object files) to the linker. - The object files need to be persistent across compiles (not deleted after the link stage). - Be able to pass/specify additional libraries and object files to the linker I expect this should be relatively straightforward except for extracting the 3 object files. What is the easiest way of getting these files? Also what Linux based SDKs, meeting the above requirements, are being used with gpc? We already use a Linux version of the Rational/IBM Clearcase and Clearquest config management tools. Hopefully there are some Linux based SDKs that are compatible with these CM tools. Thanks --- The results of my latest compile attempt: [etms@lxstn08 dev]$ gpc -v -Wa,--32 hello.pas Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: ../gcc-3.4.6/configure --enable-languages=pascal Thread model: posix gpc version 20070904, based on gcc-3.4.6 /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.6/gpc1 -quiet -v hello.pas -quiet -dumpbase hello.pas -mtune=pentiumpro -auxbase hello -famtmpfile=/tmp/ccobDgZ4.gpa -version -o /tmp/cci6p6IZ.s GNU Pascal version 20070904, based on gcc-3.4.6 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Pascal Compiler PreProcessor version 20070904, based on gcc-3.4.6 as -V -Qy --32 -o /tmp/ccWia0MX.o /tmp/cci6p6IZ.s GNU assembler version 2.17.50.0.6-12.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-12.el5 20061020 /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.6/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 crt1.o crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/crtbegin.o -L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6 -L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/../../.. /tmp/ccWia0MX.o -lgpc -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/crtend.o crtn.o /usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status [etms@lxstn08 dev]$ -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 25, 2010 03:40 PM To: GNU Pascal mailing list Subject: Re: GPC Assembler/linker errors - help needed On 25 Aug 2010, at 21:26, Morton, John wrote: > The gpc -v output shows that the compile now gets to the linker stage - > which complains that it cannot find crtl.o (and probably crt1.o and > crtn.o). These are part of the glibc-devel.i386 package. You have to install it on your compilation machines. It does not have to be installed on the staging/deployment machines (but glibc.i686 will have to be installed there). <<SNIP>> Jonas

3 2

Re: GPC Assembler/linker errors - help needed
by Morton, John 25 Aug '10

25 Aug '10

Thanks to the list (especially Jonas and Maurice) I've made progress. I am now able to log in as an unprivileged user ("etms") and run gpc (from "/home/etms/dev" which holds the "hello world" source code). The gpc -v output shows that the compile now gets to the linker stage - which complains that it cannot find crtl.o (and probably crti.o and crtn.o). Since none of these files are prefixed with a path it seems that the linker assumes they are in the current directory or are in the following default path (as one line - you can safely ignore the two "etms" folders): /usr/local/bin/:/usr/bin:/usr/X11R6/bin:/home/etms/bin: /opt/0V/bin:/opt/0V/bin/0pC:/etms/com:. I thought I saw the missing files somewhere but (assuming I've used "find" correctly) they aren't on my system at all. I did the search after deleting gpc-2.1 (from gnu-pascal.de) and then untarring (as root) "gcc-core-3.4.6.tar.tar" (from Brandeis) into it's default location (/usr/local/gcc-3.4.6). Shouldn't the 3.4.6 extraction have placed the 3 files in or under that directory? In theory all I need to do is update $PATH to include the appropriate directory - but which one is supposed to contain the three files? Or is there some other way (e.g. a command line option) to make the files visible to the linker? --- BTW, yum reports glibc 2.5-42 (i686 and x86_64 versions) and glibc-common 2.5-42 (x86_64 version only) but not libc (or libc-dev). My understanding is that this naming difference does not affect gpc (or anything else) on my Linux box. Finally, my thanks to Maurice for explaining the 64 bit situation. Luckily for me a 64 bit image is not (yet) an absolute requirement. Once I've got the 32 bit version working I'll be looking into building a 64 bit version from source code. John -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 25, 2010 07:11 AM To: GNU Pascal mailing list Subject: Re: GPC Assembler errors - help needed On 24 Aug 2010, at 23:35, Morton, John wrote: > Given that the "with gcc" binary tarballs are intended to be > stand-alone I am somewhat surprised that installing 32 bit > versions of "all dev packages (including libc-dev)" may be > needed. <<SNIP>> GPC programs by default use functionality from libc afaik, and hence to compile such programs you have to have the right libraries installed. <<SNIP>> > And am I correct in that a true 64-bit wide (x86_64) gpc Linux > compiler is not yet available? See Maurice' answer for this. > If so I expect I need to install the i686 version > of the "binutils" package. (yum only lists the x86_64 version and the > trace below implies that the 64 bit assembler is being used - this > seems to confirm my initial suspicion about a word length mismatch.) The x86-64 version of the assembler can also assemble 32 bit code. You just have to specify the correct parameter <<SNIP>> > [root@lxstn08 dev]# gpc -v -Wa -m32 hello.pas -Wa by itself does nothing. That parameter means "pass everything after the comma literally as option to the assembler". If you don't add anything, nothing will be passed. Use this instead: -Wa,--32 (including the comma, and no spaces in between) Jonas

4 4

Re: GPC Assembler errors - help needed
by Morton, John 25 Aug '10

25 Aug '10

Thanks to Jonas for the command line option suggestions. With them I am getting only 3 "push" (and no "pop") errors when I use the 2007 version of gpc (the 2002 version would not accept those options). Given that the "with gcc" binary tarballs are intended to be stand-alone I am somewhat surprised that installing 32 bit versions of "all dev packages (including libc-dev)" may be needed. And since I do not come from the C/Linux world (my background is primarily Fortan, Pascal, Ada) I'm not sure quite what is meant by "dev packages" - are we talking only libraries (libc-dev), tools (gcc, gpc, etc.) or something else? And which ones do I need, if any? (The issue may not be important, see below.) First: Am I correct in assuming that the "i686" versions are: a) 32-bit not 64-bit, and more importantly, b) NOT for the iTanium chip? And am I correct in that a true 64-bit wide (x86_64) gpc Linux compiler is not yet available? If so I expect I need to install the i686 version of the "binutils" package. (yum only lists the x86_64 version and the trace below implies that the 64 bit assembler is being used - this seems to confirm my initial suspicion about a word length mismatch.) Or, put another way, have I encountered a hidden assumption/pitfall that the "binary" stand-alone gpc packages expect binutils to always be 32-bits wide? BTW, The application has safety, security, configuration control and legal reasons that preclude the target machines from ever having anything installed that someone can use (e.g. compilers) to compromise the system. All development is done here, all that our field sites ever get are the binary executables in the form of an install package. And FYI, the entire program is: program hello; begin writeln('Hello, world!'); end; Compiling this (as root) using the -v option produced: [root@lxstn08 dev]# gpc -v -Wa -m32 hello.pas Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: ../gcc-3.4.6/configure --enable-languages=pascal Thread model: posix gpc version 20070904, based on gcc-3.4.6 /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.6/gpc1 -quiet -v hello.pas -quiet -dumpbase hello.pas -m32 -mtune=pentiumpro -auxbase hello -famtmpfile=/tmp/ccA5rIAp.gpa -Wa -version -o /tmp/ccALeZVE.s GNU Pascal version 20070904, based on gcc-3.4.6 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Pascal Compiler PreProcessor version 20070904, based on gcc-3.4.6 as -V -Qy -o /tmp/ccKyOQdV.o /tmp/ccALeZVE.s GNU assembler version 2.17.50.0.6-12.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-12.el5 20061020 /tmp/ccALeZVE.s: Assembler messages: /tmp/ccALeZVE.s:9: Error: suffix or operands invalid for `push' /tmp/ccALeZVE.s:37: Error: suffix or operands invalid for `push' /tmp/ccALeZVE.s:51: Error: suffix or operands invalid for `push' [root@lxstn08 dev]# -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 24, 2010 12:01 PM To: GNU Pascal mailing list Subject: Re: GPC Assembler errors - help needed On 24 Aug 2010, at 17:47, Morton, John wrote: > However when I compile the simplest possible "hello world" on RHEL 5.4 > (a fedora variant) I always get the following assembler errors: > > Error: suffix or operands invalid for "push" > Error: suffix or operands invalid for "pop" > > Does anyone know what is causing these errors - and/or a fix for them? This means that GPC is generating 32 bit code, but that it is being assembled as [64] bit code. Try passing the "-m32" parameter to gp/gpc, and if that does not work, try -Wa,-m32. Note that you may have to install 32 bit versions of all dev packages (including libc-dev) that you need, unless those are installed by default. <<SNIP>> Jonas

3 2

GPC Assembler errors - help needed
by Morton, John 24 Aug '10

24 Aug '10

We need to port and upgrade an existing gpc application from 32 to 64 bit Linux. (If you fly anywhere within/to/from North America your flight is indirectly affected - airport delays, etc. - by this application.) Naturally 64 bit gpc is our first choice for this task. However when I compile the simplest possible "hello world" on RHEL 5.4 (a fedora variant) I always get the following assembler errors: Error: suffix or operands invalid for "push" Error: suffix or operands invalid for "pop" Does anyone know what is causing these errors - and/or a fix for them? Background: The development system does NOT have gcc installed (since gcc cannot be installed on the machines that will be running our application). On the dev system I installed the 2002 gpc BINARY (the "gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz" file) from the gnu-pascal.de/binary/ web page. I also tried the 20070904 Linux binary downloaded from brandeis.edu and got exactly the same results. Both downloads are i686 versions. Will these versions work on x68_64 Linux variants? If not what version of GPC should I be using for XEON based systems? 32-bit i586? Or - and as the very, very last resort - should I install gcc 3.4.6 and, heaven help me, attempt to compile GPC from source code? For more details (including results from "gpc -v") see my original post of 2008-10-12 entitled "RE: hello world causes Linux assembler errors". Thanks. John Morton NavCanada Technical Services Centre 280 Hunt Club Road, Ottawa, Ont, Canada K1V 1C1 (613) 248-7184, mortonj(a)navcanada.ca

3 3

Re: Quo vadis, GPC?
by samiam＠moorecad.com 18 Aug '10

18 Aug '10

12 31

How important is GPC for you?
by Peter Gerwinski 17 Aug '10

17 Aug '10

Hello, everyone! Some of you might still remember me. From about 1995 to 2001 I was the main GPC developer who implemented BP-style units, objects, and other things. I am still hosting the GPC web pages, this mailing list, etc. In 1998 I started my own company (G-N-U GmbH, http://www.g-n-u.de) doing business on free software. Our product range includes professional service for GNU Pascal, developing and customizing free software, and other services. For a while, GNU Pascal was a very important tool for my company, which justified that I invested a lot of time and money into it. However, over the years more and more customers addressed me with other needs. Meanwhile, GNU Pascal has reached a point where it needs full-time attention by an experienced GPC developer for several months. 1. The GCC backend is drifting away. Even if we just want to keep the existing language alive, without aiming at extensions, we need to transplant it onto a new, long-time stable backend. 2. It is very difficult for GPC enthusiasts to join the development team, since GPC is written in C rather than Pascal. Realistically, only Waldek, Frank, and/or myself can replace the GPC backend or rewrite the GPC frontend in Pascal without breaking the compiler. However all three of us face the necessity to make a living and thus cannot afford to do that large amount of work just for fun. It needs to be funded. I suggest to concentrate our forces on problem 2 and to rewrite the GPC frontend in Pascal without any backend. This gives you, Pascal programmers using GPC, the opportunity to watch the emerging new compiler and to become a GPC developer. Once this step is completed and the new compiler can represent a Pascal program in memory, the (hopefully enlarged) GPC development team has a free choice which backend(s?) to implement. If GNU Pascal is important for you, please consider to invest into its future by funding our work on GPC. You can contact me either on this list or in private email. Encrypted mail is welcome. Please find my public key at: http://www.peter.gerwinski.de/peter-gerwinski.public-key.asc Greetings, Peter -- Dr. rer. nat. Peter Gerwinski - http://www.peter.gerwinski.de G-N-U GmbH - First Class IT Services - http://www.g-n-u.de German pages for GNU & free software - http://www.gnu.de GNU Pascal - http://www.gnu-pascal.de

10 30

Re: Quo vadis, GPC?
by Steven D'Aprano 14 Aug '10

14 Aug '10

On Sat, 14 Aug 2010 04:17:58 pm Rugxulo wrote: > Hi, > > On 8/13/10, Steven D'Aprano <steve(a)pearwood.info> wrote: > > But we're not discussing what "should be", but what *is*, > > Even if we cared enough to find out (and apparently none of us do, or > don't know who to ask), the way it *is* could change yet again by the > time we finish GPC 2015. Yes. So what? You have to consider the laws as they are *now*, not how they might be some time in the indefinite future. > Besides, like I said, what if your country > doesn't approve of such laws? Then you won't be infringing your own country's laws, and you have nothing to worry about so long as you don't distribute the software in countries where it is infringing. [...] > > and the legal > > reality is that works like P5, even without a copyright notice, > > *are* copyrighted and will remain so for the foreseeable future. > > P5 is Scott's (heavy) modification. I don't know if it's enough to > constitute a whole "new" work or just another derivative. It's a derivative. > He says his work is PD. If he is infringing the P4 copyright, he doesn't have the right to write P5 in the first place, let alone to put it into the public domain. I don't equate copyright infringement with theft, but the analogy sometimes is useful. If you steal a diamond, and put it into a ring, and then give that ring away, the recipient is still receiving stolen goods. The excuse "But Scott said I could have it" is worthless. (The excuse "but I didn't know it was stolen" *might* help, but that's not always a given, and regardless, you don't get to keep the ring.) > And > Pemberton publishes his book online for free now (though he didn't > write P4 himself, right??). That should tell you something, even if > it's not legally airtight. No, it doesn't tell you anything. "You can download this book for free" is not the same as "You can write derivative works from this" or "you can re-distribute it". These are separate rights. > (Scott says several commercial compilers > used P4 as a basis. So apparently they didn't mind!!) Scott has no credibility in my mind. The legal theories he has been promoting in this thread are beyond ridiculous, e.g. the theory that works enter the public domain if you *know about* (not even approve of, or give permission to, but merely *know*) somebody -- anybody -- giving away copies for free. > > That means > > that using such a work puts you in legal jeopardy unless you get an > > explicit licence to use it. > > Right, but who to ask? I assume Pemberton, he should know better than > any of us. But if even he didn't write it, how can we be sure who > did? Ask the author if he is the copyright holder, and if so, what rights is he willing to give. -- Steven D'Aprano

3 2

Fwd: Quo vadis, GPC?
by Rugxulo 14 Aug '10

14 Aug '10

Argh, did it again, sent to wrong address. ---------- Forwarded message ---------- Hi, On 8/13/10, Steven D'Aprano <steve_AT_pearwood_DOT_info> wrote: > > But we're not discussing what "should be", but what *is*, Even if we cared enough to find out (and apparently none of us do, or don't know who to ask), the way it *is* could change yet again by the time we finish GPC 2015. Besides, like I said, what if your country doesn't approve of such laws? It really pains me to hear that such and such is illegal (only) now or such and such a country doesn't follow this or that the U.S. is more strict, etc. Sure, if you think "all the world's U.S./Europe", it simplifies things, but it doesn't truly solve it. > and the legal > reality is that works like P5, even without a copyright notice, *are* > copyrighted and will remain so for the foreseeable future. P5 is Scott's (heavy) modification. I don't know if it's enough to constitute a whole "new" work or just another derivative. He says his work is PD. So we'd only have to worry about the "old" P4 bits. And Pemberton publishes his book online for free now (though he didn't write P4 himself, right??). That should tell you something, even if it's not legally airtight. (Scott says several commercial compilers used P4 as a basis. So apparently they didn't mind!!) > That means > that using such a work puts you in legal jeopardy unless you get an > explicit licence to use it. Right, but who to ask? I assume Pemberton, he should know better than any of us. But if even he didn't write it, how can we be sure who did? > If you, or somebody else, chooses to take that risk, then by all means > do so. Just do so with full understanding that you *are* infringing > copyright, and even if the author is happy to turn a blind eye, the > copyright holder might not be. I have no intention of screwing over anybody. But we're talking about something very small and old. Doesn't mean legal wars haven't been waged on similarly old or small stuff, but still ... it doesn't seem like it's THAT big a deal! > As for the rest of the debate... well, it's too long, too rambling, the > analogies you make are strange, and none of it really matters. Okay, so I ramble, and my analogies suck. Sue me. (Oh wait, that's not illegal.) ;-) > We're > not designing our perfect copyright law, nor are we documenting all the > crazy things people do. We're trying to help Frank decide what the > future of gpc should be. Clearly Scott (who is clearly intelligent) thinks P5 is worthwhile. Frank (also intelligent) would prefer to go another direction. That's his right. The point is that if we want a (classic / standard) Pascal written in Pascal, P5 would probably be a good starting point. Otherwise it might be better just to modify FPC to add an ISO 10206 mode.

1 0

Fwd: Quo vadis, GPC?
by Rugxulo 13 Aug '10

13 Aug '10

Bah, silly reply sent only via private mail (Gmail's fault). I'm not egotistical to expect this post to be worth anything, but here ya go anyways .... ---------- Forwarded message ---------- From: Rugxulo <rugxulo(a)gmail.com> Date: Thu, 12 Aug 2010 23:55:07 -0500 Subject: Re: Quo vadis, GPC? To: Steven D'Aprano <steve(a)pearwood.info> Hi, On 8/12/10, Steven D'Aprano <steve(a)pearwood.info> wrote: > On Fri, 13 Aug 2010 02:26:41 am Rugxulo wrote: > >> It may be true that now all work is by default copyrighted. I'm not >> even sure you can PD software in some countries (ugh). But most >> important is the original author(s)' intent. > > That is possibly the LEAST important factor. What the original author > wants doesn't matter. What matters is what the current copyright holder > thinks, and what the law says. You're right, good point, BUT copyright was never meant to be extended indefinitely. And there are a lot of crazy laws. You can't please everybody, even if you try. It's a minefield. I'm not saying you shouldn't try, but pretending that a law (standard) matters over what most people think (Borland) is naive at best. Some people support the law just because it's the law. Others follow what's good and decent. (Yes, I have an unrelated grudge, heh, stupid law changed much to my disadvantage in an extremely arbitrary way.) For example, I personally disagree that anybody but Terry Welch should've ever had the LZW patent, esp. since it was milked for twenty years AFTER he died!! Somebody please tell me how that's fair. (BTW, I hate software patents, just giving a lame example. If it doesn't help the guy who invented it, what good is it?) >> If they don't care, >> nobody else will. It's not worth arguing over their "rights" when >> they don't care anymore (or never did). > > That's simply not true. What happens when the author dies, and his heirs > inherit ownership of the copyrighted work? What happens when the compiler for the copyrighted work is no longer available? What happens when the OS it ran on is no longer available? What happens when it's no longer available for sale? What happens when the cpu it runs on is no longer mass produced? (See, I can worry too!) What happens if nobody remembers how to use it? What happens if everybody is too busy arguing legalities to appreciate the gift horse (and his mouth or whatever)? > What guarantee do you have > that they will be as easy-going with regard to copyright as the > original owner? Without a licence from the original author, this > becomes a clear and obvious case of infringement. I agree that a clear statement would be best. But if you can't get one, don't worry! No reason to assume the worst if you make a best effort to find out. BTW, many people have rescinded licenses for various things without any good reason. And they scream and yell how they are allowed to push people around. It's disgusting. "Oops, sorry, end users, we don't care about you." Big surprise. It's not the first time nor the last. > What happens if the work was written under the auspices of a university, > which in 1972 was quite happy to let the author publish without a > copyright notice, but in 2010 discover that under the terms of their > employment contract at the time, they actually own the copyright, not > the author? Gross incompetence at best, flagrant misuse of copyright at worst. Lucky for them it wasn't written in some extinct language! (How many existing, popular Pascal compilers can build P4 out-of-the-box? If it's only GPC, then I would find that highly ironic.) > Or what happens if responsibility for enforcing copyright is separate > from the creative act? You can have a situation where the left hand is > explicitly encouraging people to use copyrighted material, while the > right hand is threatening those same people for infringement. Probably a good reason that companies shouldn't get exclusive rights to all their workers' efforts. (How that's even legal is beyond me. What they do in their free time should never be owned by anyone else.) > A recent > case, where the Discovery Channel's marketing department provided > promotional material to a fan website, and the legal department then > threatened them with a lawsuit and forced the owner to hand over > ownership of the domain: Trust me, I know of plenty of similarly crazy cases. I try not to infuriate myself with too much of that. People are crazy and will do crazy things whether it makes sense or not, legal or illegal, etc. The world is broken. > Don't imagine for one second that this is unique. I've even seen cases > where the marketing department of a record label uploaded videos to > YouTube, and the legal department then made DMCA claims and had their > own videos removed. (I can't find the link right now, sorry.) I've seen lots of crazy things too. Yes, big companies are crazy, and the crazy laws that cater to them are just as bad. > I note that you made a quip: > > You know what they say about "assume". > > and then immediately go on to advise us to assume that the absence of an > explicit prohibition against copying a work is the same as permission > to copy. That's terribly irresponsible. Under copyright law, it works > the other way: in the absence of explicit permission, you are legally > required to assume the prohibition stands. Like I said, it's moot here since nobody here (except Scott) is using P4 or P5 for a compiler. BUT, if we were, I would definitely ask Steve P. (and whoever else) for some kind of reassurance. If that failed to get any response, I would not worry and proceed as normal. It's kinda funny that this comes up today. I've had a certain book in my possession for months now because the person I returned it to (so they could return it to their mother, who loaned it to me) accidentally returned it back to me (!) and yet refused to retrieve it! Am I legally bound to return what I already returned, even at my own inconvenience? If so, how fast should I send it? I already told them twice about it, and they gave me the runaround. I finally just said, "Forget it, I'll mail it directly." Had to do it myself, they weren't responsible enough to do it! (Note that this book was only $15 new, which is very small claims at best. How much is a compiler [or more specifically, P4] worth to you??) I also had some really old baseball cards I assumed for YEARS belonged to a distant family member, but that person never stayed in contact with me. (I am much younger.) I never could even confirm whose they were, much less what to do with them. I finally shipped them off to the "nearest" other relative I could find. Legally, I have no idea what I would be required to do, but I did my best to be fair (even if it took like twenty years, and note that I'm only 31, heh). So yes, I do indeed care, but often times it's worrying over nothing. If nobody complains about something you ALREADY have in your possession, why would they complain once you do something with it? (Did Pemberton's publisher care to get the original authors' explicit permission? If they didn't care, why should we? For laughs???)

3 2

Quo vadis, GPC?
by Objective Modula-2 13 Aug '10

13 Aug '10

Frank Heckenbach wrote: > since GPC development has mostly stalled, I've thought about if and > how its development could be continued. Here are my current thoughts > about it. Since the text is quite long, I put it on the web: > http://fjf.gnu.de/gpc-future.html Although I no longer use Pascal, I would like to make a plea for GNU Pascal to be sustained. Generating C (or even C++) as an alternative target is certainly a useful feature for any compiler to have but if GPC was to lose its interface to the GCC back-end, I wonder if it would still be GNU Pascal. I believe most people associate GCC back-end support with any compiler that carries the GNU moniker. Don't get me wrong, I am not a GNU fanboy nor a GCC zealot. I know that developing for the GCC back-end can be painful. Nevertheless, I believe it would be a loss for the Algol/Pascal family of languages and their users to see Pascal disappear from the list of supported languages in the GCC toolbox. It is correct that the existing code will remain available but without maintenance, GNU Pascal would eventually cease to work with the latest GCC distribution. GNU Modula-2 is now very close to its 1.0 release at which point it is expected to become part of the main GCC distribution. It would be sad to see Pascal leave the GCC party just as Modula-2 joins. It is not uncommon that a project maintainer burns out after a decade. Nobody can blame you for that. Perhaps somebody else can be found to take over the project and continue it. As for retargeting GNU Pascal, I personally would consider that a new project. How much sense it would make to reuse the GNU Pascal front end for a new compiler project to target a different back-end I am unable to say. However, I can comment on targeting the LLVM compiler infrastructure. First, some clarification. Some posters appear to be confused about what LLVM is. For example, I saw one commenter writing "I am not interested in programming in ... LLVM". The LLVM compiler infrastructure is not a programming language you would write programs in. Instead, it is a compiler-back end library that compiler developers can use to plug their compilers into thereby saving themselves the effort to write their own target specific back-ends and optimisers. Compared to using the GCC back-end, LLVM is far more straightforward. There are two ways to interface to it. You can either use the C or C++ bindings and generate your LLVM AST directly from within your own parser, or you could write a back-end for LLVM pseudo-assembly code which is actually far cleaner than C or C++. It is a typed virtual assembly language that has atomic intrinsics and trampolines and a lot of other useful things. I am currently involved in a Modula-2 compiler project that targets C and LLVM (via the LLVM pseudo-assembly language). We are using a template approach for code generation and for each AST node a corresponding C or LLVM template is populated with the details from the AST node. So far code generation has only been in an experimental stage but I can already tell you from this experimental experience that targeting LLVM is certainly far more straight forward than targeting the GCC back-end. It would certainly be nice to see a Pascal compiler targeting LLVM but as I said, this should probably be considered a new project and no longer GNU Pascal. Even with an LLVM Pascal compiler available, I still believe it would be beneficial to sustain GNU Pascal (as a Pascal compiler targeting the GCC back-end). Anyway, good luck to you and the GNU Pascal community -- Projects mentioned in this post: GNU Modula-2 (http://www.nongnu.org/gm2) LLVM Compiler Infrastructure (http://llvm.org) Objective Modula-2 (http://objective.modula2.net) Modula-2 R10 (http://www.ohloh.net/p/m2r10)

8 25

Re: D (was: Quo vadis, GPC?)
by Frank Heckenbach 13 Aug '10

13 Aug '10

Bastiaan Veelo wrote: > We have an extensive code base of Extended Pascal that is in active use > commercially, and we will continue development in many years to come. We > are using the Prospero compiler, which is still serving our needs. But, > as Prospero is Windows-only, gpc has always appeared as the most > promising escape route to portability, should we need it. Therefore I am > hoping that gpc will find its way into the future. > > I have a small contribution to the discussion. Regarding the suggestion > of turning gpc into a translator to some other language, I would suggest > considering the D programming language as the target language, instead > of C++. I have been following the development of D for many years, and > have always seen similarities between Extended Pascal and D. Off the top > of my head there are nested functions, modules, function argument > storage classes, better type safety than C++, dynamic arrays with size > information, and fast compilation (especially compared to C++). There > may be more similarities. D's template design is also much better than > C++'s, as is its approach to const-correctness and its alternative to > multiple-inheritance. D is designed to be a better language than C++, > and I think it is. I think that of modern languages D is most compatible > to the way Pascal programmers like to think (pardon the generalization) > and although its syntax is C++-inspired, D might be a good candidate to > "take over" from Pascal. If gpc would do a good job at generating > readable D code, Pascal programmers could choose to continue writing > Pascal or make the switch to D completely and be happy with it. > > Some pointers: > http://en.wikipedia.org/wiki/D_%28programming_language%29 > http://www.digitalmars.com/d/ As for the main features as listed in the Wikipedia article: - some are mainly library issues or can be addressed as such, including associative and dynamic arrays (e.g. map and vector in STL) or array slicing (not sure if STL currently provides this, but it could), - some of the mentioned improvements actually exist in C++ such as inner classes and the previously mentioned STL types, - some things will be addressed in the planned C++0x standard (http://en.wikipedia.org/wiki/C%2B%2B0x), e.g. foreach-like loops, better metaprogamming including compile-time function execution, and anonymous functions, including nested ones and closures, - some things I don't necessarily see as advantages for our purposes, e.g. automatic gargabe collection (on a (Pascal) language level, I think we should leave the choice to the user), or limited multiple inheritance (though I hardly need the full version myself, but if we choose to implement just the limited form, we can do it equally well in C++ and D, since it's a strict subset of the full version; but if we, now or later, decide we want the full form in some object model, C++ has it), - for some things the description there is too vague, e.g. "reengineered template syntax" (the example doesn't tell me much -- however, if it's only about syntax, it doesn't matter much for a target language anyway) or the inline assembler (g++ has one, I have no idea if D's is better or worse -- mostly likely it won't be (CPU-)portable (quite hard for assembler code ;-), and apart from that, I see no major drawbacks in the g++ inline assembler (same as that in gcc and gpc), except maybe from syntax (irrelevant, see above); in particular it cooperates well with the optimizer which is not true of many other inline assemblers I've seen, in particular BP's, even for that tiny bit of optimization that BP has), - so only a few things are left that are clearly advantages in my view, e.g. true modules and first class arrays. (Though modules are not such a big issue for a compiler-converter either; converting to C++ style "compilation units" and headers is not much more difficult, and the more tricky part -- processing modules in the correct order WRT dependencies -- has to be done in the frontend anyway; this is what "gp" currently does which could partly be reused as well.) But most importantly of all (IMHO), D doesn't seem very widespread. Maybe this will change. However, since one root of our problems is really that Pascal isn't so widespread (anymore), I'm reluctant to base its renewal on another language whose long-time future is also in doubt AFAICS. Honestly, if I had to bet on the futue of D vs. C++0x, I'd take the latter, even if it's still in the standardization process, just because of the mass of existing C++ code and compilers. (And even if C++0x fails, the fallback to the existing C++ standard is soft, whereas a failure of D a few years from now when we have based our new compiler on it would be fatal.) Of course, for manually (or semi-automatically) converting your Pascal programs to another language if GPC has no future, D might be a good choice. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

13 48

Backspace on a Mac with GPC doesn't work - why?
by Tom Schneider 13 Aug '10

13 Aug '10

Here's a puzzle in the from of a program. Regards to all! Tom program inout (input,output); (* version = 1.01 of inout.p 2010 Aug 12 2010 Aug 12, 1.01: testing on Sun 2010 Aug 12, 1.00: origin on mac Thomas D. Schneider, Ph.D. National Institutes of Health Gene Regulation and Chromosome Biology Laboratory schneidt(a)mail.nih.gov http://alum.mit.edu/www/toms (permanent) Test input string in GPC. The program reads one character from the user at a time. If the user types the wrong character and wishes to correct it, then they should be able to type control-H (^H) or delete and correct the input. This works with GPC on a Sun computer, but on a Mac OSX (10.6.2) one instead sees '^H' and no backspace occurs. What can be done at compile time to make backspace work on the Mac? ******************************************************************************** On a Sun computer: % inout h the character was h u the character was u b the character was b z the character was z a the character was a b the character was b q the character was q Backspace (control-H) and delete work as expected. On a Mac: % inout a the character was a abcd the character was a abcd^H^H^H^H^H^H^H^H control H or delete gives same^H^H^H the character was a q the character was q Backspace (control-H) and delete do not work. *) var n: char; (* a character from the user *) begin n := ' '; while (n <> 'q') do begin readln(input, n); writeln(output, 'the character was ',n); end; end.

2 3

Pascal for Python extensions
by Andrew Gregory 13 Aug '10

13 Aug '10

I've been following the debate with some interest - although I'm no expert on compilers. My work involves a lot of data processing, for which I use Python scripts from which I can call functions coded in Pascal (and other languages). The interfacing works as follows: Pascal modules are linked statically to some C interface code (which converts Python objects to/ from C types). The C interface code is compiled to Python compatible DLLs, which can be imported directly into Python. I'm sure there are other ways to achieve the same end (and it would be nicer to be able to do the conversion to/from Python objects in Pascal) - but it works. I use the MinGW compiler to compile my code. The extensions work with the standard (MSVC) Python distribution. As long as there is a straightforward means of creating Python binary extensions from Pascal source code I'll be happy - but since Python is written in C the C++ solution sounds more promising, so I will vote for that. Andrew. http://www.npl.co.uk/materials/ http://www.npl.co.uk/electromagnetic/ ------------------------------------------------------------------- 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: Serco House, 16 Bartley Wood Business Park, Hook, Hampshire, United Kingdom RG27 9UY -------------------------------------------------------------------

3 3

Re: "hello world" causes Linux assember errors
by Morton, John 12 Aug '10

12 Aug '10

First, everything in this message occurred while logged in as "root". I think I've installed the compiler properly but the assembler always reports errors for "push" and "pop". Sample messages and the results when compiling with the -v option can be found below. The platform is a HP xw8200 (Xeon) machine running 64 bit Red Hat Enterprise Linux Desktop, probably release 5.2. On this system "uname -a" produces: Linux lxstn08 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux gcc was not installed on this system when gpc was loaded. Using the web page instructions for binaries at http://www.gnu-pascal.de/binary/ I installed the "gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz" file into the standard location. After gpc was installed "man gpc" worked and "gpc -v" says: gpc version 2.1 (20020510), based on 2.95.2 19991024 (release). So far so good. Now the problem: Compiling the absolute minimum version of "hello.pas" (1 writeln statement) produced ~15 assember error messages, a mixture of: Error: suffix or operands invalid for "push" (and/or) Error: suffix or operands invalid for "pop" messages with about 4 times more "push" than "pop" messages. Any ideas about how to fix this problem? BTW, Although a 64 bit executable would be much preferred a 32 bit target that can run under 64 bit RHEL would also work for us. ----- BACKGROUND INFO For safety, security, and configuration control reasons changing the RHEL components is not allowed. But installing applications (e.g. gpc, vnc, Open Office) that do not affect the O/S is OK. "man as" says that binutils contains the portable Gnu assember. My first thought was a 64/32 bit word length mismatch in a library, the compiler or the assembler. The "yum" results are at the end of this message. Using the "-v" option produces (with <CR>s inserted for clarity): # gpc -v hello.pas Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 2.1 (20020510), based on 2.95.2 19991024 (release) /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpcpp -lang-pascal -v -famtmpfile=/tmp/ccL8ikKt -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__=2.1 -D__GPC_RELEASE__=20020510 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ hello.p /tmp/cc3waT7h.i GNU Pascal Compiler PreProcessor version 2.1 (20020510), based on gcc-2.95.2 19991024 (release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/i686-pc-linux-gnu/include /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include /usr/include End of search list. /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 /tmp/cc3waT7h.i -quiet -dumpbase hello.pas -version -famtmpfile=/tmp/ccL8ikKt -o /tmp/cc3waT7h.s GNU Pascal version 2.95.2 19991024 (release) (i686-pc-linux-gnu) compiled by GNU C version 3.3.3. GNU Pascal version is actually 2.1 (20020510), based on gcc-2.95.2 19991024 (release) as -V -Qy -o /tmp/cc3waT7h1.o /tmp/cc3waT7h.s GNU assembler version 2.17.50.0.6-12.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-12.el5 20061020 /tmp/cc3waT7h.s: Assembler messages: /tmp/cc3waT7h.s:14: Error: suffix or operands invalid for `push' /tmp/cc3waT7h.s:18: Error: suffix or operands invalid for `push' ... (about ~14 more "pop" and "push" error messages) --- The man page for "as(1)" does not list the options -V or -Qy (used above). Also odd is that the "/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2" folder contains "collect2" instead of "collect" - and that the file "/lib/crt[01n].o" does not exist on this system (or is the "gpc" man page out of date?). I have downloaded but not installed the "gcc-core-2.95.2.tar.gz" compiler (from http://www.gnu-pascal.de/stable/). As suggested by the mailing list archives I have also downloaded a newer version of gpc and gcc from http://alignment.hep.brandeis.edu/Software/Pascal/Index.html (by using the "Linux binary", "GCC 3.4.6" and "GPC 20070904" links on that page). I then untarred gcc 3.4.6 into it's normal location (but "man gcc" and "gcc" still do not work). I have not yet tried installing the newer version of gpc. yum reports the following packages as installed: binutils.x86_64 2.17.50.0.06-12.el5 (missing i386 version?) glibc.i686 2.5-42 (instead of i386 version?) glibc.x86_64 2.5-42 glibc-common.x86_64 2.5-42 libgcc.i386 4.1.2-46.el5 (i686 version needed?) libgcc.x86_64 4.1.2-46.el5 <EOM>

1 0

Re: Vector arithmetic
by Contestcen＠aol.com 11 Aug '10

11 Aug '10

When I first started using FPC, I went through the manuals looking for useful features. I came across both open arrays and dynamic arrays, and thought that they might be valuable. But nowhere could I find any notation for the second, third ... dimension of the array. Without that, open and dynamic arrays were little more than curiosities, possibly useful for 1-dimensional array, but not beyond. Now I see from your email that the notation for the second dimension of an array is Length(xarray[i]) where i is any valid index value (and hence can always be 0). By extension, the third dimension presumably would be Length(xarray[0,0]), and so forth. Never, ever, would I have guessed that would work. It makes sense mathematically, but notationally I would have expected something like Length(xarray,2) for the second dimension. If I had thought of Length(xarray[0]), I would have deemed it so implausible that I never would have tried it. But simply because this is feasible does not mean that one should use it. For one thing, I would like the compiler to generate warning messages if I try to add two matrices of incompatible sizes. I don't want to discover this hours into a computation. That type of checking is one of the main virtues of Pascal. For another, it requires that I code a SetLength statement for every array. That means the array information becomes decentralized. I can't just read down the VAR section of my procedure and learn what I need about the variables, I must consult two sections. Of course I wouldn't have to make every array open, but then I would have a mixture of two kinds of array declarations. This creates an extra maintenance task, making some arrays open, when needed, and restoring them to fixed size when they no longer need to be open. The problem could become fierce when the same declarations are shared by several different procedures. Which one should set the length? How can I be sure the length is set before I reach MyProc? So, once again, I throw my support towards adding vector operations to the compiler. Frank Rubin In a message dated 8/6/2010 12:23:25 P.M. Eastern Daylight Time, harley(a)umich.edu writes: Dear Frank Rubin, "Except that you have to code every single case separately, 2x6, 3x10, 4x4x4, etc. You need to write a separate routine for every shape of array you want to use." Not so: Use open arrays (always 0-based): type Matrix = array of array of TRing; Youu can write code, roughly: operator * (const A, B: Matrix): Matrix; var RowA, ColA, RowB, ColB, I, J, K: Integer; T: TRing; begin RowA := Length(A); ... ColB := Length(B[0]); if ColA <> RowB then ... SetLength(Result, RowA); for J := 0 to RowA - 1 do SetLength(Result[J], ColB); for I := 0 to RowA - 1 do for K := 0 to ColB - 1 do begin T := Zero; // prefer just 0 for J := 0 to ColA - 1 do T := T + A[I, J]*B[J, K]; Result[I, K] := T; end; end; once and for all, covering all sizes of matrices. The problem I do not yet know how to solve: to do it for all TRing. So I need a type TRing that can include any structure that has + and * operators, and a 0 element: Integers, Floats, Rationals, Gaussian Integers, Polynomials with xxx coefficients,... any possible data type I can define with overloaded +, *, etc. Note that 0 is a problem in itself -- one really needs to overload it too! Frank Heckenbach's first reply to me may contain the answer. I haven't completely digested it yet. Cheers, Harley

3 4

Re: Vector arithmetic
by Contestcen＠aol.com 10 Aug '10

10 Aug '10

> Do not built things into the compiler (or ask for them) that can be > done outside of it. Building in things is many times as much work. > Maybe I haven't stressed this enough so far because it's so obvious > to me, but not to those who haven't worked in the compiler. I understand, but the balance changes when 10 people, or 100 or 1000 people need to do the same thing. Which is more work, a compiler writer making a hard change, or 100 people each writing a set of relatively straightforward code? That's why we try to identify features that will be widely used, such as vector arithmetic. FPC already supports assignments of vectors and arrays, so why not addition and subtraction? It builds on a capability that the compiler already has. Frank Rubin

3 2

Re: Vector arithmetic
by Contestcen＠aol.com 09 Aug '10

09 Aug '10

(Oops, I hit Send before I hit the control that removes the HTML tags. Please excuse the error. Here is the cleansed message.) I see. How would that work? Can you give me an example of a routine that would, for example, add arrays of long integers and could handle the 3 cases that I mentioned? Would it also handle arrays of bytes? arrays of words? arrays of reals? Would I need to repeat the same for multiplication? for xor? for string concatenation? for modular arithmetic? for 96-bit arithmetic? for quaternions? for division rings? A general vector facility would be a great work saver, even if it did nothing regarding parallel execution. In a message dated 8/6/2010 3:16:27 A.M. Eastern Daylight Time, felipemonteiro.carvalho(a)gmail.com writes: On Fri, Aug 6, 2010 at 8:35 AM, <Contestcen(a)aol.com> wrote: > Except that you have to code every single case separately, 2x6, 3x10, > 4x4x4, etc. You need to write a separate routine for every shape of array you > want to use. Or you could use dynamic arrays instead of static ones. Then you can write only one case. -- Felipe Monteiro de Carvalho

1 0

Re: Vector arithmetic
by Contestcen＠aol.com 09 Aug '10

09 Aug '10

I see. How would that work? Can you give me an example of a routine that would, for example, add arrays of long integers and could handle the 3 cases that I mentioned? Would it also handle arrays of bytes? arrays of words? arrays of reals? Would I need to repeat the same for multiplication? for xor? for string concatenation? for modular arithmetic? for 96-bit arithmetic? for quaternions? for division rings? A general vector facility would be a great work saver, even if it did nothing regarding parallel execution. In a message dated 8/6/2010 3:16:27 A.M. Eastern Daylight Time, felipemonteiro.carvalho(a)gmail.com writes: On Fri, Aug 6, 2010 at 8:35 AM, <Contestcen(a)aol.com> wrote: > Except that you have to code every single case separately, 2x6, 3x10, > 4x4x4, etc. You need to write a separate routine for every shape of array you > want to use. Or you could use dynamic arrays instead of static ones. Then you can write only one case. -- Felipe Monteiro de Carvalho

1 0

Vector arithmetic
by Contestcen＠aol.com 08 Aug '10

08 Aug '10

> For your information: that already exists in FPC. It's called operator overloading: > > http://www.freepascal.org/docs-html/ref/refch12.html#x161-16800012 > > -- > Felipe Monteiro de Carvalho Except that you have to code every single case separately, 2x6, 3x10, 4x4x4, etc. You need to write a separate routine for every shape of array you want to use. Frank Rubin

4 3

Re: [GPC]: Ada
by Pascal 07 Aug '10

07 Aug '10

Hello Adriaan. Few years ago, Mac Pascal Interfaces were translated into Carbon-Ada. You can found them on www.macada.org. Basically Ada 2005 is supporting all modern object oriented paradigmes : classes as package + tagged record, multiple inheritance with interfaces (as Java), static and dynamic binding... Would be the translation of Cocoa Interfaces into Ada achievable? What would be necessary ? Anyway, I'm really interesting in "such thing like Objective-Ada" and contributing if I can help. Regards, Pascal. http://blady.pagesperso-orange.fr Le 5 août 10 à 09:46, gpc-owner(a)gnu.de a écrit : > De : Adriaan van Os <gpc(a)microbizz.nl> > Date : 5 août 2010 09:01:36 HAEC > À : gpc(a)gnu.de > Objet : Rép : Ada (was: D > > > But there is no such thing like Objective-Ada, is there ? That > would be a clear disadvantage of Ada as an intermediate language. > > Regards, > > Adriaan van Os

2 1

pascal code for numerical computations
by Leo Brewin 06 Aug '10

06 Aug '10

Hi, I'd like to put in my 2 cents worth for GPC. It is fantastic! I've been using GPC for the past few years and it has been an invaluable aid to my productivity. It meets all my needs (most importantly the support for conformant arrays and modules). My main area of research is in numerical general relativity and I have taught numerical methods to science students for a number of years. With the current lively discussion on the future directions of GPC I though it would be good time to make my own contribution by way of making some of my code available. It's a collection of numerical codes covering a range of standard numerical methods (root finding, interpolation, integration etc.) as well as some more advanced methods (multigrids, adaptive integrations, improper integrals, boundary value problems, genetic algorithms and so on). You can find the code at http://users.monash.edu.au/~leo/software/pascal/files/GPCExamples.tar.gz More information can be found in the README.txt in the parent directory. Cheers, Leo Brewin School of Mathematical Sciences Monash University Australia

2 1

For the wish list: Vector Arithmetic
by John L. Ries 06 Aug '10

06 Aug '10

Fortran 90 and later allow arithmetic operations on whole arrays, like so: !Both arrays must be the same shape integer foo(37), doublefoo(37) doublefoo=foo*2 This is actually a highly useful feature as it reduces the need for looping (a common place for bugs to hide) and allows array operations to be distributed over multiple processors, if available. In Pascal, the above might look something like this: var foo, doublefoo: array[1..37] of integer; {...} begin {...} doublefoo:=2*foo; {...} end. --------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

4 7

Quo vadis, GPC?
by Frank Heckenbach 06 Aug '10

06 Aug '10

Hi everybody, since GPC development has mostly stalled, I've thought about if and how its development could be continued. Here are my current thoughts about it. Since the text is quite long, I put it on the web: http://fjf.gnu.de/gpc-future.html As I write there, I don't see much future in the current way of developing GPC, but also alternative development models will not be a task for a single person. In other words, without some new contributors, there is probably no chance for GPC development to continue. I don't really know how many of you currently use GPC, and to what extent and in which ways, e.g., do you use it just to maintain some legacy code, or are you actively writing new applications? So in order to tell whether continuing GPC development is worthwhile, I'd like to know who of you would actually care about major new features in GPC (as opposed to just preserving the status quo), and who would be interested not only in using GPC, but also supporting its continued development, either by actively contributing to it, or -- perhaps in the case of companies that use GPC -- by paying for continued development. If it turns out there is no sufficient amount of interest, I'm afraid to say it's probably better to put an end to it now rather than further dragging along. (Of course, the existing GPC versions will continue to be available, and anyone who wants to can use and modify them, which the GPL already guarantees, but without prospects for the future, I would then retire from GPC development and start to rewrite my own Pascal programs in other languages.) Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

26 98

Pastel compiler (GCC's predecessor)
by Rugxulo 05 Aug '10

05 Aug '10

Okay, somebody mentioned the Pastel compiler (Pascal-ish, compiled itself) that was the original basis for RMS' hacking. He wrote his own C frontend and that later became GCC proper. It's very hard to find info on this, so I'm pasting here my recent findings for ya. (Note that I know less than probably anybody about this. I'm no knowledgeable insider or anything!) In particular, GCC's history and Wikipedia seem to omit mention of most of this. Somebody should also probably e-mail RMS to ask if he still has a copy of the sources around somewhere (interesting to me, at least, and I'm just vaguely curious!). "Jeff Broughton, then Amber project leader, implemented two extended Pascal compilers. The extended language was named Pastel (an off-color Pascal). A complete compiler targeted to the S-1 architecture was completed in several months. However, the first version of the compiler, which was implemented in slightly more than a weekend, produced PL/1 as its output! This was done to allow the continued use of Multics, which had no Pascal compiler, as the development site for Amber. At that point the project had a couple of man-years of code written in PL/1. The conversion of all PL/1 code to Pastel was accomplished in about 3 man months. (1998 historical note: at one point in the project Richard Stallman visited, and had the Pastel compiler explained to him. He left with a copy of the source, and used it to produce the Gnu C compiler. Most of the techniques that gave the Gnu C compiler its reputation for good code generation came from the Amber Pastel compiler.)" http://www.mit.edu/~cbf/thesis.htm http://killian.com/earl/ http://www.lbl.gov/cs/CSnews/CSnews073109a.html http://en.wikipedia.org/wiki/PathScale

2 3

Rewriting Pascal
by Prof. Harley Flanders 04 Aug '10

04 Aug '10

To Frank H. and all Pascal re-writers: One of the main, if not the main, point of keeping Pascal updated is to extend its usefulness. I want to address one area: scientific programming. It is what I do; I have done it in Pascal for vary many years, and continue doing so in Delphi. I even wrote a book, "Scientific Pascal", in 2 editions. So here is my wish list: Add types Complex Rational coded in assembler. All the standard operations and functions should apply to these types: Complex: +, -, *, /, ^ or ** Sqr, Sqrt, Sin, Cos, ..., Exp Ln Rational: +, -, *, /, Sqr, LowestTerms,... Even 40-year old FORTRAN has complex types. Obviously Complex is needed for numerical analysis, differential equations, electrical engineering, etc. A rational type would be very useful for number theory. Add higher precision floats (20 bytes, 24 bytes, user-chosen precision) again with all the standard operations and functions implemented in assembler. Borland introduced type Extended (10 byte floats), possibly in Turbo Pascal 4 or 5. This was an enormous improvement over the Real type, (4 byte), and made full use of the 80x87 mathematical coprocessor. Extended has remained the highest precision f.p. type in Borland Pascal and probably all other Pascals for 15-20 years, while computer speed and memory have improved by orders of magnitude. It is surely time for more accurate real types, coded in assembler. The current real types (in Delphi) are Single (4 bytes), Real48 (6 bytes), Double (8 bytes), Extended (10 bytes), [and Comp and Currency]. Synonyms are in order,skipping the factor of 8: Real4, Real6, Real8, Real10, etc. for the hopefully new ones. It is also time for more accurate integers. Borland introduced Int64 10-20 years ago, and it has remained the standard highest accuracy integer type. Delphi wisely added the names (and unsigned types) Int8, Int16, Int32, Int64, UInt8, UInt16, UInt32, UInt64. (My preference again would be to drop the factor 8: Int1, Int2, Int4, Int8, UInt1, UInt2, UInt4, UInt8.) I would love to see Int16, Int32, Int64 and Int128, and their unsigned counterparts. Add exponentiation, with the symbol ^ or ** overloaded for the special cases of the exponent: positive or negative integer [ (-0.02)^(-3) = -1.25E5 ], rational with odd denominator [ (-8)^(5/3) = -32 ]. FORTRAN and even BASIC have had exponentiation forever. Allow genuine operator overloading, such as operator "+" (const X, Y: MyType): MyType; operator "*" (const X: Integer; const Y: IntegerVector): IntegerVector; Delphi has made a mess of this so far, with overloading only possible with class functions and records. GNU Pascal and Free Pascal do much better. It should be possible to overload all the standard operators: + - * / ^ = <> <= >= > < There should be an abstract classes TRing which can be specialized to TField, etc. TRing should have a Ring Element that can be specialized. So one could define TMatrix, with elements in TRing, and define matrix multiplication A*B and Det (determinant) without specifying the elements in advance, and specialize them to any ring, such as the rings of rationals, of polynomials with complex coefficients, etc. This is what OOP, polymorphism, abstraction, inheritance should be about. Add Print Methods for TMemo, TStringGrid, TImage, and maybe a few other components. Obviously if I compute data and store it in a table or memo, or create a graph, I want to print it. Currently this requires searching the WWW for someone's code. One of the advantages of unicode (see below): one can mix alphabets in tables. For instance a table of number theoretic functions will have Greek headings: Omega, Phi, omega, etc. Any modern Pascal should use unicode, with all character and string procedures modified accordingly. This is a big advance Delphi started a year or so ago Add some more fonts that include Greek letters and many math symbols, and which can be easily added to code (which should be WYSIWYG). Fonts for scientific use should be non-justified, so that "9", "1" and "." are the same width in displays of numbers. As far as I can tell, Courier New (OEM CharSet) is the only satisfactory font at present. Harley Flanders -- ============================= Prof. Harley Flanders 3533 Windemere Court Ann Arbor, MI 48105-2867 Home: 734 668 1546 harley(a)umich.edu =============================

6 9

Re: Quo vadis, GPC?
by samiam＠moorecad.com 03 Aug '10

03 Aug '10

Frank heckenbach wrote: >samiam(a)moorecad.com wrote: >> P5 is a much better basis for a compiler front end, being 40 years >> old, very well documented, and completely ISO 7185 compliant (not a >> subset), and completely free of copyright or license encumberments. > Where is the copyright/license/public domain statement from its > authors? I didn't find them in p5.zip from your web site. Note that > "no copyright notice" doesn't mean "no copyright", but in fact the > opposite "all rights reserved" is the default. Like it or not, > that's the legal situation. Only since the Berne convention was adopted. Pascal-P predates the Berne convention (in the USA, I guess it depends on where and which treaty you are talking about, Berne dates back to 1886)[1], it was written in 1972. It was also openly distributed to anyone that asked for it. Steve Pemberton published it without problems (or agreement with the original authors) in his book, and made it available on his web site, again without restrictions (and I asked the author about it personally). You could also ask Wirth about it, but I don't suppose it would make a difference, since he didn't personally write it, his students did. Neither the old nor the new united states copyright laws specifically stated what the exact meaning of public domain was. The former law simply stated that copyright didn't apply by default, but the berne convention says it does. In any case, the courts have weighed in on the subject, and ruled time after time that works given out freely and freely published loose any copyright status. In fact, I have yet to see a single example of a work that was freely given out by the author, but later retracted and successfully sued over (note patents are a completely different subject). However, its not really my office to talk you into anything here, just point out possibilities. Scott Moore Berne convention: [1] This Convention shall apply to all works which, at the moment of its coming into force, have not yet fallen into the public domain in the country of origin through the expiry of the term of protection. US "Berne Convention Implementation Act of 1988" Sec. 12. Works in the public domain. Title 17, United States Code, as amended by this Act, does not provide copyright protection for any work that is in the public domain in the United States.

4 4

Re: Quo vadis, GPC? PL features for compiler
by Frank Heckenbach 03 Aug '10

03 Aug '10

spir wrote (by PM, but I supposed it was meant for the list): > > Yes, it's possible, but it's IMHO not conformtable. I know I'm > > repeating myself, but I'm really fed up with having to "reimplement > > the list", as I wrote. It's also a psychological thing IMHO -- if > > advanced data structures (objects, trees, hash tables) are readily > > available (as in C++), you tend you use them when useful; if they're > > not (as in Pascal, except for objects), you're much more likely to > > do quick ad-hoc work-arounds, which affect the efficiency, but also > > the design of your program, especially in the long run. GCC's > > TREE_NODEs are a particularly bad example of this, spreading all > > over the code, but also in my Pascal programs, I often find a lot of > > ad-hoc list (or other structures) handling code that obscures the > > actual purpose of my code and thus make it harder to understand > > later. > > This very clearly shows how much a (fully flexible and generic) > sequence type is a fondamental feature for any general-purpose > language. Thus, it must be part of new-GPC (meaning also > prerequisites such a generic & referenced types); then, we have > them available to write the new-GPC compiler in new-GPC ;-) I'd say not only simple lists (sequences), also hash tables, vectors (dynamic arrays) and trees are data structures I use regularly and would like to have readily available. > I take the opportunity to ask a side-question: is there a logical > or practical link between compiler target and implementation > languages? For instance, provided GPC's feature set is good enough > (see above) to write a compiler comfortably, At the moment it isn't yet WRT the above features. That's the chicken and egg problem I referred to. Either one uses C++ initially (which has the features) to implement a new compiler with the features and then ports the compiler to Pascal, or one uses the existing GPC to write the new compiler in a more awkward way and later cleans it up when it's self-hosting. Kevan Hashemi wrote: > I guarantee you that's the case for me. I read through Bison and I liked > it very much, and I am thoroughly convinced of its merit by your ^C > example. But my first look through the Bison manual page suggested that > the output was a C program that we would then compile and link to, which > means that at least part of our Pascal compiler would be written in C. The Bison output basically consists of generated tables (which are mostly numbers), and a fixed parsing algorithm that uses these tables which is more or less verbatim copied from a template file. It provides several such templates, the basic C algorithm, a GLR algorithm (that parses a larger class of syntax, which GPC requires) also written in C, and one in C++. So it's possible to add a Pascal template as well. Of course, it would have to be written (probably by us), which is some work -- though probably minor compared to the rest of the compiler, and of course, a one-time job, independent of grammar changes, and it would be useful to Pascal programmers who'd like to implement their own parsers. > Given the extent of my inexperience, but at the same time my eagerness > to help, perhaps you could explain to me how we could use Bison on the > way to a self-compiling Pascal, or how the C-code output of Bison (if > that's indeed what it puts out) could be part of the project in a way > that left us independent of the GCC back-end problems. It's nothing to do with backend problems. A newly written compiler implemented in C(++) with a non-GCC target (whether C++, Ada or LLVM) could still use Bison as is. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Re: Quo vadis, GPC?
by samiam＠moorecad.com 03 Aug '10

03 Aug '10

1 0

Re: Quo vadis, GPC? (Managing by license)
by Objective Modula-2 03 Aug '10

03 Aug '10

John L. Ries wrote: > Such a policy would seem irrational to me, as I fail to see any real benefit > to the project, but it's possible I'm misunderstanding something. I didn't say it was policy. I said it has an influence. Many of the developers think that GCC can and should compete on technical merit alone, but a there are those who think that the design needs to protect the license. Sometimes decisions lean in one direction, sometimes they lean in the other direction. Both these groups have an influence. The decision of whether or not to introduce a plugin interface was certainly made at the highest level at the FSF, so you may want to consider than a matter of policy. But many decisions are made further down and they shouldn't be considered matters of policy. There was another incident many years ago where a developer had created a GCC to JVM translator or vice versa and was about to donate his code to the FSF. Richard Stallman was outraged and he trounced this poor guy in public, asking him to destroy his code so it would never leak anywhere. Clearly there is an influence of the school of thinking that says design has to follow the license. I wouldn't call it policy, but the influence is there.

2 1

Re: Quo vadis, GPC? (Community Survey)
by Prince Riley 02 Aug '10

02 Aug '10

Hello everyone, Frank's excellent post raises several issues about GPC that have been nagging at me for quite some time. As I read his post I began to understand several of the issues from the development/maintainers standpoint. There broad range of issue and concerns surrounding the future direction of GPC needs to have some refinement to provide the user community a clearer idea of the priorities and to help summarize their ideas for the maintainers. Perhaps a well structured online survey would both encourage greater response by the user community and make those ideas and opinions more accessible. I'm willing to take on the task of designing a draft user community survey, and making it accessible. Comments on this idea would be most appreciated. Prince Riley >

2 1

Re: Quo vadis, GPC?
by samiam＠moorecad.com 02 Aug '10

02 Aug '10

1 0

Rép : Ada (was: D (was: Quo vadis,
by Pascal 31 Jul '10

31 Jul '10

Hello. My background came deeply from Pascal language before I discovered Ada which provides last modern object programming with last standard Ada 2005. Just as you mentioned them, Ada provides Pascal like range checking, exceptions, generic and more: native tasking model and much more, see http://en.wikibooks.org/wiki/Ada_Programming With my huge legacy Mac Pascal code, I got involved in Pascal to Ada translator P2Ada: http://sourceforge.net/projects/p2ada It comes with some explanations: http://p2ada.sourceforge.net/ pascada.htm It comes with ISO and Borland TurboPascal translation on NewP2Ada branch (pretty stable release http://p2ada.svn.sourceforge.net/viewvc/ p2ada/newp2ada). It comes also with Object-Pascal translation mainly coming from Delphi and FPC on ObjP2Ada branch (alpha release http:// p2ada.svn.sourceforge.net/viewvc/p2ada/objp2ada/). For translating all macro of Pascal Mac interfaces I used GPC pre- processor. At the beginning of the century I was very happy to get a Pascal compiler on Mac new OS X. Thanks to all that make GPC possible. Nowadays, as mentioned, Ada tool chain GNAT is available with GPL (http://libre.adacore.com/libre) thus I switched without forgotten why. Regards, Pascal. http://blady.pagesperso-orange.fr Le 31 juil. 10 à 06:54, gpc-owner(a)gnu.de a écrit : > De : Frank Heckenbach <ih8mj(a)fjf.gnu.de> > Date : 31 juillet 2010 06:01:17 HAEC > À : gpc(a)gnu.de > Objet : Rép : Ada (was: D (was: Quo vadis, > > > J. David Bryan wrote: > >> This raises a point of interest to me. When GPC development >> stalled, I had >> to decide whether to continue with GPC as it was, switch to >> another Pascal >> compiler, or switch languages. I have programmed in Pascal for >> thirty >> years; it was my fifth language, after BASIC, Algol 60, FORTRAN >> IV, and >> SNOBOL, and of those, it is the only one in which I have continued to >> develop new programs. This was due primarily to the existance of >> GPC, and >> especially its good support for ISO 10206. >> >> For a number of reasons, I elected to switch to Ada, as >> implemented by the >> GNU Ada compiler (GNAT). I had studied the language shortly after >> it was >> introduced in 1983 but did not use it seriously until a GCC >> version became >> available. I found the transition from Pascal to Ada to be quite >> easy, >> because many of the implementation concepts are similar. For several >> years, I've done all of my new work in Ada instead of Pascal. >> >> I would think that translating from Pascal to Ada would have some >> advantages over C++. For example, Ada inherently supports scalar >> subrange >> types and range checking. I'm not that familiar with C++, but I >> don't >> believe that subranges are supported. > > No, not directly. However, range-checks are a rather minor issue -- > for comparison, it took me a few days to implement them in GPC, > while the object models took weeks or months (I'm not sure exactly > how much work Peter and Waldek spent on them), exceptions > implemented from scratch would take weeks, and templates probably > much longer. So it's these "big things" that matter most. You might > think checked subranges are more important because they're more > fundamental (which they are), but they're just not so difficult to > implement. For the 3 big things I mentioned, I know C++ has them > already. I don't know if Ada does, perhaps you can give us some > information here, e.g., is its object model comparable to those GPC > supports or that of C++; does Ada supported exception handling and > how; does it support something like templates (IOW, how can one > implement, say, a generic list, applicable to any given type, with > strong type-checking). >

1 0

Re: OS wars (was: Quo vadis, GPC?)
by samiam＠moorecad.com 31 Jul '10

31 Jul '10

1 0

Re: Quo vadis GRX?
by twixt＠cstone.net 30 Jul '10

30 Jul '10

| At some point in time I have to wonder when people will go to use free | pascal at http://www.freepascal.org/ | | They are Delphi and turbo pascal compliant How is free pascal an improvement over gpc in terms of graphics output? I searched both the programmer's guide and the language reference guide for "graphics." I found nothing. | And lets face it, here in the states pascal usage has dropped | significantly since the the infestation of java... Perhaps your intent was to post in the "Quo vadis GPC" thread? I plea for discussions of GPC that have nothing to do with GRX be taken to that thread. Thanks. | | | | | | -----Original Message----- | From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of | twixt(a)cstone.net | Sent: Thursday, July 29, 2010 11:51 AM | To: gpc(a)gnu.de | Subject: Quo vadis GRX? | | | | I would like to use Pascal to generate images in high resolution and at | least 24 bit color depth. There are links to a GRX library, which | provides | 2d graphics, but the user manual there was last updated in 2007, which | suggests they are further behind than GPC. I don't find any grx library | in | my Debian (Lenny) list of available packages, using the search feature | within aptitude. Apparently I would have to compile GRX and then somehow | get it to work with Pascal. As a barely capable programmer, I do not | look | forward to this with glee. (BTW I am not asking for help, just making a | point.) In all the discussion about the future of GPC, I am a bit | surprised that no one seems to talk about graphics output. Did I miss | something? I do that a lot. | | How about incorporating graphics | output directly in Pascal? Is there much interest in this? It seems to | me | that it would make Pascal more attractive. It would be "like POVray | but even more powerful" as any general purpose programming language | naturally would be. Thanks for your time. | | | | | PRIVILEGED AND CONFIDENTIAL | This email transmission contains privileged and confidential information | intended only for the use of the individual or entity named above. If the | reader of the email is not the intended recipient or the employee or agent | responsible for delivering it to the intended recipient, you are hereby | notified that any use, dissemination or copying of this email transmission | is strictly prohibited by the sender. If you have received this | transmission in error, please delete the email and immediately notify the | sender via the email return address or mailto:postmaster@argushealth.com. | Thank you. | | | | |

2 1

Quo vadis GRX?
by twixt＠cstone.net 30 Jul '10

30 Jul '10

I would like to use Pascal to generate images in high resolution and at least 24 bit color depth. There are links to a GRX library, which provides 2d graphics, but the user manual there was last updated in 2007, which suggests they are further behind than GPC. I don't find any grx library in my Debian (Lenny) list of available packages, using the search feature within aptitude. Apparently I would have to compile GRX and then somehow get it to work with Pascal. As a barely capable programmer, I do not look forward to this with glee. (BTW I am not asking for help, just making a point.) In all the discussion about the future of GPC, I am a bit surprised that no one seems to talk about graphics output. Did I miss something? I do that a lot. How about incorporating graphics output directly in Pascal? Is there much interest in this? It seems to me that it would make Pascal more attractive. It would be "like POVray but even more powerful" as any general purpose programming language naturally would be. Thanks for your time.

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