- Gpc - gnu.de

Out of town
by Frank Heckenbach 15 Jul '04

15 Jul '04

I'll be out of town for 2 1/2 weeks. I'll probably read and perhaps reply to email occasionally, but don't expect timely reponses from me ... As far as the integer type are concerned, I hope the discussion will be finished until I return (if there's anything more to say), so I can then make the necessary changes. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

gpc-20040516 for AMD64 (Linux)
by Prof A Olowofoyeku (The African Chief) 12 Jul '04

12 Jul '04

Hi I have built gpc-20040516 for AMD64 (platform: Fedora Core 2, 64-bit). Binaries can be obtained here: http://gnu-pascal.de/contrib/chief/fedora-2/ Built and tested on an Athlon-64 3.2+, the testsuite ran fine, except for these: TEST asmtest.pas: SKIPPED: only for IA32 TEST az20.pas: ./test_run: line 334: 4929 Segmentation fault ./"$A_OUT" "$1" TEST confarr5.pas: ./test_run: line 334: 9516 Segmentation fault ./"$A_OUT" "$1" TEST fjf746.pas: ./test_run: line 334: 14662 Segmentation fault ./"$A_OUT" "$1" TEST fjf746.pas: ./test_run: line 334: 14662 Segmentation fault ./"$A_OUT" "$1" TEST jj5.pas: SKIPPED: `attribute (stdcall)' not available TEST martin3.pas: ./test_run: line 334: 27275 Segmentation fault ./"$A_OUT" "$1" TEST pack10.pas: ./test_run: line 334: 30277 Segmentation fault ./"$A_OUT" "$1" TEST pack5.pas: ./test_run: line 334: 30396 Segmentation fault ./"$A_OUT" "$1" One curious thing. "Writeln (sizeof (Integer))" prints "4", as does "Writeln (sizeof (Cardinal))". Shouldn't these be 64-bit? Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

6 29

Integers
by Prof. Harley Flanders 12 Jul '04

12 Jul '04

Tower of Babel! It later grows higher to CUnsignedLongLongLong, CUnsignedLongLongLongLong,... Ugh! The "C-like" names are makeshift and awful, with no room for expansion. Whatever the names are forced to be by historical considerations, why not the simple alternative nomenclature: Signed: Unsigned: Int8 UnsInt8 Int16 UnsInt16 Int32 UnsInt32 Int64 UnsInt64 Int128 UnsInt128 Int256 UbsInt256 ...... ......... With these names you know exactly where you're at, and when 512 bit computing... becomes available, extending the list will be a piece of cake. Harley Flanders ----- Original Message ----- From: Frank Heckenbach To: gpc(a)gnu.de Sent: Sunday, July 11, 2004 2:53 PM Subject: Re: Making Integer bigger ? Adriaan van Os wrote: > I agree on the size issue, but not on the proposed nomenclature. Since > the purpose of the C-type names is C-header conversion, C-like names > will be more practical. > > CChar > CSignedChar > CUnsignedChar > CShort > CSignedShort > CUnsignedShort > CInt > CSignedInt > CUnsignedInt > CLong > CSignedLong > CUnsignedLong > CLongLong > CSignedLongLong > CUnsignedLongLong =========================================== Prof. Harley Flanders 3533 Windemere Court Ann Arbor, MI 48105-2867 Home: 734 668 1546 harley(a)umich.edu ===========================================

2 1

gpc 20040516 binary on suse 9.x
by Matthias Schweinoch 12 Jul '04

12 Jul '04

hi all, i tried the gpc binary (20040516 with gcc backend, i686 pc linux) on my debian woody box, and it ran smooth. i then tried to get that same package running on a suse linux box (running 9.1, i believe), and this is what it gives me when i try to compile the very same pascal program that worked on my debian box: --- output starts --- uhle@linux:~> gpc kreis3.p /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 5e3): In function `_p_UpCase': /home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:899: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 603): In function `_p_LoCase': /home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:906: undefined reference to `__ctype_tolower' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 622): In function `_p_IsUpCase': /home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:911: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 642): In function `_p_IsLoCase': /home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:916: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 662): In function `_p_IsAlpha': /home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:921: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 6a2): In function `_p_IsAlphaNum': /home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:926: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 712): In function `_p_IsSpace': /home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:936: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 732):/home/frank/gpc/gcc-3.3.3/gcc/p/rts/rts.c:941: more undefined references to `__ctype_b' follow collect2: ld returned 1 exit status --- output ends --- i'm slightly lost here: this seems to be a linking problem, but AFAIK the gcc 3.3.3 backend is included with the GPC package. anyone know why this happens? (or better yet: why does it happen on the suse box, but not on the debian box?). oh, btw, the version of GPC is: gpc 20040516, based on gcc-3.3.3 thanks for your help in advance! matthias schweinoch

