- Gpc - gnu.de

executable-file-name
by Waldek Hebisch 17 Nov '05

17 Nov '05

gpc -fexecutable-file-name -x Pascal fooo happily overwrites input file. I am not sure if we consider this a bug or a feature. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 4

other compilers
by Andres K. Foerster 16 Nov '05

16 Nov '05

Hello, as I'm interrested in free software pascal compilers, I'd like to hear about your opinions about the others. I don't want to start a flamewar - of course yours's the best! But what experiences do you have with the others? I know Free Pascal very well. It comes with a lot of extensions, is fast and produces small binaries. But when you want to program for different platforms, you'll end up with lots of {$IfDef}s. I had a look at p2cc, but it seems very weak, isn't it? Has anybody experiences with the pascal compiler from the ACK package? http://tack.sf.net/ Are there others? -- AKFoerster

6 19

compute_checksum speed
by Peter N Lewis 16 Nov '05

16 Nov '05

One thing that stood out in the profile was that compute_checksum, a two line function that is called once for each loaded gpi is responsible for 12% of the total time. It scans through the entire gpi bytes (in this case, including my GPCMacOSAll 27Meg gpi, once for each of the 250 units in my project), that adds up to around 43 seconds of the 6 minute rebuild time. static gpi_int compute_checksum_original (unsigned char *buf, gpi_int size) { gpi_int sum = 0, n = 0; for (n = 0; n < size; n++) sum += n * buf[n]; return sum; } It appears that gpc_int is a 64 bit int on my system. I did some timing of some improvements: time= 42.1 sum= 46473731586140096 compute_checksum_original time= 35.0 sum= 46473731586140096 compute_checksum_unrolled time= 18.8 sum= 8551919141529536 compute_checksum_native time= 12.2 sum= -2963523148067389 compute_checksum_shift time= 7.8 sum= -852473248 compute_checksum_add (time is roughly the time in seconds gpc is taking just calling compute_checksum on the GPCMacOSAll.gpi in my complete rebuild). The unrolled version is pretty trivial, chops about 7 seconds off and has no consequences. Switching to native int instead of gpi_int affects the value of the checksum, reducing it's precision somewhat, but given the purpose of the checksum, I dont think it would impact on its purpose. This drops the time down by a further 16 seconds. The negative is it changes the existing gpi checksum, meaning all gpis would have to be recompiled. Switching to using shift instead of multiply drops the time a further 6 seconds. However the PowerPC is very good at shifts (and quite good at multiplys for that matter), so this would be something that should be tested at least on an Intel system to see how it compares. Switching to just basic addition drops the time a further 4 seconds, but at the loss of quite a lot of bits in the checksum. I would recommend that the loop be unrolled (trivial and no consequences), and then one of the native checksum routines, or something like it, be used, and the code can then use the new routine for new gpi's, and when reading existing gpi's first check if the checksum matches the new value, or failing that if it matches the old value. That way users will never notice the change. A possible patch for this is included below. I implemented this and it dropped the time to build from 6 to 5 minutes. I've attached the testchecksum.c file I used to check various checksum times, which could be used to compare the speed to the different routines on an Intel platform to see how the relative speed compares so that a generally good solution could be chosen. Please note, I dont have any attachment to the particular checksum routines included in testchecksum.c, they were just some quick routines I wrote to try out various solutions to see the affect they would have. Any checksum routine that was fast would be fine - a table driven CRC might work for example. Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

5 28

Global Variable Problem
by vanam srihari kumar 15 Nov '05

15 Nov '05

