September 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

cast increases required alignment of target type
by Adriaan van Os 15 Feb '05

15 Feb '05

Consider the followig test program: program TestCast; type BytePtr = ^Byte; IntPtr = ^Integer; var theBytePtr : BytePtr; theIntPtr: IntPtr; begin theBytePtr := nil; theIntPtr:= nil; theIntPtr:= IntPtr( theBytePtr); {testcast.pas:11: warning: cast increases required alignment of target type} BytePtr( theIntPtr) := theBytePtr; theBytePtr:= BytePtr( theIntPtr); IntPtr( theBytePtr):= theIntPtr; {testcast.pas:14: warning: cast increases required alignment of target type} end. 1. Compiling with gpc produces two warnings as indicated in the comment. The compiler warns if the "casting" pointer type (outside the parenthesis) points to a larger type than the "casted" pointer type (inside the parenthesis). Gale Paper brought to my attention that the same holds on the left side of an assignment and I am inclined to regard this as a bug - the compiler should check here for a smaller type, rather than a larger type. 2. the -Wcast-align and -Wno-cast-align command-line switches don't seem to work with gpc. Regards, Adriaan van Os

2 5

Environment variables on Mac OS X
by Adriaan van Os 01 Nov '04

01 Nov '04

As discussed before, shared libraries on Mac OS X can not reference the environ variable directly, where applications can. This is a show stopper on Mac OS X, because of the internals of autoconf and because the environ variable is referenced in gpc's runtime library. To solve this problem, I apply the following patch: --- gcc/p/rts/rts.c.orig Wed Apr 16 01:58:46 2003 +++ gcc/p/rts/rts.c Fri Jun 6 11:35:50 2003 @@ -195,7 +195,15 @@ extern int errno; #endif -#if defined (HAVE_ENVIRON) || defined (environ) +/* needed by Mac OS X */ +#if defined (__MACH__) && defined(__APPLE__) +#include <crt_externs.h> +#endif + +/* on Mac OS X the environ variable can not be referenced in shared libraries */ +#if defined (__MACH__) && defined(__APPLE__) +#define environ (*_NSGetEnviron()) +#elif defined (HAVE_ENVIRON) || defined (environ) #if !defined (environ) && !defined (ENVIRON_DECLARED) extern char **environ; #endif I would be grateful if this patch is merged with gpc's sources. Regards, Adriaan van Os

2 4

gpidump
by Adriaan van Os 19 Oct '04

19 Oct '04

