November 2005 - 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

Building gpc-20051104 on i686-apple-darwin8
by Adriaan van Os 01 Mar '06

01 Mar '06

> [Darwin:gcc/p/test] adriaan% gpc -v > Reading specs from > /Developer/Pascal/gpc344x1/lib/gcc/i686-apple-darwin8/3.4.4/specs > Configured with: ../gcc-3.4.4/configure --enable-languages=c,pascal > --enable-threads=posix --target=i686-apple-darwin8 > --host=i686-apple-darwin8 --build=i686-apple-darwin8 > --prefix=/Developer/Pascal/gpc344x1 > Thread model: posix > gpc version 20051104, based on gcc-3.4.4 > > (more about the testsuite in the next message) Because of <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22099> I ran the testsuite with --no-pic, so I had to tell the darwin linker to shut up complaining about that. [Darwin:gcc/p/test] adriaan% make EXTRA_PFLAGS="--no-pic -Wl,-read_only_relocs,suppress" 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="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --no-pic -Wl,-read_only_relocs,suppress " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --no-pic -Wl,-read_only_relocs,suppress " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By adriaan on 2005-11-14 00:37:07 Native configuration is i686-apple-darwin8 (Darwin.local) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas ^[[FAIL: backtracerr.pas ^R FAIL: bo4-19.pas FAIL: bprealtest.pas FAIL: emptyrec.pas FAIL: fay.pas UNSUPPORTED: fjf165a.pas FAIL: fjf35.pas FAIL: fjf464c.pas FAIL: fjf464e.pas FAIL: fjf908.pas FAIL: fproc.pas UNSUPPORTED: gmptest.pas FAIL: gpcu_c_u.pas FAIL: knuth1.pas FAIL: nicola4d.pas FAIL: nlgpp.pas FAIL: nlgpp2.pas FAIL: robert1a.pas FAIL: robert1b.pas FAIL: systemtest.pas FAIL: t6334-2.pas FAIL: t6p6p3p4.pas FAIL: waldek1.pas === gpc Summary === # of tests 4965 # of expected passes 4939 # of unexpected failures 21 # of unsupported tests 5 gpc version 20051104, based on gcc-3.4.4 Innocent ------- * systemtest failure is caused by a Max OS X bug * bo4-19.pas fails because of the linker option passed to the testsuite gpc: -read_only_relocs: linker input file unused because linking not done gpc: suppress: linker input file unused because linking not done, * emptyrec.pas, same * gpcu_c_u.pas, same * waldek1.pas, same Serious ------ * bprealtest.pas, segmentation fault Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000041 Thread 0 Crashed: 0 dyld 0x8fe03d1b dyld::bindLazySymbol(mach_header const*, unsigned long*) + 119 1 dyld 0x8fe135cf stub_binding_helper_interface + 61 2 a.out 0x00001000 0x1000 + 0 3 a.out 0x000020c6 _p__M6_System_S63_Realtobpreal + 102 (system.pas:425) 4 a.out 0x0000305e _p__M0_main_program + 142 (bprealtest.pas:25) 5 a.out 0x000033ba main + 58 (<implicit code>:36) 6 a.out 0x00001cfe _start + 228 (crt.c:272) 7 a.out 0x00001c19 start + 41 ? maybe floating point exception * fay.pas, bus error Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0xbffff6d0 Thread 0 Crashed: 0 <<00000000>> 0xbffff6d0 0 + -1073744176 1 a.out 0x00002da8 Q.5 + 168 (fay.pas:92) 2 a.out 0x00002dbd _p__M0_S6_Outer + 13 (fay.pas:90) 3 a.out 0x00002e2a main + 58 (<implicit code>:134) 4 a.out 0x0000211e _start + 228 (crt.c:272) 5 a.out 0x00002039 start + 41 ? procedural parameter and local procedure problems (? trampolines ?) the following test failures look the same: * backtraceerr.pas * fjf35.pas * fjf464c.pas * fjf464e.pas * fproc.pas, same * knuth1.pas, same * nicola4d.pas, same * nlgpp.pas * nlgpp2.pas * t6334-2.pas * t6p6p3p4.pas * fjf908.pas failed 89 1.000000000000000e+00 2.500000000000000e-01 * robert1a.pas x ** y = NaN trunc( x ** y) = 0 * robert1b.pas 10.0 ** y = NaN trunc( 10.0 ** y) = 0 Anything I can do to investigate this further and report it to gcc bugzilla ? Regards, Adriaan van Os

