June 2005 - Gpc

gpc crash
by Peter N Lewis 28 Jun '05

28 Jun '05

The following program (with an error in it) crashes the compiler. The error (BSET undeclared) is detected, but then the compiler crashes trying to bail out. I'm using gpc-20050331/gcc-3.4.3 with the delphi object patch. Program, execution, and crash report follows. Peter. program peterM; type MyCollection = object function GetDataHandle: Integer; end; function MyCollection.GetDataHandle: Integer; var flags: longint; begin flags := 0; BSET(flags, 16); GetDataHandle := flags; end; begin WriteLn( 'OK' ); end. gpc -o peterM peterM.pas peterM.pas: In method `MyCollection.GetDataHandle': peterM.pas:14: error: undeclared identifier `BSET' (first use in this routine) peterM.pas:14: error: (Each undeclared identifier is reported only once peterM.pas:14: error: for each routine it appears in.) peterM.pas:15: confused by earlier errors, bailing out [crash] Date/Time: 2005-06-27 12:32:35.975 +0800 OS Version: 10.4.1 (Build 8B15) Report Version: 3 Command: gpc1 Path: /Developer/Pascal/gpc-20050331/libexec/gcc/powerpc-apple-darwin8.1.0/3.4.3/gpc1 Parent: gpc [2697] Version: ??? (???) PID: 2699 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000034 Thread 0 Crashed: 0 gpc1 0x0005324c expand_pascal_assignment + 288 (statements.c:1116) 1 gpc1 0x00009048 yyuserAction + 22488 (parse.c:4561) 2 gpc1 0x00010f9c main_yyparse + 544 (parse.c:7900) 3 gpc1 0x000c17c4 toplev_main + 1976 (toplev.c:1826) 4 gpc1 0x00002438 _start + 344 (crt.c:272) 5 gpc1 0x000022dc start + 60 Thread 0 crashed with PPC Thread State: srr0: 0x0005324c srr1: 0x0200f930 vrsave: 0x00000000 cr: 0x44004242 xer: 0x00000000 lr: 0x00053138 ctr: 0x00008ff4 r0: 0x00000028 r1: 0xbfffed00 r2: 0x00000000 r3: 0x40d29078 r4: 0x40d21e00 r5: 0xfefefeff r6: 0x80808080 r7: 0x00000000 r8: 0x00000000 r9: 0x40d26000 r10: 0x40d25b80 r11: 0x40d25b80 r12: 0x00008080 r13: 0x0033ad0c r14: 0x003455d8 r15: 0x00000001 r16: 0x0044bca8 r17: 0x0033a2fc r18: 0x00300d84 r19: 0x00000190 r20: 0x00300d84 r21: 0x00345be4 r22: 0x404cc4bc r23: 0x00000029 r24: 0xa0001bc8 r25: 0x00340d84 r26: 0x00000000 r27: 0x00000000 r28: 0x40d21e00 r29: 0x40d26f80 r30: 0x40d29078 r31: 0x00053138 Binary Images Description: 0x1000 - 0x443fff gpc1 /Developer/Pascal/gpc-20050331/libexec/gcc/powerpc-apple-darwin8.1.0/3.4.3/gpc1 0x40b54000 - 0x40b5bfff libintl.3.dylib /usr/local/lib/libintl.3.dylib 0x8fe00000 - 0x8fe50fff dyld 43 /usr/lib/dyld 0x90000000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x90727000 - 0x90800fff com.apple.CoreFoundation 6.4.1 (368.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x9084b000 - 0x9094dfff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x909a7000 - 0x90a2bfff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x90ae3000 - 0x90af5fff libauto.dylib /usr/lib/libauto.dylib 0x91d33000 - 0x91d53fff libmx.A.dylib /usr/lib/libmx.A.dylib 0x92c9b000 - 0x92d89fff libiconv.2.dylib /usr/lib/libiconv.2.dylib 0x93614000 - 0x9361cfff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib Model: PowerMac7,3, BootROM 5.1.8f7, 2 processors, PowerPC G5 (3.0), 2 GHz, 1.5 GB Graphics: GeForce FX 5200, GeForce FX 5200, AGP, 64 MB Memory Module: DIMM0/J11, 256 MB, DDR SDRAM, PC3200U-30330 Memory Module: DIMM1/J12, 256 MB, DDR SDRAM, PC3200U-30330 Memory Module: DIMM2/J13, 512 MB, DDR SDRAM, PC3200U-30330 Memory Module: DIMM3/J14, 512 MB, DDR SDRAM, PC3200U-30330 Modem: Jump, , V.92, Version 1.0, Network Service: Built-in Ethernet, Ethernet, en0 Serial ATA Device: ST3160023AS, 149.05 GB Parallel ATA Device: HL-DT-ST DVD-RW GWA-4082B, USB Device: CanoScan, Canon, Up to 12 Mb/sec, 500 mA USB Device: Hub, , Up to 12 Mb/sec, 500 mA USB Device: CF076, CF076, Up to 12 Mb/sec, 500 mA USB Device: Hub in Apple Pro Keyboard, Chicony, Up to 12 Mb/sec, 500 mA USB Device: Apple Optical USB Mouse, Logitech, Up to 1.5 Mb/sec, 100 mA USB Device: Apple Pro Keyboard, Chicony, Up to 12 Mb/sec, 250 mA USB Device: Studio Display, , Up to 1.5 Mb/sec, 500 mA -- <http://www.stairways.com/> <http://download.stairways.com/>

2 2

"reference expected, value given" weird error
by Peter N Lewis 27 Jun '05

27 Jun '05

The following gives the error "reference expected, value given", which is very confusing (it took me ages to spot the problem as being a mismatched procedure type in one of the parameters. I realize error messages are often very difficult, and it looks like in this case, the error was actually changed from "type mismatch in argument 1 of" (see Subject: Protected Var parameter bug in the list archives). You can mark this as a low priority, but it took me quite a while to figure out what was wrong. Peter. gpc -c peterS.pas peterS.pas: In main program: peterS.pas:25: error: reference expected, value given // This program is meant to fail to compile, but would hopefully display a better error message. program PeterS; type SInt16 = Integer attribute( size = 16 ); function InitIcons( var msg: SInt16 ): Integer; begin return 0; end; type StartupInitProc = function( var msg: Integer ): Integer; procedure SetStartup( init: StartupInitProc ); begin end; begin SetStartup( InitIcons ); end. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

Which gpc version is recommended for windows (C and pascal code parts)?
by Peter Radloff 26 Jun '05

26 Jun '05

Hi everybody, I want to start porting a old DOS application written with Metaware Pascal and some C to Windows. I have found gcc 3.2.3 and gpc for the same gcc version (last year). Is this the recommend stable version? Is gpc support complete dead now? No compiled version available for download anymore. No WEB site update,... no hints, archive of mailing list broken long time. Please can somebody give a statement what happend with gpc. I am not sure is gpc the right compiler for this port, if nobody support it. On the other site i like to use of gcc compiler. Only if there is no other way i will switch to Free Pascal or Delphi. Thanks Peter

4 5

Unix compatibility
by Rick Engebretson 26 Jun '05

26 Jun '05

While trying to learn and exploit the unix (linux) platform, my google searches have turned up ms.net references (for example named pipes or fifos). MS is re-learning unix. In unix, software is built as small programs (tools) and assembled via scripting languages into executables. Tool instances are managed as "processes" by the OS itself. This script level approach is similar to compiled level classes, polymorphism, encapsulation, etc, of other languages. But of course, scripts are far simpler and more flexible. Many of these unix tools are quite old, but still useful. For example the cron program is a background job scheduler. Where modern pascal works so well is in building new compiled unix tools. C is just not an option for most applications programmers. So I am less concerned with "new" features than I am with stability and clarity. Both GPC and FPC are fantastic contributions to the world's technical community (on the linux platform). The learning process is very long, so stability and clarity are essential.

6 6

Re: essential pascal
by Frank Heckenbach 24 Jun '05

24 Jun '05

Forwarding from Marco van de Voort (with my comments): : I sometimes see "how does this work in delphi" kind of msgs in the NG. : : I don't know if you are aware of it, but there is a language tutorial for : this that is public (so can be pointed to in the maillist) and quite decent : on : : http://www.marcocantu.com/epascal/default.htm : : It is no deep treatise for a compiler writer, but it might be useful anyawy. Thanks. Though the author makes the usual mistake of claiming that Turbo Pascal supported J&W Pascal, and a few other small factual errors I noticed at a quick glance, it may be useful as a reference sometimes. : (for compiler writer, the quite up to date "keyword/reserved words" list : might be useful, it also lists the other OOP method modifiers besides virtual : and override. (see automated, dynamic, reintroduce, abstract, message) : : Not all might be interesting for your purposes, but reintroduce and abstract : could be. Where is `reintroduce' described? (Couldn't find it browsing through, and the book doesn't seem to have a real index. The keyword list only mentions that is exists.) I suppose `abstract' means the same as in GPC. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

