- Gpc - gnu.de

Re: GPC problem with redhat 9 (Linker
by Hiekkalinna Tero 10 Aug '03

10 Aug '03

> > GPC variable: > > > > % echo $GPC_EXEC_PREFIX > > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/ > > What are the contents of that directory? Here: -rwxr-xr-x 1 root root 6691112 May 11 04:49 cc1 -rwxr-xr-x 1 root root 308920 May 11 04:49 collect2 -rwxr-xr-x 1 root root 344917 May 11 04:49 cpp0 -rw-r--r-- 1 root root 1952 May 11 04:49 crtbegin.o -rw-r--r-- 1 root root 2284 May 11 04:49 crtbeginS.o -rw-r--r-- 1 root root 1952 May 11 04:49 crtbeginT.o -rw-r--r-- 1 root root 1216 May 11 04:49 crtend.o -rw-r--r-- 1 root root 1284 May 11 04:49 crtendS.o -rwxr-xr-x 1 root root 6639642 May 11 04:49 gpc1 -rwxr-xr-x 1 root root 208091 May 11 04:49 gpcpp drwxrwxr-x 5 root root 4096 Aug 1 13:48 include -rw-r--r-- 1 root root 1745556 May 11 04:49 libgcc.a -rw-r--r-- 1 root root 206352 May 11 04:49 libgcc_eh.a -rw-r--r-- 1 root root 589278 May 11 04:49 libgpc.a -rwxr-xr-x 1 root root 6777 May 11 04:49 specs drwxrwxr-x 2 root root 4096 Aug 1 13:48 units > > /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:871: undefined > reference to > > `__ctype_toupper' > > I don't know of this problem. Does such a function exist in > some library (you might want to grep for it in /usr/lib/lib* > or so ...)? > > If so, does it help if you add this library explicitly on the > command-line? If I execute command "gpc hello.pas -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/" : % gpc hello.pas -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/ /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 465): In function `_p_UpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:871: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 485): In function `_p_LoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:879: undefined reference to `__ctype_tolower' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 4a4): In function `_p_IsUpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:884: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 4c4): In function `_p_IsLoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:889: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 4e4): In function `_p_IsAlpha': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:894: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 524): In function `_p_IsAlphaNum': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:899: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 594): In function `_p_IsSpace': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:909: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 5b4):/home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:914: more undefined references to `__ctype_b' follow collect2: ld returned 1 exit status % Thanks for help! Tero

4 4

Problem on solaris
by Mehdi Khaldi 09 Aug '03

09 Aug '03

