Gpc September 1999

gpc@gnu.de

44 participants
93 discussions

Internal compiler error with arithmetic or arrays?
by Matthias Friedrich 05 Sep '99

05 Sep '99

Hello! Who can help me with my gpc-compiler error? I think its an arithmetic problem, maybe the declaration of Single-Arrays... The following code produces an 'Internal compiler error: program gpc1 got fatal signal 6' on my Solaris2.6 system: function GetdtCourant:Single; var i,j,k:Integer; du,dv,dw:Single; dtmax,dthier:Single; begin dtmax:=10.0; if LowWindMode then dtmax:=0.1; For k:=1 to KK DO For j:=1 to JJ DO For i:=1 to II DO if h_c[i,j,k]=1 then begin du:=abs((0.5*(UU[i,j,k]+UU[i+1,j,k]))/dx[i]);gpc: Internal compiler error: program gpc1 got fatal signal 6 If I replace 'dx[i]' with '2' or '2.5', it works. (I find it strange...) For better debugging I append the declaration of all variables and constants: UNIT Stroemtest; INTERFACE function GetdtCourant:Single; const max_x=70; const MAX_Y=70; const MAX_Z=32; const maxCFLStep:Single=1.0; const ee:Single=1*10e-10; const courantfactor:Single=1.0; const MAX_Zges=32+15; type maingrid= Array[1..max_X,1..Max_Y,0..Max_Z] of Single; var uu: maingrid; vv: maingrid; ww: maingrid; LowWindMode: Boolean=false; II: SmallInt; JJ: smallInt; KK: Smallint; H_c: Array[1..max_X,1..Max_Y,0..Max_Z] of Byte; dx: Array[0..Max_x] of Single; dy: Array[0..Max_y] of Single; dz: ARRAY[0..MAX_Zges] of Single; IMPLEMENTATION function GetdtCourant:Single; var i,j,k:Integer; . . . . ==> great thanks for helping Matthias _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ - Matthias Friedrich - email: mafri(a)ipg.uni-freiburg.de

