January 2004 - Gpc

Inefficiency of `mod'
by Emil Jerabek 26 Oct '10

26 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

-mlong-double-128
by Adriaan van Os 13 May '05

13 May '05

The following produces an internal compiler error: [G4:~/gnu/testgpc/adriaan] adriaan% cat compare.pas program Compare; procedure R ( var r1, r2: real); begin if r1 <> r2 then r1:= r2 - 1.0 end; begin end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o compare compare.pas -mlong-double-128 compare.pas: In procedure `R': compare.pas:6: error: unrecognizable insn: (insn 26 34 27 2 0x0 (set (reg:SI 126) (subreg:SI (reg:TF 33 f1) 0)) -1 (nil) (nil)) compare.pas:6: internal compiler error: in extract_insn, at recog.c:2175 It may be, of course, that the Darwin target doesn't properly support the -mlong-double-128 PowerPC processor option. If it's a gcc back-end bug, I can report it to Bugzilla. However, the "real" type used is 64-bit on the Darwin target, with or without -mlong-double-128 ... The option only changes the size of the "longreal" and "extended" types to 128-bit. Regards, Adriaan van Os [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc33d7/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d7/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d7 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3

6 15

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

BP question
by Frank Heckenbach 20 May '04

20 May '04

BP seems to allow overriding a public method with a private one (and vice versa). Does this seem reasonable? What do Delphi and other compilers do? At first sight, I'd rather forbid this in GPC (as usual, with an exception in `--borland-pascal', but perhaps a warning even there?). program Foo; type a = object procedure p; end; b = object (a) private procedure p; { ??? } end; procedure a.p; begin end; procedure b.p; begin end; begin end. Oh, wait a second, it gets really strange ... unit U; interface type a = object procedure p; end; b = object (a) private procedure p; end; implementation procedure a.p; begin WriteLn ('a.p') end; procedure b.p; begin WriteLn ('b.p') end; var v: b; begin v.p end. program Foo; uses U; var v: b; begin v.p end. Under BP, this says: b.p a.p What does it mean actually? It means that `b' has *two* methods called `p'. Within the unit, one of them shadows the other, and outside of the unit, the first one is hidden (or non-existent because not exported), and the second one becomes visible. That's crazy, isn't it? 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

5 11

gpc-20030830 released
by Frank Heckenbach 13 May '04

13 May '04

