February 2007 - Gpc

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

make for GPC on Solaris and quad processing
by Bernd Rehling 28 Feb '07

28 Feb '07

Hello, these are my first trials with GPC: The compilation with GNU-make failed on Solaris 10 in context with 'quad processing'. I guess this stands for long floating point data types. The 'gmake' command fails with: ../.././xgpc -B../.././ -L../.. -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/home/paspro/Compiler/gcc-3.2.3/gcc/p/rts --unit-path=/home/paspro/Compiler/gcc-3.2.3/gcc/p/units "/home/paspro/Compiler/gcc-3.2.3/gcc/p/utils/binobj.pas" Undefined first referenced symbol in file _Q_itoq ../../libgpc.a(files.o) (symbol scope specifies local binding) _Q_qtou ../../libgcc.a(_fixunstfdi.oS) (symbol scope specifies local binding) _Q_add ../../libgpc.a(files.o) (symbol scope specifies local binding) _Q_flt ../../libgpc.a(files.o) (symbol scope specifies local binding) _Q_mul ../../libgpc.a(files.o) (symbol scope specifies local binding) _Q_sub ../../libgpc.a(files.o) (symbol scope specifies local binding) ld: fatal: Symbol referencing errors. No output written to ./binobj On the internet I found hints, that Solaris in general has different 128bit processing: " Sparc 64bit ABI requires different syntax of the quad floating point software emulation (_Qp_* routines) than what is common in gcc. 128bit long doubles are passed by reference to these functions and if it returns a long double, they take the first argument as a pointer to that long double. ... " I couldn't find a solution. The make works with the languages C,C++ and Fortran, but not with Pascal. Can somebody working on Solaris help how to compile GPC or where I can get binaries ? Best Regards Bernd -- Bernd Rehling Hermann-Rodewald-Str.3 Raum 411 Tel.: (0431) 880-4475 Institut für Informatik der Christian-Albrechts-Universität zu Kiel

1 0

Runner script
by Mirsad Todorovac 27 Feb '07

27 Feb '07

Mr. Waldek, Could you please publish your runner script so I could run properly test suite despite the presence of PAX process killer on my Linux kernel? IMHO these half-done tests are of no use to anybody, so please if you would be so kind to grant my request. Regards, Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

2 2

CRT unit and UTF-8 displays
by Andreas K. Foerster 18 Feb '07

18 Feb '07

Hello, there is some trouble when the display is set to UTF-8 and my program uses the CRT unit. Some characters are just shown as several spaces or even scramble the display. For example I cannot use the german letter sharp s #$C3#$9F (U+00DF) or german quotation marks #$E2#$80#$9E ... #$E2#$80#$9C (U+201E ... U+201C). It works fine without the CRT unit. Also when I use FreePascal it is all right. I've tried to use the command "SetPCCharset(false);", but that didn't help. Is there anything else I could try? -- AKFoerster

2 5

Test results gpc-20060325 on gcc-4.1.1
by Mirsad Todorovac 17 Feb '07

17 Feb '07

