Gpc

gpc@gnu.de

5400 discussions

Re: assigning files
by Frank Heckenbach 05 Mar '98

05 Mar '98

Laussy Fabrice wrote: > laussy@localhost ~/conway 16:58:02 Thu Mar 5 > 25$ gpc -g game.of.life.pas > /tmp/cca005911.o: In function `Fileop': > /home/laussy/conway/game.of.life.pas:44: undefined reference to > `_p_assign' > > _p_assign, I just don't know what it is, since I didn't define it, > it is not due to me if that does not work! _p_assign is the procedure of the RTS (run time system) that is called internally for Assign. It should be included in libgpc.a -- did you check that the version you use is the correct one (and not perhaps an older version is laying around somewhere else; perhaps try "locate libgpc.a" if that's set up to work on your system, and remove any old version it finds). -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: patching gcc
by Peter Gerwinski 05 Mar '98

05 Mar '98

Hi! According to Laussy Fabrice: > Hi the list, > > I am currently compiling gcc and gpc, till there everything went ok but > this: > > Next, go to the GCC source directory and apply the GCC patch > required by GNU Pascal: > > % patch -s -p1 < p/patches/gcc-2.7.2.1.patch Hmm ... `./configure' should do this automatically for you when you invoke it from `/usr/local/gcc-2.7.2.1' while the subdirectory `p' is already present. > The problem is: > > root@localhost /usr/local/gcc-2.7.2.1/p/patches 09:24:02 Thu Mar 5 > 148$ ./mkpatch > diff: gcc-2.7.2.1/gcc.c.orig: No such file or directory > [...] You are trying to *create* `gcc-2.7.2.1.patch'. What you probably want is to *apply* it. Please `cd' to `/usr/local/gcc-2.7.2.1/' and really type the line `patch -s ...' above - or just `./configure'. > Is it important? Yes. Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

assigning files
by Laussy Fabrice 05 Mar '98

05 Mar '98