Please find below the test code I am using 1) Makefile ****************************************************************************** PC=gpc PFLAGS= -DSOLARIS PLINK = -lgpc VPATH = /home/kvsspl/ ModDemo3.o :ModDemo3.pas $(PC) --automake -c $(PFLAGS) ModDemo3.pas DemoMod3.o :DemoMod3.pas $(PC) --automake -c $(PFLAGS) DemoMod3.pas DemoMod4.o :DemoMod4.pas $(PC) --automake -c $(PFLAGS) DemoMod4.pas ModDemo3 :ModDemo3.o DemoMod3.o DemoMod4.o $(PC) -o ModDemo3 ModDemo3.o DemoMod3.o DemoMod4.o $(PLINK) clean : rm -f *.o *.out xtramain ModDemo3 *.gpi *.gpm ****************************************************************** 2) DemoMod4.pas ****************************************************************** Module DemoMod4 (Output); export DemoMod4=all; type FileNameString = string(80); var PAS_DATABASE : FileNameString; end; end. (*Is it possible to make these variables global, without using export?*) ****************************************************************** 3) DemoMod3.pas ****************************************************************** Module DemoMod3 (Output); export DemoMod3=all; procedure readenv; end; type FileNameString = string(80); var PAS_DATABASE : FileNameString;external; uses gpc; procedure readenv; var pascalEnv : string(80); begin pascalEnv:='PAS_DATABASE'; pascalEnv:=getenv(pascalEnv); writeln('module pascalEnv = ',pascalEnv); PAS_DATABASE := Copy(pascalEnv,1,Length(pascalEnv)); writeln('module PAS_DATABASE = ',PAS_DATABASE); (*here PAS_DATABASE is printing nothing but pascalEnv is ok*) end; end. ****************************************************************** 4) ModDemo3.pas ****************************************************************** program ModDemo3 (Output); uses gpc; type FileNameString = string(80); procedure readenv;external; var PAS_DATABASE : FileNameString;external; begin readenv; writeln('program PAS_DATABASE = ',PAS_DATABASE); (*here also PAS_DATABASE is printing nothing*) end. ****************************************************************** what I want is to access 'PAS_DATABASE' variable in all the modules, when I set it in DemoMod3.pas line PAS_DATABASE := Copy(pascalEnv,1,Length(pascalEnv)) Please suggest me as how to make it work? Regards Hari __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

4 3

Compiling with gp
by Pascal Viandier 15 Nov '05

15 Nov '05