4 3

Re: page function
by Tom Schneider 11 Jul '04

11 Jul '04

Thanks Emil and Frank for clarifying the page function issue. > http://www.gnu-pascal.de/gpc/Page.html > as "Page is an ISO 10206 Extended Pascal extension." | Yes, the GPC docs are wrong, `page' is ISO 7185. I see that this is still there - is there a mechanism for making sure it gets fixed? Also, it would be very useful to have the ISO definitions listed all on one page and for the url given above and all others in the documentation to point to the definitions page. (A script could be built that does this automatically of course.) The definitions page could then point to the individual documents. Frank: | If you can recompile 2.1, here's a fix. | [Attachment of type application/octet-stream removed.] Attachments are removed from the gpc list, so this didn't come through. On the other hand, it is probably easier for Rye to just upgrade the entire compiler. Thanks! Tom

2 1

Bad stabs
by Adriaan van Os 10 Jul '04

10 Jul '04

The output below from objdump suggests that stabs debugging info from gpc is broken. Does this happen on other platforms also ? Regards, Adriaan van Os ------- [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c hello.pas -g [G4:~/gnu/testgpc/adriaan] adriaan% objdump -g hello.o hello.o: file format mach-o-be Bad stab: Datevalid:(0,5)=@s8;- 16;,0,1;Timevalid:(0,5),1,1;Year:(0,1),2,32;Month:(0,6)=r(0,1);1;12;,34, 4;Day:(0,7)=r(0,1);1;31;,38,5;Dayofweek:(0,8)=r(0,1);0;6;,43,3;Hour:(0,9 )=r(0,1);0;23;,46,5;Minute:(0,10)=r(0,1);0;59;,51,6;Second:(0,11)=r(0,1) ;0;61;,57,6;Microsecond:(0,12)=r(0,1);0;999999;,63,20;Timezone:(0,1),83, 32;Dst:(0,5),115,1;Tzname1:(0,13)=s44Capacity:(0,14)=r(0,14);00000000000 00;0037777777777;,0,32;length:(0,14),32,32;_p_Schema_:(0,15)=ar(0,1);1;3 3;(0,2),64,264;;,128,352;Tzname2:(0,16)=s44Capacity:(0,14),0,32;length:( 0,14),32,32;_p_Schema_:(0,17)=ar(0,1);1;33;(0,2),64,264;;,480,352;; Last stabs entries before error: n_type n_desc n_value string SO 0 0000000000000000 /Users/adriaan/gnu/testgpc/adriaan/ SO 0 0000000000000000 hello.pas OPT 0 0000000000000000 gcc2_compiled. LSYM 0 0000000000000000 integer:t(0,1)=r(0,1);-2147483648;2147483647; LSYM 0 0000000000000000 char:t(0,2)=@s8;-20; LSYM 0 0000000000000000 Complex:t(0,3)=R4;16;0; LSYM 0 0000000000000000 Timestamp:t(0,4)=s104Datevalid:(0,5)=@s8;- 16;,0,1;Timevalid:(0,5),1,1;Year:(0,1),2,32;Month:(0,6)=r(0,1);1;12;,34, 4;Day:(0,7)=r(0,1);1;31;,38,5;Dayofweek:(0,8)=r(0,1);0;6;,43,3;Hour:(0,9 )=r(0,1);0;23;,46,5;Minute:(0,10)=r(0,1);0;59;,51,6;Second:(0,11)=r(0,1) ;0;61;,57,6;Microsecond:(0,12)=r(0,1);0;999999;,63,20;Timezone:(0,1),83, 32;Dst:(0,5),115,1;Tzname1:(0,13)=s44Capacity:(0,14)=r(0,14);00000000000 00;0037777777777;,0,32;length:(0,14),32,32;_p_Schema_:(0,15)=ar(0,1);1;3 3;(0,2),64,264;;,128,352;Tzname2:(0,16)=s44Capacity:(0,14),0,32;length:( 0,14),32,32;_p_Schema_:(0,17)=ar(0,1);1;33;(0,2),64,264;;,480,352;; [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs Configured with: ../gpc-332d1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, based on gcc-3.3.2 [G4:~/gnu/testgpc/adriaan] adriaan% objdump -v GNU objdump 2.13.90 20030128 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty.

4 10

AIX again
by Frank Heckenbach 10 Jul '04

10 Jul '04

More good news: A problem with `for' loops that I found in 2001 with gcc-2.95.x is apparently also fixed in gcc-3.3.3. So we can put this in statements.c to disable a work-around and perhaps produce slightly better code for `for' loops: #ifdef EGCS97 #define FOR_BUG_OK #endif Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

page function
by Tom Schneider 09 Jul '04

09 Jul '04

Hi folks: I'm using GNU Pascal version 20000707, based on gcc-2.95.2 19991024 (release). Copyright (C) 1987, 1989, 1992-2000 Free Software Foundation, Inc. while my student Ryan is using: GNU Pascal version 2.1 (20020510), based on gcc-2.95.3 20010315 (release). Copyright (C) 1987-2002 Free Software Foundation, Inc. I have no problem compiling with gpc --standard-pascal \ --transparent-file-names \ --no-mixed-comments \ -O0 \ -Wall \ $program.p -o $program but Ryan has trouble compiling a program that has a call to the page() function: alist.p:3960: undeclared identifier `Page' (first use in this routine) To my surprise, this is listed: http://www.gnu-pascal.de/gpc/Page.html as "Page is an ISO 10206 Extended Pascal extension." Did GPC change between these compilers? Does the use of page() mean I cannot use --standard-pascal ? page() was in the original book! It is listed on page 105 (Appendix A) as a standard procedure! 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 (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

3 2

Compiling unit gives ld error
by Frank Brooks 09 Jul '04

09 Jul '04

I am running gpc version 20030830, based on gcc-3.3.2 on Mac OS 10.3. When attmpting to compile any unit, I get the following error: /usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status Any way for me to solve this problem by RTFM? I apologize if I missed it in my (as yet) futile but lengthy search of the GPC mail archive/documentation. Thanks so much, Frank

2 1

Gcc-3.4 & gpc II
by David Kredba 08 Jul '04

08 Jul '04

Hello. I ran into another problem. gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -fno-common -pedantic -Wno-long-long -o xgpc p/gpc.o prefix.o version.o \ intl.o ../libiberty/libiberty.a gcc -o p/diagnostic.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I. -Ip -I../../gcc-3.4-20040702/gcc -I../../gcc-3.4-20040702/gcc/p -I../../gcc-3.4-20040702/gcc/../include -DGPC ../../gcc-3.4-20040702/gcc/diagnostic.c echo "expect 16 shift/reduce and 30 reduce/reduce conflicts" >&2 expect 16 shift/reduce and 30 reduce/reduce conflicts cd ../../gcc-3.4-20040702/gcc/p && bison -o parse.c parse.y parse.y: conflicts: 16 shift/reduce, 295 reduce/reduce gcc -o p/parse.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -pedantic -Wno-long-long -I. -Ip -I../../gcc-3.4-20040702/gcc -I../../gcc-3.4-20040702/gcc/p -I../../gcc-3.4-20040702/gcc/../include -DGPC -DGPC_UNITS_DIR=\"/opt/gcc-3.4/lib/gcc/i686-pc-linux-gnu/3.4.1/units\" -I../../gcc-3.4-20040702/gcc/p ../../gcc-3.4-20040702/gcc/p/parse.c parse.c:380: warning: useless keyword or type name in empty declaration parse.c:380: warning: empty declaration parse.c: In function `yydoAction': parse.c:8160: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c:8160: error: (Each undeclared identifier is reported only once parse.c:8160: error: for each function it appears in.) parse.c: In function `yyglrReduce': parse.c:8276: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yysplitStack': parse.c:8314: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveStates': parse.c:8413: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveAction': parse.c:8444: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyprocessOneStack': parse.c:8637: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.y: At top level: parse.y:2837: warning: `locations' defined but not used make[2]: *** [p/parse.o] Error 1 make[2]: Leaving directory `/home/dave2/gcc/gcc-3.4/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/dave2/gcc/gcc-3.4/gcc' make: *** [bootstrap] Error 2 I use Gentoo 2004.1 default bison : bison -V bison (GNU Bison) 1.875 Thanks, David -- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024D/5B6B02DE Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

2 2