Gpc March 2004

gpc@gnu.de

24 participants
41 discussions

Extended Pascal question
by Frank Heckenbach 21 Apr '04

21 Apr '04

Sometime ago I asked the following questions, but got no replies. What about the EP experts out there? ;-) A question to the EP experts. Are these things allowed? a) module m; export m = (a => a); const a = 1; end; end. b) module m; export m = (a => b, a => c); const a = 1; end; end. c) module m; export m = (a => b, a); const a = 1; end; end. Likewise for import (assuming m exports a): a) program p; import m (a => a); begin end. b) program p; import m (a => b, a => c); begin end. c) program p; import m (a => b, a); begin end. 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

3 10

GPC ISO 7185 compliance data
by Scott Moore 09 Apr '04

09 Apr '04

I have posted ISO 7185 compliance data for GPC on my web site: http://www.moorecad.com/standardpascal/compiler.html I welcome any comments or corrections you might have. In addition, there is a section for the "makers comments" (I can't say "vendor" because some compilers are free :). If you wish for me to add your commentary for this section, please send it to me.

4 11

GPC and EP -- restriced types
by Waldek Hebisch 09 Apr '04

09 Apr '04

AFAIKS GPC implements resticted types quite unlike what EP requires. 1) Restriced types should be different then underlying type (6.4.1 says that restricted-type is a new-type, and new-type is different from other types. So according to rules for return values the following program (accepted by GPC in EP mode) is incorrect: program prog; type a=0..5; b= restricted a; var c:a; procedure foo(function bar:b); begin end; function baz:a; begin baz := c end; begin foo(baz) end . 2) According to 6.9.2.2 assignment to variable of restricted type is legal, and IMHO the following program (rejected by GPC) is legal: program prog; type a=0..5; b= restricted a; var c:b; begin c := 0; end . By the way, greping the testsuite for `restricted' gave me no matches... -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

5 8

Re: internal error in gpc
by Adriaan van Os 02 Apr '04

02 Apr '04

In the Macintosh Pascal mailing list (<http://pascal-central.com/maillist.html>) Scott Lindhurst wrote: > I just started playing around with gpc, working on getting some old > code to work with it, and have found a bug. This is version 3.3.2d1, > just downloaded a few days ago with the accompanying GPCInterfacesB2, > on OS X 10.2.8. > > I get the message "gpc: Internal error: Illegal instruction (program > gpc1)" when compiling the following program: > > program bug; > > uses > GPCMacOSAll, GPCStringsAll; {No error if remove GPCStringsAll} > > var > tix: UInt32; {No error if change to integer or longint} > begin > tix := 1; > > if tix > TickCount then {error while processing this line} > tix := 2; > end. > > My makefile generates this command line (which is going to be wrapped, > sorry): > gpc --automake --unit-path=./:/Developer/Pascal/GPCPInterfaces/ > --object-path=./build/ --unit-destination-path=./build/ > --executable-path=./build/ > -Wl,-framework,Carbon,-framework,ApplicationServices -o ./bug -Wl,-x > -O2 -Wall -Wno-identifier-case --ignore-garbage-after-dot > --longjmp-all-nonlocal-labels ./bug.pas > > but the internal error can be reproduced with just > gpc --unit-path=/Developer/Pascal/GPCPInterfaces/ ./bug.pas > > I have the workaround of using integer or longint instead of UInt32. Peter N. Lewis helped out by noting that "limit stacksize 8096" solves the problem. This is true, but still it is strange that the compiler needs such a huge amount of stack for compilation. So, I wonder if maybe there is indeed a problem in the compiler, solved only "by accident" by a stacklimit of nearly a megabyte. When I set "limit stacksize 4096", the backtrace reads: Date/Time: 2003-11-07 11:36:46 +0100 OS Version: 10.2.8 (Build 6R73) Host: G4.local. Command: gpc1 PID: 437 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7fff0 Thread 0 Crashed: #0 0x000a9dc8 in tree_size (tree.c:161) #1 0x000aa024 in make_node (tree.c:237) #2 0x000c6980 in alloc_node (stringpool.c:70) #3 0x0024b4b0 in ht_lookup (hashtable.c:162) #4 0x000c6b1c in get_identifier (stringpool.c:109) #5 0x0001bb04 in get_operator (expressions.c:425) #6 0x0001c7e4 in build_pascal_binary_op (expressions.c:661) #7 0x0001c514 in parser_build_binary_op (expressions.c:583) #8 0x0000dd48 in yyuserAction (parse.c:4580) #9 0x000136c8 in yydoAction (parse.c:8238) #10 0x00013190 in yyglrReduce (parse.c:8290) #11 0x000124d0 in main_yyparse (parse.c:8991) #12 0x000a49c0 in compile_file (toplev.c:2134) #13 0x000a9c38 in do_compile (toplev.c:5402) #14 0x000a9d04 in toplev_main (toplev.c:5432) #15 0x00001fa8 in _start (crt.c:267) #16 0x00001e28 in start PPC Thread State: srr0: 0x000a9dc8 srr1: 0x0200f930 vrsave: 0x00000000 xer: 0x20000000 lr: 0x000a9dc0 ctr: 0x000c6968 mq: 0x00000000 r0: 0x000aa024 r1: 0xbff80040 r2: 0x6c616773 r3: 0xbff80080 r4: 0x0000002a r5: 0x0000002a r6: 0x00000001 r7: 0x00000002 r8: 0x727900e4 r9: 0x002e8a28 r10: 0x02a4f000 r11: 0x00020000 r12: 0x48042447 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00387e40 r19: 0x002eb814 r20: 0x00000000 r21: 0x00000001 r22: 0xbff80200 r23: 0x0000002a r24: 0x0000b04b r25: 0xe972469b r26: 0x00883890 r27: 0x00000078 r28: 0x00000000 r29: 0x00011a6c r30: 0x00000001 r31: 0x000a9dc0 [G4:~] 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 The same problem also occurs with the previous alpha and gcc-3.3, but the backtrace is different: Date/Time: 2003-11-07 11:34:03 +0100 OS Version: 10.2.8 (Build 6R73) Host: G4.local. Command: gpc1 PID: 404 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffe0 Thread 0 Crashed: #0 0x000c3b74 in alloc_page (ggc-page.c:660) #1 0x000c2b24 in ggc_alloc (ggc-page.c:1026) #2 0x0009c430 in make_node (tree.c:292) #3 0x000c25ac in alloc_node (stringpool.c:70) #4 0x0023cd30 in ht_lookup (hashtable.c:161) #5 0x000c2748 in get_identifier (stringpool.c:109) #6 0x000097d4 in get_operator (expressions.c:426) #7 0x0000a478 in build_pascal_binary_op (expressions.c:656) #8 0x0000a1ac in parser_build_binary_op (expressions.c:578) #9 0x0002d8d8 in main_yyparse (parse.c:2400) #10 0x00096e88 in compile_file (toplev.c:2134) #11 0x0009c03c in do_compile (toplev.c:5370) #12 0x0009c108 in toplev_main (toplev.c:5400) #13 0x000018a8 in _start (crt.c:267) #14 0x00001728 in start PPC Thread State: srr0: 0x000c3b74 srr1: 0x0000f930 vrsave: 0x00000000 xer: 0x00000000 lr: 0x000c3b6c ctr: 0x0009c3a0 mq: 0x00000000 r0: 0x000c2b24 r1: 0xbff80060 r2: 0x6c616773 r3: 0x00000023 r4: 0xbff80280 r5: 0x00000027 r6: 0x00000000 r7: 0x00000003 r8: 0xbff80100 r9: 0x002db53c r10: 0x00000001 r11: 0x0000002c r12: 0x88048444 r13: 0x00000003 r14: 0x000000c8 r15: 0xbfffec80 r16: 0x00000034 r17: 0x00000000 r18: 0x0036c9a0 r19: 0x002d94e4 r20: 0x00000000 r21: 0x02fa3e70 r22: 0x00000001 r23: 0xbff80280 r24: 0x00302ad0 r25: 0x00302ad0 r26: 0x00824890 r27: 0x0000008c r28: 0x03423e70 r29: 0x0000002c r30: 0x002fc69c r31: 0x000c3b6c The needed units can be found at <www.microbizz.nl/GPCMacOSAll.pas.bz2> and <www.microbizz.nl/GPCStringsAll.pas.bz2>. They were too large to include with this message. Regards, Adriaan van Os

4 6

interface and implementation
by mkhaldi＠gosympatico.ca 02 Apr '04

02 Apr '04

I have a question about implementation and interface. If i want only to get the interface from a module which has an implementation module, how must I do to get also the symbol init_XXXXX?? example : ---------------------------------------------- module a interface; export a =all; type string80 = string(80); procedure p; end. module a implementation; procedure p; ...... ...... end. module b interface; export b =all; import a; end. module b impleementation; .... end. I just want to get the type definition without the implementation of module a. In the b.o file, init_A symbol appears. ------------------------------------------------- Actually, I compile my modules in 2 steps. The first one is with --interface-only to get gpi file. Then, I compile my module with --implementation-only. Sometimes, I only need the interface files. But, importing a module always adds the init_XXX symbol. So what is the solution?

3 2

multiprocessor use w/ GPC compiled program (OT?)
by Boris Herman 01 Apr '04

01 Apr '04

Hi list, I have compiled a single-threaded (and quite non MP aware) pascal program that does a lot of numerical computations. One calculation takes about 5 days on my 1.25 GHz DDR G4 (single cpu) and I need about 200 computations to do. Well, when I run the program on my G4 it takes up all CPU time (cca 93%-95%). I thought of speeding the whole thing by running it on a dual processor machine so I got someone to run it on a dual 2 GHz G5. So here comes the problem. If only one instance is run on a dual G5 the Activity monitor shows 50% CPU load (which is understandable) but the graph alternates between 100% load on 1st CPU and 100% load on 2nd CPU. I thought that is an anomaly of Activity Monitor. However, when two instances are run, the time required to execute each task doubles even though the Activity monitor shows both cpus at 100% load. My program doesn't really do anything much - it performs gazillions of computations in arrays that all together consume less than 20 Mb of memory. Am I doing anything wrong or shouldn't I expect better performance on a dual cpu unit? Highest regards, Boris

6 5

packed records' address again
by Francesco Bonomi 31 Mar '04

31 Mar '04

I have been following the "cannot take address of packed record" thread and now I have a similar problem. I perfectly understand that doing a strcopy is an implicit conversion, but I think that the program gets carried away during checks :-) I had a VERY complex data structure and it took me quite a while to reduce it to the minimum, please bear with me if it's anyway a bit intricate. let's have the following definitions: type char_arr = array[1..30] of char; smallrec = RECORD arr : char_arr; END; largerec = packed RECORD one_rec : smallrec; many_rec : array[1..5] of smallrec; one_array : char_arr; many_arrays : array[1..5] of char_arr; END; VAR r:largerec; c:char_arr; The largerec record is packed, and contains an assortment of structures. A lot of assignments are allowed, like: r.one_array :=c; r.one_rec.arr :=c; r.many_arrays[1] :=c; This single one is not allowed: r.many_rec[1].arr:=c; BTW, assigning a single char is allowed: r.many_rec[1].arr[1]:=#0; So I guess it must be a check that deals with implicits type conversions. but: 1) I am not converting strings, I am assigning a char_arr to another char_arr 2) if the "r.one_rec.arr :=c" assignment is allowed, I cannot see how the "r.many_rec[1].arr:=c;" can be more "dangerous" in addressing mode. I am not trying to be fussy just for the fun of it, but my structure is (as life goes :-) just the single variant that will not work. I am porting an old source code to gpc, while keeping the data file compatibility, so I will explore the unpack-access-pack solution, (hoping that it will not degrade performances too much) BTW (and here I go into newbie mode) how can I check if there is after all any physical difference between a packed and an un-packed record? Is there something like a length() to measure a record's size in memory?? Also, do I understand correctly that the proposed solution: > {$pack-struct, maximum-field-alignment 8} > foo = record > sig : array [ 0..3 ] OF Char; > end; > {$no-pack-struct, maximum-field-alignment 0} would change the structure of a "file of foo" ? Thanks! Francesco Bonomi Francesco Bonomi Si.lab s.r.l. Via Citille 13 50022 Greve in Chianti FI- Italy Tel +39 - 055 8544805 Fax +39 - 055 8547418 http//:www.silab.it

6 8

gpc reference reader
by Russell Whitaker 29 Mar '04

29 Mar '04

hi The attachment, readhelp.pas.gz, is a simple, fast reader for the reference portion of the gpc manual. Uncompress with gunzip. The first few lines after the start is a "readme". Be sure to read it before compiling. The plan here is to merge this program with an updated version of the simple Pascal Editor I contributated a little over a year ago. When done will contribute the result. Meanwhile, perhaps this little program will encourage someone to work on the gpc manual. russ

1 0

Mailing list problems (March 20-23)
by Frank Heckenbach 27 Mar '04

27 Mar '04

Hallo, due to a problem when installing spam and virus filters, the mailing lists were out of order from last Saturday till Tuesday. Incoming mails were probably dropped without notice. If you sent any mail to the lists in this time, please check in the archives to find out if it got through, and otherwise please resend it. Sorry for the inconvenience, 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

ISO 7185 compliance issue for GPC
by Scott Moore 25 Mar '04

25 Mar '04

Hello, My name is Scott A. Moore, I am the person who performed some of the ISO 7185 compliance testing on GPC. I have done a minor update to some of my ISO 7185 compliance testing material, and reran this against the current version of GPC (2.95). In the process, I have discovered a compliance problem with GPC. Please reference the program: ============================================================== program test(output); var f: text; c: char; begin rewrite(f); writeln(f, 'how now'); writeln(f, 'brown cow'); reset(f); write(''''); while not eof(f) do begin if eoln(f) then write('<eoln>'); read(f, c); write(c) end; write(''''); writeln(' s/b ''how now<eoln> brown cow<eoln> '''); rewrite(f); writeln(f, 'too much'); write(f, 'too soon'); reset(f); write(''''); while not eof(f) do begin if eoln(f) then write('<eoln>'); read(f, c); write(c) end; write(''''); writeln(' s/b ''too much<eoln> too soon<eoln> '''); end. ================================================================ The results from GPC for running this command are as follows: ================================================================ C:\TEST>test 'how now<eoln> brown cow<eoln> ' s/b 'how now<eoln> brown cow<eoln> ' 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> ' C:\TEST> ================================================================ The first section of the test verifies that eoln in text file is replaced with space, GPC passes this. The second section of the test verifies that eoln is automatically inserted at the end of a text file if it was terminated without a eoln. See ISO 7185 section 6.4.3.5: ===================================================================== There shall be a file-type that is denoted by the required structured-type-identifier text. The structure of the type denoted by text shall de ne an additional sequence-type whose values shall be designated lines. A line shall be a sequence cs ~S(end-of-line), where cs is a sequence of components possessing the char-type, and end-of-line shall represent a special component-value. Any assertion in clause 6 that the end-of-line value is attributed to a variable other than a component of a sequence shall be construed as an assertion that the variable has attributed to it the char-type value space. If l is a line, then no component of l other than l.last shall be an end-of-line. There shall be an implementation-defined subset of the set of char-type values, designated characters prohibited from text les; the effect of causing a character in that subset to be attributed to a component of either t.L or t.R for any text le t shall be implementation-dependent. A line-sequence, ls, shall be either the empty sequence or the sequence l ~ ls' where l is a line and ls' is a line-sequence. Every value t of the type denoted by text shall satisfy the following two rules: a) If t.M = Inspection, then t.L ~t.R shall be a line-sequence. b) If t.M = Generation, then t.L ~t.R shall be ls ~cs, where ls is a line-sequence and cs is a sequence of components possessing the char-type. ==================================================================== Basically, the rules say that a text file shall consist of either whole lines, or be entirely empty. Whole lines are defined as "~S(end of line)", or a series of arbitrary characters terminated by end of line. In effect, the program processor must arrange for eoln to be true at the end of a file, either by faking it while reading, or by forcing an eoln to be written at the end of a file during generation. Thank you for your attention.

4 11

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 March 2004