Gpc July 2000

gpc@gnu.de

35 participants
109 discussions

Re: fatal signal 6
by Frank Heckenbach 05 Jul '00

05 Jul '00

Marinier, M. Claude, G. wrote: > Frank, > > Thank you for your help. > > Could you be more specific with the release date? It would help me decide > whether to wait or try something else. Peter is just doing final tests. If nothing fails unexpectedly, the release should come out today. 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: fatal signal 6
by Frank Heckenbach 05 Jul '00

05 Jul '00

Mariusz Zynel wrote: > Claude, Victor and Others > > Khimenko Victor wrote: > > > > 30-Jun-00 13:16 you wrote: > > > Maruisz, > > > > > The package wants to install in /usr/local. Will this clobber (i.e. > > > overwrite) my existing gcc 2.95.2 installation? > > > > If gcc is installed in /usr/local then it CAN do it. Probability is SMALL, > > though: files common for gcc and gpc should be equal anyway. > > Victor is right. Since my package is based on gcc 2.95.2, I think > common files i.e. libgcc.a, collect2 and specs should be equal up > to functionality. One problem I've seen with libgcc.a: It contains common code used by all compilers and some special code for C++ (and perhaps other languages such as Fortran). So, if the GPC binary was built with C++ disabled, the libgcc.a might be missing this code, causing C++ programs to fail. However, GPC does not add special code to libgcc.a (all of GPC's runtime code is in libgpc.a), so keeping (or restoring) the libgcc.a from the GCC installation is safe for C and C++, and should work for GPC as well. > Files my differ due to compiler used. Please, > correct me if I'm wrong. Different compiler versions might have slightly different libgcc.a's (though I've done a mixed C/C++/Pascal project with different versions of GCC, G++ and GPC, and it was linked without problems under Solaris and Linux), but in this case there's no danger of overwriting files because the compiler backend version (e.g., 2.95.2) is part of the directory name. > Sorry List for being a bit OT, Not really, IMHO. :-) 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:
by Frank Heckenbach 04 Jul '00

04 Jul '00

Nathalie Jarosz wrote: > > > I have change of system: from linux, I am on a Unix workstation and when > >I > > > compile program which used to work under linux, the following message > > > appears: > > > "Internal compiler error in 'emit_library_call_value', at calls.c:3198" > > > > > What does it mean? > > > >Exactly what it said: you just found bug in GPC itself (calls.c is part of > >GPC). In such cases you REALLY must supply all details: > > 1. What type of unix you are using (CPU version, OS version, etc). > Sun Microsystems Inc. SunOS 5.7 > > > 2. What type of GPC you are using (built against GCC v..., GPC v..., > >etc). > gpc version 19991030 based on 2.95.2 19991024 > > > 3. Sample code to get internal error. > ? > > Here is the routine which is involved: > > function travel(djk:real;md:mat;A:minitable;Ak:real;ns,j:integer):real; > {probability of an individual leaving patch j to reach patch k} > const > alpha = 4.910; > zim = 0.263; > lambda = 0.175; > var > Sj,t : real; > begin > Sj:=connect(md,A,ns,j); > t:=(exp(-alpha*djk)*pow2(Ak,zim))/((lambda/Sj)+Sj); > travel:=t; > end; This is exactly the same GPC bug that Clyde Meli has just reported. As I wrote last night, this bug has been fixed meanwhile. According to the `Fixed Bugs' section in the To-Do list <http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html>: 20000503: Sparc: division by reals (fjf237.pas, matt1.pas) or `Round (real_constant)' (chaput1.pas) make the compiler crash <199911040915.KAA11168@@humulus.daimi.au.dk> (Sparc is the processor used in Sun's machines.) Until there is a new GPC release with this bug fixed, you can work around by type-casting the constants to Real: const alpha = Real (4.910); zim = Real (0.263); lambda = Real (0.175); 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: beta distribution
by Nathalie Jarosz 04 Jul '00

04 Jul '00

