July 2003 - Gpc

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

25 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

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

License of the GNU Pascal documentation?
by Matthias Klose 09 Aug '03

09 Aug '03

On The debian-legal mailing list there currently is a major discussion about the "freeness" of the "GNU Free Documentation License". You may want to look at the archives yourself, one point to start is http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00307.html The problem are the "Invariant Sections" of the GFDL, which make the GFDL non-free from Debian's viewpoint. Looking at gpc's documentation, I see the GFDL-1.1 (with the short example GFDL license at the end), but in the man page I only find: COPYING Copyright (c) 1997-2003 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 version published by the Free Software Foundation. A copy of the GFDL comes as a texinfo document along with the GPC manual. In contrast with copying-fdl.texi, there is no mentioning of the "Invariant Sections": "If you have no Invariant Sections, write ``with no Invariant Sections'' instead of saying which ones are invariant. If you have no Front-Cover Texts, write ``no Front-Cover Texts'' instead of ``Front-Cover Texts being @var{list}''; likewise for Back-Cover Texts." Please clarify the copyright of the man page. I'll have to remove the info and html docs from the Debian main section (maybe somebody volunteers to repackage them to the non-free section), but to keep at least the manual pages in the package I'd like to see the license of the manual pages be clarified. Thanks, Matthias

6 16

Re: range check test programs
by Mirsad Todorovac 07 Aug '03

07 Aug '03

