August 2006 - Gpc

Problem with --enable-keyword and --enable-predefined-identifier
by J. David Bryan 17 Aug '06

17 Aug '06

Running gpc-20060325 on i486-pc-mingw32 (gcc-3.4.6), I wish to use an "asm" statement and the predefined identifiers "Cardinal" and "ParamCount" in an Extended Pascal program. However, the following program fails to compile: {$ extended-pascal } {$ enable-keyword asm } {$ enable-predefined-identifier Cardinal } {$ enable-predefined-identifier ParamCount } program Predefs; var C : Cardinal; I : integer; begin asm ('nop'); I := ParamCount; C := 1 end. With "gpc -c predefs.pas", I get: predefs.pas:1: warning: compiler directives are a UCSD Pascal extension predefs.pas: In main program: predefs.pas:12: error: `asm' is an extension of Borland Pascal, traditional predefs.pas:12: error: Macintosh Pascal predefs.pas:13: error: `ParamCount' is an extension of Borland Pascal Note from the above that "Cardinal" is being enabled by the directives, whereas "ParamCount" and "asm" are not. I get the same results if I specify the compiler switches on the command line (e.g., "--enable-keyword=asm", etc.) instead of within the program. I see the same behavior with gpc-20051116. Is this a compiler bug, or am I doing something wrong? -- Dave

3 14

which is faster: inc(x) 'or' x:=x+1 ?
by wangtj＠Safe-mail.net 17 Aug '06

17 Aug '06

as title thanks.

3 2

broken links(?)
by wangtj＠Safe-mail.net 13 Aug '06

13 Aug '06

these days i was trying to enter some page of gpc: http://www.gnu-pascal.de/djgpp/ http://www.gnu-pascal.de/contrib/chief/ i tried different method but still couldnt get in. i keep got messages like that one below: Forbidden You don't have permission to access /djgpp/ on this server. after i checked the mailing list i found nobody mention this problem and i think it'll be ok though nobody has ever gave me "permission" to download an open source ware which i used for a long time. so,i thought it to be broken links and hope it can be fixed, if i was wrong please point it out. BTW, i'm wondering if gpc has stopped development since i saw the alpha version has a date of 2005? whether there's newer version? Thanks.

3 2

gdb, sets, big endian and 64 bit machines
by Jonas Maebe 06 Aug '06

06 Aug '06

Hello, gdb currently displays the contents of set variables wrongly on big endian machines for at least GPC and FPC. The reason is that it treats a set as a linear array of bits, while both GPC and FPC treat it as an array of ordinals in which bits are set using "1 shl (elementnr mod sizeof(ordinal))". The problem with creating a patch is that in FPC the size of this ordinal is always 32 bit, while on GPC it is MedCard (which is 64 bit on 64 bit architectures). The main reasons for FPC to always use 32 bits are a) binary compatibility b) performance (even on 64 bit machines, loading/storing a 32 bit value from/to memory is often faster) I have found several mails in the archives of this list noting that people should not rely on GPC sets having a particular format, so I wonder whether this could be changed in GPC? Regardless of those warnings, I guess it will still cause problems (the same binary compatibility mentioned above, for people who created data files containing sets on 64 bit machines with GPC), but it will also have advantages (making files containing sets compatible with both 32 and 64 bit apps compiled by GPC). If someone sees a way to automatically detect the used set format inside gdb itself, that would be great as well of course. What do you think? Jonas PS: I've attached a patch to gdb which fixes the problem for big endian FPC and 32 bit GPC apps. I think it may still have to be changed to not treat bitstrings differently from sets, because the stabs docs (http://www.cygwin.com/stabs.html) state: --- S Indicate that this type is a string instead of an array of characters, or a bitstring instead of a set. It doesn't change the layout of the data being represented, but does enable the debugger to know which type it is. --- What are "bitstrings" in Pascal anyway? gdb displays them as B'1..3,5,7' (sets are printed as [1..3,5,7]) so they don't seem to be the same as a bit-packed array of boolean or so. PS2: the patch was created against Apple's gdb-477. However it applies cleanly to plain GNU gdb (cvs version) as well (with a few line offset differences)

4 12

Dev+GNU Pascal: unrecognised escape sequence
by Bastiaan Veelo 06 Aug '06

06 Aug '06

Also, when I load an example project, e.g., C:\dev_gpc\examples\WinHello\Windows Hello.dp and try to build, I get this error three times: c:/dev_gpc/Examples/WinHello/rsrc.rc:1: unrecognised escape sequence and this line is highlighted: 500 ICON MOVEABLE PURE LOADONCALL DISCARDABLE "C:\dev_gpc\Icon\Mainicon.ico" Any ideas why? Bastiaan.

2 1

Repost
by Adriaan van Os 05 Aug '06

05 Aug '06

(previous post was refused) Jonas Maebe wrote: > Hello, > > While working on packed array support for FPC and verifying against GPC, I discovered a bug in GPC's packed array support. The following program prints 0 as second line instead of 1540222835 > > *** > type > ta = packed 0..$7fffffff; > tb = packed array[0..40] of ta; > > function test(i: longint): integer; > var > b: tb; > begin > b[1] := $5BCDEF73; > test := b[i]; > end; > > begin > writeln(sizeof(tb)); > writeln(test(1)); > end. > *** Thanks for the testprogram. On Mac OS X, I get [P17:~/gpc/testgpc/adriaan] adriaan% gp packing.p PC=gpc-ppc [P17:~/gpc/testgpc/adriaan] adriaan% ./packing 160 0 [P17:~/gpc/testgpc/adriaan] adriaan% gp packing.p PC=gpc-i386 [P17:~/gpc/testgpc/adriaan] adriaan% ./packing 160 126835 [P17:~/gpc/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/i386-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=i386-apple-darwin8 --host=i386-apple-darwin8 --build=i386-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 --with-arch=pentium-m --with-tune=prescott Thread model: posix gpc version 20051116, based on gcc-3.4.5 Regards, Adriaan van Os

