Gpc March 2002

gpc@gnu.de

22 participants
41 discussions

StringUtils, FileUtils
by Frank Heckenbach 31 May '02

31 May '02

Hi, in the current GPC version, I've included a StringUtils unit for general string handling routines (on a higher level than the built-in and RTS routines). Up to now, it only contains routines for a string hash table, but I'm planning to add some more routines. Perhaps some of you also have some routines to contribute (or features to request). Conditions for inclusion into this unit should be, IMHO: - Generally useful (not meant specifically for a certain program or something), - self-contained (not relying on an external library etc.), - new functionality compared to the existing routines (whereas the same or similar functionality under a different interface for compatibility purposes should go into other units, like GPCUtil for compatibility to `Turbo Power' units), - and, of course, compilable with the current GPC version, portable, bug-free, etc. ;-) The same goes for the FileUtils unit which has been there for some months already. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 10

Problem with gpc 2.1 RC 3
by Martin Liddle 04 Apr '02

04 Apr '02

I have just moved to RC 3. Looking at the list of fixed bugs it is obvious that a lot of work has been done in the last few months; thanks to all concerned. The stricter type checking required a lot of effort to get our code to compile but in fairness did highlight a number of problems in our code; so I think it was time well spent. However I am now stuck because of the following problem: Program WriteTest; Procedure ZWriteln(AString:String); Begin AString:=AString+'ML'; Writeln('String [',AString,'] Length is ',Length(AString)); End; Begin ZWriteln(' '); End. What I see is that length is reported as 1 i.e. the string concatenation is failing. Is this expected behaviour or a bug? I also note that trying to set the Capacity of a string schema is now flagged as an error. Is there an "official" way to set the capacity? We were only setting the capacity as a workaround for problems in previous versions of gpc where under various circumstances it wasn't initialised properly. My first stab is to comment out all the places where we were setting capacity but I can't test if everything is OK because of the problem noted above. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

9 22

Re: Problem with gpc 2.1 RC 3
by da Silva, Joe 04 Apr '02

04 Apr '02

Interesting. However, I wonder if this truncation is valid. Looking at ISO-10206, it states in section <6.4.6 Assignment-compatibility> : "At any place where the rule of assignment-compatibility is used ... c) it shall be an error if T1 and T2 are compatible, T1 is a string-type or the char-type, and the length of the value of T2 is greater than the capacity of T1;" My interpretation of this, is that in this situation, the statement <AString:=AString+'ML'> should have resulted in an error, since the compiler only allocated a capacity of 1 to AString, yet such a concatenation can never fit within this capacity. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, March 18, 2002 8:42 AM > To: gpc(a)gnu.de > Subject: Re: Problem with gpc 2.1 RC 3 > > Prof Abimbola Olowofoyeku wrote: > > > On 17 Mar 2002 at 13:16, Martin Liddle wrote: > > > > > I have just moved to RC 3. Looking at the list of fixed bugs it is > > > obvious that a lot of work has been done in the last few months; > thanks > > > to all concerned. The stricter type checking required a lot of effort > > > to get our code to compile but in fairness did highlight a number of > > > problems in our code; so I think it was time well spent. However I am > > > now stuck because of the following problem: > > > > > > Program WriteTest; > > > > > > Procedure ZWriteln(AString:String); > > > Begin > > > AString:=AString+'ML'; > > > Writeln('String [',AString,'] Length is ',Length(AString)); > > > End; > > > > > > Begin > > > ZWriteln(' '); > > > End. > > > > > > What I see is that length is reported as 1 i.e. the string > concatenation > > > is failing. Is this expected behaviour or a bug? > > > > It is a bug alright. If you pass a string variable rather than a > > literal to 'ZWriteln', the concatentation is successful. So, something > > seems to have gone awry somewhere. > > No, it's not a bug. `AString' is a formal parameter of > undiscriminated schema type. This means it assumes the discriminants > (in case of String: Capacity) of the actual parameter. In the > example, the actual parameter is a string constant of length 1. It > also has capacity 1, since constants can't change, anyway. > > So also the parameter has capacity 1 during the execution of > `ZWriteln'. Assigning ` ML' (the result of concatenation) to a > capacity 1 string results in truncation to ` '. This behaviour is > not new, BTW. > ------ snip ------

5 12

GPC 2.1 RC 4 on Unixware 7.1
by Theo Carr-Brion 02 Apr '02

02 Apr '02

For your information. gpc --version 20020318, based on gcc-2.95.3 20010315 (release) Compiling and installation gave no problems. Running the tests on unixware 7.1 gives # of GPC tests 2616 # of GPC tests passed 681 # of GPC tests skipped 5 # of GPC tests failed 1930 However it looks like only 6 tests failed from the output! The following was produced. The other 3 fails are duplicates. TEST aturbo3test.pas: UX:as: WARNING: /var/tmp/ccyREJFc.s:102:name already bound as global: pascal_main_program UX:as: WARNING: /var/tmp/ccyREJFc.s:106:name already bound as global: init_pascal_main_program Undefined first referenced symbol in file getbegx /usr/ccs/lib/libpanel.a(move.o) getbegy /usr/ccs/lib/libpanel.a(move.o) getmaxx /usr/ccs/lib/libpanel.a(move.o) getmaxy /usr/ccs/lib/libpanel.a(move.o) UX:ld: ERROR: a.out: fatal error: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status failed TEST dialec3.pas: UX:as: WARNING: /var/tmp/ccSiB14a.s:1050:name already bound as global: _p_new UX:as: WARNING: /var/tmp/ccSiB14a.s:1051:name already bound as global: _p_dispose UX:as: ERROR: /var/tmp/cc4nnmDk.s:49:too many operands: outw: No such file or directory UX:as: ERROR: /var/tmp/cc4nnmDk.s:65:too many operands: outb UX:as: ERROR: /var/tmp/cc4nnmDk.s:81:too many operands: inw UX:as: ERROR: /var/tmp/cc4nnmDk.s:101:too many operands: inb gpc1: gpc exited with status 1 failed TEST fjf602.pas: UX:as: WARNING: /var/tmp/ccIfVTNM.s:303:name already bound as global: pascal_main_program UX:as: WARNING: /var/tmp/ccIfVTNM.s:381:name already bound as global: init_pascal_main_program failed 1 -100 4.987541511039074e-03 -5.012541823544287e-03 Debugging still crashes so I used -g0 for everything Theo Carr-Brion

2 1

Re: Record alignment
by KOCHERALKOTA harikrishna 02 Apr '02

02 Apr '02

Hello, Is it possible to make the set datatype to occupy only one byte? Now by default the compiler allocates 4 bytes.We even tried packing it,but it's still the same. Have a Great Day! Kind Regards, Karthic and Hari P.S: As specified in one of your mails in the mailing list for a similar problem, we even tried builiding the compiler by changing the P/rts/sets.pas(Tsetelement = byte) and also in P/util.c(set_word_size and set_alignment = 8).Still we are unsuccessful.

3 6

Re: GPC Bug?
by Ernst-Ludwig Bohnen 27 Mar '02

27 Mar '02

On Tue, 26 Mar 2002, Silvio a Beccara wrote: > Hello, > > thank you for your help; under which version have you tried compiling this, > and under which OS? > [pal06] bohnen $ gpc -v Reading specs from /afs/desy.de/user/b/bohnen/.gnu/lib/gcc-lib/i386-suse-linux/2.95.2/specs gpc version 20020304, based on 2.95.2 19991024 (release) [pal06] bohnen $ uname -a Linux pal06 2.4.18 #1 SMP Tue Mar 5 15:27:45 MET 2002 i686 unknown AFAIK any floating point unit can be configured to treat 'out of range' FP-numbers (NaNs) as legal infinity/zero values or as errors. I couldn't find any hint about 'NaN' or 'IEEE' in the gpc - units directory to control this behavior. If there is no user control on that, the current behavior of gpc seems to me the best solution. Otherwise one might run into severe mathematical problems without any notification. Ernst-Ludwig > Regards > > Silvio > > > > Hello, > > I changed your program somewhat: > > > > PROGRAM espa; > > var > > i, j, k : integer; > > esp, res : double; > > > > begin > > writeln (exp(1.0)); ^^^^^^^^^^^^^^^^^^^ this is garbage, I forgot the value of e > > for i := 1 to 50000 do > > begin > > esp := i * 0.1 ; > > res := exp ( -esp ); > > writeln (' Minus the exponential of ', esp :5 :1, ' is ', res ); > > end > > end. > > > > Last lines written are: > > ...... > > Minus the exponential of 744.9 is 4.940656458412465e-324 > > Minus the exponential of 745.0 is 4.940656458412465e-324 > > Minus the exponential of 745.1 is 4.940656458412465e-324 > > espa: error in exponentiation (Numerical result out of range) (error #700 > > at 8049c8a) > > > > This indicates that res runs into undefined range between zero and > > minimum valid value of IEEE double precision numbers. > > Minimum decimal value is approximately +/- 10**(-323). If your > > application allows lower values to be interpreted as zero (0.0) > > you may tell it to gpc, but I don't know how to do that.. > > > > Ernst-Ludwig > > > > On Tue, 26 Mar 2002, Silvio a Beccara wrote: > > > Hello, > > > > > > I tried compiling this simple program, with GPC RC3 (20020304), with GCC > > > 2.95.3 (20010315). > > > > > > > > > program espa; > > > > > > > > > var > > > > > > i, j, k: integer; > > > > > > esp: double; > > > > > > res: double; > > > > > > > > > begin > > > > > > > > > > > > for i := 1 to 50 do begin > > > > > > esp := i * 1000 ; > > > > > > res := exp ( -esp ); > > > > > > writeln (' Minus the exponential of ', esp :1 :0, ' is ', res :1 :15 > > > ); > > > > > > > > > end; > > > > > > > > > end. > > > > > > > > > > > > Surprisingly, and disappointingly, when I run it I get the following > > > result: > > > > > > espa: error in exponentiation (Numerical result out of range) (error #700 > > > at 8049c75) > > > > > > while with any Pascal (like FPC), and C compiler, I get no error (like it > > > should be ). It really looks like a bug. > > > > > > Can anyone help? > > > > > > Thanks, regards > > > > > > Silvio a Beccara >

4 4

Re: GPC Bug?
by Maurice Lombardi 26 Mar '02

26 Mar '02

Silvio a Beccara wrote: > Dear Monsieur Lombardi, > > thank you for your suggestion about the CEPHES library. I used your wrapper > unit, modified for double types, and it works! I do not get that foolish > error any longer. Do you know anything about its speed as compared to native > GPC functions? No way to compare with djgpp. There are no LongReal (long double: 80 bits) math routines there. Even those included in the x87 coprocessor are not declared in math.h nor in libm/math.h, and thus unknown in C (I think) and in gpc (I am sure). If I understand correctly, at least with the option -ffast-math they are used in intermediate calculations in C, which are done in the FP, but the final results are converted to double (real). Anyway after some unconclusive trials with these options when I begun to use gpc, I use CEPHES with a import unit each time I need mathematical accuracy. > > Silvio a Beccara > > ps: are your roots italian? What are roots ? The father of my father was italian, born in france, turned back to italy afterwards, and I still know cousins in Italy (two of them have migrated meanwhile to Spain and USA, and married there). The mother of my father came from corsica, and thus was french to begin with, but migrated to italy afterwards. My father was born in france, and chose the french nationality when doing military service. My mother was french, and I have also cousins round here. The husband of my daughter is malian. And there is presumably a drop of yellow somewhere in the ancestors of my mother. 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

Re: GPC 2.1 RC 4 released
by da Silva, Joe 26 Mar '02

26 Mar '02

Thanks, Maurice! Joe. > -----Original Message----- > From: Maurice Lombardi [SMTP:Maurice.Lombardi@ujf-grenoble.fr] > Sent: Monday, March 25, 2002 11:14 PM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 4 released > > da Silva, Joe wrote: > > > Don't worry, I'm sure Maurice will have a DJGPP port > > available for us "in due course". <G> > > > I was out of office last week for family problems. > > It is uploaded as usual under the link > > ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip > > > 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

Re: GPC 2.1 RC 4 released
by da Silva, Joe 25 Mar '02

25 Mar '02

Don't worry, I'm sure Maurice will have a DJGPP port available for us "in due course". <G> Joe. > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Tuesday, March 19, 2002 6:55 PM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 4 released > > Frank Heckenbach wrote: > > > > GPC version 20020318, the release candidate #4 for GPC 2.1, has > > been uploaded to > > > > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20020318.tar.g > z > > > > Compared to RC 3, this release contains only some minor bug fixes > > and portability enhancements. > > > > One bug in the recent OOP extensions has been fixed (thanks to > > Maurice Lombardi for the report). Some build problems on > > Cygwin/mingw have been resolved (thanks to the Chief). Some minor > > problems on Linux/S390 have been fixed (thanks to Gerhard Tonn and > > Matthias Klose for providing a test account). Some bugs regarding > > types of size 0 have been fixed (thanks to reports by Emil Jerabek). > > The cooperation with GCC patched for Cygwin/mingw, gcc-2.95.3-5, > > gcc-2.95.3-6 and gcc-2.95.4 has been improved. > > Is there a DJGPP build available, and where is it located? I > assume such will be built on gcc 2.953. > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net) > Available for consulting/temporary embedded and systems. > (Remove "XXXX" from reply address. yahoo works unmodified) > mailto:uce@ftc.gov (for spambots to harvest) > >

2 1

proper extension for interface modules
by Carel Fellinger 24 Mar '02

24 Mar '02

First let me thank all that are involved in creating this Pascal compiler on linux. You are doing a great job! It's mere exsistence and (hopefully:) its quality make it possible for me for the first time to undertake what has been a dream of me for so many years: porting this largish (over thousand prestine source files) 80's project. It went from unix pascal to VAX/VMS Pascal to MetaWare Pascal back on a sun, and now finally to Extended Pascal with gpc. I very much would like to stick to Extended Pascal as close as possible. But (un)fortunately iso10206 doesn't define all, so the first silly problem I have is that of naming the files. What is generally thought of as the proper extension to use for files holding an Extended Pascal Interface Module, and what is the proper extension for files holding the corresponding Implementation Module. Both for the simple case where each module only has one interface exported. And finally, do you deem it wise to use yet another extension to denote a file containig an Extended Pascal Program as opposed to a Module of some sort? -- groetjes, carel

2 7

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 March 2002