5 17

Re: GPC on i686-apple-darwin
by Waldek Hebisch 19 Jan '06

19 Jan '06

Adriaan van Os wrote: > You were quite right about -fPIC. All the failures, except emil9.pas > disappear with -fno-pic. However, many of the other tests fail with > -fno-pic, because the option disables dynamic linking on Mac OS X. The > PPC back-end has a workaround (-mdynamic-no-pic) but that doesn't seem > to work for i686-apple-darwin. > I have just realized that Darwin PIC problem have nothing to do with Linux PIC problems: Darwin does not use the binutils feature (ELF GOT relocations) that Linux uses. > Updating the linker and assembler to odcctools-20050327 had no effect > on testsuite results. > > So, I must either > - find a backport of i686-apple-darwin PIC fixes > - find a solution for gcc-3.4 bootstrap problems > - wait for gcc-4.0 support. > > Still, I am glad with the results so far. > Well, I was able build 3.3.6 based cross-compiler for i686-apple-darwin target, and I can see duplicate labels in the assembler output. It seems that 3.4.3 has changed the parts responsible for generating those labels. I have found that 3.4.[34] contain blatant bug with easy fix: --- gcc-3.4.4/gcc/config/i386/darwin.h.orig Thu Jun 16 01:10:29 2005 +++ gcc-3.4.4/gcc/config/i386/darwin.h Thu Jun 16 01:10:32 2005 @@ -43,7 +43,7 @@ /* Use the following macro for any Darwin/x86-specific command-line option translation. */ -#define SUBTARGET_OPTION_TRANSLATE_TABLE +#define SUBTARGET_OPTION_TRANSLATE_TABLE { 0, 0 } #define ASM_SPEC "-arch i386 \ %{Zforce_cpusubtype_ALL:-force_cpusubtype_ALL} \ After that I can build the compiler proper. However I get ICE when building gcc runtime. Trying gpc on knuth3.pas (to get assembler output) give me ICE. Both ICE-s seem related to generting labels needed in PIC code... So, it seems that nobody tried gcc-3.4.x for i686-darwin for almost a year (ChangeLog entry for SUBTARGET_OPTION_TRANSLATE_TABLE change is from 2004-08-23) -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 9

Success!
by Peter N Lewis 11 Jan '06

11 Jan '06

Thanks to all the help from Frank, Waldek, Adriaan, Gale and others, I now have all of Interarchy compiling and running under GPC. 270 files, 160,000 lines of code, 290 Mac Style object types, all compiling and working. There are probably a few glitches left here or there, but I've tested out the bulk of the program and nothing remains broken (that was not before - it is bug for bug compatible ;-). Thanks all! Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

6 5

Building gpc-20051104 on i686-apple-darwin8
by Adriaan van Os 17 Dec '05

17 Dec '05

