Gpc June 2007

gpc@gnu.de

15 participants
20 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

indirect jmp redux (Mac OS on Intel)
by Frederick Karl Kepner DuPuy 04 Sep '07

04 Sep '07

Hi. Regarding gpc for Mac OS X on Intel, I found a thread in the archives (see below) from October 2006 concerning an error message a user (Nestor Aguilera) got in compiling even the simplest programs. Unless I'm misreading the thread, no final conclusion was reached. Is anything further known now? Here's the thread: http://www.gnu-pascal.de/crystal/gpc/en/mail13854.html And the gist of the error messages: indirect jmp without `*' I'm having the same issue he had: programs which used to compile and execute happily with the gpc for PPC compiler are less happy with the gpc for Intel compiler--- they're still compiling, but issuing this error message repeatedly as they do so. I believe the output executes OK; but you can see why this is unsettling. So: is this a problem, or just an annoyance to be lived with? And is it happening to everybody trying to use gpc for Mac on Intel? (If so I'm curious as to why it hasn't been discussed since October.) (Please pardon my near-complete ignorance, by the way.) Thanks a lot, Rick DuPuy

3 5

attempted build with gcc-4.2.0
by Russ Whitaker 17 Jun '07

17 Jun '07

hi Applied Waldek's gcc patch for an older gcc. Got these rejects: dbxout.c.rej *************** *** 1916,1922 **** { stabstr_S ("@s"); stabstr_D (BITS_PER_UNIT * int_size_in_bytes (type)); - stabstr_S (";-20;"); } else { --- 1916,1922 ---- { stabstr_S ("@s"); stabstr_D (BITS_PER_UNIT * int_size_in_bytes (type)); + stabstr_S (";-20"); } else { gimplify.c.rej *************** *** 4948,4953 **** case POINTER_TYPE: case REFERENCE_TYPE: gimplify_type_sizes (TREE_TYPE (type), list_p); break; --- 4952,4959 ---- case POINTER_TYPE: case REFERENCE_TYPE: + break; + gimplify_type_sizes (TREE_TYPE (type), list_p); break; tree-flow-inline.h.rej *************** *** 1470,1476 **** return false; return (AGGREGATE_TYPE_P (TREE_TYPE (v)) && - TREE_CODE (TREE_TYPE (v)) != ARRAY_TYPE); } --- 1470,1477 ---- return false; return (AGGREGATE_TYPE_P (TREE_TYPE (v)) && + TREE_CODE (TREE_TYPE (v)) != ARRAY_TYPE + && TREE_CODE (TREE_TYPE (v)) != SET_TYPE); } varasm.c.rej *************** *** 2725,2731 **** VEC(constructor_elt, gc) *v; unsigned HOST_WIDE_INT idx; tree purpose, value; - v = VEC_alloc(constructor_elt, gc, VEC_length(constructor_elt, CONSTRUCTOR_ELTS (exp))); FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (exp), idx, purpose, value) --- 2725,2731 ---- VEC(constructor_elt, gc) *v; unsigned HOST_WIDE_INT idx; tree purpose, value; + v = VEC_alloc(constructor_elt, gc, VEC_length(constructor_elt, CONSTRUCTOR_ELTS (exp))); FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (exp), idx, purpose, value) *************** *** 3765,3771 **** /* Allow conversions to struct or union types if the value inside is okay. */ if (TREE_CODE (dest_type) == RECORD_TYPE - || TREE_CODE (dest_type) == UNION_TYPE) return initializer_constant_valid_p (src, endtype); } break; --- 3765,3776 ---- /* Allow conversions to struct or union types if the value inside is okay. */ if (TREE_CODE (dest_type) == RECORD_TYPE + || TREE_CODE (dest_type) == UNION_TYPE + #ifdef GPC + || TREE_CODE (TREE_TYPE (value)) == ARRAY_TYPE + #endif + ) + return initializer_constant_valid_p (src, endtype); } break; However, for that last one was able to find where the patch belongs, so here's a diff: 3843c3843,3847 < || TREE_CODE (dest_type) == UNION_TYPE) --- > || TREE_CODE (dest_type) == UNION_TYPE > #ifdef GPC > || TREE_CODE (TREE_TYPE (value)) == ARRAY_TYPE > #endif > ) 4017c4021 < --- > Wasn't sure how to correct the other rejects, so at least I got this far: *** glibc detected *** corrupted double-linked list: 0x08aa5f50 *** ../../gcc-4.2.0/gcc/tree-ssa-loop-ivopts.c In function 'find_optimal_iv_set': ../../gcc-4.2.0/gcc/tree-ssa-loop-ivopts.c: 5271 internal complier error: aborted Hope this helps Russ

