Gpc January 2005

gpc@gnu.de

20 participants
23 discussions

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

gpc-20041017 released
by Frank Heckenbach 15 Feb '05

15 Feb '05

I have uploaded a new beta version of GPC to <http://www.g-n-u.de/gpc/>! Because our main server is still out of order, please note: - The new URL, as stated above. www.gnu-pascal.de still doesn't work. - There are just the "bare bones" files (full and minimal source distribution, binaries for Linux/IA32 with and without gcc). No diffs, no separate test files, no HTML pages etc. - The main directory in the full source distribution is probably different! Be careful with automatic build scripts. - The releases are signed with a new OpenPGP key. The fingerprint is given in my signature in this mail and my other mails to the gpc(a)gnu.de list for some weeks. When the main server is back again, I'll do the usual release procedures there. One major change is that the types `Integer', `Word', `Cardinal' are now equivalent to `PtrInt', `PtrWord', `PtrCard', no more (necessarily) to C's `int' and `unsigned int' types. New types `CInteger', `CWord', `CCardinal' are provided for the latter purpose. This affects C interfaces in particular. A "porting guide" is given below. If you maintain any such interfaces, be sure to read it carefully. Another major improvement is in the area of initializers, thanks to Waldek Hebisch. GPC now allows initialization of variant records (fjf259.pas, peter6.pas) and packed arrays (emil5.pas) and supports Extended Pascal's structured initializers (fjf964*.pas, fjf967*.pas, fjf968*.pas) as well as record, array and set values (constdef.pas, fjf966*.pas, fjf971*.pas). Unfortunately, we don't have very many test programs for these new features yet. If you can send us some (according to the guidelines described in the manual), this will be very welcome. Other new features: * `Discard' * new make variable `GPC_PAGESIZE' to set the page size when building the manual (PDF, PostScript, DVI) * `qualified' and import lists are no more allowed after `uses' (only after `import', as EP demands) (@) * the `GMP' unit doesn't support gmp-2.x anymore (if you used it, just upgrade to a newer GMP version) (@) * conflicts between object fields/methods and ancestor type names are detected as required by OOE (fjf945*.pas) (@) (O) * repeated function headings (in `forward' declarations and interfaces) are checked stricter: if one has a result variable, so must the other (according to the OOE draft) (@) (O) Bugfixes: * records with no fields are invalid according to EP (fjf972.pas) * `Index' and `Pos' cannot be used in constant expressions (fjf970*.pas) * the `__FILE__' and `__BASE_FILE__' macros should return full paths * `Sqr' sometimes evaluates its argument twice (fjf963.pas) * memory leak in routines with a local variable of file type that are left via `Exit' or `Return' (fjf962.pas) * using a Boolean function as a condition in a `repeat' loop doesn't work correctly (artur1*.pas) * overstrict type-checking in comparisons involving procedural types (fjf960*.pas) * `Read', `Write' etc. evaluate its arguments in the wrong order (az43*.pas) * `Read' etc. evaluate references to string parameters twice (fjf958.pas) * on targets with 16 bit `Integer' type, the `MicroSecond' field of `TimeStamp' causes a compilation error * character arrays indexed by non-integer ordinal types treated as strings cause internal compiler errors (fjf957*.pas) * `-W[no-]cast-align' does not work (fjf956*.pas) * in `FormatTime' `%Z' and `%z' unless provided by system library ignore DST * powerpc: `--strength-reduce' doesn't work with `for' loops (was kludged before, fixed in gcc-3.3.3) * AIX: `ReturnAddress' doesn't work after use of dynmamic variables (backend bug, fixed in gcc-3.3.3) * functions returning sets are called twice if range-checking is on (inga1*.pas) PORTING GUIDE FOR THE NEW C COMPATIBLE INTEGER TYPES ==================================================== In my experience, the transition goes as follows: 1. If you want your code to keep working with older GPC versions after this change, add (near the top) the following part. You can omit the types you will not need in the following. {$if __GPC_RELEASE__ < 20041017} type CInteger = Integer; CCardinal = Cardinal; CWord = Word; {$endif} 2. In all C-visible declarations, replace `Integer' with `CInteger' and `Cardinal'/`Word' with `CCardinal'/`CWord'. C-visible declarations are usually `external' declarations (routines and/or variables) in Pascal which are implemented in C, but they can also be Pascal-implemented declarations (usually with a `name' attribute) which are declared `extern' in C code. Do not forget structures that are used within such declarations, e.g. parameters of type [pointer to] a record, or procedural parameters, etc. The same goes for other languages such as C++. 3. Fix any resulting incompatibilites. (This is the nasty part.) Value parameters are usually no problem. Anything else might be a problem, e.g., reference parameters, variables, structure fields, procedural parameters' parameters (including value parameters). As long as they are used only in the implementation of a unit/module which exports a Pascal interface, necessary changes can be confined to and handled within this interfaec. Otherwise, you have the choice whether to change the interface, which will require further changes in code using the interface, or to add wrappers to keep the interface. Example: unit MyCInterface; interface uses GPC; type t = record x, y, z: Integer end; procedure a (n: Integer); external name 'a'; procedure b (var n: Integer); external name 'b'; procedure c (var r: t); external name 'c'; function d (var n: Integer): TString; implementation function cd (var n: Integer): CString; external name 'd'; function d (var n: Integer): TString; begin d := CString2String (cd (n)) end; end. Changing a to procedure a (n: CInteger); external name 'a'; is usually harmless. Changing b to procedure b (var n: CInteger); external name 'b'; is problematic, since all callers would need to change their types (which might cause further ramifications in indirectly dependent code). So it might be in order to add a wrapper, such as: procedure b (var n: Integer); [implementation] procedure cb (var n: CInteger); external name 'b'; procedure b (var n: Integer); var cn: CInteger; begin cn := n; { omit if n is used only as an "output" parameter } cb (n); n := cn end; Procedure c uses a record containing `Integer' fields. Here, it's a hard choice between adding a wrapper (might be expensive, as the record gets bigger, and if more routines are affected) or changing the record to: type t = record x, y, z: CInteger end; The choice might depend on how many other routines use this structure and how many of them are written in Pascal or C, and how much existing code already uses the structure and what it does with it. Function d already has a wrapper, so it's usually best to also take care of the new change there: function d (var n: Integer): TString; var cn: CInteger; begin cn := n; { omit if n is used only as an "output" parameter } d := CString2String (cd (n)) n := cn end; Finally, note that `Integer' might be bigger than `CInteger', especially on newer platforms (that's the reason for the whole change in the first place). So if you want to have a bigger range available, you might want to consider changing from `CInteger' etc. (`[unsigned] int' in C) to `MedInt' etc. (`[unsigned] long' in C). This, however, requires (possibly substantial) changes in the C code, and might be out of your control (when interfacing to 3rd party libraries). 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 NEW! GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