Another problem - with most .gpi files, gpidump stops with the following error: gpidump: ... .gpi: unexpected flag `unused lang flag 1' I tried this with gpc-20030830 and gpc-20040516, both with gcc-3.3.2 on powerpc-apple-darwin. Regards, Adriaan van Os

5 9

Re: GPC and Threads
by Jose Pascual 07 Oct '04

07 Oct '04

Hi Markus, first of all thank for you answer. > Jose Pascual wrote: > > I'm working in port some of my little application to linux. > All of my > > application has been writting in pascal. My porting to > linux is going > > ok but some of them use threads. > > > > I have read in GPC lists there are people working in a > thread unit for > > GPC, aren't you? > > Yep. great! > > Could someone share this unit with me? I could help to debugging it. > > I'm almost done with the threads themselves and mutexes. If > that is sufficient for your purposes, I'll put it online as > soon as I've finished testing. It'll be afable! I'm in a hurry so I have made some very alpha version with importing funtion from libpthread so I'd like to test your beta version. I'll need threading an semaphore in my application. Do you know (more or less) you are going to put it online? > > thank you so much > > You're welcome, > > Markus thank again best regards Jose Pascual

15 117

building GPC toolchain. Large Files Support.
by Igor Marnat 22 Sep '04

22 Sep '04

Hello dear list! I'm building GPC for arm-elf target. In the source directory in files p/rts/configure.in and rts.h options "_LARGEFILE64_SOURCE" and "_FILE_OFFSET_BITS 64" are hardcoded. Is it really necessary? Is it possible to build GPC without large file support as it doesn't make sense for embedded platforms? It doesn't depend of version of GPC sources. Best regards, Igor Marnat mailto:marny@rambler.ru

3 9

Alternative download sites for gpc?
by Francesco Bonomi 21 Sep '04

21 Sep '04

Dear friends, While www.gnu-pascal.de is down (and I hope the job to bring it up again is not too hard) does anyone know of abother download site that is not too outdated? I am searching for documetnation and binaries, but all I find is VERY old stuff. thanks Francesco Bonomi

4 6

Upper/lower case in identifiers
by Tom Schneider 20 Sep '04

20 Sep '04

program capbug(output); (* capbug: capitalization bug in gpc compiler Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group 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/ *) const (* begin module version *) version = 1.00; (* of capbug.p 2004 Sep 10 2004 Sep 10, 1.00: origin *) (* end module version *) (* begin module describe.capbug *) (* name capbug: capitalization bug in gpc compiler synopsis capbug(output: out) files output: messages to the user description Demonstrate capitals bug in GPC. The name of a local procedure is objected to by GPC if there is a global by the same name but different capitalization. In theory the compiler should keep track of what is local and what is global anyway, so it should be able to avoid this. It is a problem because if one imports procedures from another program, they are not being treated as pure 'black boxes'. Instead, local variable names are being compared to the global variable names. In otherwords, the scope rule of Pascal is being violated when these warnings are generated. This problem is not fixed by adding the flag: -Widentifier-case-local Warn about an identifier written with varying case within one program/module/unit. examples gpc 20040516, based on gcc-3.3.3 for this program itself gives: capbug.p:113: warning: capitalisation of `x' doesn't match capbug.p:111: warning: previous capitalisation `X' capbug.p:113: warning: capitalisation of `y' doesn't match capbug.p:111: warning: previous capitalisation `Y' capbug.p: In procedure `themain': capbug.p:138: warning: capitalisation of `X' doesn't match capbug.p:113: warning: previous capitalisation `x' capbug.p:139: warning: capitalisation of `Y' doesn't match capbug.p:113: warning: previous capitalisation `y' The result is: capbug 1.00 outside: x = 1 outside: y = 2 inside: x = 3 inside: y = 4 themain: X = 5 themain: Y = 6 which demonstrates that the scope rules are being followed when the progrm runs, because X and Y are set before the calls to routines outside and inside, but they are not affected by those calls. That is, the outside and inside routines have local variables. documentation see also {Manual on GPC that gives the -Widentifier-case-local flag:} http://www.gnu-pascal.de/gpc/GPC-Command-Line-Options.html {Discussion on the topic, "Upper/lower case in identifiers":} http://www.gnu-pascal.de/crystal/gpc/en/raw-mail7665.html author Thomas Dana Schneider bugs technical notes *) (* end module describe.capbug *) var X, Y: integer; (* global X and Y *) procedure outside(x, y: integer); (* an outside procedure *) begin x := 1; y := 2; writeln(output,'outside: x = ',x:1); writeln(output,'outside: y = ',y:1); end; (* begin module capbug.themain *) procedure themain; (* the main procedure of the program *) procedure inside(x, y: integer); (* an inside procedure *) begin x := 3; y := 4; writeln(output,'inside: x = ',x:1); writeln(output,'inside: y = ',y:1); end; begin writeln(output,'capbug ',version:4:2); X := 5; Y := 6; outside(X, Y); inside(X, Y); writeln(output,'themain: X = ',X:1); writeln(output,'themain: Y = ',Y:1); end; (* end module capbug.themain *) begin themain; end.

12 30

www.gnu-pascal.de not available
by Eike Lange 18 Sep '04

18 Sep '04

Hi Folks! Due to some misunderstandings is our GPC server not available. Please be patient. Eike -- http://www.gnushi.de

2 2