This time it seems that GPC works all right, the compilation went fine. I promise I won't ask for bug that are mines, but look at this one: laussy@localhost ~/conway 16:58:02 Thu Mar 5 25$ gpc -g game.of.life.pas /tmp/cca005911.o: In function `Fileop': /home/laussy/conway/game.of.life.pas:44: undefined reference to `_p_assign' _p_assign, I just don't know what it is, since I didn't define it, it is not due to me if that does not work! My last assign procedure coming from the doc went okay. The new version of GPC that should support it does not accept a simple call to assign! What's the problem? If this is still a compilation problem, so there is a bug in the new installation procedure ;) I installed GPC without *any* problem the first time, I have encountered a lot of problem for those of the beta version! which I have reported (unfortunatly for you) only a very little part. Am I getting inane with time? Otherwise, now bytes and all other family is accepted. Cheers. F.P.L

1 0

patching gcc
by Laussy Fabrice 05 Mar '98

05 Mar '98

Hi the list, I am currently compiling gcc and gpc, till there everything went ok but this: Next, go to the GCC source directory and apply the GCC patch required by GNU Pascal: % patch -s -p1 < p/patches/gcc-2.7.2.1.patch The problem is: root@localhost /usr/local/gcc-2.7.2.1/p/patches 09:24:02 Thu Mar 5 148$ ./mkpatch diff: gcc-2.7.2.1/gcc.c.orig: No such file or directory diff: gcc-2.7.2.1/gcc.c: No such file or directory diff: gcc-2.7.2.1/convert.c.orig: No such file or directory diff: gcc-2.7.2.1/convert.c: No such file or directory diff: gcc-2.7.2.1/dbxout.c.orig: No such file or directory diff: gcc-2.7.2.1/dbxout.c: No such file or directory diff: gcc-2.7.2.1/expr.c.orig: No such file or directory diff: gcc-2.7.2.1/expr.c: No such file or directory diff: gcc-2.7.2.1/fold-const.c.orig: No such file or directory diff: gcc-2.7.2.1/fold-const.c: No such file or directory diff: gcc-2.7.2.1/function.c.orig: No such file or directory diff: gcc-2.7.2.1/function.c: No such file or directory diff: gcc-2.7.2.1/optabs.c.orig: No such file or directory diff: gcc-2.7.2.1/optabs.c: No such file or directory diff: gcc-2.7.2.1/stor-layout.c.orig: No such file or directory diff: gcc-2.7.2.1/stor-layout.c: No such file or directory diff: gcc-2.7.2.1/toplev.c.orig: No such file or directory diff: gcc-2.7.2.1/toplev.c: No such file or directory and no way to make the PATH okay (in /usr/local/gcc-2.7.2.1 with p/ of GPC) Is it important? Cheers.

1 0

GPC Binary for Solaris 2.6
by Geoffrey Arnold 04 Mar '98

04 Mar '98

To Whom It May Concern: I am looking for a gpc 2.0 binary package compiled for a Sun SPARC running Solaris 2.6 with gcc 2.7.2.3 installed in /usr/local. If you have any information, please contact me directly by email. Thanks. ----Geoffrey Arnold--- garnold(a)cyberdrive.net

2 1

bug: unit initializer fails on Alpha-Digital Unix
by Miguel A. Alonso Pardo 03 Mar '98

03 Mar '98

Unit Initializers begin ... end. to begin do begin ... end; to end do begin ... end; does not work on our Alpha machines with Digital Unix 4.0. It works well on machines with SPARC with Solaris 2.0 and PC with Linux. I have not found this bug as reported in the GPC web pages, so I report it to you. Please inform me if there are a fix for this problem. Version of gpc: $ gpc -v Reading specs from /usr/local/lib/gcc-lib/alpha-dec-osf4.0/2.7.2.1/specs gpc version 2.0(2.7.2.1) Version of Digital Unix: $ uname -a OSF1 dexo V4.0 564 alpha Best Regards, ======================================================================= Miguel Angel ALONSO PARDO Grupo COLE ----------------------------------------------------------------------- Facultad de Informatica _/ email: alonso(a)dc.fi.udc.es Universidad de La Coruna _/ WWW : http://www.dc.fi.udc.es/~alonso/ Campus de Elvina s/n _/ phone: +34 (9) 81 16.70.00 ext. 1338 E-15071 La Coruna (Spain) _/ fax : +34 (9) 81 16.71.60 =======================================================================

3 2

bug report.
by Laussy Fabrice 02 Mar '98

02 Mar '98

Hi the list. I am now running what I think is the up to date gpc version: 971001(2.7.2.1) (documentation of 970714) (why is the name now xgpc?) Except my misunderstanding of something, the followings are types expected to be supported by the brand new GPC: (signed) (unsigned) (signless) GNU C equivalent typical size (bits) ByteInt ByteCard Byte [un]signed char 8 ShortInt ShortCard ShortWord [unsigned] short int 16 Integer Cardinal Word [unsigned] int 32 MedInt MedCard MedWord [unsinged] long int 32 LongInt LongCard LongWord [unsinged] long long int 64 But none of them is accepted by the compilator (except Integer, and may be few last I haven't tested, but ByteInt, ShortInt, MedInt, LongInt, ByteCard, Byte, Shortcard, ShortWord and Word does not work, for the others, I don't know but I bet they do not work as well). That a type "does not work" means that in my source if I put var i, j : byte; then GPC will yell at me: laussy@localhost /home/laussy/conway 18:17:35 Sun Mar 1 20$ gpc --version 971001(2.7.2.1) laussy@localhost /home/laussy/conway 18:18:19 Sun Mar 1 21$ gpc byte.test.pas byte.test.pas: In function `program_Test': byte.test.pas:3: type name expected, identifier `Byte' given The same for the others. If I keep the old type definition: type shortint = __byte__ integer; byte = __unsigned__ shortint; then the byte algebra is still bugged, with for example and absolute value of (2-4) given to be 252! Besides, in the doc, one can find: * The Run Time System (RTS) does not know about modified types such as `__byte__' or `__unsigned__ Integer's or `__long__ Real's. Especially, you cannot `writeln' such variables. Is it somewhat related? Cheers, F.P.L

2 1

Re: bug report.
by Frank Heckenbach 02 Mar '98

02 Mar '98

Laussy Fabrice wrote: > I am now running what I think is the up to date gpc version: > > 971001(2.7.2.1) This was the last beta version. More recent versions are currently available as alpha only. > (why is the name now xgpc?) xgpc is a temporary filename used while building gpc. With a "make pascal-install" or similar, it should be installed as gpc in the appropriate directory. > Except my misunderstanding of something, the followings > are types expected to be supported by the brand new GPC: > [...} > > That a type "does not work" means that in my source if I put > > var i, j : byte; > > then GPC will yell at me: > > laussy@localhost /home/laussy/conway 18:17:35 Sun Mar 1 > 20$ gpc --version > 971001(2.7.2.1) > laussy@localhost /home/laussy/conway 18:18:19 Sun Mar 1 > 21$ gpc byte.test.pas > byte.test.pas: In function `program_Test': > byte.test.pas:3: type name expected, identifier `Byte' given Should not happen in 971001. Perhaps an installation problem: "gpc" is only the compiler driver, the actual compiler is "gpc1". If you only installed gpc manually, but not gpc1, you're (for the most part) still using an older version, in spite of the "--version" output which is generated by gpc, not gpc1. (The version of your documentation might be due to the same reason.) > then the byte algebra is still bugged, with for example > and absolute value of (2-4) given to be 252! Did you do somehting like: var a,b: Byte; ... a := abs (a - b) In this case, this is not really a bug ;-) ... it's a general problem (found in other compilers and languages, too) with unsigned and/or differently sized integers. Since a and b are bytes, a - b will be evaluated as a byte, resulting in an overflow and the wrong result 254, of which then the absolute value is taken. Of course, in Pascal such an overflow should be caught, but GPC doesn't currently do range checking, unfortunately... The solution would be type casting the values (or one of them) like: a := abs (Integer(a) - b) Not tested, but should work... > Besides, in the doc, one can find: > > * The Run Time System (RTS) does not know about modified types such > as `__byte__' or `__unsigned__ Integer's or `__long__ Real's. > Especially, you cannot `writeln' such variables. This has been fixed, too. BTW: the RTS is in libgpc.a, yet another file. And there's also gpc-cpp, so be sure to do a complete installation... -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

