Gpc October 2000

gpc@gnu.de

29 participants
35 discussions

Registers
by Maurice Lombardi 27 Oct '00

27 Oct '00

Hi all, In gpc.pas, in the declaration { 8086 CPU registers -- only used by the unportable Dos routines } Registers = record case Boolean of False : (AX, BX, CX, DX, BP, SI, DI, DS, ES, Flags : Word); True : (AL, AH, BL, BH, CL, CH, DL, DH : Byte) end; Word should be replaced by Word16. It is the same if one defines __BP_TYPE_SIZES__ but not otherwise. The alignment between X and H+L is then lost, and this triggered a bug in a program for which I prefer gpc type sizes for mainstream computations, but which uses incidentally a unit which comes from old BP stuff and calls a msdos interrupt. Hope this helps 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 2

Pascal for Atari platform
by Sikor 27 Oct '00

27 Oct '00

Hallo! I search for Turbo Pascal or compatible for Atari TT (ST). Some people written to me, to search for GNU PASCAL. Please, give me answer for this question: Find I Gnu Pascal on my computer? Thanks You! Pawel Sikorski e-mail:sikor_soft@poczta.fm

2 1

portable programming
by Eike Lange 25 Oct '00

25 Oct '00

Hi! Thorsten and I use a very (possibly, depending on the source-size) large stack for the "pindent"- program. Are there any limitations for stack-size on some systems, gpc runs on? Eike

1 0

Bug report. Problems with initialising sets to the empty set.
by Martin Liddle 25 Oct '00

25 Oct '00

I believe that I have mentioned this problem previously but have not been confident that it was a bug. I am now. I have repeatedly been hit by the problem that initialising a set to the empty set will work correctly for many versions of a program then recompiling the source without changing anything will produce a version where the set is not initialised (I think but am not certain that it is left with whatever value it had previously). A typical code snippet might be Const Maxcomp=180; Type TSetComp=Set of 1..Maxcomp; Var SetComp:TSetComp; begin SetComp:=[]; ... Usually this will result in SetComp being the empty set. Our code uses sets quite extensively and every so often we will build a version of the code where one or other of the sets is not initialised. The behaviour is then repeatable until we build a new version. This makes testing a complete nightmare as we have to test everything each time we build a new version even if nothing has changed. The workaround that I have not seen fail, is to use SetComp:=[1]-[1]; This is with gpc version 19991030 based on 2.95.2 running under RedHat Linux 6.2 on a Pentium PC. To me this smells like an uninitialised variable in the compiler that only gives problems when it picks up a limited range of values. Apologies if this is a known problem (and more apologies if it is fixed in a later snapshot) but I couldn't immediately see it in the bug lists. Could somebody recommend a strategy for using the daily snapshots? Is it a case of taking pot luck or are their particular releases that are known to work tolerably well? Is their likely to be a beta in the near future? -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324.

2 2

Re: portable programming
by Nick Burrett 25 Oct '00

25 Oct '00

Eike Lange <eike.lange(a)uni-essen.de> writes: > Thorsten and I use a very (possibly, depending > on the source-size) large stack for the > "pindent"- program. Are there any limitations > for stack-size on some systems, gpc runs on? Stack sizes can be set by ulimit on some systems. On such systems, it may be set as low as 2Mb. It is set at either 4Mb or 8Mb on all the servers we use here though. For large allocations, it is usually better to use a more permanent storage mechanism Nick.

4 4