On Sat, 12 Jul 2003, Frank Heckenbach wrote: [...] > Perhaps you've missed Francois' previous mail where he quoted the > items I have thought of already (appended below). If you can think > of more (which Francois didn't already write), fine, but first we > need someone to write those tests. Sure. Here is the point when I think I've done what I could. Let's go step by step with this list (I'm sorry if I'm repepating something that has been said already, but the list archive appears to be out :-(: > > > What's missing is a test where the formal discriminants are of a > > > subrange type and the actual discriminants (in `New' or a variable > > > declaration) are out of range. TEST mir040a.pas: gpc1: warnings being treated as errors ./mir040a.pas: In main program: ./mir040a.pas:34: warning: tag value must be a constant of ordinal type failed (I think it could be the problem in GPC, since the code is precisely the same, as with integer subrange bounds conformant arrays.) Am I allowed to suppress this specific warning, is it possible to do suppress it, or have I done something wrong? (mir040a.pas is in attachment.) > > > Initialization of types, variables and typed constants. (I.e., > > > variables (or fields) or subrange type with an out-of-range > > > initializer; must be locally, otherwise GPC won't accept > > > non-constants initializers.) Done. mir041[ceil][ul].pas > > > The `FillChar' test (fsc20.pas) shouldn't (I think) work like this > > > since it takes an untyped parameter. (Some people (ab)use it for > > > strange purposes.) Instead, the 3rd parameter may also be an > > > integer, so it's an error if it's < 0 or > Ord (MaxChar). Done: mir042[ul].pas > > I've found some more missing cases: > > > > - `Return' (where the result type is a subrange and the `Return' > > value is out of range) Done. mir0{24c[ul],25[ei][ul],26l[ul].pas > > - `Pack', `Unpack' (the index parameter) Done. mir03[56]*.pas > > - `Include', `Exclude' Done. mir028*.pas > > - `Inc', `Dec' Done. mir027*.pas > > - 4th parameter of `BlockRead', `BlockWrite' (not obvious, but GPC > > allows a subrange here which may be too small for the actual > > result) Done. mir039*.pas > > - `Val' (2nd and 3rd parameter) Done 2nd parm. mir034[ab].pas Q: What is the legal range for 3rd parm of Val? > > - `and', `or', `xor', `shl', `shr' used as procedures, e.g., if a is > > of type 1 .. 10: a := 5; or (a, 8) (whereas normal use as > > operators will be covered by assignments or whatever is done with > > them) Done. mir03[0-3]*.pas > > - Conformant arrays (i.e., where the index type in the conformant > > array in the formal parameter list is a subrange, and the actual > > parameter's range is too big -- check both bounds) Integer subrange Done. Problems with Char and enumerated subranges. I can confirm that it gives me this error: TEST mir038ea.pas: ./mir038ea.pas: In main program: ./mir038ea.pas:29: invalid operands to binary `+' ./mir038ea.pas:29: incompatible type for argument 1 of `conformantArray' ./mir038ea.pas:11: routine declaration failed {$gnu-pascal} program mir038ea; {slice array write, what Francois has done for Integer here is for subrange} uses GPC; type TGrayScale = (Black, Gray10, Gray20, Gray30, Gray40, Gray50, Gray60, Gray70, Gray80, Gray90, White); TMidTones = Gray30..Gray70; var v : array[1..100] of Integer; i,j : TGrayScale; procedure conformantArray(a: array[l..u : TMidTones] of Integer); begin end; procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end; begin AtExit(ExpectError); i:=Gray30; j:=White; {j > upper} conformantArray(v[i..j]); end. > > - `New' with variant records (where the variant tag is of subrange > > type) See the generated warning in test above. > > - sets (e.g., assigning a set of a larger range to one of a smaller > > range where the former contains out of range elements) Done. mir029*.pas Conclusion: 1. variant record warning 2. Val's 3rd parameter 3. Possible bug with conformant arrays when bounds are of Char subrange, confirmed it occurs with enumerated subranges too 4. All tests WILL AND MUST give "failed" if you don't have range-checking compiler, with range-checking on, they should give OK The latest result is at http://www.alu.hr/~mtodorov/pascal/rngv0.03.tar.gz There is significantly more of them now than in v0.02, and some bugs are fixed. I think we're moving somewhere. Have a nice day, Mirsad -- "I have a dream!" -- Martin Luther King Jr.

4 21

Units and --uscd-pascal
by Adriaan van Os 05 Aug '03

05 Aug '03

[G4:~/gnu/testgpc/adriaan] adriaan% cat unita.pas unit A; interface end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c unita.pas --ucsd-pascal unita.pas:2: error: units are an extension of Borland Pascal, traditional unita.pas:2: error: Macintosh Pascal UCSD Pascal certainly supports units. unita.pas:3: error: units without `implementation' part are an extension of unita.pas:3: error: traditional Macintosh Pascal UCSD Pascal also supports units without 'implementation part', or at least Apple UCSD Pascal does. Regards, Adriaan van Os

5 21

Dynamic Array Size
by Silvio a Beccara 29 Jul '03

29 Jul '03

Hi, how do I get the dimensions of a dynamic array? For instance, like the following: type PMatr2Dob10 = ^Tmatr2Dob10; Tmatr2Dob10 (Size1, Size2: Integer) = array [ 1 .. Size1, 0 .. Size2 ] of double; var kets: Pmatr2Dob10 Thanks very much Silvio a Beccara - Cornell University, USA

4 3

Conformant array problem
by Mirsad Todorovac 29 Jul '03

29 Jul '03

Hi, Here is the variant of Francois' test fsc28.pas: ----------------------- {$gnu-pascal} program mir037c; {slice array write, what Francois has done for Integer here is for Char} uses GPC; var v : array['A'..'Z'] of Integer; i,j : Char; procedure conformantArray(a: array[l..u : Char] of Integer); begin end; procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end; begin AtExit(ExpectError); i:='W'; j:=Succ('Z', 5); {j out of bounds so slice will be out of bounds too (write)} conformantArray(v[i..j]); { line 26 } end. ------------------------ here is what I get: bash-2.05b$ gpc mir037c.pas mir037c.pas: In main program: mir037c.pas:26: invalid operands to binary `+' mir037c.pas:26: incompatible type for argument 1 of `conformantArray' mir037c.pas:8: routine declaration bash-2.05b$ Now, what is done in fsc28.pas looks apparently the same: --------------------------- {$gnu-pascal} program fsc28; {slice array write} uses GPC; var v : array[1..100] of Integer; i,j : Integer; procedure conformantArray(a: array[l..u : Integer] of Integer); begin end; procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end; begin AtExit(ExpectError); i:=99; j:=110; {j out of bounds so slice will be out of bounds too (write)} conformantArray(v[i..j]); end. ----------------------------- And it passes. Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr.

1 0

Bug report/feature request: overly aggressive warning on use of for-loop variable
by Joseph Oswald 29 Jul '03

29 Jul '03

The attached program demonstrates an issue with Gnu Pascal, version 20030507. The program cannot be compiled because of a non-existent "threat" on the global loop variable used in a subroutine. The main program has a loop which uses the variable, but calls no subroutines within the loop, and therefore is not vulnerable to any threat from use of that variable by other subroutines. Attempting to compile this program results in the message gpc -o forwarning forwarning.pas forwarning.pas: In main program: forwarning.pas:13: error: `for' loop counter is threatened in a subroutine This usage is present in Donald E. Knuth's WEB and TeX programs, and requires changing these loops to use unique loop variables. If there is a way to disable this check, I cannot find it in the documentation. gpc --version results in: 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 Thank you for your help. --Joe Oswald

4 4

Range tests
by Mirsad Todorovac 29 Jul '03

29 Jul '03

I have been rather busy in all this rush before holidays. I've seen that some of those range tests had problem compiling within testsuite, mostly because of rather harmless problems such as capitalisation. I've fixed that (hopefully), and henceforth I'll take as a standard that I don't submit a test unless it's successfully passed (or in this case - successfully failed) in the testsuite, under testsuite's compile options. Please find what's been done so far at http://www.alu.hr/~mtodorov/pascal/rngv0.02.tar.gz At my side they are of course all "failed". It would be reassuring if I get a confirmation that on range-checking compiler they all pass "OK". Mirsad -- "I have a dream!" -- Martin Luther King Jr.

1 0

Redelaration problems.
by nick 28 Jul '03

28 Jul '03

Hi! As I told I have some problems in the last GPC version (20030507) with repeated declaration in implementation part. consider the following: module test1 interface; export test1=all; procedure mt1 (str:string); function mt2 (str:string):string; end. module test1 implementation; procedure mt1 (str:string); begin writeln (str); end; function mt2 (str:string):string; begin mt2:=str; end; end. this file doesn't compile. GPC tells that mt2 redeclaration doesn't match the first one. The funny thing is that if I add type mystr=string after the "export" line and then change the function to use mystr - everything compile. Nick

2 2