August 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

-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

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

Re: MacOS X Update Request due to strange
by Tom Verhoeff 08 Sep '03

08 Sep '03

>Frank D. Engel, Jr. wrote: > >> The strange thing is that sometimes the problem can be fixed by >> sticking extra WRITELNs in between various lines of code. So for >> example, if I am having trouble and think the following code is at >> fault: >> >> x := SomeFunction(y, z); >> DoSomethingTo(x); >> >> I might change it to: >> >> WRITELN('1'); >> x := SomeFunction(y, z); >> WRITELN('2'); >> DoSomethingTo(x); >> WRITELN('3'); >> >> >> and sometimes this fixes the problem (but of course, I don't want that >> extra output...) >> >> >> Any ideas/fixes/patches? My father had this same problem. I seems that the compiler misbehaves (buffer-length/line-length interaction problem?) when the source text itself contains Mac-style end-of-lines (carriage returns only). Possibly the problem only occurs when the source file contains MIXED Mac-style and Unix-style end-of-lines. This can happen when you switch editor, or when you modify a program taken from elsewhere. I have not investigated it deeply. The problem disappeared when the source files where fully converted to Unix-style end-of-lines (Line feeds only). A decent text editor like BBEdit will make this change in two clicks. Tom

7 18

gpc --version confusion and "external name"
by Anders Lindén 01 Sep '03

01 Sep '03

gpc --version is not coherent among different versions of gpc, i.e. they do not provide me with output that is comparable to each other. I have access to one gpc installation that is on a sparc system. It gives me the output: gpc --version 2.8.1 This is a very laconic output compared to the one I get on my cygwin version (I was installing a binary distribution): gpc --version gpc 20030323, based on gcc-3.2.2 Copyright (C) 1987-2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This output also reveals that gpc is based on gcc. However, I thought gpc was a freestanding compiler that did not precompile anything (according to "The GNU Pascal Manual", which is something I was able to get in PDF). Is it based on gcc or not? Now on the 2.8.1 system, I have problems compiling source that uses the extension "external" in combination with a "name" directive like this: procedure foo; external name 'foo'; I have to keep it like this instead: procedure foo; external; However, this means that I come in trouble when I want to compile source that some people have made. My questions are: How is the version system working with gpc? Which is the latest stable gpc and does it use the "extern name 'foo'" extension? Which is the latest unstable gpc? How unstable is it? Is there a switch to actually enable "extern name 'foo' in all versions? Thanks a lot for your attention, and I also want to thank the people that already have helped me on this list. /Anders

2 1

Re: [churchgrowthideas] Marian McQuade Nat. Grandparents Day
by toms＠ncifcrf.gov 31 Aug '03

31 Aug '03

Could someone on the gpc admins please remove the gpc mailing list from this irrelevant yahoo group? | The Church Growth Ideas list is intended to help members churches | grow in attendance. Pastors and lay leaders are welcome to | contribute. To subscribe send an e-mail to: | churchgrowthideas-subscribe(a)yahoogroups.com or go to | http://www.yahoogroups.com/subscribe.cgi/churchgrowthideas I suspect that the Sobig worm got into someone's computer and signed the gpc up ... Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

2 1

gpc-20030830+gcc-3.3.1
by Russell Whitaker 31 Aug '03

31 Aug '03

Hi Build fails at: ... /p/rts/filename.pas:518: internal compiler error: Seg. fault Hope this info is helpful Russ

1 0

x-window programming
by Anders Lindén 31 Aug '03

31 Aug '03

Thanks for the answer of my earlier question. (By Maurice). I would like to know if there is an easy way to make a x-window application using gpc. Do I have to use "external" and in that way use the C generated libraries? Then I also need to create a lot of records that resembles the structs normally used when doing this in C? Or is there a "header file" usable from gpc, so I dont have to rewrite all that is in Xlib.h? best regards /Anders

3 6

Sqrt problem
by Silvio a Beccara 31 Aug '03

31 Aug '03

Hi everybody, I get a 'argument to `SqRt' is < 0' error. I have checked that the argument is never < 0, so I don't understand why I should get this error (if I comment the sqrt instruction, though, the error goes away!). Also by using the -g option and gdb, I don't get any more information. Can anybody help me, possibly by suggesting some other debug option/method? Thanks Silvio a Beccara - Cornell University - USA

3 3