1 0

Re: bug: unit initializer fails on Alpha-Digital Unix
by Peter Gerwinski 02 Mar '98

02 Mar '98

According to Miguel A. Alonso Pardo: > Unit Initializers > > begin ... end. > to begin do begin ... end; > to end do begin ... end; > > does not work on our Alpha machines with Digital Unix 4.0. > [...] > gpc version 2.0(2.7.2.1) Upgrading to a more recent (beta or alpha) GPC will solve this problem. Please go to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ to get the most recent version of GPC (source code only, sorry). Hope this helps, Peter -- Peter Gerwinski, Essen, Germany, free physicist and programmer Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - 1 Oct 1997 PGP key fingerprint: AC 6C 94 45 BE 28 A4 96 0E CC E9 12 47 25 82 75 Fight the SPAM! - http://maps.vix.com/

1 0

I should really update my GPC version!
by Laussy Fabrice 26 Feb '98

26 Feb '98

Hi again list, (sorry Peter) Here is a sample of some code I am currently working on: 1 if (abs(x-transient^.x)<2) then 2 if (abs(y-transient^.y)<2) then 3 tmp:=tmp+1; 4 if (transient^.x=x) and (transient^.y=y) then Well, what happens is that everything goes ok for the first test, but whatever the value is for the second one (y-transient^.y), the PC will jump to line 4, never doing 3. I have tested with gdb: (gdb) p Y $1 = 30 '\036' (gdb) p Transient.Y $2 = 31 '\037' (gdb) n (gdb) p Tmp $3 = 0 '\000' where Tmp was previously naught. Those are declared as byte. Is it a GPC bug? Is it a Pascal misunderstanding of mine? What the hell is it?

2 1

Jump to page:

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