Hi, I had a close look at the gp output in verbose mode (-v) and I understand why the objects are not produced in the directory specified with --object-destination-path. This option seems to be ignored silently since the compilation command shows the -o directive make the object in the path specified by the directive --gpi-destination-path. May I consider this a bug in gp? Thanks Pascal Viandier pascal(a)acovia.com -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Peter N Lewis Envoyé : November 14, 2005 21:38 À : gpc(a)gnu.de Objet : Re: Compiling with gp At 14:17 -0500 14/11/05, Pascal Viandier wrote: >First: >There are some objects from c sources not found at link time. >I put {$L my_c_extern.c} in a Pascal source but gp says "my_c_extern.c must >be compiled" and stops instead of compiling it (I think since is knows that >the source must be compiled, it should do it, no?). >Then I tried {$L my_c_extern.o} instead and gp says " >My_c_extern.c:999: undefined reference to 'symbol' >where 'symbol' is defined in a third party library for which I put a -l >directive on gp command-line. I believe this is due to a bug I fixed in my copy of gp. It stems from the comment: { Just make sure the file is added to Deps. We don't need any dependency relations because files linked with linker directives can be compiled at any time. } which I believe is erroneous. A patch (based on my subversion history) is attached below, but I do not know if it interacts with any of the other patches I've done. >Second: >The link command. >I put gp in verbose mode and made a copy of the link command which fails to >find out what is going wrong. > >I see that the list of my external (third party) libraries comes before any >object in the link command. (-llib1 -llib2...) > >By putting this list of libraries at the end of the link command, it worked. >But since I have no control on this at the gp command-line level I cannot >make it work. I saw something like this with libpcre and libxml2 - reordering the libraries fixed the problem without any changes to gp. >Also, I noticed that objects are written in the same directory as gpi files >despite the option --object-destination-path=obj on the gp command-line. I can't help you much with that, as I don't use it. But for {$L}, gp stores a gpd file, so it would need to go somewhere. gp patch follows. This is definitely not any sort of official patch. My gp has wandered far from the track. Peter. Index: gp.pas =================================================================== --- gp.pas (revision 331) +++ gp.pas (revision 332) @@ -164,6 +164,7 @@ TUnitList = record Next: PUnitList; FileName, InterfaceName: TString; + IsUnit: Boolean; MD5: TMD5; Dep: PDep end; @@ -365,6 +366,17 @@ ErrorFile (FileName, 'no directory or not writable') end; +function NewUsesElement (const InterfaceName, FileName: String; Next: PUnitList) = p: PUnitList; +begin + New (p); + p^.InterfaceName := LoCaseStr (InterfaceName); + p^.FileName := FileName; + MD5Clear (p^.MD5); + p^.Dep := nil; + p^.IsUnit := True; + p^.Next := Next +end; + { GPD file handling } function ReadGPD (var Dep: TDep): TGPD; @@ -430,7 +442,9 @@ end; function AddUnitList (var p: PPUnitList): Boolean; - var i, j: Integer; + var + i, j: Integer; + MD5: TMD5; begin AddUnitList := False; if not PascalFlag then @@ -438,17 +452,15 @@ ReadGPDError ('invalid unit dependency for C file'); Exit end; - New (p^); i := PosFrom (' ', Line, 3); j := LastPos (' ', Line); - if (i >= j) or not MD5Val (Copy (Line, j + 1), p^^.MD5) then + if (i >= j) or not MD5Val (Copy (Line, j + 1), MD5) then begin ReadGPDError ('invalid unit entry'); Exit end; - p^^.InterfaceName := Copy (Line, 3, i - 3); - p^^.FileName := Copy (Line, i + 1, j - i - 1); - p^^.Dep := nil; + p^ := NewUsesElement( Copy (Line, 3, i - 3), Copy (Line, i + 1, j - i - 1), nil ); + p^^.MD5 := MD5; p := @p^^.Next; AddUnitList := True end; @@ -568,7 +580,9 @@ begin while p <> nil do begin - WriteLn (f, Prefix, p^.InterfaceName, ' ', p^.FileName, ' ', MD5Str (p^.MD5)); + if p^.IsUnit then begin + WriteLn (f, Prefix, p^.InterfaceName, ' ', p^.FileName, ' ', MD5Str (p^.MD5)); + end; p := p^.Next end end; @@ -656,7 +670,7 @@ Assert (i = e + OptionCount); for i := 1 to n - m + 1 do Parameters^[e + OptionCount + i] := NewString (AdditionalParameters[i + m - 1]^); - if (Verbosity >= 2) or (@CmdLine <> nil) then + if (Verbosity >= 1) or (@CmdLine <> nil) then begin l := Length (Compilers[PascalFlag].ProgName); for i := 1 to Parameters^.Count do @@ -666,7 +680,7 @@ for i := 1 to Parameters^.Count do s^ := s^ + ' ' + Parameters^[i]^; if @CmdLine <> nil then CmdLine := s^; - Message (2, s^); + Message (1, s^); Dispose (s) end; ProgressMessageStartSubprocess; @@ -730,16 +744,6 @@ UnitNameMatch := LoCaseStr( Dep.SrcBaseName ) = LoCaseStr( InterfaceName ); end; -function NewUsesElement (const InterfaceName, FileName: String; Next: PUnitList) = p: PUnitList; -begin - New (p); - p^.InterfaceName := LoCaseStr (InterfaceName); - p^.FileName := FileName; - MD5Clear (p^.MD5); - p^.Dep := nil; - p^.Next := Next -end; - procedure GetDep (var Dep: TDep); function ReadBufferAndIncludes (var OutputFile: File; var StdErrFile: Text; var Buffer: PBytes; @@ -1345,10 +1349,13 @@ ps := DepToDo^.Dep^.LinkedFiles; while ps <> nil do begin - { Just make sure the file is added to Deps. We don't need - any dependency relations because files linked with - linker directives can be compiled at any time. } - Discard (FindDep (ObjectPath, ps^.s, '', fk_CFile)); + { Must compile $L files before implementation. } + CurrentDep := FindDep (ObjectPath, ps^.s, '', fk_CFile); + AddDepList (CurrentDep^.Dep^.UsedBy[False], DepToDo^.Dep); + DepToDo^.Dep^.UsedUnits[False] := NewUsesElement ( CurrentDep^.Dep^.InterfaceName, CurrentDep^.Dep^.SrcName, DepToDo^.Dep^.UsedUnits[False]); + // what FileName should I use? + DepToDo^.Dep^.UsedUnits[False]^.Dep := CurrentDep^.Dep; + DepToDo^.Dep^.UsedUnits[False]^.IsUnit := False; ps := ps^.Next end; DepToDo := DepToDo^.Next -- <http://www.stairways.com/> <http://download.stairways.com/>

