April 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

random number unit
by Toby Ewing 14 May '04

14 May '04

Hi, all I've been working with the Mersenne Twister random number generator for a while. I translated it from the original C to Pascal several years ago, and the GPC team incorporated it into the GPC unit. But since then the original authors have found and fixed a bug in their initilization procedures, and other users have suggested various speedups. I've now updated my original translation, validated it against the authors' test output, performed some other minor tests, and done what small optimizations I know how to do. Source for the unit and a test program are appended below. I don't know much about optimization, and there may be some compiler directives that would greatly speed the unit. I'd appreciate any comments on that front: currently I only use: {$no-pack-struct, maximum-field-alignment 0} and more could probably be done. regards, Toby ------------------------------------------ Unit MTrand; { Mersenne Twister random number generator -- a Pascal unit. Based on code by Makoto Matsumoto, Takuji Nishimura, Shawn Cokus, Richard J. Wagner, and others. This code is based on the Jan 26 2002 version, found on Matsumoto's MT website: http://konatu.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html See also the original website: http://www.math.keio.ac.jp/~matumoto/emt.html Translation to a GPC unit by Toby Ewing (ewing(a)iastate.edu) March 2004, with assistance from James Houston (jhouston(a)tsargent.com) The Mersenne Twister is an algorithm for generating random numbers. It was designed with consideration of the flaws in various other generators. The period, 2^19937-1, and the order of equidistribution, 623 dimensions, are far greater. The generator is also fast; it avoids multiplication and division, and it benefits from caches and pipelines. Reference: M. Matsumoto and T. Nishimura, "Mersenne Twister: A 623-Dimensionally Equidistributed Uniform Pseudo-Random Number Generator", ACM Transactions on Modeling and Computer Simulation, Vol. 8, No. 1, January 1998, pp 3-30. Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The names of its contributors may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The original code included the following notice: When you use this, send an email to: matumoto(a)math.keio.ac.jp with an appropriate reference to your work. } {$no-pack-struct, maximum-field-alignment 0} Interface const mtN = 624; {length of state vector} type MTcard = cardinal attribute (Size = 32); PMTary = ^Buffary; Buffary(m : medCard) = array[0..m] of medCard; {Generate uniform random 32-bit cardinal} Function randInt : MTcard; {cardinal in [0,2^32-1]} Function randrInt(range : MTcard) : MTcard; {cardinal in [0,n-1]} {Generate uniform random double} Function rand : double; {double in [0,1]} Function randr(range : double) : double; {double in [0,r]} Function randEx1 : double; {double in [0,1)} Function randrEx1(range : double) : double; {double in [0,r)} Function randEx0 : double; {double in (0,1]} Function randrEx0(range : double) : double; {double in (0,r]} Function randDblExc : double; {double in (0,1)} Function randrDblExc(range : double) : double; {double in (0,r)} {Generate 53-bit uniform random double (capacity of IEEE double precision)} Function rand53 : double; {double in [0,1)} {Generate random double from normal distribution, given mean and stdev} Function randNorm(Mean, stdev : double) : double;{double from (mean, stdev)} {Initialization} Procedure SeedRand(RandSeed : MTcard); {initialize with an MTcard} Procedure SeedRandArray( keylen : medCard; {initialize with an array} var initkey : PMTary); Implementation const mtM = 397; {period parameter} vectA = 16#9908b0df; {constant vector a} UMask = 16#80000000; {most significant bits} LMask = 16#7fffffff; {least significant bits} TempB = 16#9d2c5680; {Tempering parameters B and C} TempC = 16#efc60000; type MTary = array[0..mtN] of MTcard; magary = array[0..1] of MTcard; var mt : MTary; {array for MT state vector} mti : MTcard; {array index} Procedure Reload; {This is the basic vector generator, making mtN random MTcards at a time} var y, kk : MTcard; mag01 : magary = (0, vectA); attribute (static); begin for kk := 0 to mtN-mtM-1 do begin y := (mt[kk] AND UMask) OR (mt[kk+1] AND LMask); mt[kk] := mt[kk+mtM] XOR (y shr 1) XOR mag01[y AND 16#00000001]; end; for kk := mtN-mtM to mtN-1 do begin y := (mt[kk] AND UMask) OR (mt[kk+1] AND LMask); mt[kk] := mt[kk+(mtM-mtN)] XOR (y shr 1) XOR mag01[y AND 16#00000001]; end; y := (mt[mtN-1] AND UMask) OR (mt[0] AND LMask); mt[mtN-1] := mt[mtM-1] XOR (y shr 1) XOR mag01[y AND 16#00000001]; mti := 0; end; Function RandInt : MTcard; {card in [0,2^32-1]} {This is the root function for returning a single random number: all of the other functions draw on this one.} var twist : MTcard; begin if (mti >= mtN) then reload; twist := mt[mti]; inc(mti); twist := twist XOR (twist shr 11); twist := twist XOR ((twist shl 7) AND TempB); twist := twist XOR ((twist shl 15) AND TempC); randInt := twist XOR (twist shr 18); end; {Real versions (in C) by Isaku Wada} Function rand : double; {double in [0,1]} begin rand := randInt * (1.0/4294967295.0); end; Function randr(range : double) : double; {double in [0,r]} begin randr := range * randInt * (1.0/4294967295.0); end; Function randEx1 : double; {double in [0,1)} begin randEx1 := randInt * (1.0/4294967296.0); end; Function randrEx1(range : double) : double; {double in [0,r)} begin randrEx1 := range * randInt * (1.0/4294967296.0); end; Function randEx0 : double; {double in (0,1]} begin randEx0 := (randInt + 1.0) * (1.0/4294967295.0); end; Function randrEx0(range : double) : double; {double in (0,r]} begin randrEx0 := range * (randInt + 1.0) * (1.0/4294967295.0); end; Function randDblExc : double; {double in (0,1)} begin randDblExc := (randInt + 0.5) * (1.0/4294967296.0); end; Function randrDblExc(range : double) : double; {double in (0,r)} begin randrDblExc := range * (randInt + 0.5) * (1.0/4294967296.0); end; Function randrInt(range : MTcard) : MTcard; {card in [0,n-1]} { Return a MTcard within [0..range-1]. The code first finds which bits are used within that range. Optimized by Magnus Jonsson (magnus(a)smartelectronix.com) } var used, i : MTcard; begin used := range; used := used OR (used shr 1); used := used OR (used shr 2); used := used OR (used shr 4); used := used OR (used shr 8); used := used OR (used shr 16); repeat i := randInt AND used {Draw numbers until one is found in [0,n]} until (i <= range); {toss unused bits to shorten search} randrInt := i; end; Function rand53 : double; {double in [0,1)} var a, b : MTcard; begin {code by Isaku Wada} a := randInt shr 5; b := randInt shr 6; rand53 := ((a * 67108864.0) + b) * (1.0/9007199254740992.0); end; Function randNorm(mean, stdev : double) : double;{double from (mean, stdev)} { Draw a double from a normal (Gaussian) distribution with specified mean and standard deviation, using the Box-Muller method. This method is adapted from Press et al.'s Numerical Recipes. Wagner used the following instead: r := sqrt(-2.0 * ln(1.0-randDblExc)) * variance; phi := 2.0 * PI * randEx0; randNorm := mean + (variance * r * cos(phi)); It is simpler, but it calls for (almost) twice as many randInts, and uses a trigonometric function. According to my time trials, the Wagner method takes approximately 3 times longer than the Box-Muller I use here. } var RF, r1, r2 : double; rsecond : double; attribute (static); bsecond : Boolean = False; attribute (static); begin if bsecond then begin bsecond := False; randNorm := rsecond; end else begin bsecond := True; repeat r1 := randr(2.0) - 1.0; r2 := randr(2.0) - 1.0; RF := sqr(r1) + sqr(r2); until ((RF < 1.0) and (RF <> 0.0)); RF := stdev * sqrt(-2.0 * ln(RF)/RF); rsecond := mean + (r2 * RF); randNorm := mean + (r1 * RF); end; end; Procedure SeedRand(RandSeed : MTcard); { Initialize generator state with seed. See Knuth TAOCP Vol 2, 3rd Ed, p.106 for multiplier. In previous versions, the most significant bits (MSBs) of the seed affected only the MSBs of the state array. Modified 9 Jan 2002 by Makoto Matsumoto. } begin mt[0] := RandSeed AND 16#ffffffff; for mti := 1 to mtN do mt[mti] := (1812433253 * (mt[mti-1] XOR (mt[mti-1] shr 30))+mti) AND 16#ffffffff; mti := mtN + 1; end; Procedure SeedRandArray( keylen : medCard; var initkey : PMTary); var i, j, k : MTcard; begin SeedRand(19650218); i := 1; j := 0; k := Max(mtN, keylen); repeat dec(k); mt[i] := (mt[i] XOR ((mt[i-1] XOR (mt[i-1] shr 30)) * 1664525)) + initkey^[j+1] + j; {non-linear} mt[i] := mt[i] AND 16#ffffffff; {if machine wordsize > 32} inc(i); inc(j); if (i >= mtN) then begin mt[0] := mt[mtN-1]; i := 1; end; if (j >= keylen) then j := 0; until (k = 0); for k := mtN-1 downto 0 do begin mt[i] := (mt[i] XOR ((mt[i-1] XOR (mt[i-1] shr 30)) * 1566083941)) - i; mt[i] := mt[i] AND 16#ffffffff; {if machine wordsize > 32} inc(i); if (i >= mtN) then begin mt[0] := mt[mtN-1]; i := 1; end; end; mt[0] := 16#80000000; {force MSB = 1} end; to begin do {Unit Initialization} begin {initialize state vector} SeedRand(5489); {this is Matsumoto's default} end; end. {unit MTrand} ------------------------------------------ program TestMTrand; uses MTrand, GPC; const big = 100000000; notsobig = 10000000; bin = 40; mean = 100.0; std = 20.0; type binary = array[1..bin] of longCard; var time1, time2, mult, i : longCard; m, s, rj : double; keylen, jj : medCard; bins : binary; init : PMTary; {This type is native to MTrand: PMTary = ^Buffary; Buffary(m : medCard) = array[0..m] of medCard;} begin writeln; writeln('Testing the Mersenne Twister Unit ''MTrand.pas'''); writeln; (* {This part passed March 23, 2004 in test against Matsumoto's original test output. Not implemented in this test program because of subsequent changes in the MT initialization procedures.} writeln('Precision: compare with Matsumoto''s 1000 original integer output'); SeedRand(4357); for i := 1 to 1000 do begin write(randInt:10, ' '); if ((i mod 5) = 0) then writeln; end; writeln; *) {This part passed March 24, 2004 in test against Matsumoto's output} writeln('Precision: compare with Matsumoto''s 1000 integer output, posted at'); writeln(' http://www.math.sci.hiroshima-u.ac.jp/~'); writeln(' m-mat/MT/MT2002/CODES/MTARCOK/mt19937ar-cok.out'); New(init, 4); init^[1] := 16#00000123; init^[2] := 16#00000234; init^[3] := 16#00000345; init^[4] := 16#00000456; keylen := 4; SeedRandArray(keylen, init); Dispose(init); for i := 1 to 1000 do begin write(randInt:10, ' '); if ((i mod 5) = 0) then writeln; end; writeln; {This part passed March 23, 2004} writeln('Uniformity of random 32-bit cardinals:'); for i := 1 to bin do bins[i] := 0; mult := bin; SeedRand(1234567890); for i := 1 to big do inc(bins[1+(randInt*mult) div 16#ffffffff]); for i := 1 to bin do begin write(i:2, ': ', bins[i]:7, ' '); if ((i mod 5) = 0) then writeln; end; writeln; writeln('Uniformity of range-specified cardinals:'); for i := 1 to bin do bins[i] := 0; mult := bin; SeedRand(1234567890); for i := 1 to big do inc(bins[1+(randrInt(bin))]); for i := 1 to bin do begin write(i:2, ': ', bins[i]:7, ' '); if ((i mod 5) = 0) then writeln; end; writeln; writeln; writeln('Distribution of doubles in [0..1]:'); for i := 1 to bin do bins[i] := 0; m := 0.0; s := 0.0; SeedRand(987654321); for i := 1 to notsobig do begin rj := rand; m := m + rj; s := s + sqr(rj); end; m := m/notsobig; s := sqrt((s-(notsobig*sqr(m))) / (notsobig-1)); writeln('Theoretical mean: 0.5000, standard deviation: 0.2886'); writeln('Returned mean : ', m:7:4, ', standard deviation: ', s:7:4); writeln; writeln('Distribution of Random normal deviates with known mean and standard deviation:'); for i := 1 to bin do bins[i] := 0; m := 0.0; s := 0.0; SeedRand(2468097531); for i := 1 to notsobig do begin rj := randNorm(mean, std); m := m + rj; s := s + sqr(rj); end; m := m/notsobig; s := sqrt((s-(notsobig*sqr(m))) / (notsobig-1)); writeln('Requested mean: ', mean:7:4, ', standard deviation: ', std:7:4); writeln('Returned mean: ', m:7:4, ', standard deviation: ', s:7:4); writeln; {This part tested and used to optimize the unit, March 23-24, 2004} writeln('Timing:'); SeedRand(1357908642); time1 := GetMicroSecondTime; for i := 1 to big do jj := randInt; time2 := GetMicroSecondTime; writeln('Time for ', big:1, ' randInts: ', ((time2-time1)*0.000001):7:2, ' seconds.'); SeedRand(564739201); time1 := GetMicroSecondTime; for i := 1 to big do rj := Rand; time2 := GetMicroSecondTime; writeln('Time for ', big:1, ' rands: ', ((time2-time1)*0.000001):7:2, ' seconds.'); SeedRand(1029384756); time1 := GetMicroSecondTime; for i := 1 to big do rj := randNorm(mean, std); time2 := GetMicroSecondTime; writeln('Time for ', big:1, ' randNorms: ', ((time2-time1)*0.000001):7:2, ' seconds.'); writeln; writeln('done.'); end.

