Gpc January 2007

gpc@gnu.de

10 participants
9 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

Memory layout of array of variable size.
by Bastiaan Veelo 24 Dec '07

24 Dec '07

Hi, In an attempt to hook up to GTK+, I am trying to pass a Pascal array of varible size to C. Static arrays are fine, but these arrays carry some additional information like capacity and size, and I gues they could be received as a struct on the C-side. However, I cannot figure out the structure that the struc should have. I do like this in Pascal: procedure YGTK_init(var argc : CInteger; argv : array of CString); external name 'YGTK_init'; procedure Y_init; var argc : CInteger; argv : array[0..ParamCount] of CString; Counter : integer; begin argc := ParamCount+1; for Counter := 0 to ParamCount do begin argv[Counter] := NewCString(ParamStr(Counter)); end; YGTK_init(argc, argv); end; And like this in C: struct t_argv { int end; void *argv; }; void YGTK_init( int *argc, struct t_argv argv ) { printf("In ygtk.c:YGTK_init.\n"); printf("argv.end: %d\n", argv2.argc); printf("argv.argv address: %p\n", argv2.argv); printf("argv.argv int: %d\n", argv2.argv); printf("argv.argv string: %s\n", argv2.argv); printf("number of arguments: %d\n", *argc); } So I figured out that the first element in the struct is an integer containing the length-1 of the array, but what it should look like for the rest I do not know yet. Do you have an idea? Thanks, Bastiaan.

5 9

Re: GCC-4.1.1
by Maurice Lombardi 01 Feb '07

01 Feb '07

CBFalconer a écrit: > Mirsad Todorovac wrote: > >>On Fri, 12 Jan 2007, Russ Whitaker wrote: >> > > ... snip ... > >>>p.s. According to the gcc site, gcc-4.1.2 should be out soon. >>>( days? weeks? ) >> >>These are very good news. >> >>Thank you, Mr. Whitaker. > > > gcc 4.1.0 is available for DJGPP, but I cannot find a port of gpc > to this version. even gcc 4.1.1 is available on the Pavenis Web Site at http://ap1.pp.fi/djgpp/gcc/4.1.1/gcc411.html With it I have built last summer gpc20060325 for djgpp v2.03p2, using the patches gpc-4.1-5f.diff.gz gcc-4.1-5f.diff.gz found on the Waldek Hebisch web site http://www.math.uni.wroc.pl/~hebisch/gpc I had not uploaded it to the gpc web site because running the gpc test suite gives (rerun today): /djgpp/b/gnu/gcc-4.11/gcc/p/script/mkdir-p p/test { \ echo "# Automatically generated from /djgpp/b/gnu/gcc-4.11/gcc/p/test/Makefile."; \ echo "# Don't change manually."; \ echo ""; \ sed -e "s,^srcdir *=.*,srcdir=`cd /djgpp/b/gnu/gcc-4.11/gcc/p/test && pwd`,; \ s,^PC *=.*,PC=`pwd`/xgpc -B`pwd`/,; \ s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --no-unit-path --unit-path=`cd /djgpp/b/gnu/gcc-4.11/gcc/p/units && pwd`," \ /djgpp/b/gnu/gcc-4.11/gcc/p/test/Makefile; \ } > p/test/Makefile || { rm -f p/test/Makefile; false; } echo timestamp > "p/stamp-test-Makefile" cd ./p/test && c:/djgpp/bin/make.exe MASK="" EXTRA_TEST_PFLAGS=" -gstabs" TEST_RUN_FLAGS="" "pascal.check-dejagnu" make.exe[1]: Entering directory `c:/djgpp/b/gnu/build.gcc/gcc/p/test' 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 GP= PC="c:/djgpp/b/gnu/build.gcc/gcc/xgpc -Bc:/djgpp/b/gnu/build.gcc/gcc/" PFLAGS="-I ../rts --no-unit-path --unit-path=c:/djgpp/b/gnu/gcc-4.11/gcc/p/units --autobuild -g -O3 -W -Wall -Wno-unused -gstabs" PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused -gstabs" SRCDIR="c:/djgpp/b/gnu/gcc-4.11/gcc/p/test" TEST_MAKE_FLAG=test-make-flag "c:/djgpp/b/gnu/gcc-4.11/gcc/p/test/test_run" | tee test_log | "c:/djgpp/b/gnu/gcc-4.11/gcc/p/test/test_sum" -d Test Run By dosuser on 2007-01-30 13:41:18 Native configuration is djgpp (KNAUTIE) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas UNSUPPORTED: longr2.pas FAIL: nicola4c.pas FAIL: y2k.pas === gpc Summary === # of tests 5070 # of expected passes 5055 # of unexpected failures 13 # of unsupported tests 2 c:/djgpp/b/gnu/build.gcc/gcc/xgpc version 20060325, based on gcc-4.1.1 (The y2K FAIL is erratic and spurious, related not to gpc, but to peculiarities of the clock when running in a DOS box under W98se) whereas there is NO error with gcc-3.4.4 I am always afraid that a beginner downloads the latest version, stump on a bug and concludes that gpc is not a good compiler. Since you seem interested I just downloaded it in the usual place http://www.gnu-pascal.de/contrib/maurice/gpc-20060325-gcc-411.i586-pc-msdos… and flagged it with a large ALPHA !!! I hope this will warn enough beginners. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 3

GCC-4.1.1
by Mirsad Todorovac 29 Jan '07

29 Jan '07

Hi, and Happy New Year [with delay]! Best wishes for your health and progress in work on project and in life for New Year! BTW, I've been checking the archives, and last message Re: GCC-4.1.1 was from Jul 21 2006. The thread says the GCC-4.1.1 port is in alpha stage. How far did the progress go, and when it could be considered beta or "release"? Regards, Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