>From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> >To: Nathalie Jarosz <jarosz_n(a)hotmail.com>, gpc <gpc(a)gnu.de> >Subject: Re: beta distribution >Date: Fri, 30 Jun 2000 17:48:58 +0200 >Well it is simple enough to be made by hand (there are no dependencies). >With GNU tools type: > >cd src >gcc -c -O2 com.c >gcc -c -O2 linpack.c >gcc -c -O2 randlib.c ># ^uppercase: meand Optimize ># at this point you have created com.o linpack.o randlib.o ># to put them in a library librandlib.a type: >ar -rv librandlib.a com.o linpack.o randlib.o >ranlib librandlib.a ># ^ no d: it is a system function > >#then move librandlib.a into a system wide library directory e.g. >/usr/local/lib ># randlib.h include >/usr/local/include All seems to be ok until here but when I check the result: >#to check the result >cd ../test >gcc -O2 -o tstbot tstbot.c -lrandlib > ^lowercase: means output the following message appears: tstbot.c: In function `main': tstbot.c:11: warning: return type of `main' is not `int' Undefined first referenced symbol in file log /usr/local/lib/librandlib.a(randlib.o) pow /usr/local/lib/librandlib.a(randlib.o) sqrt /usr/local/lib/librandlib.a(randlib.o) exp /usr/local/lib/librandlib.a(randlib.o) ld: fatal: Symbol referencing errors. No output written to tstbot collect2: ld returned 1 exit status What is the problem now? Thanks in advance, Nathalie ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

2 1

Re: Internal compiler error - bug
by Clyde Meli 04 Jul '00

04 Jul '00