9 23

the magics of eof()
by Francesco Bonomi 13 Feb '05

13 Feb '05

Dear friends, I don't know if what I found is a bug or a correct behaviour I don't understand. The following program halts with error 'attempt ro read past end of file'; program test; var f : file of char; begin rewrite(f,'test.dat'); seek(f,0); f^:='x'; (*GIVES ERROR HERE*) put(f); close(f); end. If I just insert a call reading eof(f) everything seems to work: program test; var f : file of char; begin rewrite(f,'test.dat'); seek(f,0); if eof(f) then ; (* do nothing *) f^:='x'; put(f); close(f); end. I am puzzled! (working with gpc 20030830) Ciao, Francesco

4 8

test-fjf949.pas - endless loop
by jan.ruzicka＠comcast.net 10 Feb '05

10 Feb '05

Hi list, the test fjf949.pas from the test suite gpc-test-20041218.tar.gz (beta) seems to be getting into a endless loop. with gdb: #0 $000025a4 in init_pascal_main_program () at fjf949.pas:4 #1 $00002614 in main (argc=1, argv=$bffff01c, envp=$bffff024) at <implicit code>:10 the line is 4 a: array [Byte] of String (2); I am running gpc on Mac OS X and it was installed through fink. There were more test failures in test suite, but this one seems to be the most critical. Jan Ruzicka PS: Disassembled portion of the code is: 0x0000253c <init_pascal_main_program+0>: mflr r0 0x00002540 <init_pascal_main_program+4>: stmw r30,-8(r1) 0x00002544 <init_pascal_main_program+8>: stw r0,8(r1) 0x00002548 <init_pascal_main_program+12>: stwu r1,-80(r1) 0x0000254c <init_pascal_main_program+16>: mr r30,r1 0x00002550 <init_pascal_main_program+20>: bcl- 20,4*cr7+so,0x2554 <init_pascal_main_program+24> 0x00002554 <init_pascal_main_program+24>: mflr r31 0x00002558 <init_pascal_main_program+28>: addis r9,r31,4 0x0000255c <init_pascal_main_program+32>: addi r9,r9,-22972 0x00002560 <init_pascal_main_program+36>: lbz r0,0(r9) 0x00002564 <init_pascal_main_program+40>: clrlwi r0,r0,24 0x00002568 <init_pascal_main_program+44>: cmpwi r0,0 0x0000256c <init_pascal_main_program+48>: bne- 0x25b8 <init_pascal_main_program+124> 0x00002570 <init_pascal_main_program+52>: addis r9,r31,4 0x00002574 <init_pascal_main_program+56>: addi r9,r9,-22972 0x00002578 <init_pascal_main_program+60>: li r0,1 0x0000257c <init_pascal_main_program+64>: stb r0,0(r9) 0x00002580 <init_pascal_main_program+68>: li r0,0 0x00002584 <init_pascal_main_program+72>: stb r0,56(r30) ;-------------------- here starts the loop 0x00002588 <init_pascal_main_program+76>: addis r9,r31,4 0x0000258c <init_pascal_main_program+80>: addi r9,r9,-26044 0x00002590 <init_pascal_main_program+84>: lbz r0,56(r30) 0x00002594 <init_pascal_main_program+88>: clrlwi r0,r0,24 0x00002598 <init_pascal_main_program+92>: mulli r0,r0,12 0x0000259c <init_pascal_main_program+96>: add r9,r0,r9 0x000025a0 <init_pascal_main_program+100>: li r0,2 0x000025a4 <init_pascal_main_program+104>: stw r0,0(r9) 0x000025a8 <init_pascal_main_program+108>: lbz r9,56(r30) 0x000025ac <init_pascal_main_program+112>: addi r0,r9,1 0x000025b0 <init_pascal_main_program+116>: stb r0,56(r30) 0x000025b4 <init_pascal_main_program+120>: b 0x2588 <init_pascal_main_program+76> ;-------------------- here ends the loop 0x000025b8 <init_pascal_main_program+124>: lwz r1,0(r1) 0x000025bc <init_pascal_main_program+128>: lwz r0,8(r1) 0x000025c0 <init_pascal_main_program+132>: mtlr r0 0x000025c4 <init_pascal_main_program+136>: lmw r30,-8(r1) 0x000025c8 <init_pascal_main_program+140>: blr