4 4

Gnu pascal and gtk
by Harmonious Botch 29 Jan '07

29 Jan '07

I recently installed gnu pascal on fedora. I have assumed that I installed it correctly because the tradional 'hello world' compiles and runs fine. I then installed gtk. I then tried a gtk version of hello world, as follows: (************************ program begins here *************) program hw( output ); {$include "gtk.inc"} begin GtkInit; Window := GtkWindowNew(GTK_WINDOW_TOPLEVEL); GtkWidgetShow(Window); GtkMain; end. (************************ program ends here ****************) I try to compile with: gpc -Wall -v -c hw.pas -o hw and I get the following error: /urs/local/i686-pc-linux-gnu/include/gtk.inc:9: module/unit `glib' could not be imported If I try to compile with: gpc --automake -Wall -v -c hw.pas -o hw I get this error: /urs/local/i686-pc-linux-gnu/include/gtk.inc:9: module/unit `glib' could not be compiled Glib is referenced in gtk.inc, as follows: (************ code snippet starts here*************) { Glib and Gdk standard units. } uses Glib, GModule, Gdk, GdkTypes; (************ code snippet ends here*************) So, I have 2 questions: 1) What do these errors mean? I am assuming that they mean that I have some file in the wrong directory. 2)What are the proper paths for the installation of the gtk libs? ( Absolute, or relative to the working directory ) Answers to those, or any general advice on how to install & use gtk will be much appreciated. Thanks HB -- View this message in context: http://www.nabble.com/Gnu-pascal-and-gtk-tf3133597.html#a8682964 Sent from the Gpc mailing list archive at Nabble.com.

1 0

compile problem on hp-ux 11.23
by Stoyan Angelov 16 Jan '07

16 Jan '07

hello all, i am trying to compile gpc-20060325 with the gcc-3.4.4 core on hp-ux 11.23 (PA-RISC) but i get the following error when the compilation process reaches the rts directory: gmake[2]: Entering directory `/home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/p/rts' echo '{ rts-config.inc. Generated automatically from rts-config.h. }' > rts-config.inc sed -e 's,/\*,{,g;s,\*/,},g;s,^[ \t]*#$.*$,{$\1},' rts-config.h >> rts-config.inc /home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/xgcc -B/home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/ -B/opt/gpc/hppa2.0w-hp-hpux11.23/bin/ -B/opt/gpc/hppa2.0w-hp-hpux11.23/lib/ -isystem /opt/gpc/hppa2.0w-hp-hpux11.23/include -isystem /opt/gpc/hppa2.0w-hp-hpux11.23/sys-include -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 -Wpointer-arith -Wwrite-strings "/home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c" /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:1: warning: -g is only supported when using GAS on this processor, /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:1: warning: -g option disabled /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:660: error: conflicting types for 'open64' /usr/include/sys/fcntl.h:246: error: previous declaration of 'open64' was here /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:660: error: conflicting types for 'open64' /usr/include/sys/fcntl.h:246: error: previous declaration of 'open64' was here /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:663:1: warning: "open" redefined In file included from /usr/include/fcntl.h:9, from /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:89: /usr/include/sys/fcntl.h:259:1: warning: this is the location of the previous definition /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:691: error: conflicting types for 'usleep' /home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/include/sys/unistd.h:413: error: previous declaration of 'usleep' was here /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:691: error: conflicting types for 'usleep' /home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/include/sys/unistd.h:413: error: previous declaration of 'usleep' was here /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c: In function `_p_Sleep': /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:1084: warning: implicit declaration of function `_sleep' /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c: In function `_p_CStringStrSignal': /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:2446: warning: empty body in an if-statement gmake[2]: *** [rts.o] Error 1 gmake[2]: Leaving directory `/home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/p/rts' gmake[1]: *** [pascal.rts] Error 2 gmake[1]: Leaving directory `/home/aduritz/truetrue/gnu-pascal/gpc-build/gcc' gmake: *** [all-gcc] Error 2 i was able to resolve the "usleep" by removing the definition from rts.c and leaving the one in unistd.h. any help will be greatly appreciated. greetings, Stoyan Angelov

1 0

Creating a DLL in MingW32
by Glenn Howes 08 Jan '07

08 Jan '07

Hi, Well, I need to create a Windows version of the library I previously created on the Mac. I've installed MingW32 and MYSYS on my PC. GPC automakes my Pascal source files and creates .o and .gpi files. And at this point I'm completely at sea. I need to create a DLL which is loadable from a Visual Studio C++ application. By analogy with the gcc command given in the MingW32 FAQ (http:// www.mingw.org/mingwfaq.shtml), I tried: $ gpc -c --automake MySource.p -shared -o MySource.DLL -Wl, --ouput- def, MySource.def, --out-implib, MySource.a -lgpc and the output is: gpc.exe: --output-def: linker input file unused because linking not done gpc.exe: MySource.def: linker input file unused because linking not done gpc.exe: --out-implib: linker input file unused because linking not done gpc.exe: MySource.a: linker input file unused because linking not done gpc.exe: -lgpc: linker input file unused because linking not done And even if this had worked, I'm not quite sure what the next step would have been, so it'd be nice if I could get all the voodoo and not just the next step. I could use, and appreciate some hand holding here. $gpc --version gpc.exe 20051116, based on gcc-3.2.3 (mingw special 20030504-1) $ gcc --version gcc.exe (GCC) 3.2.3 (mingw special 20030504-1) --glenn

3 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 2007