Re: rts.c:326: `T_RESADFLT' undeclared
by Nick Burrett 25 Oct '00

25 Oct '00

Frank Heckenbach <frank(a)g-n-u.de> writes: > Nick Burrett wrote: > > > Frank Heckenbach <frank(a)g-n-u.de> writes: > > > > > Honda Hirotaka wrote: > > > > > > > I'm trying to build gpc-20001019 on an old i486DX2 DECpc running > > > > FreBSD 2.2.8 , but I get the error message of > > > > "gcc-2.95.2/gcc/p/rts/rts.c:326: `T_RESADFLT' undeclared here (not in > > > > a function)" . > > > > > > > > I can't find the word "T_RESADFLT" in rts.c. > > > > I want to know what is happenning. > > > > > > No, this word doesn't occur. However, the line refers to > > > ILL_RESAD_FAULT (and two lines below to ILL_RESOP_FAULT). > > > > > > So, it may be that these symbols are defined to T_RESADFLT and > > > T_RESOPFLT in some system header, but the latter symbols are not > > > defined. Now, why would one define something to something undefined? > > > I don't know, I guess only a C programmer can understand this... > > > > FreeBSD doesn't use T_RESADFLT or T_RESOPFLT and therefore doesn't > > define them. > > > > The ILL_* macros are defined as placeholders for a time when they might > > be used. > > So, they define them so #ifdef ILL_... is true, but ILL_... still > can't be used. Very strange, IMHO... It is usually done as a placeholder. If people use them, then they get a compile error. Although simply not defining them at all would make no difference either. > > So for FreeBSD, you will need to check that the definitions of T_RESADFLT > > and T_RESOPFLT exist and then fix the definition of ILL_RESAD_FAULT > > and ILL_RESOP_FAULT accordingly. > > I'd consider this a last resort. I mean we want to use ILL_... -- > why should we check whether T_... is defined? Perhaps the next > system defined them to BLAH_... and whatever, what then? Yeah, I know what you mean. I can't think of a decent answer to this one either. > > The ILL_RESAD_FAULT and ILL_RESOP_FAULT are defined by FreeBSD in > > machine/trap.h if you are curious. > > We don't include this. We include signal.h if it exists, and if not, > bsd/signal.h if that exists. Probably machine/trap.h is included by > one of them (or some other header we use). signal.h includes sys/signal.h, which in turn includes machine/trap.h. > > This is also where the corresponding T_* > > macros are defined. > > Now I don't understand. You said above they're not defined, didn't > you? So, should we explicitly include machine/trap.h, would that > help? I think this is best explained by simply including a chunk of the file: /* * Trap type values * also known in trap.c for name strings */ #define T_PRIVINFLT 1 /* privileged instruction */ #define T_BPTFLT 3 /* breakpoint instruction */ #define T_ARITHTRAP 6 /* arithmetic trap */ #define T_ASTFLT 7 /* system forced exception */ #define T_PROTFLT 9 /* protection fault */ #define T_TRCTRAP 10 /* debug exception (sic) */ #define T_PAGEFLT 12 /* page fault */ #define T_ALIGNFLT 14 /* alignment fault */ #define T_DIVIDE 18 /* integer divide fault */ #define T_NMI 19 /* non-maskable trap */ #define T_OFLOW 20 /* overflow trap */ #define T_BOUND 21 /* bound instruction fault */ #define T_DNA 22 /* device not available fault */ #define T_DOUBLEFLT 23 /* double fault */ #define T_FPOPFLT 24 /* fp coprocessor operand fetch fault */ #define T_TSSFLT 25 /* invalid tss fault */ #define T_SEGNPFLT 26 /* segment not present fault */ #define T_STKFLT 27 /* stack fault */ #define T_MCHK 28 /* machine check trap */ #define T_RESERVED 29 /* reserved (unknown) */ /* XXX most of the following codes aren't used, but could be. */ /* definitions for <sys/signal.h> */ #define ILL_RESAD_FAULT T_RESADFLT #define ILL_PRIVIN_FAULT T_PRIVINFLT #define ILL_RESOP_FAULT T_RESOPFLT #define ILL_ALIGN_FAULT T_ALIGNFLT #define ILL_FPOP_FAULT T_FPOPFLT /* coprocessor operand fault */ > More generally: Is there any point in supporting these things > (subcodes of numeric error signals) at all? AFAICS, they're > remainings from the signal handler in ancient versions of the RTS > (which had been disabled for a long time). This handler was labeled > "BSD style", but if these things are not even supported on FreeBSD, > perhaps we should simply drop them. Does any other system support > them? For the SIGILL, I don't think it is worth it. An illegal instruction is an illegal instruction, it isn't going to make much difference to the end user whether it was a privileged instruction or simply an undefined operation. I think many systems define them, but in usually unportable ways. The SIGFPE error codes are useful though. Nick.

2 1

Installation problem: Assembler
by Michael Höhle 25 Oct '00

25 Oct '00