1 0

Re: Bit packing
by Contestcen＠aol.com 15 Jun '07

15 Jun '07

In a message dated 6/14/2007 1:40:34 AM Eastern Standard Time, florian(a)freepascal.org writes: How does the pascal macro compiler solve it? It tries to solve it for bit/booleans arrays but not for subrange types which are much harder because of endian issues. Tries because it doesn't take care of things like debugging. (Continuing previous answer) If the problem is that some Pascal compilers store large integers with the least-significant byte first, while others store the most-significant byte first, one solution would be to form the concatenation of bit fields into a string of integers, and let each compiler store them according to its own rules. How complex the macros become depends on what is needed. Do the bit fields need to cross boundaries of integer fields? Are mixed-sized integers needed within each record? Are you carving up a large array into bit fields whose lengths will be determined at runtime? If the problem is that one compiler stores array elements in order x[1], x[2], x[3], ... which another compiler stores them x[100], x[99], ... then you simply let the compiler use its own array indexing scheme. Frank ************************************** See what's free at http://www.aol.com.

1 0

Re: Bit packing
by Contestcen＠aol.com 15 Jun '07

15 Jun '07

1 0

Bit packing
by Contestcen＠aol.com 14 Jun '07

14 Jun '07

On 13 jun 2007, at 07:26, Contestcen(a)aol.com wrote: > That's precisely the point. The Borland, TMT, FPC and GPC > compilers are not > compatible on bit-packing. By using the Macro Compiler you get bit- > packing > which is independent of the compiler, so that programs compiled > with any of > these Pascal compilers can exchange data. The bitpacking format is defined in the ABI of the respective platforms (at least all SYSV processor-specific supplements define how you should bitpack), and gcc follows that ABI. Some documentation: * http://www.sco.com/developers/devspecs/abi386-4.pdf : i386 sysv abi supplement, see p. 3-6 and following (look, SCO is still useful for something after all :) * http://refspecs.freestandards.org/elf/elfspec_ppc.pdf : ppc sysv abi supplement, see p. 3-8 and following Jonas Let me see if I follow this. You posted to this forum because you were having problems with bit-packing. You said that you wanted bit-packing that would allow data exchange between programs that were compiled with different compilers, and perhaps ran on different platforms. The Pascal Macro Compiler could make that possible. Now you say that there are standards for bit-packing, and that the GCC compiler follows the standards. Apparently the other Pascal compilers don't follow the standard. (So far as I know, the Borland and TMT compilers don't do bit-packing at all.) Also, the standard does not seem to work across multiple platforms because of different unit sizes. But you still won't use the Pascal Macro Compiler because it solves the bit-packing problem by a means other than enforcing the bit-packing standard on all Pascal compilers. Does that sum it up? Frank ************************************** See what's free at http://www.aol.com.

3 2

TR : GP Internal error
by Pascal Viandier 13 Jun '07

13 Jun '07

Sorry, the gp version I use is 0.61 not 0.60 - typo :-( - Pascal -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Pascal Viandier Envoyé : June 13, 2007 14:12 À : gpc(a)gnu.de Objet : GP Internal error In the course of the SUN Pascal to GNU Pascal conversion of a all set of programs, I use gp to handle the compilation of a program that has many - around 750 - modules. I call gp with the main program and correct errors progressively as they are encountered. I already compiled more than 600 modules this way. Until now all was going well but today I got an error message from gp when it calls "gpc --interface-only" for a module that has never been compiled yet: gp: internal error: complete cycle not found Since gp worked perfectly well for the previous modules, I suspect something wrong in this particular module but I don't see any error when looking at the Pascal code. What kind of twist in the source code can produce this error? I use gp 0.60 build with gpc 20051116 based on gcc-3.4.4 under SPARC Solaris 10 Kind regards. Pascal Viandier

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