GPC and Mac implicit pointer objects
by Waldek Hebisch 24 Jun '05

24 Jun '05

I have updated my class patch to gpc-2005031. Testing I get failure with fjf903c.pas: TEST fjf903c.pas: /pom/kompi/gcc/tst44/gcc-3.4.3/gcc/p/test/fjf903c.pas:14: error: method `p', overrides parent method /pom/kompi/gcc/tst44/gcc-3.4.3/gcc/p/test/fjf903c.pas: In main program: /pom/kompi/gcc/tst44/gcc-3.4.3/gcc/p/test/fjf903c.pas:31: error: assignment from incompatible pointer type And the question now: what happens if the child tries to make a method with the same name as a parent, but without `override'. Is it an error (like OOP) or maybe just "shadows" parent method? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

5 14

Re: GPC and Mac implicit pointer objects
by Waldek Hebisch 23 Jun '05

23 Jun '05

Peter N Lewis wrote: > >the in the case of overriding `b.dop' prints `b.p'. but in the case > >of shadowing it just prints `a.p', because `b.p' beeing a new method > >gets a new VMT slot, but `b.dop' calls old slot (so old method). > > Ok, I think I understand. When is shadowing used? > In Borland Delphi methods are by default shadowed, and overriden only if `override' is given. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Re: GPC and Mac implicit pointer objects
by Peter N Lewis 23 Jun '05