10 45

not 0
by Adriaan van Os 08 Feb '05

08 Feb '05

GPC accepts: var i: integer value not 0; but it doesn't accept: var w: word value not 0; not.pas:4: error: constant out of range not.pas:4: error: initial value is of wrong type so, the workaround is: var w: word value not word( 0); At first sight, this looks a bit clumsy (but at second sight it may not). It gives rise to general questions about the type of constants in Pascal, e.g. * is there a difference between $FF.. and $0FF.. ? * is $FF.. signed or not ? Any comments ? Regards, Adriaan van Os

5 18

segmentation fault
by willett 07 Feb '05

07 Feb '05

program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits. tested on GNU Pascal version 20030830, based on gcc-3.3.2 Willett Kempton

7 19

64 bit GPC on AIX
by Peter Keenan 06 Feb '05

06 Feb '05

I have built GPC 20041218 on GCC 3.3.4 on AIX 5.2, and thought it might be useful to document my experiences. I wanted to have the capacity to build 64 bit programs, however only 32 bit libraries are installed for GPC. Following my earlier post http://www.gnu- pascal.de/crystal/gpc/en/mail11115.html Waldek suggested trying build a 64 bit version of GCC including GPC. However having tried various strategies I was not successful in building a 64 bit only version of any version of GCC, even without GPC. So I tried to just build a 64 bit libgpc.a. I eventually achieved this export OBJECT_MODE = 64 export CFLAGS=-maix64 then run ./configure in ...gcc3.3.4/gcc/p/rts directory edit Makefile add -maix64 to CFLAGS (CFLAGS=-O2) copy libgpc.a to ...lib/gcc-lib/power..../3.3.4/ppc64 This allowed me generate 64 bit programs. My program contained a reference to the memavail function in system.pas. I had earlier had some problems with this function in 32 bit mode when it gave an error http://www.gnu-pascal.de/crystal/gpc/en/mail11086.htm In 64 bit mode the use of this function did not report an error but partly disabled the operating system, which should have been quite impossible for a normal user without root privileges! The operator had to reset the machine following this error. Programs without this function call seem to work fine.

2 1

testsuite with gp
by Adriaan van Os 05 Feb '05

05 Feb '05

Built gp-0.57 on powerpc-apple-darwin. Tried to run the testsuite with PC=gp. [G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels PC=gp rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core PC="gp" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d ./test_run: fatal: `--print-needed-options' yields: gp: internal problem: unexpected additional output of `gp -dumpmachine' Nothing was run. gp -dumpmachine on the command line displays gp help lines. I don't know if running the testsuite with gp is something that can already be done. Just reporting the results. Regards, Adriaan van Os

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc January 2005