1 0

When is InvalidObjectError called?
by Peter N Lewis 03 Aug '06

03 Aug '06

Who calls InvalidObjectError and why (other than the obvious!). I searched the code but couldn't find any enlightening references as to who actually detects an invalid object and calls this...? Thanks, Peter. -- Check out Interarchy 8.1.1, just released, now with Amazon S3 support. <http://www.stairways.com/> <http://download.stairways.com/>

3 4

Bug: string cannot be given an initial value
by Bastiaan Veelo 03 Aug '06

03 Aug '06

Hi, Thank you for providing GNU Pascal! In the process of migrating from Prospero Pascal to GNU Pascal, it seems I found a bug in the latter. Given the following program: program stringtest; type record_with_empty_string = record empty_string : string(127) {VALUE ''}; end; some_records_with_empty_string(length : integer) = array[1..length] of record_with_empty_string; five_records_with_empty_string = some_records_with_empty_string(5); begin end. This program compiles. But if you uncomment the initial value of empty_string, GPC complains with "initial value of discriminated schema type is of wrong type". Things like this used to work with Prospero. Is there a workaround? Thanks, Bastiaan Veelo.

5 7

Re: Can Assert report the file name and line number?
by Bastiaan Veelo 03 Aug '06

03 Aug '06

Peter N Lewis wrote: >> I have a lot of assertions. If one of them fails, GPC only reports >> something like "assertion failed (error #306 at 40dd45)". How can I >> find out the exact assertion that failed? > > > Rather than use the built in assertions, we use our own assertions, > that way it allows us to compile them out of the later beta/final > builds (a requirement for over-asserting as recommended by Writing > Solid Code which should be essential reading for any programmer). > > The code we use is basically: > > Prefix file: > > {$definec do_debug true} > > {$ifc do_debug} > {$definec Assert(b) AssertCode((b), __FILE__, __LINE__)} > {$definec AssertNoErr(err) AssertNoErrCode((err), __FILE__, __LINE__)} > {$definec InitAssertions(name, version) InitAssertionsCode(name, > version)} > {$elsec} > {$definec Assert(b)} > {$definec AssertNoErr(err)} > {$definec InitAssertions(name, version)} > {$endc} > > > Assertions unit: > > unit MyAssertions; > > interface > > {$ifc do_debug} > procedure AssertCode( b: Boolean; const sourceFileName: String; > sourceFileLine: Integer ); > procedure AssertNoErrCode( err: OSStatus; const sourceFileName: > String; sourceFileLine: Integer ); > procedure InitAssertionsCode( const name: String; const version: > String ); > {$endc} > > implementation > > {$ifc do_debug} > > var > gAppName: String255; > gAppVersion: String255; > > procedure InitAssertionsCode( const name: String; const version: > String ); > begin > gAppName := name; > gAppVersion := version; > end; > > procedure AssertCode( b: Boolean; const sourceFileName: String; > sourceFileLine: Integer ); > begin > if not b then begin > WriteLn( 'Assert: ' + gAppName + ' ' + gAppVersion + ' - ' > + sourceFileName + ':' + NumToStr( sourceFileLine ) ); > end; > end; > > procedure AssertNoErrCode( err: OSStatus; const sourceFileName: > String; sourceFileLine: Integer ); > begin > if err <> noErr then begin > WriteLn( 'Assert: Error=' + NumToStr(err) + ' ' + gAppName > + ' ' + gAppVersion + ' - ' + sourceFileName + ':' + NumToStr( > sourceFileLine ) ); > end; > end; > > {$endc} > > > Obviously this can easily be extended to implement assertions any way > you desire. > > Please be aware that if you intend to compile out assertions (as you > should for at least some assertions), then you must never include real > code in your assert statement, eg: > > Assert( (open( ... )) == 0 ); > > Rather you need to do > > err = open( ... ); > Assert( err == 0 ); > > Why do you have to compile out some assertions? Because you should be > doing things like: > > Assert( ValidDataStructure( complex_structure ) ); > > Where ValidDataStructure is walking through your complex structure > ensuring it is all internally self consistent, which could be a > significantly time consuming task. But that does not matter as it > will be compiled out when you are performance tuning and in the > shipping version. > > The alternative is you would have to be very light weight with what > you assert, or have two different classes of assertions (perhaps by > using something like) > > {$ifc do_heavy_debug} > Assert( ValidDataStructure( complex_structure ) ); > {$endc} > > Enjoy, > Peter. > Thank you for this detailed solution. Bastiaan.

3 3

Common OpenMP syntax?
by Florian Klaempfl 03 Aug '06

03 Aug '06

I'am currently thinking about implementing OpenMP support in FPC. However, there is currently (to my knowledge) no pascal syntax defined for OpenMp support. Do you think we can find a common syntax to simplify things for users? I've some ideas how it be done, but I want to hear other ideas first so they are maybe better if they aren't influenced by my ideas :) I started also a wiki page about it http://www.freepascal.org/wiki/index.php/OpenMP_support where ideas can be written down and shared.

4 3