Gpc January 2008

gpc@gnu.de

6 participants
7 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

compiling static library + gpc runtime without _statvfs on Mac OS X for Intel
by Glenn Howes 20 Apr '08

20 Apr '08

Hello, After months of being distracted by another portion of my application, I'm back to creating a universal binary version of the Pascal based library we are linking into our C++ based application. The problem is the application will not launch under PPC on Mac OS X 10.3 (Panther). The console registers an undefined symbol: _statvfs expected to be defined in /usr/lib/libSystem.B.dylib After some research, I found this call is being used by the StatFS routine implemented in rts.c (line 1510) /** Get information about a file system. */ GLOBAL (Boolean _p_StatFS (char *Path UNUSED, StatFSBuffer *Buf)) { int Result; #ifdef HAVE_STATVFS struct statvfs b; errno = 0; Result = statvfs (Path, &b); Buf->BlockSize = (long long int) b.f_frsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_favail; #elif defined (HAVE_STATFS) struct statfs b; errno = 0; Result = statfs (Path, &b); Buf->BlockSize = (long long int) b.f_bsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_ffree; #else Result = -1; errno = ENOSYS; #endif if (Result == 0) return True; Buf->BlockSize = 0; Buf->BlocksTotal = 0; Buf->BlocksFree = 0; Buf->FilesTotal = 0; Buf->FilesFree = 0; return False; } It appears to me that HAVE_STATVFS is defined if my current OS X SDK (10.4) has a statvfs.h header file amongst its include files, which means if I build my Pascal development environment from the build-on- Intel.command that the statvfs version will be hard wired into the runtime and any binary I generate will not work on 10.3 (which does not have statvfs in its libSystem.B.dylib library). Also, if I build my environment/library on a PowerPC using the build-on- powerPC-10.3.command, I end up with a different set of link problems involving the long double version of pow(). Besides which, I'd prefer to do my development on OS X for Intel going forward. I have tried hand editing the above routine and rebuilding my Pascal development environment, and pulling the statvfs.h file from my OS X SDK, and yet when my application links, it still has an unresolved reference to _statvfs. I'm not a build engineer, as my previous missives to this mailing list make clear, and I'm at a loss as to how to proceed. Just to be clear, I link in two static libraries: a universal version of the libgpc.a for the runtime, and a universal version of the library I've created. Neither of them contain the symbol _statvfs (at least I can't find that text in them). I link that with my application. The application now references _statvfs (I can now see the text in it's executable). I can't launch on 10.3. I comment out the calls to the Pascal library and recompile+relink, and the application no longer has the symbol and I can launch under 10.3. So something in either of the gpc associated libraries must be calling something which calls statvfs, making the linker (ld) mark statvfs as an unresolved symbol to be loaded in at runtime. At least that is my impression. So, I'd appreciate some suggestions. --glenn

4 8

[Patch] testsuite/gdb.pascal new testcase integer.exp
by Pierre Muller 31 Jan '08

31 Jan '08

I committed this as pascal language maintainer. For gpc mailing list mainly: I had to add to XFAIL for gpc because of the buggy line information. I used an old gpc gpc 20050331, based on gcc-3.4.4 (cygming special, gdc 0.12, using dmd 0.125) but this is the official cygwin distro of gpc. Do newer gpc binaries give better results? Pierre Muller testsuite/ChangeLog entry: 2008-01-31 Pierre Muller <muller(a)ics.u-strasbg.fr> * gdb.pascal/integers.pas: New test program. * gdb.pascal/integers.exp: New testcase. Index: gdb.pascal/integers.pas =================================================================== RCS file: gdb.pascal/integers.pas diff -N gdb.pascal/integers.pas --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/integers.pas 31 Jan 2008 14:49:23 -0000 1.1 @@ -0,0 +1,51 @@ +{ + Copyright 2008 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. +} + +program integers; + + +function add(a,b : integer) : integer; +begin + add:=a+b; +end; + +function sub(a,b : integer) : integer; +begin + sub:=a-b; +end; + +var + i, j, k, l : integer; + +begin + i := 0; + j := 0; + k := 0; + l := 0; { set breakpoint 1 here } + i := 1; + j := 2; + k := 3; + l := k; + + i := j + k; + + j := 0; { set breakpoint 2 here } + k := 0; + l := add(i,j); + l := sub(i,j); + +end. Index: gdb.pascal/integers.exp =================================================================== RCS file: gdb.pascal/integers.exp diff -N gdb.pascal/integers.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/integers.exp 31 Jan 2008 14:49:23 -0000 1.1 @@ -0,0 +1,129 @@ +# Copyright 2008 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +if $tracelevel then { + strace $tracelevel +} + +load_lib "pascal.exp" + +set testfile "integers" +set srcfile ${testfile}.pas +set binfile ${objdir}/${subdir}/${testfile}$EXEEXT + +if {[gdb_compile_pascal "${srcdir}/${subdir}/${srcfile}" "${binfile}" executabl e [list debug ]] != "" } { + return -1 +} + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir +gdb_load ${binfile} +set bp_location1 [gdb_get_line_number "set breakpoint 1 here"] +set bp_location2 [gdb_get_line_number "set breakpoint 2 here"] + +if { [gdb_breakpoint ${srcfile}:${bp_location1}] } { + pass "setting breakpoint 1" +} +if { [gdb_breakpoint ${srcfile}:${bp_location2}] } { + pass "setting breakpoint 2" +} + +# Verify that "start" lands inside the right procedure. +if { [gdb_start_cmd] < 0 } { + untested start + return -1 +} + +gdb_test "" ".* at .*${srcfile}.*" "start" + +gdb_test "cont" "Breakpoint .*:${bp_location1}.*" "Going to first breakpoint" + +gdb_test "print i" ".* = 0" "Print i before assigned to 1" + +gdb_test "next" "i := 1;" "Next to 'i := 1' line" +gdb_test "next" "j := 2;" "Next to 'j := 2' line" +# At that point, +# i should be equal to 1 +gdb_test "print i" " = 1" +# but j should still be equal to zero +if { $pascal_compiler_is_gpc } { + setup_xfail *-*-* +} +gdb_test "print j" " = 0" "Test j value before assignment" + +gdb_test "next" "k := 3;" "Next to 'k := 3' line" +gdb_test "next" "l := k;" "Next to 'l := k' line" + +#j should be equal to 2 +gdb_test "print j" " = 2" +# k should be equal to 3 +gdb_test "print k" " = 3" +# But l shoud still be zero +if { $pascal_compiler_is_gpc } { + setup_xfail *-*-* +} +gdb_test "print l" " = 0" + +# Test addition +gdb_test "print i + j" " = 3" +gdb_test "print i + k" " = 4" +gdb_test "print j + k" " = 5" +gdb_test "print i + j + k" " = 6" + +# Test substraction +gdb_test "print j - i" " = 1" +gdb_test "print i - j" "= -1" +gdb_test "print k -i -j" " = 0" +gdb_test "print k -(i + j)" " = 0" + +# Test unany minus +gdb_test "print -i" " = -1" +gdb_test "print (-i)" " = -1" +gdb_test "print -(i)" " = -1" +gdb_test "print -(i+j)" " = -3" + +# Test boolean operators =, <>, <, <=, > and >= +gdb_test "print i + 1 = j" " = true" +gdb_test "print i + 1 <> j" " = false" +gdb_test "print i + 1 < j" " = false" +gdb_test "print i + 1 <= j" " = true" +gdb_test "print i + 1 > j" " = false" +gdb_test "print i + 1 >= j" " = true" + +# Test multiplication +gdb_test "print 2 * i" " = 2" +gdb_test "print j * k" " = 6" +gdb_test "print 3000*i" " = 3000" + +#Test div and mod operators +gdb_test "print 35 div 2" " = 17" +gdb_test "print 35 mod 2" " = 1" + +# Test several operators together +gdb_test "print i+10*j+100*k" " = 321" +gdb_test " print (i + 5) * (j + 7)" " = 54" + +# 'set i' does not work, as there are set sub-commands starting with 'i' +# Thus we need to use 'set var i' +gdb_test "set var i := 2" " := 2" +gdb_test "print i" " = 2" "Testing new i value" + +gdb_test "cont" \ + "Breakpoint .*:${bp_location2}.*" \ + "Going to second breakpoint" +gdb_test "print i" \ + ".* = 5.*" \ + "Value of i after assignment"

1 0

Help installing on Mac OSX 10.5
by Tom Schneider 30 Jan '08

30 Jan '08

Could someone point me to simple step-by-step instructions for complete installation of GPC on Mac OSX 10.5? I got: http://www.microbizz.nl/gpc.html GNU Pascal 3.4.5u2 installer for Mach-O Intel (Intel native and PowerPC cross compiler) (16.6 MB) and was able to get it installed at: /Developer/Pascal/gpc345u2/bin/gpc so: [toot:~/now/delila] tds% which gpc /usr/bin/gpc [toot:~/now/delila] tds% dir /usr/bin/gpc lrwxr-xr-x 1 root wheel 34 Jan 29 23:19 /usr/bin/gpc@ -> /Developer/Pascal/gpc3 45u2/bin/gpc but when I try to compile I get: /usr/bin/ld: can't locate file for: -lcrt1.o (along with various warnings about my program that are ok.) I get no compiled result. (I also installed the Mac OS X Pascal Interfaces but that did not help.) Adding: --unit-path=/Developer/Pascal/GPCPInterfaces -I/Developer/Pascal/GPCPInterfaces to my control script did not help. I have no clue as how to fix this. Thanks, Tom Dr. Thomas D. Schneider National Institutes of Health National Cancer Institute Center for Cancer Research Nanobiology Program Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.ccrnp.ncifcrf.gov/~toms/

2 1

Problem porting to Mac OS-X
by Martin Liddle 16 Jan '08

16 Jan '08

Apologies because this is probably a silly question. I have a small application that I have written in Gnu Pascal that works nicely under Fedora Core 7 on an Intel PC using gpc 20020502 (yes I know it is old but there are reasons not connected with this task). I now want to port the application to Apple Macs running OS-X. I have downloaded and installed gpc 20051116 from <http://www.microbizz.nl/gpc.html> and that appears to be working. My application compiles OK but fails at the linking stage with the message: /usr/bin/ld: can't locate file for : -lcrt1.o The only unit my application includes is gpc.pas and the only screen input and output is simple reads and writes. A search doesn't find a crt1.o anywhere on the system. What do I do next? -- Martin Liddle, Tynemouth Computer Services, 3 Kentmere Way, Staveley, Chesterfield, Derbyshire, S43 3TW. Web site: <http://www.tynecomp.co.uk>.

3 9

bug report
by Russell Whitaker 04 Jan '08

04 Jan '08

hi given: program bug; procedure foo; begin end; begin foo( 1 ); writeln("OK"); end. gives these compile errors: bug.pas: In main program: bug.pas:8: error: too many (>1) arguments to routine `foo' bug.pas:3: error: routine declaration bug.pas:8: error: too few (1) arguments to function `foo' russ

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 January 2008