1 0

global variable problem
by vanam srihari kumar 15 Nov '05

15 Nov '05

Dear All I am using gpc 2.1 version I have declared a string variable 'PAS_DATABASE' in 'module1.pas' and exporting it so that other modules in my project can use it. In the 'module2.pas' I am trying to copy 'PAS_DATABASE' with other string which is local to 'module2.pas' but It is not taking that value. How the Global variable concept is implemented in gpc? If I assign some value to that global variable it should be accessible to all other modules of my project. Please suggest as how to implement this feature. Reagrds Hari __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

1 0

Operators and shadowing
by Frank Heckenbach 14 Nov '05

14 Nov '05

I just realize one issue with user-defined operators that might not have been discussed here yet, shadowing. If an operator is defined in outer and inner scopes, say with different enough argument types, is the outer one still accessible in the inner scope (i.e., the inner one overloads the outer one) (a), or not accessible (i.e., shadows) (b)? If (a), what if argument types are similar enough? Will usual ambiguity resolution (or complaining) rules apply (c), or will the inner operator be stronger (d)? If (b), what about built-in operators? If something like + is overloaded with new argument types, the built-in + is still available (e). But if it's overloaded again in an inner scope, and the outer operator is shadowed, does the built-in operator remain unshadowed (f) or not (g). Of course, the same questions can be asked about function overloading as well. (c) that's basically what GPC currently does (where ambiguity resolution rules are name-based and first-match, which is bad, as was said before) (d) this might be more logical, as the relationship between inner and outer operators would be the same as between outer and built-in ones -- the latter come into play only if the former have no possible match at all (e) that's so in GPC currently, but I suppose also elsewhere, isn't it? I.e., defining one + operator doesn't shadow the built-in +. (f) if the outer operator shadows the built-in operator (by using similar argument types, say operator + (a, b: Integer) -- if this will be allowed at all), and the inner operator has completely different types, the built-in + for Integer would "reemerge" in the inner scope, very strange (g) one user-defined operator does not shadow a built-in, but two nested ones do -- also strange What do other dialects do about 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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 3

Building gpc-20051104 on i686-apple-darwin8
by Adriaan van Os 12 Nov '05

12 Nov '05

> For those intererested, here is some information on building > gpc-20051104 with gcc-3.4.4 on i686-apple-darwin8. Sources, patches, building instructions and an installer for the binaries can now be downloaded from <http://www.microbizz.nl/gpc.html>. Regards, Adriaan van Os

1 0

New gpc snapshot released
by Waldek Hebisch 12 Nov '05

12 Nov '05

I have put a gpc snapshot on my GPC web page <http://www.math.uni.wroc.pl/~hebisch/gpc> This is my (unofficial) "stable snapshot": I have included Delphi and Mac objects patch and collected fixes (most fixes appeared on the mailing list). On i386 Linux using gcc-3.4.4 as a backend it is supposed to build without problems and pass all the tests. On 64-bit targets there are still multiple test failures (19 on my Amd64). I tried to be conservative: new features are all related to Delphi classes and Mac objects. Also, I postponed fixing some problems where immediate fix was too risky. I did routine testing ot this snapshot and I am not aware of any problem not present in earlier gpc versions. However, it is up to you to decide how good this snaphot is. Why this shapshot? The last official gpc release was 7 months ago. There were more then dozen of fixes posted on the mailing list. I would like to reduce resultiong confusion collecting all the fixes together. Since some fixes are to backend diffs and another one renames a file it somewhat inconvenient to have the fixes as a patch, so I created a new tarball. More detailed locations: the tarball: http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051104.tar.bz2 Minimal diff (does not include generated files): http://www.math.uni.wroc.pl/~hebisch/gpc/curr4.diff.gz News file (includes older news too): http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20051104 List of fixed bugs: http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20051104 Enjoy -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

4 5

gcc-20051104
by Russell Whitaker 12 Nov '05

12 Nov '05

Thought you'd like to know: Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: ../gcc-3.4.4/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-cxa_atexit --enable-languages=c,pascal Thread model: posix gpc version 20051104, based on gcc-3.4.4 # of tests 4965 # of expected passes 4964 # of unsuported 1 Good job! Russ

1 0