March 2008 - Gpc

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

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

Building latest gpc on Intel OS X 10.5.2
by Peter Schorn 28 Apr '08

28 Apr '08

I'm trying to build the latest gpc (gpc-20070904.tar.bz2) with Adriaan's patches on a Macintosh OS X 10.5.2. with Intel. I configure with ../gcc-4.1.2/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc412 but the "make bootstrap" fails with Undefined symbols: "___sysctl", referenced from: ___enable_execute_stack in _enable_execute_stack_s.o ld: symbol(s) not found /usr/bin/libtool: internal link edit command failed make[3]: *** [libgcc_s.dylib] Error 1 make[2]: *** [libgcc.a] Error 2 make[1]: *** [stage1_build] Error 2 make: *** [bootstrap] Error 2 What am I missing? Peter --- peter.schorn(a)acm.org

4 19

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

Re: gpc and gcc-4.1.2
by Waldek Hebisch 16 Mar '08

16 Mar '08

Martin Marques wrote: > > Yes. Unpack gpc sources, make sure that p subdirectory from gpc > > source tree appears as gcc-4.1.2/gcc/p is gcc source tree (either > > use move or a symlink), configure and make. > > Didn't work. :-( > > make[2]: se ingresa al directorio > `/usr/src/redhat/BUILD/gcc-4.1.2-20070925/host-x86_64-unknown-linux-gnu/gcc' > gcc -c -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 -I. > -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include > -I../.././gcc/../libcpp/include ../.././gcc/dbxout.c -o dbxout.o > ../.././gcc/dbxout.c: In function ?dbxout_type?: > ../.././gcc/dbxout.c:1978: error: ?have_used_extensions? no se declaró > aquí (primer uso en esta función) > ../.././gcc/dbxout.c:1978: error: (Cada identificador no declarado > solamente se reporta una vez > ../.././gcc/dbxout.c:1978: error: ara cada funcion en la que aparece.) > make[2]: *** [dbxout.o] Error 1 > make[2]: se sale del directorio > `/usr/src/redhat/BUILD/gcc-4.1.2-20070925/host-x86_64-unknown-linux-gnu/gcc' > make[1]: *** [all-gcc] Error 2 > make[1]: se sale del directorio `/usr/src/redhat/BUILD/gcc-4.1.2-20070925' > make: *** [all] Error 2 > > Any ideas? > Do you really use use gcc-4.1.2? The name gcc-4.1.2-20070925 indicates that you have different version. IIRC the patch /usr/src/redhat/BUILD/ is was used for Redhat modified sources, which are usually different than official version. I would suggest to try to use unmodified gcc-4.1.2. If for some reason you need to use RedHat/Fedora specific version, please make sure first that you can compile gcc alone -- without gpc. Concerning the error message: it tells you that the identifier 'have_used_extensions' is undefined. AFAICS this identifier does not apper in gcc-4.1.2 (change log claims that it was removed in 2005). Gpc patches some gcc files, but the patch also does not contain it. So I think that you get message about 'have_used_extensions' because your 'gcc-4.1.2-20070925' is a modified version and that the modification contains error. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 4

gpc and gcc-4.1.2
by Martin Marques 13 Mar '08

13 Mar '08

I'm trying to compile gpc on a Fedora 8 system, and I can' find instructions on how to compile it with newer versions of gcc. Should I just get the latest gpc sources and try to compile with newer gcc-4.1.2 sources?

3 4

[Fwd: GCC 4.3.0 Released]
by Adriaan van Os 10 Mar '08

10 Mar '08

-------- Original Message -------- Subject: GCC 4.3.0 Released Date: Mon, 10 Mar 2008 06:21:34 -0400 From: Jakub Jelinek <jakub(a)redhat.com> Reply-To: Jakub Jelinek <jakub(a)redhat.com> To: gcc-announce(a)gcc.gnu.org GCC 4.3.0 has been released. GCC 4.3.0 is a major release, containing substantial new functionality not available in GCC 4.2.x or previous GCC releases. See: http://gcc.gnu.org/gcc-4.3/changes.html for more information about changes in GCC 4.3.0. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-4.3.0/ subdirectory. There is one important caveat. It was discovered after the final release has been made that some OS kernels on i?86 and x86_64 architectures violate the processor specific ABI with regards to the DF flag, if a process is interrupted with a signal while doing overlapping memmove or running some other code with DF flag set, the signal handler might be started with DF flag set on entry to the signal handler. GCC 4.3.0 no longer emits cld instructions unnecessarily, so GCC 4.3.0 compiled async signal handlers or functions the signal handlers call that rely on DF flag being cleared might misbehave. This will be hopefully fixed in the kernels soon and future GCC releases might provide an optional workaround for this bug. Fixes for some systems: Linux http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi… FreeBSD http://www.freebsd.org/cgi/query-pr.cgi?pr=121422 Hurd http://sources.redhat.com/ml/libc-alpha/2008-03/msg00020.html If you encounter difficulties using GCC 4.3, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. As always, a vast number of people contributed to this GCC releases -- far too many to thank individually!

1 0