Gpc April 2006

gpc@gnu.de

18 participants
29 discussions

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

New (gpc-20060325)
by Waldek Hebisch 08 Dec '09

08 Dec '09

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 Main change is preliminary gcc-4.0.x support. The other changes are rather small. Note that for "production use" 3.4.x and 3.3.x backend are prefered. Also, using 2.8.1, 2.95.3 and 3.2.3 backend should work, but is depreciated. For more detail see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20060325 and http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20060325 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

7 44

Range checking problem
by Adriaan van Os 05 May '06

05 May '06

The following was initially discovered by Gale Paeper. [g5:~/gpc/testgpc/adriaan] adriaan% cat rangecheck1.p program rangecheck1; var i: 1..5; begin i:= 5; {$local R-} i:= i+1; {$endlocal} i:= 4; i:= i+2; writeln( 'i = ', i); end. [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 rangecheck1.p --range-checking [g5:~/gpc/testgpc/adriaan] adriaan% ./a.out i = 6 [g5:~/gpc/testgpc/adriaan] adriaan% cat rangecheck2.p {$R+} program rangecheck2; var i: 1..5; begin i:= 5; {$local R-} i:= i+1; {$endlocal} i:= 4; i:= i+2; writeln( 'i = ', i); end. [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 rangecheck2.p --range-checking [g5:~/gpc/testgpc/adriaan] adriaan% ./a.out ./a.out: value out of range (error #300 at 2487) [g5:~/gpc/testgpc/adriaan] adriaan% cat rangecheck3.p {$R+} program rangecheck3; var i: 1..5; begin i:= 5; {$local R-} i:= i+1; {$endlocal} writeln( 'i = ', i); end. [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 rangecheck3.p --range-checking [g5:~/gpc/testgpc/adriaan] adriaan% ./a.out i = 6 [g5:~/gpc/testgpc/adriaan] adriaan% cat rangecheck4.p {$R+} program rangecheck4; var i: 1..5; begin i:= 4; i:= i+2; writeln( 'i = ', i); end. [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 rangecheck4.p --range-checking [g5:~/gpc/testgpc/adriaan] adriaan% ./a.out ./a.out: value out of range (error #300 at 2477) [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 -v Using built-in specs. Configured with: ../gcc-4.1.0/configure --enable-languages=c,pascal --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc410d1 Thread model: posix gpc version 20060325, based on gcc-4.1.0 In other words, {$local R-} disables range-checking for the rest of the file when using --range-checking as a command-line option, not when using {$R+}. I can hardly imagine this is intended behaviour. Regards, Adriaan van Os

2 1

"Frame size too large..."
by lanceboyle＠qwest.net 26 Apr '06

26 Apr '06

I'm getting the following warning when compiling a main program on OS X using the Xcode kit. The whole project includes a number of units too. This reminds me of the days when I would have to make more pointers to arrays and the like and/or increase the stack size in other Mac Pascals. Is there something that I can do to make the messages go away? Is this affecting debugging? warning: frame size too large for reliable stack checking warning: try reducing the number of local variables Jerry

2 1

Re: No run-time check of restricted types
by Dan N 25 Apr '06

25 Apr '06

--- Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > Dan N wrote: > > > The following program runs without any run-time > errors > > or warnings. How to make it produce a (useful) > > run-time error? > > > > program prog; > > var a:1..5; > > begin > > a:=5; > > writeln(a); > > a:=a+1; {Here it should produce at least a > warning} > > writeln(a); > > end. > > Which GPC version do you use? Newer versions should > produce a > run-time error here. The latest snapshot is: > > http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 I have gpc 3.3.3 under Cygwin. This is the latest version avaliable. $ cat a.pas program prog; var a:1..5; begin a:=5; writeln(a); a:=a+1; writeln(a); end. $ gpc -v Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir= /etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --ena ble-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls --without-included-gettext --enable-libg cj --with-system-zlib --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable-sj lj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry Thread model: posix gpc version 20040516, based on gcc-3.3.3 (cygwin special) $ gpc -o aa a.pas $ ./aa.exe 5 6 $ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

No run-time check of restricted types
by Dan N 25 Apr '06

25 Apr '06

The following program runs without any run-time errors or warnings. How to make it produce a (useful) run-time error? program prog; var a:1..5; begin a:=5; writeln(a); a:=a+1; {Here it should produce at least a warning} writeln(a); end. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

out of range error
by vanam srihari kumar 21 Apr '06

21 Apr '06

Hi While running a pascal program on Intel Solaris platform, getting below runtime error /home/kvsspl/deb/solaris/tcp: value out of range (error #300 at 81a473c) Program exited with code 052. Eventhough I am running the program in the debugger, unable to find out the line in the code where it is going. Please suugest me as how to get rid of this error. Regards Hari __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

Problem with Copy in gpc-20060325
by Peter Schorn 20 Apr '06

20 Apr '06

The following program does not compile with gpc-20060325 (but was ok with gpc-20051116). program cpt; type String255 = String(255); function flux: String255; begin flux := 'Flux' end; begin writeln(Copy(flux, 2, 3)) { error: reference expected, value given } end. -- Peter Schorn mailto:peter.schorn@acm.org

1 0

GPC and CodeWarrior Object Pascal
by Peter Schorn 20 Apr '06

20 Apr '06

Dear all, while porting from CodeWarrior Object Pascal to GPC I noticed the following differences which might be worthwhile to address in GPC. 1) Mutual recursive object type declaration program prog1; { compile with gpc --mac-pascal prog1.pas } type t1 = object function f: t2; { error: unknown identifier `t2' } { above works in CodeWarrior Object Pascal as objects are always references } end; t2 = object function g: t1; end; function t1.f: t2; begin f := nil; end; function t2.g: t1; begin g := nil; end; begin end. As a workaround this can be solved by introducing a common super class and subsequent casting. 2) Procedure type assignment compatibility with specialized parameters program prog2; { compile with gpc --mac-pascal prog2.pas } type baseType = object end; derivedType = object(baseType) end; procedure p1(x: baseType); begin end; procedure p2(x: derivedType); begin end; var pv: procedure(x: baseType); begin pv := p1; pv := p2; { error: incompatible types in assignment } end. A workaround is to declare the x in p2 as baseType and perform a cast in the body of p2. 3) Cast in with statement program prog3; { compile with gpc --mac-pascal prog3.pas } type baseType = object end; derivedType = object(baseType) procedure f; end; procedure derivedType.f; begin end; var a: baseType; b: derivedType; begin new(b); a := b; derivedType(a).f; { ok } with derivedType(a) do { warning: `with' element is not a constant or an lvalue } f; { error: invalid lvalue in method call } { error: function call used as a statement } end. A workaround is to use a temporary variable for the with statement.

4 7

Re: Experimental 4.1 port
by Adriaan van Os 20 Apr '06

20 Apr '06

Waldek Hebisch wrote: > I have now "almost ready" experimental gcc-4.1.0 port. There are some minor problems but > basically 4.1.0 port should be now as good (or as bad...) as 4.0.3 port. I would > like to fix some > extra problems (most of them not related to port) and add some feature before I make a new > snapshot, so ATM I have made port available as patches: For inclusion into a new snapshot, may I suggest the following ? 1. <http://www.gnu-pascal.de/crystal/gpc/en/mail13049.html> 2. <http://www.gnu-pascal.de/crystal/gpc/en/mail13046.html> 3. <http://www.gnu-pascal.de/crystal/gpc/en/mail12165.html>, diff attached 4. <http://www.gnu-pascal.de/crystal/gpc/en/mail13557.html> Regards, Adriaan van Os

1 0

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 April 2006