I've uploaded a new alpha to <http://www.gnu-pascal.de/alpha/>. IMPORTANT LICENSING NOTE: Due to the recent disputes over the GNU Free Documentation License by some parties, we made a detailed investigation of the license status of GPC's documentation. Thereby it turned out that the change to the FDL last November might not have been done absolutely correctly, since neither permission of some earlier authors nor of the FSF as the copyright holder was obtained for that change. To avoid any possible problems resulting from that, we decided to rewind the complete documentation to the state of 2002-11-27, the last version licensed under the GPL, and redo all later changes with explicit permission of the respective authors under the GPL. As the result, the whole documentation is now licensed under the GPL (again), and the license status of GPC versions 20021128, 20030209, 20030323 and 20030507 remains dubious. (Note: This affects only the documentation. The compiler itself has not changed its license and is therefore safe. Neither are programs compiled by such a GPC version affected.) I am not a lawyer, so I can't give you any advice what to do if you have used such a version, but my personal suggestion (also for technical reasons) is to change to the current release as soon as possible. Therefore, we have removed the problematic distributions from our server. Those who have made available binaries of one of the problematic versions are suggested to do the same (which, I suppose, they will do anyway, replacing them by the new release). For the same reason, we do not offer a patch against gpc-20030507, so you will have to download the whole GPC distribution to upgrade. (A patch against gpc-20021111 would be safe, but probably rather large and not worth the effort, since many users might not have gpc-20021111 handy anymore.) To avoid similar problems, we do not plan another attempt to change the license in the nearer future. It may be required for GCC integration someday, but not until the disputes over the FDL are finally settled. If you have any suggestions regarding these matters, please contact Peter Gerwinski or me by private mail. BUILD NOTE: This GPC version requires quite a recent version of Bison. (And building CVS Bison again requires bleeding edge versions of some other utilities.) Therefore, I have included the Bison generated files in the distribution (also in the "minimal" distribution), so you won't need Bison at all unless you remove them or change parse.y. New features: * `CompilerAssert' (fjf904*.pas) * options `--[no]-assert' renamed to `--[no]-assertions' (necessary to avoid a conflict with GCC) (@) * new options `--[no-]range-checking', also as short compiler directives `{$R+}'/`{$R-}' (default is on) (C, E, B, @) * new options `--[no-]methods-always-virtual' (fjf903*.pas) (M) * new options `--[no-]pointer-arithmetic', `--[no-]cstrings-as-strings', `-W[no-]absolute' (all of which `--[no-]extended-syntax' implies) * `Integer2StringBase', `Integer2StringBaseExt' * new constants `NumericBaseDigits', `NumericBaseDigitsUpper' * allow assigning, passing by value and returning objects, with assignments of an object of derived type to one of a base type (chief35[ab].pas, fjf451*.pas, fjf696[ef].pas, fjf884*.pas), BP compatible except for a bug in the BP feature itself (see the comment in `p/test/fjf451h.pas') (B) * new options `-W[no-]object-assignment' * warn (except in `--borland-pascal') if a virtual method overrides a non-virtual one (chief52*.pas) * warn when an non-abstract object type has virtual methods, but no constructor (chief51*.pas) * `--maximum-field-alignment' does not apply to `packed' records * `ArcSin', `ArcCos' Note: Range checking options are recognized, but range checking in general is *not* yet implemented. Only some special cases are checked, such as sets and dynamic subranges (subranges in local declarations and array slice access). Fixed bugs: * open internal files with `O_EXCL' on `Rewrite' (as a protection against symlink attacks) * `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas) * `--enable-keyword'/`--disable-keyword' on the command-line makes GPC crash (david5.pas) * GPC accepts, but ignores, options with invalid suffixes (e.g. `--delphi-pascal') * wrong type-error when applying `Inc' to a type-casted pointer (peter3.pas) * with range checking enabled, check dynamic subrange/array size (fjf222*.pas, fjf813*.pas, fjf900*.pas) * GPC allows modification of conformant array bounds, result of `High'/`Low' etc. (fjf897*.pas) * don't allow linker names starting with a digit (fjf894.pas) * `SubStr' with constant arguments doesn't work in constants (gale1.pas) * handle `BitSizeOf' correctly for packed array fields, don't allow `SizeOf' on them (fjf891*.pas) * System: `BPReal' must be a packed record <3EE8A26D.C919BE7D(a)flexim.de> * schema types with initializers (drf1.pas, fjf886*.pas) * `Return' doesn't work for sets (fjf885.pas) * bug with arrays as fields of `packed' records (waldek6.pas) * don't allow duplicate imports in a module interface and implementation (nick1b.pas) * compensate for parser read-ahead in the lexer, so compiler directives don't become effective too early and error messages refer more closely to the correct source position (still not quite correct due to issues with Bison) * bug when dividing two integers with `/' (fjf481.pas) * don't allow `absolute' in type definitions * subranges with variable limits (couper[23].pas) 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

9 23

Protected Var parameter bug
by Gale Paeper 11 May '04

11 May '04

While investigating a different issue, I found what I think is a problem with GPC's enforcement of Extended Pascal's actual parameter requirements for formal protected var parameters. The problem is that GPC allows function-access expressions to be used as the actual parameter for a formal protected var parameter and the function-access isn't a variable-access as required by Extended Pascal. For formal variable parameters, Extended Pascal requires the actual-parameter ... "shall be variable-access" (see paragraph 6.7.3.3) regardless of whether 'protected' is used in the formal parameter declaration. ('Protected' does not change the requirements for the actual-parameter. It just requires that no statements within the procedure/function shall threaten a protected formal-parameter identifier.) While GPC doesn't allow function-access expression actual-parameters for non-protected formal variable parameters, it incorrectly allows function-access expression actual-parameters to be used for protected formal variable parameters. A short test program that demonstrates the problem: {$extended-pascal} program ProtectVarParameterTest(input, output); var globalInt : Integer; function GetInteger: Integer; begin GetInteger := 1; end; procedure DoSomethingProtectedVar(protected var anInt : Integer); begin globalInt := anInt; end; procedure DoSomethingVar(var anInt : Integer); begin globalInt := anInt; end; begin globalInt := 0; DoSomethingProtectedVar(GetInteger); {WRONG} writeln('FAIL'); {DoSomethingVar(GetInteger); writeln('FAIL');} end. With the last two statements commented out, GPC compiles the program with no errors and running the compiled program produces and output of: FAIL. Uncommenting out the last two statements, GPC doesn't compile the program and generates error messages: ProtectVarParameterTest.pas: In main program: ProtectVarParameterTest.pas:26: error: type mismatch in argument 1 of `DoSomethingVar' ProtectVarParameterTest.pas:18: error: routine declaration (Note - the error messages in this test example are pretty obtuse. In the program where I initial found the problem, the error message of "error: reference expected, value given" is much clearer as to what the real cause of the problem is.) The command line and compiler information used on both versions of the test program were: gpc --automake -v ProtectVarParameterTest.pas -o ProtectVarParameterTest 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__ ProtectVarParameterTest.pas -fautomake -famtmpfile=/var/tmp//cc2sio8x.gpa /var/tmp//ccmxZG89.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//ccmxZG89.i -fPIC -quiet -dumpbase ProtectVarParameterTest.pas -auxbase ProtectVarParameterTest -version -fautomake -famtmpfile=/var/tmp//cc2sio8x.gpa -o /var/tmp//ccPyvMwU.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 Gale Paeper gpaeper(a)empirenet.com

2 1

Bug Report
by Frank D. Engel, Jr. 27 Apr '04

27 Apr '04

Not sure if this one has come up yet, but I have been experiencing some strange behavior in that some of my strings seem to disappear when used as parameters for procedure calls. I'm not in a position to offer a demo program, and unfortunately, this does not seem to happen in every situation, but here is in essence what is happening. Consider: TYPE STRING63 = STRING(63); FUNCTION x : STRING63; { returns a nonempty string } PROCEDURE y(z, t : STRING63); { ... } VAR a, b : STRING63; BEGIN a := 'hi'; y(x, a); <..> Now if I try to use t within y, I should get the string 'hi', but it turns out to be an empty string (even if I WRITE(t) immediately after the opening BEGIN in the procedure). However, if I do this: a := 'hi'; b := x; y(b, a); then it works correctly. There seems to be a problem with using a function returning a string (maybe just one with no parameters?) directly as an argument to a procedure. Storing the result in a variable then using the variable as the parameter solves the problem. Obviously this creates a simple workaround, but it is still a bug... ----------------------------------------------------------- Frank D. Engel, Jr. <fde101(a)fjrhome.net> ____________________________________________________________ Free 20 MB Bannerless Domain Hosting, 1000 MB Data Transfer 10 Personalized POP and Web E-mail Accounts, and more. Get It Now At www.doteasy.com

4 8

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