Here are the test results on my box. Test Run By mtodorov on 2007-02-13 22:15:43 Native configuration is i686-pc-linux-gnu (domac) gpc 20060325, based on gcc-4.1.1, flags: -g -O3 -W -Wall -Wno-unused TEST agettext2test.pas: SKIPPED: could not set locale `de_DE' TEST aregextest.pas: SKIPPED: librx not installed TEST backtracerr.pas: 14c14,71 < ./test_run: line 339: 20465 Killed ./"$A_OUT" "$1" --- > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > d: > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > b: back from yy > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > program: back from b( d ) failed TEST fay.pas: 1c1,12 < ./test_run: line 339: 420 Killed ./"$A_OUT" "$1" --- > stacking 1 > Doing successors of 1 > stacking 2 > Doing successors of 2 > Now checking if 2 is an SCC root > Now checking if 1 is an SCC root > 1 is an SCC root; SP= 2 T= 1 > Yield SCC should pass 1 out to TakeUSCC > YieldUSCC passes 1 to TakeUSCC > TakeUSCC receives V= 1 from YieldUSCC > The SCC's constituents are: > 2 1 failed TEST fjf165a.pas: SKIPPED: German locale not installed TEST fjf206c.pas: failed: ./fjf206c.pas:2: error: arithmetical overflow ./fjf206c.pas:2: error: constant overflow in expression TEST fjf322.pas: 'result_0.length./fjf322.pas: In function `o': gpc1: warnings being treated as errors ./fjf322.pas:8: warning: ' is used uninitialized in this function failed TEST fjf35.pas: ./test_run: line 339: 16467 Killed ./"$A_OUT" "$1" TEST fjf395a.pas: a Value 2 TEST fjf395b.pas: a Value -128 TEST fjf403b.pas: failed: failed TEST fjf563e.pas: failed: failed TEST fjf587b.pas: 'concat_0._p_Schema_[3]{lb: 1 sz: 1}./fjf587b.pas: In procedure `Foo': gpc1: warnings being treated as errors ./fjf587b.pas:5: warning: ' is used uninitialized in this function failed TEST fjf779a.pas: failed: TEST fjf779b.pas: failed: TEST fjf779e.pas: failed: TEST fjf779f.pas: failed: TEST fjf779g.pas: failed: TEST fproc.pas: 4c4,11 < Stack frame: 0 formal print =./test_run: line 339: 1897 Killed ./"$A_OUT" "$1" --- > Stack frame: 0 formal print = 4 formal routine = 4 > Stack frame: 1 formal print = 4 formal routine = 4 > Stack frame: 2 formal print = 4 formal routine = 4 > Stack frame: 3 formal print = 4 formal routine = 4 > Stack frame: 4 formal print = non-local jump > Stack frame: 8 formal print = -1 formal routine = -1 > Stack frame: 9 formal print = -1 formal routine = -1 > Stack frame: 10 formal print = -1 formal routine = -1 failed TEST gmptest.pas: SKIPPED: libgmp (>=3.x) not installed TEST knuth1.pas: ./test_run: line 339: 175 Killed ./"$A_OUT" "$1" TEST nicola4c.pas: failed: TEST nlgpp.pas: ./test_run: line 339: 21147 Killed ./"$A_OUT" "$1" TEST nlgpp2.pas: 13c13,30 < ./test_run: line 339: 12038 Killed ./"$A_OUT" "$1" --- > DoGoto 3 True > OK > Recursive end 3 True > Recursive before goto 4 True > Recursive end 4 True > Recursive before goto 5 True > Recursive end 5 True > Recursive before goto 6 True > Recursive end 6 True > Recursive before goto 7 True > Recursive end 7 True > Recursive before goto 8 True > Recursive end 8 True > Recursive before goto 9 True > Recursive end 9 True > Recursive before goto 10 True > Recursive end 10 True > Main end failed TEST t6334-2.pas: ./test_run: line 339: 27049 Killed ./"$A_OUT" "$1" TEST t6p6p3p4.pas: ./test_run: line 339: 7676 Killed ./"$A_OUT" "$1" # of tests 5070 # of expected passes 5044 # of unexpected failures 22 # of unsupported tests 4 Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

3 6

gcc-4.1.2
by Russ Whitaker 14 Feb '07

14 Feb '07

hi The gcc home page has announced gcc-4.1.2 is released. Should I try it with the existing gpc or wait for the next one? russ

1 0

GPC 20060325 @ gcc-4.1.1 build problems
by Mirsad Todorovac 13 Feb '07

13 Feb '07

I used the patch gcc-4.1-5.diff on gcc-4.1.1, and a simple gpc-build % ../gcc-4.1.1/configure --enable-languages=pascal gpc-build % make ... on Linux Debian sarge box. It breaks like this. Rerunning make gives this: mtodorov@domac:~/pascal/gpc20060325@gcc-4.1.1-build$ make make[1]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libiberty' make[3]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libiberty/testsuite' make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libiberty' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/fixincludes' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/intl' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/libiberty' make[3]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/libiberty/testsuite' make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/libiberty' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/fixincludes' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libcpp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libcpp' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/gcc' gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition-Wmissing-format-attribute -DHAVE_CONFIG_H -o xgpc p/gpc.o prefix.o version.o \ ../libcpp/libcpp.a ../libiberty/libiberty.a p/gpc.o(.text+0xab30): In function `main': ../../gcc-4.1.1/gcc/p/gpc.c:6941: undefined reference to `gcc_init_libintl' collect2: ld returned 1 exit status make[2]: *** [xgpc] Error 1 make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build' make: *** [all] Error 2 mtodorov@domac:~/pascal/gpc20060325@gcc-4.1.1-build$ Any advice? Thanks. Regards, Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

3 5