Gpc April 1998

gpc@gnu.de

20 participants
35 discussions

Bug??
by Bendersky 21 Apr '98

21 Apr '98

Hi again, Why do I get this: *********************************** Reading specs from c:/utils/gpc/lib/specs gpc driver version 980420(2.80) executing gpc version 2.8.0 c:/utils/gpc/bin/gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__unix -D__i386 -D__GO32 -D__ MSDOS -D__DJGPP=2 -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D_ _BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -Asystem(unix) -Acp u(i386) -Amachine(i386) mandel1.pas c:/utils/gpc/tmp/ccbaaaaa GNU CPP version 980420(2.80) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/utils/gpc/include c:/utils/gpc/lang/pascal c:/utils/gpc/contrib/grx22/include /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.80/include $DJDIR/include End of search list. c:/utils/gpc/bin/gpc1.exe c:/utils/gpc/tmp/ccbaaaaa -quiet -dumpbase mandel1.pa s -version -famtmpfile=mandel1.gpc -fautomake=-v -o c:/utils/gpc/tmp/cccaaaaa GNU Pascal version 980420(2.80) (djgpp) compiled by GNU C version 2.8.0. Exiting due to signal SIGSEGV Page fault at eip=00122752, error=0004 eax=003c500c ebx=00394620 ecx=00000000 edx=00084421 esi=003d8ca0 edi=003dabac ebp=0035f5f4 esp=0035f5ec program=c:/utils/gpc/bin/gpc1.exe cs: sel=0117 base=838a8000 limit=ff6b6fff ds: sel=011f base=838a8000 limit=ff6b6fff es: sel=011f base=838a8000 limit=ff6b6fff fs: sel=00ef base=00035580 limit=0000ffff gs: sel=012f base=00000000 limit=ffffffff ss: sel=011f base=838a8000 limit=ff6b6fff Call frame traceback EIPs: 0x00122752 0x0011e0a2 0x00120600 0x0011f8fd 0x0011f928 0x0011f933 0x0011f933 0x0011f933 0x0011f933 0x0011f933 0x0011f933 *********************************** While trying to compile this: ********MANDEL1.PAS************* Program Mandelbrot; Uses grx20; Procedure Genera; var z, c : complex; x, y : integer; n : integer; pre, pim : real; begin for x:=1 to 640 do for y:=1 to 480 do begin pre := (4/640)*x - 2; pim := (4/480)*y - 2; z := cmplx (pre, pim); c := z; n := 0; repeat z:=(z pow 2) + c; inc(n); until ((n=255) or (abs(z)>4)); GRplot(x, y, n); end; end; var x, y, xv, yv, c, m : integer; begin x := 640; y := 480; xv := 640; yv := 640; c := 256; M := GrSetMode(GR_width_height_color_graphics,x,y,c,xv,yv); genera; end. ********************************* Using: ********************************* gpc -v --automake=-v mandel1.pas I'm running GPC under DJGPP in a DOS box under windows 95. Thanks, Ariel. --- Ariel Bendersky bender(a)einstein.com.ar

2 1

New Alpha: gpc-980420
by Peter Gerwinski 20 Apr '98

20 Apr '98

Hi, everybody! A new alpha version of GPC is now on Agnes, ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. (Source (diff) and binaries for Linux and DJGPP.) Hopefully those strange DJGPP-specific problems are solved now. AFAI could find out, they came from a stack limit of 256kB on DJGPP which was not enough for `load_tree()', a function which recurses deeply when loading a large GPI file. In the DJGPP binary just uploaded, I `stubedit'ed it to 2MB. Now you can again do `uses GRX20'. Have fun, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980410 PGP: see homepage - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

1 0

trouble compiling gpc source on m68k
by alan czarnecki 19 Apr '98

19 Apr '98

