Gpc November 2001

gpc@gnu.de

28 participants
70 discussions

test results
by Russell Whitaker 30 Nov '01

30 Nov '01

Hi After editing diff file ( thanks, Maurice ), Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.3/specs gpc version 20011123, based on 2.95.3 20010315 (release) test results: # of GPC tests 2159 # of GPC tests passed 2158 # of GPC tests skipped 1 # of GPC tests failed 0 Russ

1 0

dostest crash with djgpp
by Maurice Lombardi 29 Nov '01

29 Nov '01

Hi all, I have compiled the last alpha (20011123) under DJGPP When running the test suite there is a weird crash in readb10.pas and friends (endless loop of SIGSEGV), due to a too small default stack size. The following diff to increase the stack solves the problem: --- read1.inc.orig Mon Nov 26 16:07:20 2001 +++ read1.inc Thu Nov 29 20:07:10 2001 @@ -1,5 +1,9 @@ uses gpc; +{$ifdef DJGPP} +const MinStackSize: Cardinal = $200000; asmname '_stklen'; {2 MB} +{$endif} + var dialect:string(100)='Unspecified dialect'; rangecheck :Boolean=(*@@not implemented yet True*)False; After that there is no more error, and I have uploaded the resulting bin to agnes. 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

2 1

Re: investigating a core dump...
by da Silva, Joe 29 Nov '01

29 Nov '01

I have a vague recollection (from previous discussions on the list) that this sort of problem only occurred if debugging was enabled, or am I thinking of some other problem? Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, November 29, 2001 4:20 AM > To: gpc(a)gnu.de > Subject: Re: investigating a core dump... > > Stephan Eickschen wrote: > > > > This might be a case of a known GPC problem that causes a stack > > > overflow if the loop runs very often. If it's that, than the crash > > > should occur sooner or later depending on the stack limit set. > > > > > > A work-around in this case could be to assign the loop condition > > > (substr(zeile2,1,ls)=suchstr) to a Boolean variable and test this in > > > the `until'. > > Thanks a lot! The program seems to work now... > > Fine. The GPC bug might be fixed in the not too distant future, but > I don't want to promise too much. > > 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

3 2

Re: GRX 2.4.4 pre-release
by da Silva, Joe 28 Nov '01

28 Nov '01

Yep! (Hey, it's all part of the Wirth family, right?;-) Joe. > -----Original Message----- > From: marcov(a)stack.nl [SMTP:marcov@stack.nl] > Sent: Thursday, November 29, 2001 10:16 AM > To: gpc(a)gnu.de > Subject: Re: GRX 2.4.4 pre-release > > > "Pointers: the GOTO of data structures" --- P.J. Moylan. > > Isn't Peter a Modula-2'er :-)

1 0

Re: GRX 2.4.4 pre-release
by da Silva, Joe 28 Nov '01

28 Nov '01

"Pointers: the GOTO of data structures" --- P.J. Moylan. Joe. ;-) > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, November 29, 2001 2:13 AM > To: gpc(a)gnu.de; grx(a)gnu.de > Subject: Re: GRX 2.4.4 pre-release > > Maurice Lombardi wrote: > > > Mariano Alvarez Fernandez wrote: > > > > > GrSaveContextToJpeg is a new function, the old SaveContextToJpeg lived > in the addon subdir, and I > > > didn't know if we can change it, so I had write a new one and his > pair: GrLoadContextToJpeg. Can > > Shouldn't this be `From' rather than `To'? > > > > you add it to grx.pas? > > > > OK. > > To check I have also written a demo program which is the exact > translation to pascal of > > jpgtest.c > > In doing this I have noticed a problem in the translation of passing > GrContext parameters > > to procedures/functions. In C they are passed as pointers. In Pascal the > best solution is > > usually to pass them as "var" parametrers, and this had been done > previously. > > However there is a trick in grx that when passing a NULL pointer instead > of a > > GrContext pointer, an internal GrContext is created and/or used. This > trick is > > very frequently used for the current context, and is done several times > in the > > demo program. But I know no way in Pascal to pass a nil pointer as a var > parameter. > > Null. :-) (This was introduced for exactly this purpose.) > > > So either one discards this possibility or pass the parameters as > pointers > > GrContextPtr like in C. This is not a natural way of doing in pascal but > it works. > > So we can do it with var parameters. However, I'm wondering if we > should do it. I'm not very familiar with using contexts in GRX, but > if the usual way to create them is via functions like > GrCreateContext that return pointers, then there is no disadvantage > in using pointers (in fact, it saves a `^'). But if there a > regularly situations where you have a real GrContext variable, then > it's better to use var parameters than have to use `@'. > > 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 1

Re: gpc-test-suite+rhide problems
by Per Persson 28 Nov '01

28 Nov '01

Frank Heckenbach wrote: >All RHIDE can really do is call GPC with different options (or >*perhaps* environment variables, but I don't think so). Try to see >which options it uses (don't know if/how this is possible from >within RHIDE -- if nothing else helps, you could temporarily install >in place of gpc a little script that just dumps its options). OK the problem was the option -ggdb Now it works (though rhide crashes sometimes). Thanks Per _________________________________________________________________ HÃ¤mta MSN Explorer kostnadsfritt pÃ¥ http://explorer.msn.se

1 0

investigating a core dump...
by Stephan Eickschen 28 Nov '01

28 Nov '01