> > I fixed the problem termporarily by commenting out (fmultiple - 1.0) as it is > > equal to 1.0 currently, and by replacing fmultiple in the other > > assignment (b:=uavg*(umax- etc.) by real(2) instead. It seems writing the > > constant there triggered a problem with the compiler. > > Indeed, this was a GPC bug that has been fixed meanwhile. According > to the `Fixed Bugs' section in the To-Do list > <http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html>: > > 20000503: Sparc: division by reals (fjf237.pas, matt1.pas) or > `Round (real_constant)' (chaput1.pas) make the compiler crash > <199911040915.KAA11168@@humulus.daimi.au.dk> > > Unfortunately, there's been no GPC release since 2000-05-03, so > please either wait for the next release, or use the type-casting > workaround in the first assignment as well (this should work, I > think -- can't verify it, since my development compiler doesn't have > this bug anymore): > > a:= (Real (fmultiple) - 1.0) * uavg / delta; > > Frank Ok, thank you very much. I think I can use it as it is. With the previous version I had problems with enumerated types in case statements, now it seems they work fine. Regards, Clyde

1 0

Re:
by Nathalie Jarosz 04 Jul '00

04 Jul '00

>From: "Khimenko Victor" <gpc(a)khim.sch57.msk.ru> >To: jarosz_n(a)hotmail.com, gpc(a)gnu.de >Subject: Re: >Date: Thu, 29 Jun 2000 00:53:40 +0400 (MSD) > >28-Jun-00 15:31 you wrote: > > Hello all! > > > I have change of system: from linux, I am on a Unix workstation and when >I > > compile program which used to work under linux, the following message > > appears: > > "Internal compiler error in 'emit_library_call_value', at calls.c:3198" > > > What does it mean? > >Exactly what it said: you just found bug in GPC itself (calls.c is part of >GPC). In such cases you REALLY must supply all details: > 1. What type of unix you are using (CPU version, OS version, etc). Sun Microsystems Inc. SunOS 5.7 > 2. What type of GPC you are using (built against GCC v..., GPC v..., >etc). gpc version 19991030 based on 2.95.2 19991024 > 3. Sample code to get internal error. ? Here is the routine which is involved: function travel(djk:real;md:mat;A:minitable;Ak:real;ns,j:integer):real; {probability of an individual leaving patch j to reach patch k} const alpha = 4.910; zim = 0.263; lambda = 0.175; var Sj,t : real; begin Sj:=connect(md,A,ns,j); t:=(exp(-alpha*djk)*pow2(Ak,zim))/((lambda/Sj)+Sj); travel:=t; end; Thanks in advance for your help, Nathalie ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

type ^T_Str_t generates a parse error
by Marten Jan de Ruiter 04 Jul '00

04 Jul '00

Hello all, I am trying to port a large program written on a SUN to linux using gpc. So far it goes well, but I run into an error. type T_PtrStr_t = ^TZ_Str_t; compiles perfectly, while type T_PtrStr_t = ^T_Str_t; generates a warning: warning: identifiers should not start with an underscore parse error before `;' I have added the transcription of the session using an as small as possible program. For clarity, the difference between the two source files is the removal of the three Z's: two in the type declaration and one in the var declaration. Can someone point out what is wrong with the compilation of the second program? Thanks in advance, Marten Jan de Ruiter mailto:m.j.deruiter@wbmt.tudelft.nl 37 % cat -n pointertypeOK.p 1 program pointertypeOK; 2 3 type 4 TZ_Str_t = string[6]; 5 T_PtrStr_t = ^TZ_Str_t; 6 7 var s: TZ_Str_t; 8 p: T_PtrStr_t; 9 10 begin 11 s:='world!'; 12 p:=addr(s); 13 writeln('hello ',p^); 14 end. src 38 % gpc pointertypeOK.p -o pointertypeOK src 39 % pointertypeOK hello world! src 41 % cat -n pointertypeNO.p 1 program pointertypeNO; 2 3 type 4 T_Str_t = string[6]; 5 T_PtrStr_t = ^T_Str_t; 6 7 var s: T_Str_t; 8 p: T_PtrStr_t; 9 10 begin 11 s:='world!'; 12 p:=addr(s); 13 writeln('hello ',p^); 14 end. 42 % gpc pointertypeNO.p -o pointertypeNO pointertype.p:5: warning: identifiers should not start with an underscore pointertype.p:5: parse error before `;' pointertype.p:5: extra semicolon pointertype.p:5: extra semicolon pointertype.p:8: type name expected, identifier `T_ptrstr_t' given pointertype.p: In function `program_Pointertype': pointertype.p:12: incompatible types in assignment pointertype.p:13: invalid type argument of ``^''

2 2

Re: type ^T_Str_t generates a parse error
by Frank Heckenbach 04 Jul '00

04 Jul '00

Marten Jan de Ruiter wrote: > I am trying to port a large program written on a SUN to linux using gpc. So far > it goes well, but I run into an error. > type T_PtrStr_t = ^TZ_Str_t; compiles perfectly, while > type T_PtrStr_t = ^T_Str_t; generates a warning: > warning: identifiers should not start with an underscore > parse error before `;' > > I have added the transcription of the session using an as small as possible > program. For clarity, the difference between the two source files > is the removal of the three Z's: two in the type declaration and one in the var > declaration. > > Can someone point out what is wrong with the compilation of the second program? This was a GPC bug that has been fixed meanwhile. According to the `Fixed Bugs' section in the To-Do list <http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html>: 19990618: the construct @samp{^f_oo} is misinterpreted as a Borland-style char constant (fjf350.pas) So, any version after this date (e.g., alpha 19990813 or the soon to come next release) will not suffer from this bug. 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

Internal compiler error - bug
by Clyde Meli 03 Jul '00

03 Jul '00

I'm compiling a PASCAL program under Solaris with gpc version 19991030 based on gcc 2.95.2. gpc --automake sgamain.pas generate.pas: In function `Prescale': generate.pas:33: Internal compiler error in `emit_library_call_value', at gcc-2. 95.2/gcc/calls.c:3198 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gpc1: gpc exited with status 1 report.pas:9: module/unit `generate' could not be compiled The code which caused the problem looks like: Procedure Prescale(umax,uavg,umin:real;VAR a,b:real); { Calculate scaling coefficients for linear scaling } CONST fmultiple = 2.0; { fitness multiple is 2 } VAR delta:real; { divisor } Begin if umin > (fmultiple * uavg - umax) / (fmultiple - 1.0) { Non-Negative Test } then Begin { Normal Scaling } Delta:=umax-uavg; a:=(fmultiple - 1.0) * uavg / delta; b:=uavg * (umax - real(2) {fmultiple} * uavg) / delta; End else I fixed the problem termporarily by commenting out (fmultiple - 1.0) as it is equal to 1.0 currently, and by replacing fmultiple in the other assignment (b:=uavg*(umax- etc.) by real(2) instead. It seems writing the constant there triggered a problem with the compiler. I don't know if this counts as a bug or not. Regards, Clyde

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