Greetings, I am having trouble compling the latest gpc source on my m68k based system... an amiga 2000. The attempt to build from source dies at the following point: [root@localhost gcc-2.8.0]# make CFLAGS=-O3 LANGUAGES=pascal make: Circular cplib2.ready <- pascal dependency dropped. case "pascal" in \ *pascal*) cd p/rts && make \ GCC_FOR_TARGET="`case './xgcc -B./' in \ './xgcc -B./') echo ../../xgcc -B../../;; \ *) echo './xgcc -B./';; esac`" \ GPC_FOR_TARGET="`case './xgpc -B./' in \ './xgpc -B./') echo ../../xgpc -B../../;; \ *) echo './xgpc -B./';; esac`" \ GCC_FLAGS="" CROSS="" AR_FLAGS="rc" AR_FOR_TARGET="/usr/m68k-unknown-linux-gnu/bin/ar"\ BISON="bison" BISONFLAGS="" CFLAGS="-O3" X_CFLAGS="" LDFLAGS=""\ RANLIB_FOR_TARGET="/usr/m68k-unknown-linux-gnu/bin/ranlib" \ RANLIB_TEST_FOR_TARGET="[ -f /usr/m68k-unknown-linux-gnu/bin/ranlib ]"\ SHELL="/bin/sh" \ all ;; \ esac make[1]: Entering directory `/temp/gcc-2.8.0/p/rts' ../../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith\ -Wmissing-prototypes -Wmissing-declarations -O3 -I.\ -I../.. -I/temp/gcc-2.8.0/p/rts/../.. -I/temp/gcc-2.8.0/p/rts/../../config rts-base.p make[1]: *** [rts-base.o] Aborted (core dumped) make[1]: Leaving directory `/temp/gcc-2.8.0/p/rts' make: *** [libgpc.a] Error 2 Any pointers as to how to deal with this would be much appreciated. Thanks, Alan Czarnecki alancz(a)columbus.rr.com

2 1

gpc with egcs
by Shane Wegner 19 Apr '98

19 Apr '98

-----BEGIN PGP SIGNED MESSAGE----- Hi all, I guess you must get this alot here but I couldn't find any info on your site. What do I have to do to get the latest alpha release of gpc to work with the egcs package? - - Shane Wegner <shane(a)continuum.eu.org> Sysadmin: Continuum Systems <http://www.continuum.eu.org> Personal website: http://www.continuum.eu.org/~shane Virtualisys: http://www.virtualisys.com/vr/swegner PGP key: finger shane(a)continuum.eu.org -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNTax/aeq+0eJMsK9AQEJFwP6A+sJZEIxgIX3FOi9iWRz9Te0zddSgnnr 10nsDN5hdg3UnwfY2dtEjxr5GAZzUzLjDjbVz3aMVAtjNS76ZbUh2sZfgT7Fs0JZ xouh78zShS+91EYEbHyeAMKYFhvSAna7tE/KOP7SVMvgvoviuj0zv9W9s0xh3dA1 VXoO/8t6kdc= =DLAC -----END PGP SIGNATURE-----

3 5

Re: String Lengths in Procedures
by Kevin A. Foss 19 Apr '98

19 Apr '98

On Sun, 19 Apr 1998 11:31:26 +0200 (MEST), Peter Gerwinski wrote: >According to Kevin A. Foss: >> [...] It appears that for some reason strings that >> are defined in procedures/functions are not initialized to a length of >> 0. > >Why should they? Local variables have no predifined value on >any Pascal compiler I know. Why? ..because >For the sake of compatibility to BP, GPC initializes >all global variables to zero/false/nil/empty string. I've never seen a compiler predefine undefined variables anywhere either locally or globally before and I thought GPC would be consistant in this strangeness by predefining in both places. I didn't realize it was another Borland "feature". Obviously I assumed wrong. But isn't this dangerous? It allows the compiler to happily accept code like: program test(output); procedure test1; var a, b : string (10); begin a := a + b end. begin test1; end. And then core dump at runtime, or presumeably some other undefined result. To me it make more sense to either set local variables to 'don't let the user shoot himself the foot' values (like global variables) or actual undefine them so that the compiler can warn/give errors about it. >That was twice the same program, and it produces 0 on my (Linux) >system, too. Ack, the second program should have been the same as above, except "a := a + b;" was replaced with "writeln(length(a));" But that is a moot point now. :) Anyway, I thought this was the source of a runtime core-dump I was having with some TP source , obviously I was wrong and I'll see if I can better locate what is happening. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