Hi, I work on a Solaris 7 plateform. GPC features are gpc version 2.1 (20020510), based on 2.95.2 19991024 (release) I have one module called sun.p : ------------------------------ Module SUN INTERFACE; export SUN = all; procedure myproc; CONST Max = 32767; Min = -32768; End. Module SUN IMPLEMENTATION; Procedure myproc; Begin Writeln('allo'); End; End. ------------------------------ I have one main program : ------------------------------ program essai; import sun; begin end. ------------------------------ When I compile with gpc. I get an error : ./src/testpascal.p:3: parse error before `1' When I watch the temporaries files, actually testpascal.i, I see "import sun" was switched by "import 1". What's wrong? Thanks

2 1

License of the GNU Pascal documentation?
by Matthias Klose 09 Aug '03

09 Aug '03

On The debian-legal mailing list there currently is a major discussion about the "freeness" of the "GNU Free Documentation License". You may want to look at the archives yourself, one point to start is http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00307.html The problem are the "Invariant Sections" of the GFDL, which make the GFDL non-free from Debian's viewpoint. Looking at gpc's documentation, I see the GFDL-1.1 (with the short example GFDL license at the end), but in the man page I only find: COPYING Copyright (c) 1997-2003 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 version published by the Free Software Foundation. A copy of the GFDL comes as a texinfo document along with the GPC manual. In contrast with copying-fdl.texi, there is no mentioning of the "Invariant Sections": "If you have no Invariant Sections, write ``with no Invariant Sections'' instead of saying which ones are invariant. If you have no Front-Cover Texts, write ``no Front-Cover Texts'' instead of ``Front-Cover Texts being @var{list}''; likewise for Back-Cover Texts." Please clarify the copyright of the man page. I'll have to remove the info and html docs from the Debian main section (maybe somebody volunteers to repackage them to the non-free section), but to keep at least the manual pages in the package I'd like to see the license of the manual pages be clarified. Thanks, Matthias

6 16

cross-referencing types
by Toby Ewing 08 Aug '03

08 Aug '03

Hi, all I'm running into a problem that I've never seen before, and hope someone here can help. I have a square grid of circles connected by lines: o--o--o--o--o | | | | | o--o--o--o--o | | | | | o--o--o--o--o The circles have different attributes; so do the lines. The basic data type I'm using is an array of pointers; each pointer points to a record of information about its circle. So far, so good. Each circle's record includes an array of pointers that point to the record of the (up to) 4 lines emanating from that circle. Likewise, I want each line record to be able to point to its two circles. This way they are cross-referential: when I'm working with a line I want to be able to find the circles it connects to, and when I'm working with a circle I want to be able to identify its (up to) 4 lines. So the code says: --------------------- type PCircle = ^CircleRec; CircleRec = record radius : double; x, y : double; t : array[0..3] of Pline; <-- "unknown identifier 'Pline'" end; Pline = ^LineRec; LineRec = record node_end : PCircle; width, length, end; Pnodary = ^nodary; nodary(wx, wy : shortCard) = array[1..wx,1..wy] of PCircle; ------------------- Naturally the compiler complains about the unknown identifier "Pline". And of course, if I reverse the order of the two records, it then complains about the unknown identifier PCircle. Is there any way to "forward declare" a record? Or am I going to have to do a serious reworking of how I handle the data? I realize of course that I could just say, I just left circle [x,y] going left, so the circle at the end of this line should be circle [x+1,y]. This utterly simple method is unfortunately not open to me, due to what data my program has access to and what it's not allowed to see. many thanks, Toby

2 2

Gcc-3.3.1 is released
by David Kredba 07 Aug '03

07 Aug '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ftp://gcc.gnu.org/pub/gcc/releases/gcc-3.3.1/gcc-3.3.1.tar.bz2 Regards, David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Msdes1v4vQGNXk8RArKpAJ9xVVGvtkUZZYO3BZf5ZLkk/gJC3ACcDImI xJWE3FnlreZ2u27erc2Vvo4= =TQX1 -----END PGP SIGNATURE-----

1 0

Re: range check test programs
by Mirsad Todorovac 07 Aug '03

07 Aug '03

On Sat, 12 Jul 2003, Frank Heckenbach wrote: [...] > Perhaps you've missed Francois' previous mail where he quoted the > items I have thought of already (appended below). If you can think > of more (which Francois didn't already write), fine, but first we > need someone to write those tests. Sure. Here is the point when I think I've done what I could. Let's go step by step with this list (I'm sorry if I'm repepating something that has been said already, but the list archive appears to be out :-(: > > > What's missing is a test where the formal discriminants are of a > > > subrange type and the actual discriminants (in `New' or a variable > > > declaration) are out of range. TEST mir040a.pas: gpc1: warnings being treated as errors ./mir040a.pas: In main program: ./mir040a.pas:34: warning: tag value must be a constant of ordinal type failed (I think it could be the problem in GPC, since the code is precisely the same, as with integer subrange bounds conformant arrays.) Am I allowed to suppress this specific warning, is it possible to do suppress it, or have I done something wrong? (mir040a.pas is in attachment.) > > > Initialization of types, variables and typed constants. (I.e., > > > variables (or fields) or subrange type with an out-of-range > > > initializer; must be locally, otherwise GPC won't accept > > > non-constants initializers.) Done. mir041[ceil][ul].pas > > > The `FillChar' test (fsc20.pas) shouldn't (I think) work like this > > > since it takes an untyped parameter. (Some people (ab)use it for > > > strange purposes.) Instead, the 3rd parameter may also be an > > > integer, so it's an error if it's < 0 or > Ord (MaxChar). Done: mir042[ul].pas > > I've found some more missing cases: > > > > - `Return' (where the result type is a subrange and the `Return' > > value is out of range) Done. mir0{24c[ul],25[ei][ul],26l[ul].pas > > - `Pack', `Unpack' (the index parameter) Done. mir03[56]*.pas > > - `Include', `Exclude' Done. mir028*.pas > > - `Inc', `Dec' Done. mir027*.pas > > - 4th parameter of `BlockRead', `BlockWrite' (not obvious, but GPC > > allows a subrange here which may be too small for the actual > > result) Done. mir039*.pas > > - `Val' (2nd and 3rd parameter) Done 2nd parm. mir034[ab].pas Q: What is the legal range for 3rd parm of Val? > > - `and', `or', `xor', `shl', `shr' used as procedures, e.g., if a is > > of type 1 .. 10: a := 5; or (a, 8) (whereas normal use as > > operators will be covered by assignments or whatever is done with > > them) Done. mir03[0-3]*.pas > > - Conformant arrays (i.e., where the index type in the conformant > > array in the formal parameter list is a subrange, and the actual > > parameter's range is too big -- check both bounds) Integer subrange Done. Problems with Char and enumerated subranges. I can confirm that it gives me this error: TEST mir038ea.pas: ./mir038ea.pas: In main program: ./mir038ea.pas:29: invalid operands to binary `+' ./mir038ea.pas:29: incompatible type for argument 1 of `conformantArray' ./mir038ea.pas:11: routine declaration failed {$gnu-pascal} program mir038ea; {slice array write, what Francois has done for Integer here is for subrange} uses GPC; type TGrayScale = (Black, Gray10, Gray20, Gray30, Gray40, Gray50, Gray60, Gray70, Gray80, Gray90, White); TMidTones = Gray30..Gray70; var v : array[1..100] of Integer; i,j : TGrayScale; procedure conformantArray(a: array[l..u : TMidTones] of Integer); begin end; procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end; begin AtExit(ExpectError); i:=Gray30; j:=White; {j > upper} conformantArray(v[i..j]); end. > > - `New' with variant records (where the variant tag is of subrange > > type) See the generated warning in test above. > > - sets (e.g., assigning a set of a larger range to one of a smaller > > range where the former contains out of range elements) Done. mir029*.pas Conclusion: 1. variant record warning 2. Val's 3rd parameter 3. Possible bug with conformant arrays when bounds are of Char subrange, confirmed it occurs with enumerated subranges too 4. All tests WILL AND MUST give "failed" if you don't have range-checking compiler, with range-checking on, they should give OK The latest result is at http://www.alu.hr/~mtodorov/pascal/rngv0.03.tar.gz There is significantly more of them now than in v0.02, and some bugs are fixed. I think we're moving somewhere. Have a nice day, Mirsad -- "I have a dream!" -- Martin Luther King Jr.