Hi all, I am a little bit in trouble with gpc on solaris >gpc -v Reading specs from /home/GFZS1/gnu/gpc/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gpc version 20010924, based on 2.95.2 19991024 (release) >uname -a SunOS aida3 5.8 Generic sun4u sparc SUNW,Ultra-5_10 The program is compiled and linked without any problems. >gpc -g -o antdb3 antdb3.pas But running it yields to core dumps... I tried to investigate on it with ddd but unfortunatly, I get stucked right after the starting shot. I have to mention, that I did not write the program on my own - and I am not a pascal hacker. I used to code in pascal some years ago, but "switched" to C. Maybe some of the wizards out there is able to help me to find the "malicious" code? As far as I know, the program was original written for BorlandPascal and then transferred to AIX using "extended syntax" (?). I tested it at home on ly linux box with gpc and everything works fine. So I installed gpc on our sun's but now I am in trouble... ############################### DDD 3.0 (sparc-sun-solaris2.5.1), by Dorothea Luetkehaus and Andreas Zeller. Copyright (c) 1998 Technische Universitaet Braunschweig, Germany. (gdb) file /home/AIDA102/eicksch/bin/antdb3 Reading symbols from /home/AIDA102/eicksch/bin/antdb3...done. (gdb) set args (gdb) run Starting program: /home/AIDA102/eicksch/bin/antdb3 warning: Unable to find dynamic linker breakpoint function. warning: GDB will be unable to debug shared library initializers warning: and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x52bb8 in Kludgestreq (S1=0xff3f00c8, L1=10, S2=0xa49b8, L2=10) at /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/rts/string.pas:813 (gdb) ---- snip: string.pas ------------------------------------- 807 function KludgeStrEQ (s1: PCharsKludge; l1: Integer; s2: PCharsKludge; l2: Integer): Boolean; asmname '_p_eq'; 808 function KludgeStrEQ (s1: PCharsKludge; l1: Integer; s2: PCharsKludge; l2: Integer): Boolean; 809 var c1, c2: Char; 810 begin 811 { @@ kluuuuuudge } if l1 < 0 then begin l1 := 1; c1 := Chr (PtrInt (s1)); s1 := PCharsKludge (@c1) end; 812 if l2 < 0 then begin l2 := 1; c2 := Chr (PtrInt (s2)); s2 := PCharsKludge (@c2) end; 813 KludgeStrEQ := StrEQ (s1^[1 .. l1], s2^[1 .. l2]) 814 end; ---- snap ------------------------------------------------ Any suggestion highly appreciated, Stephan -- ---------------------------------------------------------------------- Stephan Eickschen Tel. : +49 (0)8153 28-1351 GeoForschungsZentrum Potsdam (GFZ) Fax. : +49 (0)8153 28-1207 Division 1, Section 1.2 c/o email: eicksch(a)gfz-potsdam.de DLR Oberpfaffenhofen www : http://op.gfz-potsdam.de Box 1116 82234 Wessling Germany ----------------------------------------------------------------------

3 9

Re: GRX 2.4.4 pre-release
by Maurice Lombardi 28 Nov '01

28 Nov '01

Mariano Alvarez Fernandez wrote: > GrSaveContextToJpeg is a new function, the old SaveContextToJpeg lived in the addon subdir, and I > didn't know if we can change it, so I had write a new one and his pair: GrLoadContextToJpeg. Can > you add it to grx.pas? OK. To check I have also written a demo program which is the exact translation to pascal of jpgtest.c In doing this I have noticed a problem in the translation of passing GrContext parameters to procedures/functions. In C they are passed as pointers. In Pascal the best solution is usually to pass them as "var" parametrers, and this had been done previously. However there is a trick in grx that when passing a NULL pointer instead of a GrContext pointer, an internal GrContext is created and/or used. This trick is very frequently used for the current context, and is done several times in the demo program. But I know no way in Pascal to pass a nil pointer as a var parameter. So either one discards this possibility or pass the parameters as pointers GrContextPtr like in C. This is not a natural way of doing in pascal but it works. I have thus corrected grx.pas this way, corrected makefiles and readme to include the new demo program, and also corrected vir_test.pas for the new syntax. I have checked that everything works on djgpp. All is contained in the attached grxdiff.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

2 1

Re: Installation problem ?? ( now cannot exec `cc1'...)
by Frank Heckenbach 27 Nov '01

27 Nov '01

laurent(a)laurent-parise.com wrote: > The fisrt time I compiled GPC, installation process didn't detect > gcc 2.95.3 .... I think the only change is the directory to compile : > now I use /usr/src whereas I did it in /root/tmp before.... That seems strange. The base directory should not matter. It's only important that the GPC sources are placed properly below GCC (i.e. .../gcc/p). If you did this, and still gcc-2.95.3 was not detected, I'd be interested in details so I can fix it. 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

1 0

Re: Installation problem ?? ( now cannot exec `cc1'...)
by Frank Heckenbach 27 Nov '01

27 Nov '01

laurent(a)laurent-parise.com wrote: > I put GCC (from Slack 8.0 source disk) and GPC sources in /usr/src and > proceed to installation. At the end of 'make', I read the message : > > checking if compiler f771 has been built... no > Configuring in i686-pc-linux-gnu/libchill > creating cache ./config.cache > checking if compiler cc1chill has been built... no > Configuring in i686-pc-linux-gnu/libobjc > creating cache ./config.cache > checking if compiler cc1obj has been built... no > > Do you think this is a normal message ? Yes, it is. It just notes that the Fortran, Chill and Objective C compilers were not built. I assume you didn't want to build them, so it's ok. > ('make' detected gcc 2.95.3 and > used a special patch ... ) so I run 'make pascal.install' in > 'gpc-build/gcc'. (Should I have done a 'make install' and install gcc > too ???) Yes. 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 1

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 November 2001