2 1

String Lengths in Procedures
by Kevin A. Foss 19 Apr '98

19 Apr '98

Hello, Today I was playing around with some code and was getting some pretty wacky results from a couple string functions (anything from random trash to SIGSEGV.) It appears that for some reason strings that are defined in procedures/functions are not initialized to a length of 0. For example: program test(output); var a : string (10); begin writeln(length(a)) end. On both Linux (gpc971001) and OS/2 (gpc980410) I get a result of 0, no problem. However: program test(output); var a : string (10); begin writeln(length(a)); end. Produces 65536 in OS/2 and 134515920 in Linux. Interestingly, if you declare more strings, usually by the third or fourth string the length will actually be 0 -- but I've seen gpc on Linux return negative integers too! I'm not sure how much of a bug this is as I'm not sure that the user should assume *anything* about undefined variables. I haven't checked the EP standard about this yet. It probably should be set to 0 for BP compatibility as the code I was trying to port to GPC was written for TP and assumed undefined strings would have a 0 length. -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

2 1

unsubscribe
by Phillip Bruce 18 Apr '98

18 Apr '98

unsubscribe -- ******************************************************************** *** Phillip B. Bruce That's Me **** *** Web Site: http://www.jps.net/~pbbruce Web Site **** *** Email: pbbruce(a)jps.net **** ********************************************************************

1 0

(Fwd) Re: More on my unit
by Bendersky 16 Apr '98

16 Apr '98

I was wrong, Rhide is working perfectly. I'm sorry. Ariel. ------- Forwarded Message Follows ------- From: Self <Single-user mode> To: Peter Gerwinski <peter(a)gerwinski.de>,gpc(a)hut.fi Subject: Re: More on my unit Date: Thu, 16 Apr 1998 21:50:28 ARG > According to Bendersky: > > In part, that helped. Now I'm almost sure that it compiles with the > > 980410, but I get this error with the gpc -v --automake=-v test.pas : > > [...] > > gpi-hash.c:321: failed assertion `ss.key == -DEBUG_HASH_KEY' > > Abort! > > The GPI format has changed. Just delete and recompile all `.gpi' > files, and this problem will vanish. > > Peter > I think it's working fine right now, thank you!!! What I couldn't make run is the rhide, is there some way? Do I need a newer version? Thanks again, Ariel. --- Ariel Bendersky bender(a)einstein.com.ar

1 0

Re: More on my unit
by Peter Gerwinski 16 Apr '98

16 Apr '98

According to Bendersky: > In part, that helped. Now I'm almost sure that it compiles with the > 980410, but I get this error with the gpc -v --automake=-v test.pas : > [...] > gpi-hash.c:321: failed assertion `ss.key == -DEBUG_HASH_KEY' > Abort! The GPI format has changed. Just delete and recompile all `.gpi' files, and this problem will vanish. Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980405 PGP: see homepage - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

2 1

Re: More on my unit
by Peter Gerwinski 15 Apr '98

15 Apr '98

According to Bendersky: > This is the output of that: > **************************** > Reading specs from c:/utils/gpc/lib/specs > gpc version 2.80 > [...] > GNU CPP version 2.0(2.7.2.1) (80386, BSD syntax) > [...] > GNU Pascal version 2.0(2.7.2.1) (80386, BSD syntax) [...] > [...] > test.pas:2: installation problem, cannot exec `gpc' Now it is clear for me: You installed gpc-980410, but you still have the old gpc-2.0 binaries in your path where they are found prior to the new ones. Thus, you are still compiling with gpc-2.0. To fix it, delete (or rename;-) the files `gpc-cpp.exe' and `gpc1.exe' in `/djgpp/bin/' and the file `libgpc.a' in `/djgpp/lib'. The new version of GPC will use the executables and libraries in `/djgpp/lib/gcc-lib/djgpp/2.80/'. Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980405 PGP: see homepage - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

1 0

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 April 1998