23 Jun '05

At 8:19 +0200 22/6/05, Frank Heckenbach wrote: >Peter N Lewis wrote: > >> b) a name in a parent object, with the same parameters (same by type >> anyway, the formal parameter name is not typically checked, although >> GPC typically requires the formal names to match), and must have >> "override" > >The latter condition is a consequence of the fact that all methods >are virtual. If we support/require `override' without >all-methods-virtual in another dialect (mix), this condition >wouldn't apply IMHO. Applying Frank's corrections/clarifications, we have: For a given subclassed object method p, which might be virtual or static, there are three possible parent method states: no method named p in any parent; a static method named p in a parent method; a virtual method named p in a parent method. It is also possible there might be a mix of static and virtual methods named p, only the most recently (object hierarchy wise) defined one is relevant. So that gives six possible combinations: 1. static method p defined and no method named p in any parent Legal. "override" is not allowed. "inherited p" not allowed. 2. virtual method p defined and no method named p in any parent Legal. "override" is not allowed. "inherited p" not allowed. 3. static method p defined where a static method named p in a parent Legal. "override" is required if enabled. "inherited p" is ok. Parameters do not have to match. 4. virtual method p defined where a static method named p in a parent Legal. "override" is required if enabled. "inherited p" is ok. Parameters do not have to match. 5. static method p defined where a virtual method named p in a parent Not Legal. Warning emitted and automatically made virtual. See 6. 6. virtual method p defined where a virtual method named p in a parent Legal. "override" is required if enabled. "inherited p" is ok. Parameters must match. Whether a method is virtual or static depends on whether the "virtual" keyword is there or the dialect "all-methods-virtual" state. Whether override is enabled depends on the dialect "override" state. If the override dialect is enabled, then "override" is required in any of the last four cases. Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

GPC and Mac implicit pointer objects
by Peter N Lewis 23 Jun '05

23 Jun '05

With the recently announced move by Apple to convert the Mac platform over to Intel processors (at least initially still closed hardware, but with an Intel processor instead of a PowerPC) starting next year and completing the transition in 2007, the need for Pascal users to move from Metrowerks CodeWarrior Pascal to XCode/GPC (or FPC) is now much more immediate. I presume since GCC can build a fat bundle application for both PPC and x86 that there will not be any problem with GPC doing that too. So the primary problem that remains is the difference between Mac style objects and Borland style objects which we've discussed before. The primary requirement as I see it is the ability to write code where the use of the objects is source compatible (possibly using Macros if necessary), and the object definition has as few changes as possible, preferably also handled by macros. As I see it, the minimal changes required are: 1. Allow objectptr.field as a synonym for objectptr^.field (currently this would be an error, so it is a relatively safe allowance) 2. Allow type newobject = object(objectptr) ... end; (currently this would be an error, so it is a relatively safe allowance) 3. Support the "override" keyword and add a compiler flag to require it. 4. Add a compiler flag to disable the "virtual" keyword and make all methods virtual by default. 5. Preferably add a compiler flag to say "objects are pointers" which simply adds an implicit pointer reference to the object type definition, ie: type myobject = object(superobject) ... end; implicitly becomes type myobject = ^object(superobject) ... end; Without this change, but with the other changes, the user could change the object definition from: type myobject = object(superobject) ... end; to type myobject = ^myrealobject; myrealobject = object(superobject) ... end; which is workable, but a bit ugly to have to do for every object definition. If a small amount of funding would help make this happen, I can look at trying to drum some up (just give me a figure, perhaps off-list). Any possibility of this happening. I'd rather not have to try to delve into the compiler to try to figure this out myself as they are clearly quite technical changes (although generally I suspect mostly not too challenging if you know what you're doing with the compiler source already). Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

8 42

gp and dependencies
by Peter N Lewis 21 Jun '05

21 Jun '05

Adriaan pointed me at the --print-only option of gp, and I was wondering about its use in setting up a Makefile (which is probably pointless since gp does that anyway). I haven't previously used gp, I've only used gpc with perl generate Makefiles. So I figured I'd try using gp. But I'm running in to some problems. First, gp never finished (well, the Makefile compiles everything in a bit over a minute, and gp was still going after 12 minutes, probably not making any progress, but possibly make progress very slowly). I turned on -v and it is endlessly listing out files "compiling implementation because target files not found or not up to date". I use --unit-destination-path and --object-path to keep the source directory unpolluted, and possibly because the names have capitals in them, or perhaps the compile options are not identical, some combination of all that means that gp cannot find the .gpi or .o file when it looks at each source file. So it has to go and compile the source file. But because it is "print only" the output of the compilation is not stored, so GPC has to compile each unit once for each unit it is included in, which is horrendous duplication. The first problem can be resolved presumably by using gp instead of gpc to compile it, and then either the object-path/unit-destination-path will work for both saving them and finding them, or a bug will have to be noted and resolved. But the second problem would appear to be challenging since it would always be the case after a clean rebuild. I don't quite see how this can be resolved, but I don't have a deep understanding of gp or the problem just yet. Hmm, no, it seems worse than that, even without --print-only it is doing much the same thing, endlessly saying it cannot find things. Ahh, hmm, interesting error. If I compile one of my base units, then it endlessly tries to compile GPCMacOSAll.pas - because it cannot find the .gpi or the .o, and so tries to compile it, but then it uses the unit in the unit, and dies recursively. Does --uses actually work in any useful way with gp? Because it appears if the --uses option is on, then gp does not find the pre-existing compiled unit, but you cannot compile it using gp with the --uses flag. So either way it does not seem to work. And even if I remove the --uses option, and the --print-only option then the compilation still seems to be endlessly listing out files it jas to compile. It does seem to make very slow forward progress, but seems to be endlessly recompiling the lower level units, for example: gpc -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__APPLE__ -g -O2 --include=/Source/PNLLibraries/Prefix.GPC --unit-path=/Developer/Pascal/GPCPInterfaces:/Source/PNLLibraries:/Source/MacOSXSupport:/Users/peter/Interarchy/Project/Build/ --object-path=/Users/peter/Interarchy/Project/Build/Objects -I /Users/peter/Interarchy/Project/Build/Objects -I /Users/peter/Interarchy/Project/Build/Objects/ -I /Developer/Pascal/GPCPInterfaces -I /Source/PNLLibraries -I /Source/MacOSXSupport -I /Users/peter/Interarchy/Project/Build/ -I /Users/peter/Interarchy/Project/Build/Objects/ -I . -I /Developer/Pascal/gpc343d6/lib/gcc/powerpc-apple-darwin7/3.4.3/units -I /Source/MacOSXSupport/ --unit-path=/Source/MacOSXSupport/ -E -H /Source/PNLLibraries/MyCalcCRC.p #progress+# #progress-# #progress# /Source/PNLLibraries/MyLowLevel.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyFileSystemUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyMathUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyMemory.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyStrings.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyExtraErrors.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTypes.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyFSXSpecs.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyStrNums.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyMathUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyCStrings.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTypes.p: compiling because target files not found or not up to date /Source/MacOSXSupport/MyUnixTypes.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyFSXSpecs.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyMathUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyUtils.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyLowLevel.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyGetString.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTypes.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyLongStrings.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyTypes.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyStartup.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyAssertions.p: compiling because target files not found or not up to date /Source/PNLLibraries/MyLowLevel.p: compiling because target files not found or not up to date... So basically the same units are being compiled over and over again. It is possible there are implementation unit cyclic dependencies, perhaps that is the problem? It's possibly because some of the units are not successfully compiling because of the lack of --uses since I can't get that to work. So it may come back to the question of "can you use --uses" with gp successfully? I know I need to go and build some smaller examples of the problem, but I figured I'd ask if any of these are known issues first. Thanks, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0