4 21

GPC problem with redhat 9 (Linker problem?)
by Hiekkalinna Tero 06 Aug '03

06 Aug '03

Hi, I have problem with GPC under Redhat 9 (x86), I have installed GPC (version: gpc-20030507-with-gcc.i686-pc-linux-gnu.tar.gz) according to install instructions. And after that I run install-gpc-binary shell script (in /usr/local dir.) which told GPC install was OK, and told to add GPC_EXEC_PREFIX variable to enviroment. here is more info GPC version: % gpc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs Configured with: ../gcc-3.2.2/configure --enable-languages=pascal --prefix=/usr/local Thread model: posix gpc version 20030507, based on gcc-3.2.2 GPC variable: % echo $GPC_EXEC_PREFIX /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/ If I just compile example hello.pas, not link it: % gpc hello.pas -o hello It's fine and object file is created. BUT if I want to link it as well to binary I get lot's of errors: % gpc hello.pas -o hello /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 65): In function `_p_UpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:871: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 85): In function `_p_LoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:879: undefined reference to `__ctype_tolower' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 a4): In function `_p_IsUpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:884: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 c4): In function `_p_IsLoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:889: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 e4): In function `_p_IsAlpha': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:894: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5 24): In function `_p_IsAlphaNum': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:899: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5 94): In function `_p_IsSpace': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:909: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5 b4):/home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:914: more undefined references to `__ctype_b' follow collect2: ld returned 1 exit status % Have I missed something from installation or is there something I need to fix? THANKS FOR HELP!! Best Regards, Tero Hiekkalinna

3 2

Units and --uscd-pascal
by Adriaan van Os 05 Aug '03

05 Aug '03