1 0

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote: >> That's not covered in the original code. Since I've never heard of >> fwrite returning less than -1, I think it is as correct as the >> original code. > I'm suggesting that perhaps you stumbled across a proper bug. According > to the man pages fwrite returns 0 on error and >0 on success. Indeed. So you (we, if you will :-) don't even need ssize_t, size_t and `== 0' will do. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

Re: option for file name input supression
by Tom Schneider 05 Sep '99

05 Sep '99

Peter: For folks on the mailing list, the issues I'm concerned with are: 1. Gpc asks for file names. I have some 200 pascal programs http://www.lecb.ncifcrf.gov/~toms/delila/delilaprograms.html and each uses as many as 10 file names. Typing all this is a waste of my time. No other compiler I've encountered (Sun, vax, CDC Cyber (!)) does this. So I'm suggesting that there be an option on gpc to simply use the file name given in the header line of the program. 2. When gpc asks for the file name, it capitalizes it. On Unix file names are case sensitive, so this is setting up for confusion and ambiguity. So I am suggesting that file names be left alone. No changing of case from what the user does. ... > > I can't do this because it would force my 200 programs to become compiler > > specific. No compiler I have encountered in the past 15 years ever forced me > > to do this. > > So all standard Pascal compilers use the same mechanism to > derive the external file name from the variable name? > Interesting. If so, GPC should do the same. Well, I don't know about ALL or how standard they are. I am currently working on Sun's rather stable complier (but hey, I found bugs in it too!! ;-). The CDC Cyber - an ancient beast running an OS called Kronos - had a really neat feature that I was sorry to see go when I went to Unix. One would type the program name followed by a series of file names: for program x(a,b,c,d,output); one could type x,1,,2,3 Kronos would: map 1 to a use file b for b map 2 to c map 3 to d That was rather handy and very quick to type. Such an option - in which if one didn't type anything at all one would get all file names to default - would be VERY handy. > How do they deal with inconsistent capitalization? Sun flags it as an unidentified symbol: program x(output); var a: integer; begin A := 5; end. 4 A := 5; E 18420---------^--- Undefined variable In program x: E 18240 A undefined on line 4 So it evidently just treats "a" and "A" as different symbols. program x(output); var a: integer; A: char; begin a := 5; A := '!'; end. I tried that and it compiled just fine. > > Is it really that difficult to have an option to just use the name as given > > in the header line? [...] > > The only problem is the capitalization issue; see below. > > > While it may be true that Pascal is supposed to be case-insensitive, it turns > > out that under Solaris it is case sensitive. This has already forced me to > > be *consistent* with the names I use, which is not unreasonable. > > Yes, I am also consistent with capitalization of my Pascal > sources, but the compiler must not depend on this. This is a matter of standards. It actually scares me that one can have that second program above and not realize the situation! However, I DO like the idea of being consistent throughout the program: either A or a, but not both. I do not like the idea of the program changing the capitalization that I set. > > It seems to me that you must have put a mechanism IN to capitalize the first > > letter. All I'm saying is that it would be best simply to remove that > > mechanism. It would be simpler, cleaner and never confusing. > > It would make user identifiers crash with libc functions while > linking. Oy. I had this problem when I first started working with Sun. It is irritating!!! In Pascal I used to have my main procedure named ... main of course. Well that is illegal because it conflicts with the underlying C compiler! (I renamed them 'themain', ugh.) What's really annoying is that I could easily have a variable named main inside the procedure, since its scope would be protected. *************************************************************** * SCOPE SOLUTION: * * Why can't the concept of symbol scope be applied to the * * entire program? Then there would be no conflict at all and * * Pascal names would be independent of the damn C complier * * names!!! * *************************************************************** On the Sun compiler, this code compiles just fine: program x(output); var a: integer; A: char; procedure x(z: char); procedure main(j: char); begin writeln(output,j); end; begin main(z); end; begin a := 5; A := '!'; x(A); end. Though the following compiles, it fails rather weirdly: program x(output); var a: integer; A: char; procedure main(z: char); procedure themain(j: char); begin writeln(output,j,' in themain'); end; begin writeln(output,z,' in main'); themain(z); end; begin a := 5; A := '?'; main(A); end. gives: ----- in main in themain ---- So using the word 'main' messes up the variable transfer. If I change the name to xmain, it works ok: ---- ? in main ? in themain ---- > What we could do is to keep the capitalization of the first > occurrence of each identifier for use with the option you are > suggesting. My initial suggestion was that if you are going to ask for file names, the string you should give should match the name in the pascal program header. *Anything* *else* is setting up for confusion on the part of the user! > It would also be a good thing for error messages and such. No, it would lead to confusion on operating systems like Unix which are case sensitive for file names. Just leave the names alone, don't modify them. > For public names however, we must use something that > does not overlap with the name space of the C library. See above scope suggestion. > Introducing this would be non-trivial. It would also be > possible (and much easier) to put the identifier into lower case > in order to derive the file name. If you make *ANY* changes in the name, you are setting it up to cause trouble at some point. I would think that ignoring the case would be simpler. > Since the discussion is now about suggested changes to GPC, > I think it's really time to move it to the GPC mailing list > <gpc(a)gnu.de>. Be welcome to forward or cite my mail there. Ok, here goes! Hmm. Thats funny. On http://agnes.dida.physik.uni-essen.de/~gnu-pascal/support.html#archives it gives gpc(a)hut.fi. as the mailing list name. Which is correct? (While we are at it, would you mind removing the periods at the ends of emails and urls on that page? They make it harder to cut and paste. Thanks.) > Thanks for your thoughts, You're welcome. > Peter > > -- > Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ > Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 > PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 > *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ *** Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

1 0

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Nick Burrett 05 Sep '99

05 Sep '99

Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: > On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote: > > > Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: > > >> +++ gcc/p/rts/file.c Sun Aug 29 15:56:11 1999 > >> @@ -887,7 +887,7 @@ > >> _p_f_write (File, Buf, Size) > [snip] > >> - ssize_t result = > >> + size_t result = > [snip] > >> - if (result < 0) > >> + if (result == (size_t)-1) > > > You cannot do this. size_t may be unsigned. > > That's the reason why I'm explicitly casting -1 to that type. > > > Also fwrite returned zero on error > > That's not covered in the original code. Since I've never heard of > fwrite returning less than -1, I think it is as correct as the > original code. I'm suggesting that perhaps you stumbled across a proper bug. According to the man pages fwrite returns 0 on error and >0 on success. This is why I originally suggested that your fix may be not quite correct. We'll come up with a proper solution if you want. Cheers, Nick.

1 0

GNU pascal installation problem
by Konstantin R.Beliaev 05 Sep '99

05 Sep '99

Hello! I'm trying to install the GNU pascal (version gpc-19990118 + gcc-2.8.1) on FreeBSD 2.2.8, but without success. The installation stops when I "make LANGUAGES=pascal" with message "`all' not remade because of errors". The latest command the script executes is "gcc -DIN_GCC -g -DHAVE_CONFIG_H obstack.o ` case "gcc" in "cc") echo "" ;; esac ` -o c++filt cxxmain.o underscore.o getopt.o getopt1.o" Please, HELP ! Reply to my e-mail: konst(a)RL7.bmstu.ru With hope, Konstantin