Hiya, This is definitely a FAQ/newbie question, but so far I have not been able to find the answer in the FAQ or on the net. :( I'm trying to get gpc running on my ntbox+cygwin. I'm using cygwin 1.1 with gcc v2.95. After downloading gpc-20001024.tar I followed the steps described in http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_49.html#SEC49 This all worked fine, and gpc runs, but when I try to compile a file I receive the following error: $ gpc helloworld.pas Assembler messages: for reading.open : No such file or directory Hmm, what seems to be the problem here - and even more important - how to fix it? Best regards, Michael HÃ¶hle

3 3

Re: rts.c:326: `T_RESADFLT' undeclared
by Nick Burrett 25 Oct '00

25 Oct '00

Frank Heckenbach <frank(a)g-n-u.de> writes: > Honda Hirotaka wrote: > > > I'm trying to build gpc-20001019 on an old i486DX2 DECpc running > > FreBSD 2.2.8 , but I get the error message of > > "gcc-2.95.2/gcc/p/rts/rts.c:326: `T_RESADFLT' undeclared here (not in > > a function)" . > > > > I can't find the word "T_RESADFLT" in rts.c. > > I want to know what is happenning. > > No, this word doesn't occur. However, the line refers to > ILL_RESAD_FAULT (and two lines below to ILL_RESOP_FAULT). > > So, it may be that these symbols are defined to T_RESADFLT and > T_RESOPFLT in some system header, but the latter symbols are not > defined. Now, why would one define something to something undefined? > I don't know, I guess only a C programmer can understand this... FreeBSD doesn't use T_RESADFLT or T_RESOPFLT and therefore doesn't define them. The ILL_* macros are defined as placeholders for a time when they might be used. So for FreeBSD, you will need to check that the definitions of T_RESADFLT and T_RESOPFLT exist and then fix the definition of ILL_RESAD_FAULT and ILL_RESOP_FAULT accordingly. The ILL_RESAD_FAULT and ILL_RESOP_FAULT are defined by FreeBSD in machine/trap.h if you are curious. This is also where the corresponding T_* macros are defined. Regards, Nick.

2 1

rts.c:326: `T_RESADFLT' undeclared
by Honda Hirotaka 24 Oct '00

24 Oct '00

I'm trying to build gpc-20001019 on an old i486DX2 DECpc running FreBSD 2.2.8 , but I get the error message of "gcc-2.95.2/gcc/p/rts/rts.c:326: `T_RESADFLT' undeclared here (not in a function)" . I can't find the word "T_RESADFLT" in rts.c. I want to know what is happenning. ==== gmake[2]: Entering directory `/usr/local/src/gcc/gpc_objir/gcc/p/rts' /usr/local/src/gcc/gpc_objir/gcc/xgcc -B/usr/local/src/gcc/gpc_objir/gcc/ -B/usr/local/i386-unknown-freebsd2.2.8/bin/ -I/usr/local/i386-unknown-freebsd2.2.8/include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /usr/local/src/gcc/gcc-2.95.2/gcc/p/rts/rts-version`'" /usr/local/src/gcc/gcc-2.95.2/gcc/p/rts/rts.c /usr/local/src/gcc/gcc-2.95.2/gcc/p/rts/rts.c:326: `T_RESADFLT' undeclared here (not in a function) /usr/local/src/gcc/gcc-2.95.2/gcc/p/rts/rts.c:328: `T_RESOPFLT' undeclared here (not in a function) /usr/local/src/gcc/gcc-2.95.2/gcc/p/rts/rts.c: In function `_p_c_strsignal': /usr/local/src/gcc/gcc-2.95.2/gcc/p/rts/rts.c:741: warning: return discards qualifiers from pointer target type gmake[2]: *** [rts.o] Error 1 gmake[2]: Leaving directory `/usr/local/src/gcc/gpc_objir/gcc/p/rts' gmake[1]: *** [pascal.rts] Error 2 gmake[1]: Leaving directory `/usr/local/src/gcc/gpc_objir/gcc' gmake: *** [all-gcc] Error 2 $ ==== Built and Installed files for preparation to build gpc make-3.79.1 sed-3.02 bzip2-1.0.1 gettext-0.10.35 bison-1.28 gcc-2.95.2 (installed already. It took me 11 hours !) gawk-3.0.6 m4-1.4 autoconf-2.13 -- Honda, Hirotaka LL.M. hirotaka(a)jca.apc.org PGP public key: http://www.jca.apc.org/~hirotaka/public.asc jcanet-beginners: http://www.jca.apc.org/jca-net/beginners/

2 1

Bug report on nonstatic types at HP systems
by Rudy Moddemeyer 21 Oct '00

21 Oct '00

Hello, I have tried to execute the simple program PROGRAM test(input, output); TYPE s(a,b:integer) = ARRAY[a..b] OF real; VAR x:s(5,6); i:integer; BEGIN writeln(x.a:3,x.b:3); END. It should write "5 6" on the output. At a HP system it writes "0 0". I am sorry but i am using a rather old version of gpc: version 19980830, based on gcc-egcs-2.91.57 19980901 (egcs-1.1 release) on a HP-system: HP-UX rug102 B.10.20 A 9000/735 2011278599 The Linux implementation, which I have also checked, does not suffer from this bug. I have not found this bug in neither the list of known bugs nor the list of fixed bugs. With kind regards, Rudy Moddemeijer --------------------------------------------------------------------- | R. Moddemeijer | Department of Computing Science | | | University of Groningen | | Phone +31/50 - 363 3940 | Blauwborgje 3 room IWI 228 | | Telefax +31/50 - 363 3800 | P.O. Box 800 | | e-Mail rudy(a)cs.rug.nl | NL-9700 AV Groningen | | r.moddemeijer(a)cs.rug.nl | The Netherlands | | | | ---------------------------------------------------------------------

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 October 2000