2 5

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

Size of 'Hello World'
by Claudiozm＠aol.com 07 May '04

07 May '04

I compiled two versions of 'Hello World!', one in C and the other in Pascal in the ctgwin environment, as follows: C source hello.c: int main() {printf("Hello World!\n");} command line: gcc hello.c -o helloc.exe Pascal source: program Hello; begin writeln('Hello World!') end. command line: gpc hello.pas -o hellopas.exe The sizes of the binaries I obtained were, respectively (copied from the DOS prompt dir command): HELLOC EXE 11.296 bytes HELLOPAS EXE 283.531 bytes Why the sizes of these files are so different? What must be done in order to obtain a hellopas.exe file of reasonable size? Thanks in advance. Claudio

6 13

MD5 unit
by Thorsten Glaser 01 May '04

01 May '04

Hello all! Recently I've discovered Frank (IIRC) telling us that the MD5 unit is, in contrast to all other units (I just double-checked), not licenced under the GNU LGPL, or GPL with library exception clause, but rather plain GPL because it contains code from Ulrich Drepper's glibc imple- mentation of the MD5 algorithm. I took the time and prepared a new, BSD-licenced, implementation of the code, while preserving the old framework (ie, interface), and having as few diffs against existing code as possible. On the other hand, since a few of the old functions continue to exist, would please the original author of the md5.pas file stand up and give permission to have the "new" md5.pas, which comes without other GPL-licenced code, under the licence shown in the attached file? If that's cleared up, I would like to have the md5.pas in the stock distribution replaced, and the md5c.c added. As for md5c.c - it depends on <sys/types.h> to exist (I think that's OK per ANSI/ISO C), and checks for a definition LITTLE_ENDIAN (if it's not defined, big endian is assumed) - that might be a portability problem to be solved. Since you are far better in gcc and non-BSD environments than myself, I'll leave that to you. But please let's clear up the licence issues first. We need permission from the FSF (who got assigned copyright for the old md5.pas file) or the person who originally wrote all the other routines (starting at MD5Clear, continuing over MD5Compare, MD5Str etc.). By acknowledging this, GPC's runtime environment is fully suitable for being used to compile, link and redistribute any application, not just Free Software. Thanks in advance, and in the hope to be helpful //Thorsten -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r

5 18

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