[G4:~/gnu/testgpc/adriaan] adriaan% cat unita.pas unit A; interface end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c unita.pas --ucsd-pascal unita.pas:2: error: units are an extension of Borland Pascal, traditional unita.pas:2: error: Macintosh Pascal UCSD Pascal certainly supports units. unita.pas:3: error: units without `implementation' part are an extension of unita.pas:3: error: traditional Macintosh Pascal UCSD Pascal also supports units without 'implementation part', or at least Apple UCSD Pascal does. Regards, Adriaan van Os

5 21

bug report
by John Ollason 04 Aug '03

04 Aug '03

Attempting to compile the following code ------------ program objtest(input,output); type obj=object a:integer; constructor initialize; end; procedure obj.initialize; begin a:=3; end; var a,b:obj; begin b.a:=0; a.initialize; b:=a; writeln(b.a); end. ------------------- I received the following error message: -------------- cd ~/pas/ gpc objtest.p objtest.p: In function `Obj_Initialize': objtest.p:10: Internal compiler error in `yyparse', at parse.y:3601 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. Compilation exited abnormally with code 1 at Sun Aug 3 16:57:52 ______________ and I am complying with the instruction to report the error, though when I went to the above URL I found that it was dealing with C++ so I thought that I ought to mention it here. Details Red Hat Linux release 7.3 (Valhalla) Kernel 2.4.18-3 on an i686 gpc --version gives 2.1 (200205), based on gcc-2.95.4 20010315 (release) (I realise that I should have written constructor obj.initialize; and when I do that the program compiles, but in view of the instruction in the error message I am writing to the mailling list.) (If this is the wrong thing to do, I'm sorry.) John O.

2 1

Undetected errors on multiply imported identifier with conflicting definitions
by Gale Paeper 03 Aug '03

03 Aug '03

Extended Pascal allows for importing an identifier of the same spelling in the same scope through multiple interfaces as long as all the imports "denote the same value, variable. procedure, function, schema, or type". If they do not denote the same thing then there is an error of multiple defining-points for the identifier being imported through multiple interfaces. (See ISO 10206 paragraphs 6.2.2.7 and 6.11.3 for the requirements language.) While GPC does allow for the import of an identier through multiple interfaces, GPC does not enforce the requirement that all the imports denote the same thing. Is this a known bug in GPC's support for Extended Pascal? A test program demonstrating the problem: {$extended-pascal} program grp1(input, output); {Undetected import error. Type identifer 't1' imported through grp1b does not denote the same type as type identifier 't1' imported through grp1a.} import grp1a; grp1b; begin writeln('FAIL'); end. {$extended-pascal} module grp1a; export grp1a = (t1); type t1 = char; end; end. {$extended-pascal} module grp1b; export grp1b = (t1); type t1 = integer; end; end. compiled with: gpc --automake -v grp1.pas -o grp1 Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin/3.3/ -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__DYNAMIC__ grp1.pas -fautomake -famtmpfile=/var/tmp//ccgw5pLe.gpa /var/tmp//ccZXMYCf.i GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3 (Darwin/PowerPC) /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpc1 /var/tmp//ccZXMYCf.i -fPIC -quiet -dumpbase grp1.pas -auxbase grp1 -version -fautomake -famtmpfile=/var/tmp//ccgw5pLe.gpa -o /var/tmp//cc3HAIMV.s GNU Pascal version is actually 20030507, based on gcc-3.3 GNU Pascal version 3.3 (powerpc-apple-darwin) compiled by GNU C version 3.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin/3.3/ -M -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__DYNAMIC__ grp1a.pas -o /var/tmp//ccoq7D0z -fautomake -famtmpfile=/var/tmp//ccgw5pLe.gpa GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3 (Darwin/PowerPC) Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin/3.3/ -M -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__DYNAMIC__ grp1b.pas -o /var/tmp//ccEGg8MF -fautomake -famtmpfile=/var/tmp//ccgw5pLe.gpa GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3 (Darwin/PowerPC) as -o /var/tmp//ccHb3AkK.o /var/tmp//cc3HAIMV.s /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/collect2 -dynamic -o grp1 -lcrt1.o -lcrt2.o -L/Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3 -L/Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/../../.. grp1b.o grp1a.o /var/tmp//ccHb3AkK.o -lgpc -lgcc -lSystem | c++filt3 Gale Paeper gpaeper(a)empirenet.com

2 1