2 1

Help! Nothing runs
by John L. Ries 05 Sep '99

05 Sep '99

I installed the latest GPC beta (gpc-19990118) on a DEC3000/800 (Alpha) running Digital UNIX 4.0B and was able to compile and install without difficulty. However, anything I compile gives me the following error message when run: internal error: duplicate constructor No coredump or anything else is produced. I compiled on top of GCC 2.8.1. 128 MB of RAM is installed. I uninstalled the DEC Pascal runtime to insure no conflict. John L. Ries System Administrator Salford Systems Phone: (619) 543-8880 x25 Fax: (619) 543-8888 E-Mail: jries(a)salford-systems.com

2 2

Unsubscribe
by John Herbster 05 Sep '99

05 Sep '99

I wish that you were a NEWSGROUP instead of just a mailing list. I =would have read a lot more of the messages. John Herbster, Herbster Scientific, 12807 Park Royal, Houston, TX w077-2249, Phn:281-531-4423, herb-sci(a)swbell.net, Elders Unite Against =Ignorance and Stupidity

2 1

`IN' operator warning
by GPC on Ken Linder's Linux Box 05 Sep '99

05 Sep '99

I have the following simple program: program fooin; var s1, s2, s3 : integer; begin s1 := 1; s2 := 3; s3 := 5; if 10 in [s1, s2, s3] then writeln('OK') else writeln('not OK') end. The code itself executes ok but at compilation gives this warning: fooin.pas:8: warning: constructing limited integer set '0..255' Does this mean I can compare a single ordinal (LHS) to a set with a maximum number of elements of 255 (RHS) ? TNX Ken Linder http://kc7rad.lvcm.com/

2 1

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote: > Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: >> +++ gcc/p/rts/file.c Sun Aug 29 15:56:11 1999 >> @@ -887,7 +887,7 @@ >> _p_f_write (File, Buf, Size) [snip] >> - ssize_t result = >> + size_t result = [snip] >> - if (result < 0) >> + if (result == (size_t)-1) > You cannot do this. size_t may be unsigned. That's the reason why I'm explicitly casting -1 to that type. > Also fwrite returned zero on error That's not covered in the original code. Since I've never heard of fwrite returning less than -1, I think it is as correct as the original code. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

I've been trying to build gcc 2.95.1 with gpc 19990813 on a couple of platforms. I had to apply the attached patch in order to get them to build xgpc and gpc1 in stage2, but this was useless on at least one platform (alphaev56-dec-osf4.0d), in which that gpc1 would print: ../../xgpc -B/n/gnu/gcc-2.95.1-gpc-19990813-libg++-2.8.1.3-libgcj-2.95.1/alphaev56-dec-osf4.0d/bin/ -B../../ -c -I. -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -O4 -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/usr/local/tmp/install-gnu-gcc-2.95.1-gpc-19990813-libg++-2.8.1.3-libgcj-2.95.1-bela-8709/libg++-2.8.1.3/gcc/p/rts --automake heap.pas error.pas: In function `Geterrormessage': error.pas:362: Internal compiler error in `copy_to_mode_reg', at explow.c:669 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gpc1: ../../xgpc exited with status 1 heap.pas:30: module/unit `error' could not be compiled It is worth noting that the directory pointed to by the first -B argument does not exist yet, so it is definitely using the just-built gpc1. If you need further informations, I'd be glad to provide, but make sure you Cc:me, since I'm not subscribed in this list. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

3 3

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 September 1999