For those intererested, here is some information on building gpc-20051104 with gcc-3.4.4 on i686-apple-darwin8. We need to build and install the right versions of sed, help2man, flex and bison first, but this has been discussed before (<http://www.gnu-pascal.de/crystal/gpc/en/thread11480.html>). Note that bison 2.1 is now needed (<http://ftp.gnu.org/gnu/bison/>). Then, we need patches to gcc-3.4.4. 1. To build gcc-3.4.4 on Darwin-8 (Mac OS X 10.4) we need the following "Tiger" patch (see <http://www.gnu-pascal.de/crystal/gpc/en/mail12302.html>) as Apple changed the rules once again: --- gcc/config/darwin.h.orig 2005-05-18 13:56:37.000000000 -0400 +++ gcc/config/darwin.h 2005-05-18 13:57:48.000000000 -0400 @@ -275,7 +275,8 @@ /* Machine dependent libraries. */ #undef LIB_SPEC -#define LIB_SPEC "%{!static:-lSystem}" +#define LIB_SPEC "%{!static:-lSystemStubs -lSystem}" + /* We specify crt0.o as -lcrt0.o so that ld will search the library path. */ 2. Then, we need to fix a bug in i386/darwin.h (see <http://www.gnu-pascal.de/crystal/gpc/en/mail12211.html>). --- gcc/config/i386/darwin.h.orig Thu Jun 16 01:10:29 2005 +++ gcc/config/i386/darwin.h Thu Jun 16 01:10:32 2005 @@ -43,7 +43,7 @@ /* Use the following macro for any Darwin/x86-specific command-line option translation. */ -#define SUBTARGET_OPTION_TRANSLATE_TABLE +#define SUBTARGET_OPTION_TRANSLATE_TABLE { 0, 0 } #define ASM_SPEC "-arch i386 \ %{Zforce_cpusubtype_ALL:-force_cpusubtype_ALL} \ 3. Third, we have to fix a problem in config/darwin-crt2 with a system routine that is no longer present on i686-apple-darwin8 (see <http://www.opensource.apple.com/darwinsource/WWDC2004/keymgr-9/ keymgr.c>). --- gcc/config/darwin-crt2.orig.c 2005-11-11 00:31:10.000000000 +0100 +++ gcc/config/darwin-crt2.c 2005-11-11 17:34:48.000000000 +0100 @@ -47,7 +47,14 @@ extern void __darwin_gcc3_preregister_frame_info (void); /* These are from "keymgr.h". */ + +/* _init_keymgr is no longer needed and it breaks the build on i686-apple-darwin8, + see <http://www.opensource.apple.com/darwinsource/WWDC2004/keymgr-9/ keymgr.c> */ +#ifdef __PPC__ extern void _init_keymgr (void); +#endif + + extern void *_keymgr_get_and_lock_processwide_ptr (unsigned key); extern void _keymgr_set_and_unlock_processwide_ptr (unsigned key, void *ptr); @@ -137,7 +144,9 @@ __darwin_gcc3_preregister_frame_info (void) { const _Tinfo_Node *info; +#ifdef __PPC__ _init_keymgr (); +#endif info = (_Tinfo_Node *)__keymgr_global[2]; if (info != NULL) { 4. Finally, there is gcc bug PR16649 (<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16649>), one of the many bugs that never get fixed by the back-end guys, because of the ingenious excuses they have found for not fixing bugs: 1. it is not a bug but a "regression" 2. it is a "regression" but not a "serious regression" 3. it is a "serious regression" but not a "serious regression for a secondary target" 4. it is a "serious regression" but not a "serious regression for a primary target" 5. it is a "serious regression" but not "release critical" 6. it was never assigned to anybody 7. it was never targeted for a specific release 8. it was targeted for a specific release, but then retargeted by the "release manager" 9. we don't know how to fix it 10. we are not longer working on it 11. or (more honest) we are really not in the mood to fix it, adding another nonsensical optimizer phase is more sexy. but here is the patch (see <http://www.gnu-pascal.de/crystal/gpc/en/mail12213.html>) --- gcc/config/i386/i386.c.orig Wed Mar 16 16:23:40 2005 +++ gcc/config/i386/i386.c Thu Jun 16 13:33:02 2005 @@ -5810,6 +5810,28 @@ return term; } + +/* Allow {LABEL | SYMBOL}_REF - SYMBOL_REF-FOR-PICBASE for Mach-O as + this is used for to form addresses to local data when -fPIC is in + use. */ + +static bool +darwin_local_data_pic (rtx disp) +{ + if (GET_CODE (disp) == MINUS) + { + if (GET_CODE (XEXP (disp, 0)) == LABEL_REF + || GET_CODE (XEXP (disp, 0)) == SYMBOL_REF) + if (GET_CODE (XEXP (disp, 1)) == SYMBOL_REF) + { + const char *sym_name = XSTR (XEXP (disp, 1), 0); + if (! strcmp (sym_name, "<pic base>")) + return true; + } + } + + return false; +} /* Determine if a given RTX is a valid constant. We already know this satisfies CONSTANT_P. */ @@ -5829,6 +5851,9 @@ x = XEXP (x, 0); } + if (TARGET_MACHO && darwin_local_data_pic (x)) + return true; + /* Only some unspecs are valid as "constants". */ if (GET_CODE (x) == UNSPEC) switch (XINT (x, 1)) @@ -5980,18 +6005,8 @@ saw_plus = true; } - /* Allow {LABEL | SYMBOL}_REF - SYMBOL_REF-FOR-PICBASE for Mach-O. */ - if (TARGET_MACHO && GET_CODE (disp) == MINUS) - { - if (GET_CODE (XEXP (disp, 0)) == LABEL_REF - || GET_CODE (XEXP (disp, 0)) == SYMBOL_REF) - if (GET_CODE (XEXP (disp, 1)) == SYMBOL_REF) - { - const char *sym_name = XSTR (XEXP (disp, 1), 0); - if (! strcmp (sym_name, "<pic base>")) - return 1; - } - } + if (TARGET_MACHO && darwin_local_data_pic (disp)) + return 1; if (GET_CODE (disp) != UNSPEC) return 0; 5. Create a build directory, cd into it and configure with something like: [Darwin:gpc-20051104/gpc344x1/build] adriaan% ../gcc-3.4.4/configure --enable-languages=c,pascal --enable-threads=posix --target=i686-apple-darwin8 --host=i686-apple-darwin8 --build=i686-apple-darwin8 --prefix=/Developer/Pascal/gpc344x1 6. Now, we can simply do a make with the system compiler that comes with Xcode 2.2 (gcc version 4.0.1 (Apple Computer, Inc. build 5247)) and a bootstrap is not needed. [Darwin:gpc-20051104/gpc344x1/build] adriaan% make 7.Installation [Darwin:gpc-20051104/gpc344x1/build] adriaan% sudo make install 8. And here we have the new compiler ! [Darwin:gcc/p/test] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc344x1/lib/gcc/i686-apple-darwin8/3.4.4/specs Configured with: ../gcc-3.4.4/configure --enable-languages=c,pascal --enable-threads=posix --target=i686-apple-darwin8 --host=i686-apple-darwin8 --build=i686-apple-darwin8 --prefix=/Developer/Pascal/gpc344x1 Thread model: posix gpc version 20051104, based on gcc-3.4.4 (more about the testsuite in the next message) Regards, Adriaan van Os

1 1

New (20051116) snapshot
by Waldek Hebisch 16 Dec '05

16 Dec '05

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2 This snapshot has integrated preprocessor. This should solve problems with (lack of) predefined symbols when using 3.3.x and 3.4.x backends. The preprocessor is just integrated -- inside it is the same preprocessor as before. There is new `--preprocessed' option, but the change is intended to be as compatible as possible. Still, the code to handle command line changed, so there may be some unintended change. Also, there is no gpcpp executable anymore (use gpc -E as preprocessor). There are also minor fixes, see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20051116 and http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20051116 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

10 34

gp vs --automake
by Pascal Viandier 01 Dec '05

01 Dec '05

Hi all, I try to use gp to build my programs and have trouble with Pascal sources using c parts. When invoked by gp, gpc stops where I put {$L source.c} saying "error: file 'source.c' must be compiled. I remarked that gpc is called with --no-automake in its options list, even if I put --automake on gp command-line. This prevents the compilation of the c sources prior the Pascal module. My question is: Is the --no-automake passed to gpc causing the problem or is it because gp should compile the c sources before the Pascal module? I applied all the recent patches to gp but with no success on this particular problem. Also, I solved the problem of link with external libraries with gp by processing the dependencies list before the command-line options in routine StartPipe(). This works well. If you are interested by the modification I can send it. Although I don't know which tool you use to make your diffs, I an ready to learn it. Let me know. Regards Pascal Viandier pascal(a)accovia.com

3 6

Compiling with gp
by Pascal Viandier 29 Nov '05

29 Nov '05

Hello, The gp fix solved the false cyclic dependencies problem. The compilation runs smooth now. Thanks! However, I probably missed something because gp does not succeed to make the programs completely for two main reasons. First: There are some objects from c sources not found at link time. I put {$L my_c_extern.c} in a Pascal source but gp says "my_c_extern.c must be compiled" and stops instead of compiling it (I think since is knows that the source must be compiled, it should do it, no?). Then I tried {$L my_c_extern.o} instead and gp says " My_c_extern.c:999: undefined reference to 'symbol' where 'symbol' is defined in a third party library for which I put a -l directive on gp command-line. Second: The link command. I put gp in verbose mode and made a copy of the link command which fails to find out what is going wrong. I see that the list of my external (third party) libraries comes before any object in the link command. (-llib1 -llib2...) By putting this list of libraries at the end of the link command, it worked. But since I have no control on this at the gp command-line level I cannot make it work. Also, I noticed that objects are written in the same directory as gpi files despite the option --object-destination-path=obj on the gp command-line. Am I trying to make gp do things it was never designed for? Hope this is clearly explained. I use gp with Debian Linux on x86 if this detail matters. Thanks Pascal Viandier pascal(a)accovia.com -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Pascal Viandier Envoyé : November 11, 2005 15:36 À : gpc(a)gnu.de Objet : TR : RE : RE : compiling with gp (was Sorry I made a typo in the description of the dependencires: The third line of the schema should be: . Module C implementation section imports Module A and Module B (not Module C) Pascal Viandier pascal(a)accovia.com -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Pascal Viandier Envoyé : November 11, 2005 15:21 À : gpc(a)gnu.de Objet : RE : RE : compiling with gp (was Hi, The schema of the cyclic dependencies I face is: . Module A implementation section imports Module B . Module B implementation section imports Module A and Module C . Module C implementation section imports Module A and Module C Please note the dependencies are in the implementation sections, not in the interfaces. Although for each module the interface section is in a separate file included in the appropriate implementation file (i.e. A.pas includes A.h but no other file), I think this is not the cause of the problem. With this, gp says: cyclic interface dependency A.pas -> B.pas -> C.pas and it stops. Hope this schema will help clarify the situation. Regards Pascal pascal(a)accovia.com > -----Message d'origine----- > De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Frank > Heckenbach > Envoyé : November 11, 2005 09:03 > À : gpc(a)gnu.de > Objet : Re: RE : compiling with gp (was > > Pascal Viandier wrote: > > > Just my two cents: > > Like Mr Van Os, I have myself the problem of cyclic dependencies in many > > programs I ported from SUN Pascal to GNU Pascal. There are hundreds of > > separate modules with cyclic dependencies up to 8th level. > > To avoid misunderstandings: GP generally should be able to handle > cyclic dependencies. I've used it compile a project with ~200 units, > all interdependent (not written by me, obviously :-). > > So we don't need to discuss whether to do that. > > > For now, I use make to build the programs because of these dependencies. > I > > have to call it two times to build the interfaces, because there are > also > > cyclic dependencies in some interface sections that import others. > > Cyclic dependencies within interfaces are forbidden, both in Borland > and Extended Pascal. (I.e., interface A uses interface B, and > interface B uses interface A.) GP will also reject this, and there's > really no sane way to do this, as you could easily construct > circular definitions and contradictions this way. > > What you can do is: Interface A uses interface B, and implementation > B uses interface A. Then GP should, in this order, compile interface > B, all of A, implementation B. > > If that's what you need, then GP should work for you. There may be > abug, perhaps the same one Adriaan found, and then, of course, I'd > like to fix it, when I know what it is ... > > > Although I am not sure if I can completely build the programs with it > since > > they link with many third party libraries and I have not found the way > to do > > it in the gp documentation yet. > > Libraries are easy. There are two ways, both work the same with GP > as with automake, and the second one also with manual make: > > - Put {$L} directives in the source (see e.g., the GMP and RegEx > units that come with GPC). > > - Add -l options on the command line. > > > > >> I am now implementing for gp: > > > >> > > > >> --compile-file Compile a file as fast as possible. > > > >> Imported > > > >> units that need recompilation are > > > >> compiled > > > >> --interface-only, which implies > that > > > >> successive linking will fail. > > > >> Therefore, > > > >> this option is useful during the > > > >> development phase only. > > > >> This option implies -c > > > >> --check-file Check the syntax of a file as fast > as > > > >> possible. Imported units that need > > > >> recompilation are compiled > > > >> --interface-only. > > > >> This option implies -c > > > >> > > > >> It mostly works already (I will post a diff later). The time gain > is > > > >> dramatic. > > > > > > > > IIUC, this is only necessary because of the bug you suppose in your > > > > previous mail (otherwise no other units would have to be recompiled > > > > if not changed)? So it might be a better use of time to concentrate > > > > on the acutal bug than on temporary work-arounds. > > > > > > No, I consider this a valuable feature, although the impact may in > > > general not be so dramatic as in my current project, porting an > > > application to GPC with many cyclic dependencies (which I didn't write > > > myself). > > Perhaps I don't yet quite understand it. Provided GP makes no > mistakes and imports are not recompiled unless necessary. So I > suppose you mean the situation that you changed the implementation > of an imported unit? But you don't want to compile (and therefore > check for syntax errors) this other unit? > > > > I will try to be useful and fix gp myself. Compile times are also > > > spoiled by the quadratic operator search > > > (<http://www.gnu-pascal.de/crystal/gpc/en/mail10055.html>) and that is > > > something I cannot fix easily myself (at some points in the > compilation > > > I see the IDE's progress bar and line counter move line by line, often > > > lines with calculations). > > I see. BTW, Waldek are you interested in the general solution of > this issue (including overloaded routines)? I'm not too much ATM > (there are many more urgent issues). If you aren't either, perhaps I > could at least try some quick fix to ease this problem somewhat. -- > Still using name-based search, with all its disadvantages, but > perhaps storing a list of actually defined operators in the > OPERATOR_DECL (this will also be a preparation for the real > solution), and then for each operator retrieve the type names and > compare them -- I suppose if we get rid of the ACONCAT and > get_identifier in the loop this way, this might make things much > faster. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html > GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 > E5E8

3 4

struct memory allocation problem
by vanam srihari kumar 29 Nov '05

29 Nov '05

Dear All Thanks for your cooperation. Again I am clearly explaining what my problem is. I have records like below PASTimeTag = RECORD high : INTEGER; low : INTEGER; END; meaobj_record = RECORD next : meaobj_pointer; prev : meaobj_pointer; status : INTEGER; timetag : PASTimeTag; value : REAL; END; meaobj_pointer = ^meaobj_record; If I print the size of the records using sizeof functions I am getting below results. sizeof(PASTimeTag) = 8 bytes (*which is correct bcoz INTEGER occupies 4 bytes ) sizeof(meaobj_record) = 32 bytes (*Actually it should be 28 bytes(meaobj_pointer=4+meaobj_pointer=4+ INTEGER=4+PASTimeTag=8+REAL=8)but it is allocating 32 bytes which is multiple of 8 near to 28*) If I am trying to access real field in the record from the pascal program it is giving 'signal SIGSEGV, Segmentation fault' but it is not happening all the times.In the debug mode I could access all the fields except real variable during the crash. This is the major problem preventing me to go further since several days. Please suggest me some solution. Regards Hari __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs

3 2

Math functions and Floating point types
by lanceboyle＠bluebottle.com 29 Nov '05

29 Nov '05

I tried posting this to the Mac Pascal (Pascal Central) list but for some reason it is not making it. =============================== I might be confused about how to import math functions in GPC. GPC itself doesn't seem to have the functions that I need (I'm looking in gpc.pas), but in the docs there is a mention of math.pas. However, I can't find such a file in my GPC installation. Do I need to use (non-portable) Mac math libraries? If so, is fp.p still the preferred interface? In the case of more common functions such as trig stuff, does fp.p override the Pascal built-ins? Or conflict with them? I believe that pow() is a problem with respect to conflicts and I see that some headers seem to note this in a compiler directive. Also, I see that floating point types Double and Real are the same and eight bytes, while Extended and LongReal are 16 bytes--is that correct? To make old code work that assumed that Extended is eight bytes, can I write type Extended = Real without my computer exploding? FWIW, I'm porting my own set of tools which needs the math functions and which was originally made on THINK Pascal, then ported to Metrowerks, and now to GPC. Thanks for any help. Jerry

5 8