- Gpc - gnu.de

CInteger and --delphi
by Adam Naumowicz 21 Dec '04

21 Dec '04

Hello, I've tried to compile the following code with --delphi option toggled on, but the compiler reported tester.pas:17: error: reference expected, value given program tester; uses gpc; procedure CatchSignal(aSig : Integer); begin case aSig of 2, 3, 15 : {SigInt, SigQuit, SigTerm} begin end; end; end; var OldSigInt : TSignalHandler; r,dummy:boolean; begin r:=InstallSignalHandler(SigInt,CatchSignal,true,false,OldSigInt,dummy); end. Then I checked the … [View More]

4 5

Re: GCC integration?
by Frank Heckenbach 19 Dec '04

19 Dec '04

Steven Bosscher <stevenb(a)suse.de> wrote in private mail: > Since I'm not allowed to post to the gpc list, I'll just mail you > in private. Feel free to forward this. These are just my personal > ideas on the matter, so don't attach to much value to them ;-) Thanks, I'm forwarding it with my reply. (Only subscribed members are allowed to post, unfortunately, but it's necessary for spam protection.) > You wrote: > > If you ask me when this will be, I don't know. And … [View More]I should point > > out that I'm a supporter of "release when it's ready", instead of > > setting fixed release dates. > > So does GCC. All the release managers of old release branches do is > set target dates. More often than not, the release is not ready by > then and so it is postponed. > > > > The latter IMHO smells too much like > > certain proprietary companies, > > Oh, no, not proprietary! :-) > > To me it just sounds like decent engineering practice to set targets > and deadlines. Otherwise there would *never* be a stable GCC. Even > now, when GCC is in stage3, the number of files changed from day to > day is simply frightening. At some point you have to say, stop, let > us first fix bugs and get this out of the door, *then* we can start > hacking like mad on our toy projects again. > > > > and usually leads to the same results > > -- such as last year when a fatal bug which was clearly identified > > (and a fix provided) was intentionally left unfixed in a GCC release > > (3.2.2 AFAIR) because of the fixed release schedule. > > I don't recall such a bug. It very much does *not* sound like GCC > practice to release a compiler with a known show-stopper bug. I was also very surprised to see such behaviour in such a high-profile free software project, but that's what happened. If you want to read it yourself: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9279 In short, I discovered a bug on sparc-linux (later it was found that it also affected other platforms). I noticed it in the form of GPC misbehaving. It took me several hours to track it down through a C library function (fwrite) via some complex macros in the libc headers to a GCC code generation bug which I could demonstrate in a short, reproducible example. Someone provided a fix, but this fix was intentionally rejected because of the fixed release deadline. (The actual bug was in the backend, and it showed in the C compiler when compiling GPC; no GPC issues involved in the actual bug, just to avoid misunderstandings.) In my view, the following comment (http://gcc.gnu.org/ml/gcc-bugs/2003-01/msg01529.html) says it all (emphasis added by me): : > The fix introduces a performance regression for PowerPC (and possibly ^^^^^^^^^^^^^^^^^^^^^^ : > other platforms) on the 3.2 branch. : : Now reverted for this reason on the 3.2 branch so GCC 3.2.2 will ship with ^^^^^^^^^^^^^^^^^^^^^^^^ : the bug. A performance regression more important than a fatal bug, hear hear! Gabriel Dos Reis later added that the patch might cause "possibly a wrong code generation" which Eric Botcazou questioned. I don't know if it did, but even if so, that's no excuse for shipping a fatal bug. I don't know if that other wrong code generation (if it existed) was also fatal -- if not, I'd rather accept that than a known fatal bug; if so, the only reasonable thing to do IMHO would have been to delay the release until the fatal bugs are fixed. But as the following quote says: : I would like to avoid last time minute patch chasing. So clearly release dates are more important than correctness. (Otherwise there would be no required "last minute", obviously.) BTW, of course, one can always argue which bugs are fatal. But since this bug (a) affects fwrite(), a standard and very common I/O function, and (b) produces silently wrong results, the worst possible failure mode, I fail to see how it could not be considered fatal. (Only a security bug would be worse, and I'm not even sure one couldn't construct one with this bug -- I/O routines give plenty of opportunities.) > > So that's one > > reason why I have some aversions against integration, if those > > schedules will also dictate our releases. > > They would, gpc would stop existing as a separate compiler as far as > GCC is concerned, so it would be released along with the rest of GCC. > Having said that, you'd have the advantages of "being part of GCC" > such as having your compiler modified when something changes in GCC > that requires front end modifications. A reduced maintenance burden, > so to speak (that sounds proprietary too I guess, but that's life). No, I do see this as an advantage. I'm just weighing it against the disadvantages that I also see ... > If you are so opposed to integration, you should say that on gcc@ and > explain your problems. Making such statements in a list that almost > nobody in the "mainstream" gcc community reads is not going to help > anyone. > > I know I'd like to see gpc be integrated in GCC, but only as "just a > new front end". From my perspective, it's strange that you want to > do releases on your own schedule. Why not spend time on making gpc > better, and let others worry about getting it out? I think GCC as a > project has a pretty decent track record for getting things released > with a high quality. To add some background, I'm not only working on GPC just for fun. I'm also using it for professional work, and as such I'm dependent on having usable versions available. (And by that, I currently mean the betas I release -- my own development code is most of the time not suitable to be used out in the wild.) Another point to note is that in GPC much work is done in visible front-end changes (new syntax etc.), probably more than in many other frontends. And I usually want to use the new features in my own code (otherwise I wouldn't have to spend my time implementing them). So using older releases of GPC is usually not an option for me, unlike say for the C compiler (where, for my purposes, I hardly notice a difference WRT features even between 2.x and 3.x). So let's consider a situation such as after the release of gcc-3.2.2. Let's assume there were some new frontend features I wanted to use. (I could look up which ones exactly those might have been at that time, but it's a safe bet there were some.) So, what should I have done, if GPC would have been integrated and the current GPC release at the time were tied to gcc-3.2.2: - Rewrite my code to avoid all new features (and later rewrite it back) -- inacceptable (too much work) - Let the customer wait for months for the next release which *hopefully* will fix the bug -- obviously inacceptable - Tell them to get another machine or OS if the bug is platform dependent such as here -- usually not an option - Tell them to get a CVS snapshot -- bad idea: unusual for most people and probably difficult to build for them, conveying strange ideas about free software etc.; it's a game of luck (as you write below, it's likely that the backend would not be as stable), and a support nightmare (if something goes wrong, and I have a slightly different version) - Take a CVS snapshot of my own, make sure it's stable (which in this case might mean, take the release and add this particular bugfix) and release that on my own. So, AFAICS, I'm bound to the last option, and I'm seriously considering it for the time after an eventual integration. (E.g., by keeping the current website, and placing releases there according to my own schedule and preferences.) If we're lucky, all official GCC releases will be stable and there will be no need for anything else, but I don't think I'd like to take the risk. > > (BTW, would this be so, or > > could we also make releases independent of GCC schedules, e.g. when > > we think it's stable rather than on a fixed date?) > > You could do that but probably the backend you'd make your release > against would not yet be stable. You could do it for release branches > of course. But as I said, I don't understand why you'd want that. See above. Of course, the GPC frontend changes will probably slow done sometime when all important features have been added (or so ;-), and then the version dependencies will not be as severe anymore. But this will probably be many years from now, much later than even my ideas of integration ... > > Automake: To be replaced by gp. (gp: Mostly working, some smaller > > known problems, some less-important to-dos.) Again, I'd like to > > keep automake present, but deprecated in one more major release > > for the same reasons as above. > > If you'd integrate with GCC, you would not need automake for the front > end sec, but for the runtime libraries, all GCC libraries use automake. > Not everyone is happy with that (automake and libtool are brain damage > in the view of many, including yours truly) but then, the alternatives > for keeping the build system portable are not very attractive either. Misunderstanding. GPC currently has a mechanism also called "automake". This is a kludge (and has always been) which, in various ways, conflicts with GCC's usual behaviour. It will be removed and replaced by a utility called "gp" (of which the first betas have been released, and it's almost ready to take over). As for automake and libtool, and partly also autoconf, I might subscribe to the view you stated. But I'm not too concerned about it. The RTS currently relies on autoconf-2.12. Someday it will have to be adjusted to a newer version, or something different, and probably libtool has to be added (if it must ;-). But these things are rather peripheral to most of our code (e.g., the RTS only contains one C file anymore which uses the autoconf macros; everything else is written in Pascal and doesn't use them directly). So while I expect some nuisances with those tools in the future, I don't expect serious problems here. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) [View Less]

2 1

Re: Re: GCC integration?
by Thorsten Glaser 19 Dec '04

19 Dec '04

Matt Austern dixit: > I suppose it's time to ask: *should* Pascal integration be a goal for 4.1? What about the goal being: Pascal should at least compile and work for simple programmes for 4.1 and be "delivered with", but not built by default, and full integration being the goal for 4.2 (if it's made in time for 4.1, even better)? In my experience, lower goals tend to be more easily achieved. I'll shut up from now and leave it to the GPC maintainers to express what they want (I think … [View More]

2 1

gpc and gcc-3.3.5
by Prof A Olowofoyeku (The African Chief) 18 Dec '04

18 Dec '04

Hi I have built gpc-20041017 based on gcc-3.3.5 (for Mingw). It seems to be alright. It passes the testsuite, except for these: "TEST piextn.pas: OK TEST pipetes2.pas: ../units/pipesc.c: In function `_p_CPipe': ../units/pipesc.c:151: warning: passing arg 3 of `spawnve' from incompatible pointer type ../units/pipesc.c:151: warning: passing arg 4 of `spawnve' from incompatible pointer type ../units/pipesc.c: In function `pexecute': ../units/pipesc.c:471: warning: passing arg 3 of pointer to … [View More]

2 4

Re: Re: GCC integration?
by E. Weddington 17 Dec '04

17 Dec '04

Steven Bosscher wrote: >On Friday 17 December 2004 20:31, Nathanael Nerode wrote: > > >>* Pascal integration as a release goal for GCC 4.1 >> >> > >You forget that it is not clear if the gpc people actually >want this. I don't see the GNU Pascal maintainers in this >discussion. > > > Since I started this whole thread off in the GPC list... What I don't fully understand is (and anybody correct me if I'm wrong): 1. From what I can tell, … [View More]

1 0

GPC: Is it currently being developed
by Jon Foster 17 Dec '04

17 Dec '04

Hi guys! I recently became aware of your project. Is GPC currently being developed? The last "stable" release was two years ago. Are Delphi classes and exceptions going to become a reality anytime soon? I wouldn't mind working with some pre-stable code if they are. If they aren't what are the GPC alternatives? THX - Jon -- Jon Foster JF Possibilites, LLC jon(a)jfpossibilities.com 541-410-2760 Making computers work for you!

3 2

Re: Re: GCC integration?
by E. Weddington 17 Dec '04

17 Dec '04

Matt Austern wrote: > On Dec 17, 2004, at 11:31 AM, Nathanael Nerode wrote: > > > I suppose it's time to ask: *should* Pascal integration be a goal for > 4.1? > > GCC was a much simpler compiler when it was just a C compiler. > Sure, but those days are long gone. Witness the number of languages GCC has now. At least Pascal is in the same family of languages as C (IIRC Algol-derived).

1 0

Re: Re: GCC integration?
by Thorsten Glaser 17 Dec '04

17 Dec '04

Gabriel Dos Reis dixit: >The situation for 3.3.x is >radically different from that of 3.2.x. The files in gcc/gcc/config/ from 3.3 are radically different from 3.2, which made it a) not feasible for MirOS to upgrade to 3.3 b) not easy for gpc (if I remember the mailing list stuff correctly). //mirabile

1 0

[RESEND] Re: GCC integration?
by Thorsten Glaser 17 Dec '04

17 Dec '04

From: Thorsten Glaser <tg(a)66h.42h.de> ^^^^^^^^^^^^^ That is the cause for this resend, fixed that now. To: gpc(a)gnu.de Cc: gcc(a)gcc.gnu.org Subject: [gpc] Re: GCC integration? Waldek Hebisch dixit: (cross-posted to gcc list, please reply to the gpc list) > appling the patch form `diffs' subdirectory. Going beyond that > would be mostly wasted effort, because gcc-3.4.x and coming 4.x > are different enough (so one would have to re-… [View More]do the work for Exactly this is the cause for the following request of mine: Since gcc 4.0 will be out of the door not in less than two months from now, and given that gcc 4.1, which ought to solve at least the basic problems with tree-ssa etc. is not even in sight yet, I propose that there will be a gcc-3.5 release with support for Pascal, based upon gcc-3.4, current gpc and Waldek's patches. This would be great since we already had the new directory layout (what I would greatly like to see for Ada and Pascal is that their RTS moves from gcc/p/ to libgpc/ ASAP), and the gcc-3.4/3.5 specific diffs integrated into the core, while the backend patches for gcc 3.3 and older are still available (I don't think Frank is going to throw them away after the integration), and so, if you do _not_ remove the ifdefs from gcc/p/*, you could do another standalone GPC release based upon the code in the gcc-3.5 development tree. While it might also be worthwhile to integrate Hiroaki Etoh's ProPolice SSP, and probably other fixes (Apple stuff?), this would mean gcc 3.5 must be an "official" release. If the SC really is reluctant to do so, it might be feasible to do a "gpc+gcc 3.5" version, developed as a branch in the gcc cvs, but not endorsed by the SC. (Of course, if there'd be interest, one could add ProPolice to that branch as well, unless you really want it to be only for your gpc-specific work. If there is interest, I myself could try to get cvs ci access to gcc.gnu.org - I've already signed the relevant forms, and etoh has, too - and integrate the current propolice; I'm already doing this for the gcc contained in my OS at the moment). For others, developers, especially OS vendors, this would also be great, because history has shown that gcc 3.x branches tend to end after 3.x.3 or 3.x.4, and for the aforementioned reasons 4.0/4.1 will not gain wide acceptance outside of Gentoo (j/k) soon; if one were to incorporate generic 3.x bugfixes and maybe backport 4.x bugfixes into a 3.5 series, this could not only get much adoption, but maybe support from the large (e.g.) GNU/Linux vendors (Novell?). This support would lead to a faster distribution of gpc to "the masses" than releasing a standalone gpc version now and then integrating it into 4.1/4.2 ever could. Besides, support for 3.4 is "almost" done for the more common platforms; I doubt gpc will make it into mainline before it runs on almost all platforms, and having it in gcc cvs will surely help to both get more eyes on the code (Nathanael said something like this IIRC) and get these who do changes to the backend more aware of gpc. Just my 0.02 EUR, //mirabile [View Less]

2 1

how to search for error address
by Francesco Bonomi 17 Dec '04

17 Dec '04

Dear friends, I am sorry I could not find the answer to this (simple??) question: If a program halts with a message like: (error #454 at 376d8) How can I use the 376d8 address to pin-point the line that caused the error? thanks Francesco

2 1

Re: GCC integration?
by Thorsten Glaser 17 Dec '04

17 Dec '04

Marcel Cox dixit: >2) I think doing major GPC integration work now based on GCC 3.x is >just a waste of resources There is not much to do. I integrated gpc into a BSD in-tree gcc once, and besides having to rewrite some stuff for BSD make and applying the diffs correctly, there was next to no work involved. //mirabile

1 0

Re: GCC integration?
by Thorsten Glaser 17 Dec '04

17 Dec '04

Joseph S. Myers dixit: (gpc, SSP) >Again, features cannot be integrated in release branches before they are >in mainline, and they cannot go in mainline if their developers will not >discuss, explain and adapt them in accordance with the usual development >procedures. What about a gcc3-mainline? Development starting from 3.4 and heading towards 3.5, until gpc is mainline-ready and etoh-san has redesigned SSP for working with tree-ssa? Not having SSP for gcc4 e.g. is for the … [View More]

1 0

Re: GCC integration?
by Thorsten Glaser 17 Dec '04

17 Dec '04

Steven Bosscher dixit: >GCC 3.x and GCC 4.0 are internally so very different already that you >will find very few bugfixes for GCC 4.0 that you can backport to any >of the GCC 3.x releases. This one >Except that you'd be integrating with an end-of-life infrastructure. And this one >a waste of effort. Why not just work against GCC 3.4 if you really >want to stay GCC3-based? And this one are the reasons for continuing the gcc3 line IMHO. >You could make it so much … [View More]

1 0

gpc on IBM AIX 5.3 with POWER5
by Neil Bunn 17 Dec '04

17 Dec '04

Hi, I'm trying to build gpc following the instructions on the web, and trying to build on AIX 5.3 using gcc 3.3.2 which is supported and install. When I attempt: configure --enable-languages=pascal I get: bash-2.05b# /work/gcc-3.3.2/configure --enable-languages=pascal Configuring for a powerpc-ibm-aix5.3.0.0 host. Created "Makefile" in /work/gpc-build using "mt-frag" And then the make process hangs, with bind64 taking up 50% of my cpu time for a while until I kill it. In the build … [View More]

2 1

[ra993482@ic.unicamp.br: Spec file for GPC]
by Anja Gerwinski 13 Dec '04

13 Dec '04

Hello, clearing up a mail folder I read only rarely (due to excess spam), I found the message below. It's of July, but maybe it is still of interest. Best Regards, Anja Gerwinski ----- Forwarded message from Ulisses <ra993482(a)ic.unicamp.br> ----- Delivery-date: Mon, 05 Jul 2004 22:09:20 +0200 Subject: Spec file for GPC From: Ulisses <ra993482(a)ic.unicamp.br> To: gpc-owner(a)gnu.de Hi, could you forward this email to your gpc mailing list? I made a spec file for gpc and … [View More]

1 0

module/unit interface `Gpc' could not be imported
by Leo Brewin 13 Dec '04

13 Dec '04

Hi Folks, My apologies if this is a silly question... I've just compiled gpc-20020510 on my Red Hat 9 system and I can't seem to compile any of the demo programs (except hello.pas). Here is what I did mv gpc-20020510/p/ gcc-2.95.2/gcc/ mkdir gpc-build cd gpc-build ../gcc-2.95.2/configure --enable-language=pascal --prefix=/home/leo/local make install There were no errors during the above compilation. Next I tried the demo programs, cd ~/… [View More]

2 1

module/unit interface `Gpc' could not be imported : Solved
by Leo Brewin 11 Dec '04

11 Dec '04

Hi Folks, The verdict is in : I'm a twit. The solution is (RTFM) gpc --automake factorial.pas Sorry to waste your time. Cheers, Leo Brewin

1 0

Linking problem on AIX
by Peter Keenan 08 Dec '04

08 Dec '04

Following my earlier post about memory limit in 32 bit programs in AIX http://www.gnu-pascal.de/crystal/gpc/en/mail11103.html I am now trying to get around the memory limitations by using 64 bit program with GPC. I am using the -maix64 flag. I can build a simple c program using GCC and this flag. When I try to do this for a simple pascal program I get linking problems. I get this using both GNU LD 2.14 or the AIX linker. This is probably a simple path or library problem, I would be very … [View More]

2 1

Re: internal compiler error: in find_function_data, at function.c:317
by Tom Schneider 05 Dec '04

05 Dec '04

Waldek: > The problem is that GPC lost track of variables. More precisely, > the line (in procedure printfeature): > > with f^, f^.definition^ do begin > > confused GPC. As a workaround you may replace it by: > > with f^ do with f^.definition^ do begin Thank you!! I confirm that that solved the problem when I did it for all cases. Also thanks for identifying how to correct the GPC code. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory … [View More]

1 0

Re: internal compiler error: in find_function_data, at function.c:317
by Waldek Hebisch 02 Dec '04

02 Dec '04

Todd Fiedler wrote: > Thanks for your quick response. > > On a side note, can you tell me if the lister.i file was included with > the message you received? I have been asked to find out. I'm hoping it > did not but I would really appreciate it if you could tell me. > The `lister.i' file was in the attachement (otherwise I would have no chance to find the problem). More precisely, the attachement contained the `lister.zip' file. Note that messages to the GPC mailing list … [View More]

1 0

Re: your mail
by Tom Schneider 02 Dec '04

02 Dec '04

Pete, Tod: > GPC: daily digest > > This is Digest Volume 1 : Issue 587 : Digest Style "text" > Below is a summary of all the messages, showing the subject of each post > and who posted it, followed by the full text of all messages. > > internal compiler error: in find_function_data, at function.c:317 > Re: internal compiler error: in find_function_data, at function.c:317 > > ---------------------------------------------------------------------- > > … [View More]Date: Wed, 1 Dec 2004 19:27:16 -0600 > From: "Fiedler, Todd, A" <tafiedler(a)cmh.edu> > To: <gpc(a)gnu.de> > Subject: internal compiler error: in find_function_data, at function.c:317 > Message-ID: <958B228E6A626242A3FEAB621C4C933504B12A0D(a)exch2000.cmh.internal> > > REVISION -- Note: I included the lister.i file as a zip because it is over > 11,000 lines long. > > Hello. I am attempting to compile a program named lister.p, that does > some genomic work. I can compile some programs in this suite while > others always generate an error. I'm not much of a pascal programmer, > it's been 15 years since I actually wrote anything in it, but a group of > researchers here would like to get this working. Any help will be very > much appreciated! > > Thanks! > Todd > > > I am compiling on Mac OS X. Here are my specs. > > $ uname -a > Darwin seed.cmh.edu 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 > 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power > Macintosh powerpc > > $ gcc -v > Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs > Thread model: posix > gcc version 3.3 20030304 (Apple Computer, Inc. build 1666) > > $ gpc -v > > Reading specs from > /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs > Configured with: ../gpc-332d1/configure --enable-languages=pascal,c > --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix > --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, > based on gcc-3.3.2 > > > I ran gpc with the following command line: > > gpc -x Pascal -save-temps lister.p -o lister > > lister.p: In procedure `showpiece': > lister.p:7730: internal compiler error: in find_function_data, at > function.c:317 Please submit a full bug report, with preprocessed source > if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. > > > > [Attachment of type application/zip removed.] > > ------------------------------ > > Date: Thu, 2 Dec 2004 03:43:39 +0100 > From: Adriaan van Os <gpc(a)microbizz.nl> > To: gpc(a)gnu.de > Subject: Re: internal compiler error: in find_function_data, at function.c:317 > Message-ID: <F8EDEB53-440B-11D9-BAA2-000A27944772(a)microbizz.nl> > > Fiedler, Todd, A wrote: > > > lister.p: In procedure `showpiece': > > lister.p:7730: internal compiler error: in find_function_data, at > > function.c:317 Please submit a full bug report, with preprocessed > > source > > if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for > > instructions. > > Reproducable with the latest gpc sources on Mac OS X. > > Regards, > > Adriaan van Os > > > > ------------------------------ > > End of > ********** Unfortunately this appears to be a release of the source code for sequence walkers. However, it says "Attachment of type application/zip removed." Does that mean it appeared in the archive but not the mailing list? Tom [View Less]

2 1

Re: your mail
by Tom Schneider 02 Dec '04

02 Dec '04

Pete: > Todd will make sure that any lister code is scrubbed from the site. > As you are aware, this was an internal error, due to modifications > of the gpc Pascal compiler and not an error in the lister code > itself. Thanks. I recognize why Todd did this, appreciate his efforts and normally it would be ok. I also recognize that we are stuck if the GPC compiler fails on lister, so it is important to have GPC working properly. It is not clear how to handle this without a … [View More]

1 0

internal compiler error: in find_function_data, at function.c:317
by Fiedler, Todd, A 02 Dec '04

02 Dec '04

REVISION -- Note: I included the lister.i file as a zip because it is over 11,000 lines long. Hello. I am attempting to compile a program named lister.p, that does some genomic work. I can compile some programs in this suite while others always generate an error. I'm not much of a pascal programmer, it's been 15 years since I actually wrote anything in it, but a group of researchers here would like to get this working. Any help will be very much appreciated! Thanks! Todd I am compiling on … [View More]

4 3

GPC on AIX - memory limit?
by Peter Keenan 29 Nov '04

29 Nov '04

Hi, I've built gpc 20041017, based on gcc-3.3.2 in my home directory on an AIX machine which has the GCC 3.3.2 binaries installed in usr/local/bin. The testsuite programs all run fine and I am able to compile and run my own programs. I am using a program converted from Delphi, where I increased the stack and heap limits to allow the program use more memory. The program ran successfully several times on a PC, using more than 1GB of memory. However on AIX the program seem to be hitting a … [View More]

2 2

-Wno-underscore
by Adriaan van Os 28 Nov '04

28 Nov '04

[G4:~/testgpcadriaan] adriaan% cat NoUnderscore.p program NoUnderscore; procedure _Run; begin writeln('_Run') end; begin _Run end. [G4:~/testgpcadriaan] adriaan% gpc NoUnderscore.p NoUnderscore.p:4: warning: identifiers should not start with an underscore [G4:~/testgpcadriaan] adriaan% gpc NoUnderscore.p -Wno-underscore [G4:~/testgpcadriaan] adriaan% gpc NoUnderscore.p --gnu-pascal -Wno-underscore NoUnderscore.p:4: warning: identifiers should not start with an … [View More]

4 6

Re: Building GPC with GCC 3.4.2 (in Fedora Core 3)
by Wood David 24 Nov '04

24 Nov '04

A big thanks Waldek. I seem to have a gpc built with gcc 3.4.2. Just a few minor hiccups which don't appear to have been too critical: 1) The man pages didn't build because help2man wasn't found. I'm not sure where this normally comes from, but the man pages have usually been built ok. 2) When I did 'cd gcc' and 'make pascal.install-with-gcc' , the gpc -v command gave me the correct build version, but a gpc compilation resulted in the error 'installation problem, cannot exec gpc1: no such … [View More]file or directory'. Repeating the installation just using 'make install' solved the problem. 3) At the end of the install, I get the error /bin/sh: -ranlib: command not found. I presume the leading '-' is messing this up. I found ranlib in /usr/bin. Apologies for the corporate nonsense that follows. I'll try to get our company policy changed but it's likely to be a David and Goliath battle! Regards David. > -----Original Message----- > From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de]On Behalf Of Waldek > Hebisch > Sent: Wednesday, November 24, 2004 2:08 PM > To: gpc(a)gnu.de > Subject: Re: Building GPC with GCC 3.4.2 (in Fedora Core 3) > > > Wood David wrote: > > I'm trying to compile gpc-20040516 with gcc-core-3.4.2 in > the hope it will > > sort out a compatibility problem when linked with other > c-code we've built. > > I found Waldek's patches to gpc proper and gcc 3.4.20041015 > (I've also tried > > the 3.4.0 patch) and applied these using $ patch -p1 < > XX.diff in the > > respective source directories. However, the make crashes, > firstly with > > > > ../../gcc-3.4.2/gcc/p/mk_lang_opt: Permission denied. > > > > In normal build `mk_lang_opt' should not run (it is needed only after > a modification). The problem is due to limitation of `patch' (inabilty > to set file mode or modification time) and microsecond timestamps > in new kernels. Before the build you should touch `lang.opt' and > `handle-opts.c' to mark them as up to date. > > > So I do a chmod +x on this file and type make again. The > next worry comes > > when it says I should have 16 shift/reduce conflicts and 30 > reduce/reduce > > conflicts but I get 16 and 295! > > > > That is harmless. > > > The final nail in the coffin appears when p/handle-opts.c > produces a string > > of errors because the OPT_* components are undeclared. > Just before this, > > lang.c reports a number of warnings about function > declarations not being > > prototypes and no previous prototype for 'pascal_post-options' or > > 'pascal_handle_option'. > > > > Trying to run `mk_lang_opt' had wiped-out pre-built `lang.opt' (you > get empty file instead). `lang.opt' is needed to define > `OPT_*' constants. > Making `mk_lang_opt' executable _before_ the build should also correct > the problem. > > -- > Waldek Hebisch > hebisch(a)math.uni.wroc.pl > The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes. [View Less]

1 0

Building GPC with GCC 3.4.2 (in Fedora Core 3)
by Wood David 24 Nov '04

24 Nov '04

I'm trying to compile gpc-20040516 with gcc-core-3.4.2 in the hope it will sort out a compatibility problem when linked with other c-code we've built. I found Waldek's patches to gpc proper and gcc 3.4.20041015 (I've also tried the 3.4.0 patch) and applied these using $ patch -p1 < XX.diff in the respective source directories. However, the make crashes, firstly with ../../gcc-3.4.2/gcc/p/mk_lang_opt: Permission denied. So I do a chmod +x on this file and type make again. The next worry … [View More]

3 2

Re: GCC integration?
by Waldek Hebisch 24 Nov '04

24 Nov '04

I wrote: > To have a comparison: I have not metered time spent hacking GPC, but > in the last year it is probably equivalent to 2-3 months. The above is about time _I_ have spent on GPC. I have not tried to quantify other contributions, so the total is much bigger. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

ia-64 test results with patch
by thomas.koenig＠bayertechnology.com 19 Nov '04

19 Nov '04

Hi everybody, thanks for pointing me to the 64-bit patch. Things are certainly looking better now. It's down to 26 unexpected failures now: === gpc tests === Running target any Running testsuite ... UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas FAIL: casts2.pas FAIL: chief40.pas FAIL: emil21a.pas FAIL: emil21c.pas FAIL: emptyrec.pas FAIL: fieldw.pas FAIL: fjf129.pas FAIL: fjf23.pas FAIL: fjf30a.pas FAIL: fjf30b.pas FAIL: fjf327.pas FAIL: fjf347.pas FAIL: fjf512.pas … [View More]FAIL: fjf526a.pas FAIL: fjf526b.pas FAIL: fjf666a.pas FAIL: fjf762a.pas FAIL: fjf9.pas FAIL: init1t.pas FAIL: math.pas FAIL: schema2a.pas FAIL: shl.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 4044 # of expected passes 4016 # of unexpected failures 26 # of unsupported tests 2 /home/zfkts/zfkts/gpc-bin/gcc/xgpc version 20041017, based on gcc-3.3.3 make[1]: Leaving directory `/home/zfkts/zfkts/gpc-bin/gcc/p/test' $ grep -v OK test_log Test Run By zfkts on 2004-11-19 16:29:31 Native configuration is ia64-unknown-linux-gnu (byzrzd.bayer-ag.com) /home/zfkts/zfkts/gpc-bin/gcc/xgpc -B/home/zfkts/zfkts/gpc-bin/gcc/ 20041017, based on gcc-3.3.3, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST aregextest.pas: SKIPPED: librx not installed TEST asmtest.pas: SKIPPED: only for IA32 TEST casts2.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/casts2.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/casts2.pas:10: warning: cast to type of different size failed TEST chief40.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/chief40.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/chief40.pas:8: error: constant out of range /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/chief40.pas:11: error: arithmetical overflow /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/chief40.pas:11: error: constant overflow in expression /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/chief40.pas:14: error: arithmetical overflow /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/chief40.pas:14: error: constant overflow in expression failed TEST emil21a.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21a.pas:12: error: invalid subrange type /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21a.pas:12: error: actual schema discriminant has invalid value /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21a.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21a.pas:15: error: undeclared identifier `A' (first use in this routine) /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21a.pas:15: error: (Each undeclared identifier is reported only once /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21a.pas:15: error: for each routine it appears in.) failed TEST emil21c.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21c.pas:12: error: invalid subrange type /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21c.pas:12: error: actual schema discriminant has invalid value /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21c.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21c.pas:15: error: undeclared identifier `A' (first use in this routine) /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21c.pas:15: error: (Each undeclared identifier is reported only once /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/emil21c.pas:15: error: for each routine it appears in.) failed TEST emptyrec.pas: failed TEST fieldw.pas: failed (Foo) TEST fjf129.pas: Failed: 1.844674407370955e+19: 1.844674407370955e+19, 1.844674407370955e+19; 0.000000000000000e+00, 7.000000000000000e-01 TEST fjf23.pas: failed: 65534, 4294967294 TEST fjf30a.pas: failed: failed TEST fjf30b.pas: failed: failed TEST fjf327.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf327.pas:4: error: arithmetical overflow /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf327.pas:4: error: constant overflow in expression /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf327.pas:4: error: constant out of range /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf327.pas:4: error: initial value is of wrong type /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf327.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf327.pas:9: error: constant out of range failed TEST fjf347.pas: failed: 18446744073709551615 TEST fjf512.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/test_run: line 335: 30623 Illegal instruction ./"$A_OUT" "$1" TEST fjf526a.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf526a.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf526a.pas:8: warning: left shift count >= width of type failed TEST fjf526b.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf526b.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf526b.pas:8: warning: left shift count >= width of type failed TEST fjf666a.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf666a.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf666a.pas:9: error: arithmetical overflow /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/fjf666a.pas:9: error: constant overflow in expression failed TEST fjf762a.pas: failed: TEST fjf9.pas: failed: 24 TEST init1t.pas: failed: failed TEST math.pas: 1,2c1 < it works !!! < /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/test_run: line 335: 27153 Illegal instruction ./"$A_OUT" "$1" --- > oh boyit works !!! failed TEST schema2a.pas: failed TEST shl.pas: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/shl.pas: In main program: /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/shl.pas:9: warning: left shift count >= width of type /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/shl.pas:11: warning: right shift count >= width of type /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/shl.pas:21: warning: left shift count >= width of type /home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/shl.pas:23: warning: right shift count >= width of type failed TEST writeb.pas: Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. TEST writec.pas: SP: LongInt `-7890123456789012345' was not indented, but should be. SP: LongInt `12345678901234567890' was not indented, but should be. SP: LongInt `-7890123456789012345' was not indented, but should be. SP: LongInt `12345678901234567890' was not indented, but should be. Run #1: LongInt `-7890123456789012345' was not indented, but should be. Run #1: LongInt `12345678901234567890' was not indented, but should be. Run #1: LongInt `-7890123456789012345' was not indented, but should be. Run #1: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. TEST writee.pas: EP: LongInt `-7890123456789012345' was not indented, but should be. EP: LongInt `12345678901234567890' was not indented, but should be. EP: LongInt `-7890123456789012345' was not indented, but should be. EP: LongInt `12345678901234567890' was not indented, but should be. EP: LongInt `-7890123456789012345' was not indented, but should be. EP: LongInt `12345678901234567890' was not indented, but should be. EP: LongInt `-7890123456789012345' was not indented, but should be. EP: LongInt `12345678901234567890' was not indented, but should be. Run #1: LongInt `-7890123456789012345' was not indented, but should be. Run #1: LongInt `12345678901234567890' was not indented, but should be. Run #1: LongInt `-7890123456789012345' was not indented, but should be. Run #1: LongInt `12345678901234567890' was not indented, but should be. Run #1: LongInt `-7890123456789012345' was not indented, but should be. Run #1: LongInt `12345678901234567890' was not indented, but should be. Run #1: LongInt `-7890123456789012345' was not indented, but should be. Run #1: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. TEST writeg.pas: Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #3: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. Run #4: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. Run #4: LongInt `12345678901234567890' was indented with field width 21, but should be with field width 44. ========================== GPC-TEST-END $ Thomas [View Less]

1 0

test log for ia64
by thomas.koenig＠bayertechnology.com 19 Nov '04

19 Nov '04

Nice thing: the compiler does build, and it does some things. There are still some tests failing, though. Following is a test log. I have the complete gpc.log for anybody who's interested (I didn't include it because of its length). Thomas $ make check-pascal ../../gcc-3.3.3/gcc/p/script/mkdir-p p/test { \ echo "# Automatically generated from ../../gcc-3.3.3/gcc/p/test/Makefile."; \ echo "# Don't change manually."; \ echo ""; \ sed -e "s,^srcdir *=.*,srcdir=`cd ../../gcc-3.3.3/… [View More]gcc/p/test && pwd`,; \ s,^PC *=.*,PC=`pwd`/xgpc -B`pwd`/,; \ s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`cd ../../gcc-3.3.3/gcc/p/units && pwd`," \ ../../gcc-3.3.3/gcc/p/test/Makefile; \ } > p/test/Makefile || { rm -f p/test/Makefile; false; } echo timestamp > "p/stamp-test-Makefile" cd ./p/test && make MASK="" EXTRA_TEST_PFLAGS=" " TEST_RUN_FLAGS="" "pascal.check-dejagnu" make[1]: Entering directory `/home/zfkts/zfkts/gpc-bin/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 PC="/home/zfkts/zfkts/gpc-bin/gcc/xgpc -B/home/zfkts/zfkts/gpc-bin/gcc/" PFLAGS="-I ../rts --unit-path=/home/zfkts/zfkts/gcc-3.3.3/gcc/p/units --autobuild -g -O3 -W -Wall -Wno-unused " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused " SRCDIR="/home/zfkts/zfkts/gcc-3.3.3/gcc/p/test" TEST_MAKE_FLAG=test-make-flag "/home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/test_run" | tee test_log | "/home/zfkts/zfkts/gcc-3.3.3/gcc/p/test/test_sum" -d Test Run By zfkts on 2004-11-19 15:10:51 Native configuration is ia64-unknown-linux-gnu (byzrzd.bayer-ag.com) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas FAIL: aturbo3test.pas FAIL: az43.pas FAIL: backtracerr.pas FAIL: bo4-10.pas FAIL: bo4-12.pas FAIL: bo4-14.pas FAIL: bo4-18.pas FAIL: bo5-17a.pas FAIL: bo5-17.pas FAIL: bo5-22.pas FAIL: casts2.pas FAIL: cfor.pas FAIL: chief31a.pas FAIL: chief31b.pas FAIL: chief31c.pas FAIL: chief31d.pas FAIL: chief40.pas FAIL: chuck6.pas FAIL: cntchars.pas FAIL: crttest.pas FAIL: dialec3.pas FAIL: dialec5.pas FAIL: dialec6.pas FAIL: dialec7.pas FAIL: eightqueens.pas FAIL: emil21a.pas FAIL: emil21c.pas FAIL: emptyrec.pas FAIL: expotst.pas FAIL: fay.pas FAIL: fieldw.pas FAIL: fjf125.pas FAIL: fjf129.pas FAIL: fjf168.pas FAIL: fjf172.pas FAIL: fjf181a.pas FAIL: fjf189.pas FAIL: fjf194a.pas FAIL: fjf194b.pas FAIL: fjf194c.pas FAIL: fjf194.pas FAIL: fjf23.pas FAIL: fjf246d.pas FAIL: fjf246e.pas FAIL: fjf254.pas FAIL: fjf257a.pas FAIL: fjf257b.pas FAIL: fjf257c.pas FAIL: fjf259.pas FAIL: fjf265.pas FAIL: fjf278.pas FAIL: fjf294a.pas FAIL: fjf306.pas FAIL: fjf30a.pas FAIL: fjf30b.pas FAIL: fjf320a.pas FAIL: fjf320b.pas FAIL: fjf323.pas FAIL: fjf327.pas FAIL: fjf343a.pas FAIL: fjf343b.pas FAIL: fjf347.pas FAIL: fjf354.pas FAIL: fjf359.pas FAIL: fjf375.pas FAIL: fjf380a.pas FAIL: fjf381.pas FAIL: fjf398.pas FAIL: fjf40b.pas FAIL: fjf40e.pas FAIL: fjf411.pas FAIL: fjf413h1.pas FAIL: fjf422.pas FAIL: fjf423.pas FAIL: fjf431.pas FAIL: fjf436b.pas FAIL: fjf436c.pas FAIL: fjf443.pas FAIL: fjf450b.pas FAIL: fjf450d.pas FAIL: fjf454.pas FAIL: fjf471.pas FAIL: fjf472.pas FAIL: fjf487b.pas FAIL: fjf488i2.pas FAIL: fjf488m2.pas FAIL: fjf488m3.pas FAIL: fjf488m4.pas FAIL: fjf488n2.pas FAIL: fjf488n3.pas FAIL: fjf488o2.pas FAIL: fjf488o4.pas FAIL: fjf488p2.pas FAIL: fjf488p4.pas FAIL: fjf496a4.pas FAIL: fjf496b4.pas FAIL: fjf496c4.pas FAIL: fjf496e4.pas FAIL: fjf501a.pas FAIL: fjf501b.pas FAIL: fjf509a.pas FAIL: fjf509b.pas FAIL: fjf512.pas FAIL: fjf516a.pas FAIL: fjf516b.pas FAIL: fjf524a.pas FAIL: fjf526a.pas FAIL: fjf526b.pas FAIL: fjf528a.pas FAIL: fjf528b.pas FAIL: fjf539a.pas FAIL: fjf574a.pas FAIL: fjf574b.pas FAIL: fjf574c.pas FAIL: fjf587f.pas FAIL: fjf619c.pas FAIL: fjf629g.pas FAIL: fjf636e.pas FAIL: fjf638.pas FAIL: fjf651a.pas FAIL: fjf651b.pas FAIL: fjf666a.pas FAIL: fjf675.pas FAIL: fjf68.pas FAIL: fjf732.pas FAIL: fjf753h.pas FAIL: fjf762a.pas FAIL: fjf768g.pas FAIL: fjf770.pas FAIL: fjf781a.pas FAIL: fjf781d.pas FAIL: fjf792a.pas FAIL: fjf792b.pas FAIL: fjf792g.pas FAIL: fjf792h.pas FAIL: fjf793a.pas FAIL: fjf793g.pas FAIL: fjf810.pas FAIL: fjf842.pas FAIL: fjf875c.pas FAIL: fjf923.pas FAIL: fjf9.pas FAIL: fnested.pas FAIL: fproc.pas FAIL: gale1c.pas FAIL: hamachi.pas FAIL: hanoi.pas FAIL: index.pas FAIL: insan.pas FAIL: jesper3.pas FAIL: math.pas FAIL: maur6.pas FAIL: miklos5.pas FAIL: nick1.pas FAIL: palindromes.pas FAIL: pat4.pas FAIL: permute.pas FAIL: pipetes2.pas FAIL: powersoftwo.pas FAIL: primes.pas FAIL: procvar3.pas FAIL: prx.pas FAIL: ptrvars.pas FAIL: pvs1.pas FAIL: random.pas FAIL: realout.pas FAIL: redef.pas FAIL: redefp.pas FAIL: rick1.pas FAIL: sam5.pas FAIL: scaltst.pas FAIL: schema2a.pas FAIL: sequin.pas FAIL: shl.pas FAIL: size.pas FAIL: slength.pas FAIL: steve1.pas FAIL: str2cstr.pas FAIL: strindex.pas FAIL: strini.pas FAIL: strptr1.pas FAIL: strptr2.pas FAIL: strptr3.pas FAIL: strptr4.pas FAIL: sven0.pas FAIL: sven15.pas FAIL: sven1.pas FAIL: sven4.pas FAIL: t04.pas FAIL: t08.pas FAIL: t09.pas FAIL: t10.pas FAIL: t11.pas FAIL: t15.pas FAIL: t17.pas FAIL: takashi1.pas FAIL: testio.pas FAIL: wnj.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas FAIL: writereal.pas === gpc Summary === # of tests 3999 # of expected passes 3794 # of unexpected failures 203 # of unsupported tests 2 /home/zfkts/zfkts/gpc-bin/gcc/xgpc version 20041017, based on gcc-3.3.3 make[1]: Leaving directory `/home/zfkts/zfkts/gpc-bin/gcc/p/test' $ [View Less]

2 1

null bytes on output with writeln
by thomas.koenig＠bayertechnology.com 19 Nov '04

19 Nov '04

There are leading null bytes on output with gpc-20041017. $ gpc -v Reading specs from /usr/local/lib/gcc-lib/ia64-unknown-linux-gnu/3.3.3/specs Configured with: ../gcc-3.3.3/configure --enable-languages=c,p : (reconfigured) ../gcc-3.3.3/configure --enable-languages=c,pascal Thread model: posix gpc version 20041017, based on gcc-3.3.3 $ cat nullbytes.pas program main; begin writeln(1.0:20:10); end. $ gpc nullbytes.pas $ ./a.out | od -x 0000000 0000 0000 2020 2020 2e31 3030 3030 3030 0000020 … [View More]

2 1

PGCC
by Silvio a Beccara 16 Nov '04

16 Nov '04

Hi, I just found about PGCC, a version of GCC specially optimised for Pentium processors. Anybody ever thought about making GPC work using PGCC as a backend, so as to take profit of the (supposed) optimisations and speed gain? Regards Silvio a Beccara

2 1

working with char driver as with the file in GPC
by Igor Marnat 16 Nov '04

16 Nov '04

Hello dear List! Unfortunately there is no possibility at the moment to search through list-archives. Perhaps someone could give me an advise. I'd like to communicate with the char device driver which is realised as a file. In C I can just make "dsp_fd = open(dsp_devname, O_RDWR|O_SYNC)" and then work with it all the time using "write(fd, (const void*)msg, nbytes)" and read respectively without additional activities. How should I use it in GPC? The only way I see is to Assign (dsp_fd, … [View More]

2 3

gpc-20041017 binaries for Mingw and Fedora Core 2 (AMD-64 )
by Prof A Olowofoyeku (The African Chief) 15 Nov '04

15 Nov '04

Hi I have released binaries for gpc-20041017 for these platforms: Mingw (Win32) MSYS (Win32-posix) Fedora Core 2 for AMD-64 Also released is Dev+GNU Pascal (a Full GPL Pascal Programming Environment + Win32 IDE) v1.94.4, based on gpc-20041017 and an updated Dev-Pascal IDE. Check here for downloads: http://www.gnu-pascal.de/contrib/chief/ Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

4 4

unbalanced comment bug
by Russell Whitaker 13 Nov '04

13 Nov '04

Hi Found a rather trivial bug, shown here as { { }, the original was a typo: { ) { }. ( so I need new glasses ). program bug; begin { this writeln("OK"); exit; { is a bug } writeln("fail"); end. Russ p.s. built gpc with gcc-3.3.5, no errors in test suite. good.

2 1

xcode and gpc?
by P. George 12 Nov '04

12 Nov '04

i've got xcode. i've got gpc. how can i get them to kiss? - philip

2 2

GPC web site is back
by Frank Heckenbach 10 Nov '04

10 Nov '04

Hi everybody, I am happy to announce that the GPC web site <http://www.gnu-pascal.de> is back online, after several weeks of problems on the server. The current GPC beta release (20041017) is on the download page. Previous alphas/betas between 2.1 and this one have been omitted since I'd have to reconstruct them from my archives and verify them to be trushworthy, and I don't think it's worth the effort. If there are serious problems with 20041017, I'd rather fix them, so everyone can … [View More]

2 1

Cross compiling for Mach-O Darwin
by Adriaan van Os 08 Nov '04

08 Nov '04

Waldek Hebisch wrote: > I am unable to reproduce the error in cross-compiler -- I have compiled > string.pas to assembler without a crash (I can not obtain object file > since I have no darwin assembler). It may be interesting to note that yesterday a cctools package has been released that can be used to cross compile and link Mach-O Darwin binaries on Linux, see the odcctools mailing list archives <http://www.opendarwin.org/pipermail/odcctools/2004-November/ 000034.html… [View More]

1 0

Environment variables on Mac OS X
by Adriaan van Os 01 Nov '04

01 Nov '04

As discussed before, shared libraries on Mac OS X can not reference the environ variable directly, where applications can. This is a show stopper on Mac OS X, because of the internals of autoconf and because the environ variable is referenced in gpc's runtime library. To solve this problem, I apply the following patch: --- gcc/p/rts/rts.c.orig Wed Apr 16 01:58:46 2003 +++ gcc/p/rts/rts.c Fri Jun 6 11:35:50 2003 @@ -195,7 +195,15 @@ extern int errno; #endif -#if defined (HAVE_ENVIRON) … [View More]

2 4

ANN id2id-20 now available
by CBFalconer 30 Oct '04

30 Oct '04

A replacement for the original version. This does not avoid comments and strings, and uses different algorithms. The hashlib package is a prerequisite, and supplies the storage. This is a complete rewrite, in a different language and thus begins life as version 2.0 of id2id. Id2id reads a list of idpairs in the form of lines holding oldname newname and then applies all those changes to the file specified. It does this with a single pass through the file, and thus is almost as quick as … [View More]

1 0

gpc-20041017 released - Mingw binaries
by Prof A Olowofoyeku (The African Chief) 29 Oct '04

29 Oct '04

Hi The Mingw binaries for gpc-20041017 have been released on the Mingw download site: http://prdownloads.sourceforge.net/mingw/?sort_by=date&sort=desc The file is called: gpc-20041017.i386-pc-mingw32-1.tar.gz Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

gpc-20041017
by Paul Igodt 29 Oct '04

29 Oct '04

I am far from a GPC expert, but mainly a user of several old but good working pascal programs. I just installed gpc-20041017 from www.g-n-u.de/gpc on my Linux PC. I downloaded gpc-20041017-with-gcc.i686-pc-linux-gnu.tar.gz, unzipped and untarred in / When I ask for gpc, it seems to be there, and gpc -v gives version 20041017, based on gcc-3.3.3. When I try to compile one of my programs, giving gpc -o dbase --automake -I/usr/include/ncurses dbase.pas I now get a very long error list, … [View More]

3 2

Built-in functions shadowed without Self?
by Neil Santos 28 Oct '04

28 Oct '04

Took me a minute to figure out what's causing this output from GPC: TCollection.epb: In method TCollection.Push': TCollection.epb:106: warning: capitalisation of high' doesn't match TCollection.eph:71: warning: previous capitalisation High' TCollection.epb:106: error: too many arguments to routine TCollection.High' TCollection.epb:88: error: routine declaration Why is a class method named High() shadowing the built-in high()? What can be done (aside from renaming the method) so built-ins … [View More]

3 2

GPC in GCC 3.4.2?
by Neil Santos 28 Oct '04

28 Oct '04

Is there a diff for GCC 3.4.2? The source distro only includes diffs for 3.3.3 and earlier; Google wasn't much help with the query, either. -- Political Dissident Neil Santos Free Software Advocate Jabber: nsantos(a)jabber.org Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

4 6

Mac OS X hosted cross compiler targeting Windows (MingW)
by Adriaan van Os 28 Oct '04

28 Oct '04

To my surprise and joy, I managed to build a Mac OS X hosted cross compiler targeting Windows (MingW). I used the information found at (or through) <http://www.mingw.org/mingwfaq.shtml>, more specifically <http://www.libsdl.org/extras/win32/cross/README.txt>. With some necessary modifications, the <http://www.libsdl.org/extras/win32/cross/build-cross.sh> script was able to build cross binutils, as well as gcc and gpc cross compilers. The actual build was done with gpc … [View More]

6 14

Re: GPC speed
by Silvio a Beccara 28 Oct '04

28 Oct '04

The random generator is in both cases the Mersenne Twister (routine mt19937 from the authors' site). And I had forgot the Fortran program. Anyway you are right: the pseudorandom generator takes the most time in the program. But here is another example, this time both in Pascal and in Fortran: ------------------------------------------------ program matrix; uses GPC, SysUtils; const size = 30; type tMatrix = array[0..size, 0..size] of longint; VAR time1, time2 : longCard; dummy, j, … [View More]big, cpu1, cpu2 : integer; procedure mkmatrix( rows, cols : integer; var mx : tMatrix); var R, C : integer; count : longint; begin Dec(rows); Dec(cols); count := 1; for R := 0 to rows do begin for C := 0 to cols do begin mx[R, C] := count; Inc(count); end; end; End; procedure mmult(rows, cols : integer; m1, m2 : tMatrix; var mm : tMatrix ); var i, j, k : integer; val: longint; begin Dec(rows); Dec(cols); For i := 0 To rows do begin For j := 0 To cols do begin val := 0; For k := 0 To cols do begin Inc(val, m1[i, k] * m2[k, j]); end; mm[i, j] := val; end; end; End; var NUM, I : integer; M1, M2, MM : tMatrix; begin writeln ('# MATRIX MULTIPLICATION: GPC'); time1 := GetMicroSecondTime; if ParamCount = 0 then NUM := 1 else NUM := StrToInt(ParamStr(1)); if NUM < 1 then NUM := 1; mkmatrix(size, size, M1); mkmatrix(size, size, M2); for I := 0 To NUM do begin mmult(size, size, M1, M2, MM); end; WriteLn( IntToStr(MM[0, 0]) + ' ' + IntToStr(MM[2, 3]) + ' ' + IntToStr(MM[3, 2]) + ' ' + IntToStr(MM[4, 4])); dummy := 0; time2 := GetMicroSecondTime; writeln('GPC: elapsed time: ', ( (time2-time1) * 0.000001):7:2, ' seconds, ' ); end. ------------------------------------------------ program perfor2for integer i character*20 argum integer size parameter ( size = 30 ) integer m1 ( 0:size, 0:size), m2 ( 0:size, 0:size), & mm ( 0:size, 0:size), mx ( 0:size, 0:size ) real etime real elapsed(2) real total write (*,*) '# MATRIX MULTIPLICATION: IFORT' call getarg ( 1, argum ) read ( argum, * ) num write (*,*) '# size = ', size if ( num .le. 1 ) num =1 call mkmatrix ( size, size, m1 ) call mkmatrix ( size, size, m2 ) write (*,*)'------------------------------------------------------' write (*,*) m1 (0,0), ' ', m1(2,3), ' ', m1(3,2), ' ', m1(4,4) write (*,*) m2 (0,0), ' ', m2(2,3), ' ', m2(3,2), ' ', m2(4,4) write (*,*)'------------------------------------------------------' do i = 1, num call mmult ( size, size, m1, m2, mm ) enddo write (*,*) mm (0,0), ' ', mm(2,3), ' ', mm(3,2), ' ', mm(4,4) total = etime ( elapsed ) print *, 'Elapsed time =', total, ' secondi '! , ' user=', elapsed(1), ' system=', elapsed(2) stop end subroutine mkmatrix ( rows, cols, mx ); integer r, c, rows, cols include 'size.h' integer mx ( 0:size, 0:size ), count rows = rows - 1 cols = cols - 1 count = 1 write (*,*) '# rows = ', rows, ' cols = ', cols do r = 0, rows do c = 0, cols mx ( r, c ) = count count = count + 1 enddo enddo return end subroutine mmult ( rows, cols, m1, m2, mm ) integer r, c, rows, cols, i, j, k include 'size.h' integer m1( 0:size, 0:size ), m2( 0:size, 0:size ), mm ( 0:size, 0:size ), count, val rows = rows - 1 cols = cols - 1 do i = 0, rows do j = 0, cols val = 0 do k = 0, cols val = val + m1(i,k)*m2(k, j) enddo mm(i, j) = val enddo enddo return end ------------------------------------------------------------------ here the difference is marked. Perhaps by exhanging columns with rows one can make Pascal execution faster. I will try. Thanks, best regards Silvio a Beccara [View Less]

4 6

GPC speed
by Silvio a Beccara 26 Oct '04

26 Oct '04

Hi everybody, I ran some tests that make extensive use of large (up to 10000 elements) arrays, up to three dimensions both in GPC and in Fortran (Intel). Even turning on optimisations, GPC is at least five times slower than Fortran in completing the tests. Anyone can tell me why, and possibly some way to make GPC recover some of this lag? Thanks Silvio a Beccara University of Trieste - Italy

4 5

Operator overloading troubles
by Neil Santos 26 Oct '04

26 Oct '04

I have a few questions regarding operator overloading. One, How do I forward-reference an operator redefinition? GPC complains when I leave out the parameter and result declarations in the actual definition: TRoot.epb:83: error: missing operator result variable TRoot.epb:83: error: result type of operator undefined TRoot.epb:83: error: operator must have two arguments If I can't do that, why not? Not being able to do that is awkward, when you're dealing with modules. Two, Why … [View More]

2 6

OO question re: private fields
by Neil Santos 26 Oct '04

26 Oct '04

Why can't I have a private field in a child that has the same name as a private field in an ancestor? I don't think there's going to be much difficulty determining which private field is referenced; UIM, it'll be similar to how `virtual' methods are traced. This is what I get while trying to do this: TException.eph:86: error: cannot overwrite data field `ObjectStructure' of parent object TException.eph:85: error: duplicate field `ObjectStructure' Using build 20040516 (binary distro). I'm … [View More]

4 7

function results in `with' statements
by Frank Heckenbach 23 Oct '04

23 Oct '04

Currently GPC allows function results in `with' statements, as in: program foo; type a = record b, c: Integer end; function f: a; begin f := a[b: 2; c: 3] end; begin with f do WriteLn (b, c); end. However, GPC currently also allows assignments to the components, such as: with f do b := 2 which is quite clearly wrong. Probably for this reasone, EP forbids function results in `with' statements at all (6.9.3.10: withÂelement = variableÂaccess | constantÂaccess.). I don't … [View More]

5 6

Re: gpc-20041017 released
by Prof A Olowofoyeku (The African Chief) 23 Oct '04

23 Oct '04

I have put the Mingw compiler through the testsuite. It passed everything, except for this: TEST pipetest.pas: cc1.exe: warnings being treated as errors ../units/pipesc.c: In function `_p_CPipe': ../units/pipesc.c:151: warning: passing arg 3 of `spawnve' from incompatible pointer type ../units/pipesc.c:151: warning: passing arg 4 of `spawnve' from incompatible pointer type ../units/pipesc.c: In function `pexecute': ../units/pipesc.c:471: warning: passing arg 3 of pointer to function from … [View More]

1 0

[Fwd: Re: gpc-20041017 released]
by Maurice Lombardi 21 Oct '04

21 Oct '04

-------- Message d'origine -------- Sujet: Re: gpc-20041017 released Date: Thu, 21 Oct 2004 16:34:27 +0200 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: cbfalconer(a)worldnet.att.net Références: <BC841B22-2079-11D9-A02D-000A27944772(a)microbizz.nl> <1098278943.2579.526904(a)goedel.fjf.gnu.de> <41779BAC.13355112(a)yahoo.com> CBFalconer a écrit: > Frank Heckenbach wrote: > >>Adriaan van Os wrote: >> >>>Frank Heckenbach wrote: &… [View More]

2 1

gpidump
by Adriaan van Os 19 Oct '04

19 Oct '04

Another problem - with most .gpi files, gpidump stops with the following error: gpidump: ... .gpi: unexpected flag `unused lang flag 1' I tried this with gpc-20030830 and gpc-20040516, both with gcc-3.3.2 on powerpc-apple-darwin. Regards, Adriaan van Os

5 9

Re: Brief comments / additions to docs
by Grant Jacobs 14 Oct '04

14 Oct '04

Excuse my slow reply - I'm flat-out at the moment. >Grant Jacobs wrote: > >> >Grant Jacobs wrote: >> > >> > > Debugging: >> >No, it isn't. Why do you think it should? `Exit' is BP compatible. >> >To stop the program use `Halt'. >> >> My screw up, sorry. I've never used BP, btw; exit in other languages >> exits the program. > >In C, yes. (I don't know about `exit' in other languages.) In this >case, I'd … [View More]rather follow BP and UCSD than C, since `Exit' to leave a >procedure is not really a misnomer. Just leave it - its just a name in the end. I was just explaining how I got confused. Most languages I know of use exit() to exit the program and return to leave a subroutine|procedure. I suspect for historical reasons languages that are (largely) Unix-based (e.g. perl, C, Unix shells) use exit(). Who knows...? > > I'll look at this again when I find time. I'd like to think I use a >> parameter in the routine though, it'd be a rather pointless parameter >> otherwise! > >Sure, and then the second error is clear (to me). But the first one >is more important, and if you don't get it, this would be a real >problem. One day...! Let's hope I remember. > > I think my confusion must have come from the fact that all other >> other descriptions other than that for rewrite (append, reset, etc.) >> say its optional. They do hint to read rewrite for more details. I.e. > > read alone (without reading the rewrite section) the descriptions for >> append, etc. would be misleading. The impression I got on reading the >> "for more details see rewrite", was that'd it'd be more of the same >> in more detail, not that'd there might be something that'd contradict >> the text preceding it. I'd be good to add a line: "If you're using >> untyped files, the last parameter is essential; see rewrite for >> details." to the descriptions for reset, append, etc. > >OK, I understand the confusion. I'll try to clarify things in the >next release. Ta. Hopefully it'll spare someone else the trouble. > > > > Macro expansion of __FILE__ seems to be inconsistent. In cases it >> > > expands to a full path and in others to just the local filename. It >> >> seems to be that if the file is in the local directory compared to >> >> the main program being compiled, just the filename is returned; if >> >> the source file is in another directory, a full path is returned. >> > >> >What do you suggest? Always a full path? >> > > I'd prefer a full path as that has all the info. Its easy enough to >> get a substring for the bits, etc. > >OK, I'll change that. Sounds good! >Anyway it should be possible to define C macros to the same effect, >such as: > >#if defined (__STDC__) || defined (ALMOST_STDC) >#define CONCAT2(a,b) a##b >#else >#define CONCAT2(a,b) a/**/b >#endif I was meaning varargs in particular, not macros in general (hope I'm reading you correctly.). I've got debugging macros in place already. I tried porting the ones I use in C code, but they have varags, so I've re-worked them as far as I could. >Making such a macro compatible to a new >Pascal macro will then also be a one-time setup, so it's acceptable >I hope. No chance you can allow the user to define a preprocessor as a command-line option, then anyone who wants to can feed the code through the C (or other) preprocessor? This could have a other uses to people who want their code preprocessed by their own means. Reminds me I wrote a Pascal preprocessor. Forget why, though! (I'm thinking in part here that although I can currently do push a single source file though the preprocessor, to compile a whole project like by first preprocessing it, I'd have to compile everything to .o files, then link them as I won't have access to pulling in things via 'uses' the way the Pascal compiler does. It'd be better for the compiler to feed each source code through my choice of pre-processor on my behalf. Follow my meaning?) > > About varargs in macros. I don't mind that varargs might be too much >> work (fair enough - there aren't enough hours in the day to do the > > things I want to either), but saying that debugging writes aren't a >> good enough use to justify varargs to me is not so valid... Like >> debugging, testing and verification isn't important enough...?! > >I didn't mean to imply this (since I put a lot of work into >maintaining GPC's test suite myself). I had hoped not :-) >Rather I'm still thinking of alternatives, and how the effort >required compares with implementing varargs macros (though, as I >said, I'm not sure yet, how much effort the latter will be, perhaps >it'll turn out rather easy). Of course you can always define >`DebugWrite1', `DebugWrite2', ... As I'm sure you already know, one of the key uses for varargs is so that you can blindly pass on argument lists without having to consider their syntax, e.g. the arguments to printf (in C). Two quick C e.g.s (not tested, based on e.g.s in Harbinson & Steele and what I recall off the top of my head my own use of them): #ifdef DEBUG #define DebugPrint(...) \ printf( debugFile, "%s %s %s > ", __FILE__, __LINE__, timestamp() ) \ printf( debugFile, __VARARGS__ ) ; printf( debugFile, "\n" ) ; #else #define DebugPrint(...) #end #define ArgList2String(...) #__VARARGS__ The reason I'm dropping these in is that they might be a couple of useful e.g.s to try test out your ideas on macros. Probably not much help, but... >I'm looking for ways to achieve a general form with the existing >capabilities. Unfortunately I haven't found any so far. The >direction I'm thinking along is something like > >{$define DebugWrite(X) WriteLn X} > >i.e. `DebugWrite ((foo, bar, baz))' -> `WriteLn (foo, bar,baz)' >(just an extra pair of parentheses needed). Unfortunately, you >probably don't want to write debug information to `Output' and I see >no way to get a file parameter in that macro expansion ... > >So varargs macros might be justified in the end, but I'm still >waiting for other arguments for both sides ... I'll try put my thinking cap in this. Jog my memory if I forget. Personally I'd plug for you popping in user-defined pre-processing options into gpc, then you're covered either way. >BTW, about the C syntax, what does `__VA_ARGS__' actually stand for? >I'm wondering if (if we do it in the end) we shouldn't allow to >define a parameter name for the varargs instead of having such an >(ugly IMHO) "magic" name. Not sure precisely, but most likely something along the lines of VARiable (number of) ARGumentS. Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 478 0095 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. [View Less]

2 1

ignore-garbage-after-dot
by Adriaan van Os 14 Oct '04

14 Oct '04

The gpc manual states: --ignore-garbage-after-dot Ignore anything after the terminating ‘.’ (default in ‘--borland-pascal’). However, the following testprogram: {$ignore-garbage-after-dot} program Test; begin end. blabla #include <sys/types.h> results in: garbage.p:6: no include path in which to find sys/types.h So, this looks like a preprocessor problem. Regards, Adriaan van Os

4 4

ANNOUNCEMENT: ODBC unit
by Markus Gerwinski 11 Oct '04

11 Oct '04

Hi Folks, the GNU Application Libraries for Pascal (GNUALP) framework has grown. After multithreading, it now also provides database access. As a default implementation, there is an ODBC unit available. The tarballs can be downloaded from http://www.markus.gerwinski.de/gnualp/. To run the ODBC part, you will have to install gnualp-0.1.5.tar.gz first, then gnualpodbc-0.1.1.tar.gz. Both projects can be installed, as usual, with ./configure, make, make install. To run the demo program(s) in the … [View More]

1 0

Gnu Pascal on Fedora/Red Hat
by Paul Igodt 09 Oct '04

09 Oct '04

Hello - where has www.gnu-pascal.de gone? It seems to be down? - I downloaded (couple of weeks ago) binaries for a Gnu Pascal installation on a Fedora Core 2, Intel processor, machine. (This is a sort of Red Hat Linux, fairly standard linux?). - After installation, I could not test yet enough, but anyhow, one of the pascal programmes which I wanted to compile (and in fact compiles under gpc on Cygwin), doesn't finish too well: upon gpc -o dbase --automake -I/usr/… [View More]

2 1

wchar
by Markus Gerwinski 08 Oct '04

08 Oct '04

Hello, does GPC have a data type that corresponds to the wchar_t data type of gcc? If not, is there an easy way to port it and make sure it always has the same size as in gcc? Yours, Markus

6 21

Better Pascal mode for Emacs?
by Neil Santos 08 Oct '04

08 Oct '04

I've been trying to switch to using GNU Emacs while writing Pascal code, but the Pascal mode shipped with GNUmacs 21.2 is... let's just say, `not up to the task'. Google-ing for one wasn't much help--none of the projects I've checked support Extended or Object Pascal properly (most don't support them at all). So, I'd like to ask if anyone here has found/written a Pascal mode for Emacs that supports most (if not all) of the Pascal dialects supported by GNU Pascal, and, if so, where I could … [View More]

3 4

Re: Brief comments / additions to docs
by Grant Jacobs 08 Oct '04

08 Oct '04

>Grant Jacobs wrote: > > > Debugging: >No, it isn't. Why do you think it should? `Exit' is BP compatible. >To stop the program use `Halt'. My screw up, sorry. I've never used BP, btw; exit in other languages exits the program. > > It would be good to see a more sensible error message generated when >> the compiler detects a missing parameter in the interface vs. >> implementation definitions of a proc/fn, e.g. >> >> if you have: >> &… [View More]gt;> interface >> >> function string_eq( str1, str2 : string; ) : boolean ; >> >> implementation >> >> function string_eq( str1, str2 : string; >> caseSensitive : boolean ): boolean ; >> begin >> ... >> end ; >> >> You get >> >> undeclared identifier `caseSensitive' (first use in this routine) > >Well, what *I* (since you say "you" ;-) You know I'm not using that as a personal pronoun! ;-) >actually get (after filling >in the missing parts and fixing the obvious syntax error) is this: > routine definition does not match previous declaration > -> previous declaration > >If you use `caseSensitive' within the body of `string_eq' (which you >didn't show in the `...') you might get that other message because >the second (wrong) redeclaration of the function is ignored, but the >first error message is the important one. If you don't get this, >please report with a full example (compilable code, compiler >version, etc., as usual). I'll look at this again when I find time. I'd like to think I use a parameter in the routine though, it'd be a rather pointless parameter otherwise! > > If you do a rewrite() or reset(), do nothing with the file, but >> forget to close the file(s) before ending the program, malloc >> complains about a "deallocation of a pointer not yet allocated". I >> presume the post-execution mop-up doesn't handle unused files well -- >> ? > >Again, *I* don't. A testing example (see above) would really help. I didn't, or I'd have said so ;-) I only added the close() and the message went away. More to the point the usual things apply: I'm flat out so it'll be a while to get an example together as it'll take a while to reduce to a small e.g. (its part of a lot of code). I'm in the middle of chunk of Perl/JavaScript/CSS/HTML stuff so I don't want to further confuse my mind by going back to Pascal until this current project is done. (I don't know about other people but I find when jumping between languages too much I write an idiom from another language accidently once in a while which does no good at all. ) But hopefully I get back to it... >From the docs: > >: The last optional parameter determines the block size of the file. >: It is valid only for untyped files. Often 1 is a reasonable value here. >: However, the existence of this parameter is a BP compatibility feature, >: and in BP it defaults to 128 because of historic misdesign. Therefore, >: GPC requires this parameter to be present. In `--borland-pascal' mode, >: it makes it optional (like BP does), but warns about the strange >: default if omitted. I think my confusion must have come from the fact that all other other descriptions other than that for rewrite (append, reset, etc.) say its optional. They do hint to read rewrite for more details. I.e. read alone (without reading the rewrite section) the descriptions for append, etc. would be misleading. The impression I got on reading the "for more details see rewrite", was that'd it'd be more of the same in more detail, not that'd there might be something that'd contradict the text preceding it. I'd be good to add a line: "If you're using untyped files, the last parameter is essential; see rewrite for details." to the descriptions for reset, append, etc. BTW, I must sound like I'm nitpicking (which I hate). I can't contribute easily to the docs as I'm not familiar with all the Pascal variants that have emerged and that GPC supports in various ways. All I can do is pick up the odd bit that throws me for whatever reason. > > Macro expansion of __FILE__ seems to be inconsistent. In cases it > > expands to a full path and in others to just the local filename. It >> seems to be that if the file is in the local directory compared to >> the main program being compiled, just the filename is returned; if >> the source file is in another directory, a full path is returned. > >What do you suggest? Always a full path? I'd prefer a full path as that has all the info. Its easy enough to get a substring for the bits, etc. > > While there is a CurrentRoutineName there is no CurrentUnitName. It'd >> be useful to have this for debugging writes, to indicate which source >> file to look for a routine in. > >For this purpose __FILE__ would seem more useful (think of include >files), I think. True ;-) In that case I'd definitely prefer a full path for __FILE__ (think: alternative build directories, libraries, etc.) > > [Fussy one] Macros can't do C99's >> #define many_arg_fn(...) some_fn( __VA_ARGS__ ) >> trick. The GNU C compiler does support this & its very useful for >> debugging writes (which, in turn, are useful for test-driven >> development). > >I plan to rewrite the preprocessor, and deal with macro facilities >in this course. For one thing, I'll surely not try hard to be C >compatible (e.g., I plan to replace that `##' stuff with something >more readable). I haven't had varargs macros on my list so far, but >I might consider them. Any other comments? If debugging writes are >the only use, I'm not sure they're justified well enough. (But I'd >also have to see how hard it is to implement them.) I'll differ with you on this on :-) :-- I like the compatibility with C as it aids porting to/from C. As you know macros are very much a part of a lot of C code, etc. I dislike changes purely for cosmetics if it forces changes on existing code for no practical gain. I know C-style macros are ugly and can be fiddly to code, but for me there is practicality in gpc current macro's compatibility (to whatever degree) with their C counterparts. To be fair, I suppose I could rig things up to put my code through the C pre-processor... About varargs in macros. I don't mind that varargs might be too much work (fair enough - there aren't enough hours in the day to do the things I want to either), but saying that debugging writes aren't a good enough use to justify varargs to me is not so valid... Like debugging, testing and verification isn't important enough...?! I don't want to say too much without trying to work around their absence again, but I presume you've used varargs in this context to understand why its useful? (macros to mimic write/writeln which take multiple args are much easier, etc.) My own use of them in C is to generate output for testing scripts to compare against (code verification). These tests remain as a test suite, etc. Without varargs the output a bit limited. (more accurately it takes too much time to make all the write's needed to generate the output, so you're inclined to skimp on debugging/testing writes). That, in turn, limits the amount of testing material generated and the sensitivity of the testing material. Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 478 0095 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. [View Less]

2 1

Re: GPC and Threads
by Jose Pascual 07 Oct '04

07 Oct '04

Hi Markus, first of all thank for you answer. > Jose Pascual wrote: > > I'm working in port some of my little application to linux. > All of my > > application has been writting in pascal. My porting to > linux is going > > ok but some of them use threads. > > > > I have read in GPC lists there are people working in a > thread unit for > > GPC, aren't you? > > Yep. great! > > Could someone share this unit with me? I could help … [View More]

15 117

Brief comments / additions to docs
by Grant Jacobs 06 Oct '04

06 Oct '04

Here are a few random things I've spotted from a recent round of programming in GPC. (BTW - I know macros aren't part of Pascal, but they are useful, especially if you are porting code to/from C). Excuse me if any of these overlap with things previously covered - I haven't been following the list as I'm too busy of late. Debugging: If your source code is in multiple source files as units (or modules? - I've only tested for units), there is no need to specify the source filename as the … [View More]GDB man pages suggest (e.g. break is defined as 'break [file:]function'). Just give the function/procedure name. Don't forget to make the first letter of the procedure/function identifier in uppercase - gpc adopts this (odd!) convention to avoid name-space conflicts with C and system libraries. Might be worth adding this to the docs - ? In my hands Exit doesn't seem to so much terminate the program as the proc/fn or the unit. Haven't tested this - I just gave up using it - but it certainly isn't stopping the program. (!) It would be good to see a more sensible error message generated when the compiler detects a missing parameter in the interface vs. implementation definitions of a proc/fn, e.g. if you have: interface function string_eq( str1, str2 : string; ) : boolean ; implementation function string_eq( str1, str2 : string; caseSensitive : boolean ): boolean ; begin ... end ; You get undeclared identifier `caseSensitive' (first use in this routine) rather than some sort of interface/implementation definition mis-match error. Its *very* confusing if you're down in the body of the unit looking at the source code for the function itself as its certainly present there and there is nothing to clue you into looking at the interface definition. If you do a rewrite() or reset(), do nothing with the file, but forget to close the file(s) before ending the program, malloc complains about a "deallocation of a pointer not yet allocated". I presume the post-execution mop-up doesn't handle unused files well -- ? Reset() and rewrite() insist on the buffer size parameter rather than defaulting if an untyped file is used. OK, you can just set it to 1, but its not consistent with the definition of the procedures in the docs which indicate [to me!] that this is optional. Macro expansion of __FILE__ seems to be inconsistent. In cases it expands to a full path and in others to just the local filename. It seems to be that if the file is in the local directory compared to the main program being compiled, just the filename is returned; if the source file is in another directory, a full path is returned. While there is a CurrentRoutineName there is no CurrentUnitName. It'd be useful to have this for debugging writes, to indicate which source file to look for a routine in. [Fussy one] Macros can't do C99's #define many_arg_fn(...) some_fn( __VA_ARGS__ ) trick. The GNU C compiler does support this & its very useful for debugging writes (which, in turn, are useful for test-driven development). Just keeping you on your toes ;-) Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 478 0095 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. [View Less]

2 1

Re: Overloads ?
by Waldek Hebisch 06 Oct '04

06 Oct '04

I have not seen Borland specs, but it seems that I independently arrived at similar rules. Let me consider few cases. Simplest is exact match overload -- types of arguments match exactly function arguments. I think we want to allow all such overloads. For example: type month_no = 1..12; servo_pos = 0..1000; for month_no modular increment may be more natural, for servo_pos intement should "stuck" at max value (both are differnt that normal increment). In general, we may want to have … [View More]

1 0

gpc/carbonlib (os x) question
by P. George 05 Oct '04

05 Oct '04

i'm using gpc (on the commandline, not in mw) in os x. i need to call a carbon library function. the following line doesn't work: {$L /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon} when i try to compile with: gpc testcarb.pas -o testcarb ... i get: testcarb.pas:6: error: file `/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon' must be compiled not sure what that means or what i can do about it. thanks. - philip

3 6

Where is the web-server?
by Miklos Cserzo 05 Oct '04

05 Oct '04

Hi Folks, the www.gnu-pascal.de site is down. Where can I find the downloads? When it will be fixed? Cheers, miklos

2 1

scanner, was 'Unused parameter warnings'
by Ernst-Ludwig Bohnen 04 Oct '04

04 Oct '04

Hallo, I followed the long discussion concerning 'Unused parameter warnings' and put my personal sulution for scanning files and strings to: http://www.desy.de/~bohnen/gpc/units1/scanner.pas Other units needed for compilation can be found on the same directory. Ernst-Ludwig

1 0

building GPC toolchain. Large Files Support.
by Igor Marnat 22 Sep '04

22 Sep '04

Hello dear list! I'm building GPC for arm-elf target. In the source directory in files p/rts/configure.in and rts.h options "_LARGEFILE64_SOURCE" and "_FILE_OFFSET_BITS 64" are hardcoded. Is it really necessary? Is it possible to build GPC without large file support as it doesn't make sense for embedded platforms? It doesn't depend of version of GPC sources. Best regards, Igor Marnat mailto:marny@rambler.ru

3 9

Alternative download sites for gpc?
by Francesco Bonomi 21 Sep '04

21 Sep '04

Dear friends, While www.gnu-pascal.de is down (and I hope the job to bring it up again is not too hard) does anyone know of abother download site that is not too outdated? I am searching for documetnation and binaries, but all I find is VERY old stuff. thanks Francesco Bonomi

4 6

Upper/lower case in identifiers
by Tom Schneider 20 Sep '04

20 Sep '04

program capbug(output); (* capbug: capitalization bug in gpc compiler Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ *) const (* begin module version *) version = 1.00; (* of capbug.p 2004 Sep 10 2004 Sep 10, 1.00: origin *) (* … [View More]end module version *) (* begin module describe.capbug *) (* name capbug: capitalization bug in gpc compiler synopsis capbug(output: out) files output: messages to the user description Demonstrate capitals bug in GPC. The name of a local procedure is objected to by GPC if there is a global by the same name but different capitalization. In theory the compiler should keep track of what is local and what is global anyway, so it should be able to avoid this. It is a problem because if one imports procedures from another program, they are not being treated as pure 'black boxes'. Instead, local variable names are being compared to the global variable names. In otherwords, the scope rule of Pascal is being violated when these warnings are generated. This problem is not fixed by adding the flag: -Widentifier-case-local Warn about an identifier written with varying case within one program/module/unit. examples gpc 20040516, based on gcc-3.3.3 for this program itself gives: capbug.p:113: warning: capitalisation of `x' doesn't match capbug.p:111: warning: previous capitalisation `X' capbug.p:113: warning: capitalisation of `y' doesn't match capbug.p:111: warning: previous capitalisation `Y' capbug.p: In procedure `themain': capbug.p:138: warning: capitalisation of `X' doesn't match capbug.p:113: warning: previous capitalisation `x' capbug.p:139: warning: capitalisation of `Y' doesn't match capbug.p:113: warning: previous capitalisation `y' The result is: capbug 1.00 outside: x = 1 outside: y = 2 inside: x = 3 inside: y = 4 themain: X = 5 themain: Y = 6 which demonstrates that the scope rules are being followed when the progrm runs, because X and Y are set before the calls to routines outside and inside, but they are not affected by those calls. That is, the outside and inside routines have local variables. documentation see also {Manual on GPC that gives the -Widentifier-case-local flag:} http://www.gnu-pascal.de/gpc/GPC-Command-Line-Options.html {Discussion on the topic, "Upper/lower case in identifiers":} http://www.gnu-pascal.de/crystal/gpc/en/raw-mail7665.html author Thomas Dana Schneider bugs technical notes *) (* end module describe.capbug *) var X, Y: integer; (* global X and Y *) procedure outside(x, y: integer); (* an outside procedure *) begin x := 1; y := 2; writeln(output,'outside: x = ',x:1); writeln(output,'outside: y = ',y:1); end; (* begin module capbug.themain *) procedure themain; (* the main procedure of the program *) procedure inside(x, y: integer); (* an inside procedure *) begin x := 3; y := 4; writeln(output,'inside: x = ',x:1); writeln(output,'inside: y = ',y:1); end; begin writeln(output,'capbug ',version:4:2); X := 5; Y := 6; outside(X, Y); inside(X, Y); writeln(output,'themain: X = ',X:1); writeln(output,'themain: Y = ',Y:1); end; (* end module capbug.themain *) begin themain; end. [View Less]

12 30

www.gnu-pascal.de not available
by Eike Lange 18 Sep '04

18 Sep '04

Hi Folks! Due to some misunderstandings is our GPC server not available. Please be patient. Eike -- http://www.gnushi.de

2 2

boolean functions as conditions
by Artur Kornilowicz 17 Sep '04

17 Sep '04

Hello, I think gpc does not work properly when one gives a boolean function as a condition in repeat until loop. Please find an example below. I tested it on 2 different machines working under Linux and Darwin. When you change repeat until F1(a,b); by repeat x := F1(a,b); until x; in procedure F2, then it works. Greetings Artur program tester; function F1(a,b : string):boolean; begin writeln('F1(',a,',',b,')',length(a),' ',length(b)); F1:=true; end; procedure F2(a,b : string)… [View More]

4 3

Re: GPC: daily digest V1 #541
by Tom Schneider 13 Sep '04

13 Sep '04

Frank Heckenbach wrote: > It may be natural for some. I actually prefer it the way it is, i.e. > I prefer to use the same spelling (capitalization) throughout. So if > you or someone else implements the other way (which is indeed more > work), it should at least be optional. What you prefer is not representative of what others prefer. Testing for case matching is already optional, given that there is a flag. > BTW, calling it a bug is a bit strange, anyway. In Pascal, even &… [View More]gt; occurrences of an identifier referring to the same declaration can > have different capitalizations; the same applies to different > declarations (e.g., local vs. global) as well. Therefore, all this > is an optional warning, not an error. It is not a Pascal bug in the sense that the program will still compile correctly since Pascal accepts any capitalization. However, it is a bug in GPC in the sense that the compiler treats the variables inconsistently. FUnCtiOnaLLy iT dOEs nOt MATteR, but for consistency it does. Frank Heckenbach wrote: > Waldek Hebisch wrote: > > I belive that capitalization is meaningfull for people. > I don't really. In natural language, capitalization is used as a > help in reading (used differently in different languages), but it > does not carry meaning itself (e.g., a text written in all-caps > still has the same meaning). It carries meaning to PEOPLE but not to the compiler (for the purpose of creating a binary). Especially in German it means that the word is either the beginning of a sentence or a noun, right? Are there cases in German - I bet you could find or make some! - where the meaning of the sentence changes dramatically if you were to change the case of a noun? This was discussed earlier, here's an example http://www.gnu-pascal.de/crystal/gpc/en/mail7664.html where in 2003 (!) Russell Whitaker wrote: > Irregardless of either Case Checking or Warning messages, I would like > to see the compiler output identifiers exactly as they appear in the > offending source line. As it is now the compiler outputs 'Gothere' when > the source could have been either 'gotHere' or 'goThere'. > (bad pun intended). Got Here is quite different from Go There! So the capitalization within a single identifier name CAN carry meaning. A person wanting to use both of these would be FLABerGASted that they could not. (Sorry about that, it just apPEARed and now you've got me going!). > - Short identifiers such as `x' vs. `X'. These names are not > actually meaningful anyway. No. X could represent Xavier, Y could be Yanni. > Tom Schneider wrote: > http://www.lecb.ncifcrf.gov/~toms/delila/module.html > ftp://ftp.ncifcrf.gov/pub/delila/moddef A point I forgot to mention is that, of course, using the module program I transfer chunks of text between programs. The current rules force me to have a single way of capitalization. FOR EXAMPLE. I am a molecular biologist, so the letters A, C, G and T have great significance. In some programs I might want to capitalize these to fit the convention in molecular biology. But in another piece of the code I may decide that 'c' is to be the name of a character read in. These would be distinct uses with different scopes. But the GPC compiler demands that I use the same rule for both. Essentially that means that I should forget about capitalization entirely or have my arm twisted every once in a while. Irrelevant warnings that I can't get rid of make it MUCH more difficult to locate the important warnings! The difficulty came up when I was preparing my 200-some programs for other people. When they compile the code they will trip over EVERY unnecessary warning. They will write me email every time, wondering what is wrong. I just got some! I would have to tell them not to worry about that. But in case there is a REAL problem, I have to check every time ... Worse, if one of my students decides to write code, I have to worry about what they have done in modules that I'm NOT working on. Suppose I ask them to write a procedure for me and they pick a "non-standard" capitalization that doesn't match something I'm doing? Or suppose I want to use a sorting routine from someone else? I should be able to plug their procedure or function into my program and have it run without warnings. Saying that I should use external files is NOT A SOLUTION because there is no standard that all compliers use for reading such files and if I used that approach, I would have to keep modifying code to switch compilers. I (and you now) already have the system-independent module transfer mechanism so there is no reason to go back to system-dependency. (GPC is essentially a system dependency since there are other compilers that exist. But, by the way, I'm going for using GPC as my main compiler now thanks to all of you folks and because the Sun Pascal compiler has been dropped.) Tom Verhoeff wrote: > I recently recompiled a project containing some seven thousand lines > of Pascal code distributed over some twenty units. A couple of years > ago when it was last compiled, gpc didn't have the identifier-case > checking feature. During the recent recompile, I was overwhelmed with > casing complaints. Some of them were legitimate: same variable referred > to by different casings. And I changed the source accordingly. But many > warnings were completely unexpected for me, and unwarranted. This is similar to what happened to me. I just upgraded from the 1999 version of GPC to 2004 and suddenly had hundreds of WARnings. (Using capitals in varIouS odd ways in a sentence could be an art form to create double MEANings.) Waldek Hebisch wrote: > 3) Many tools are easier to use as case sensitive ones (simple example > is global regex search&replace) Yes. This is why the GPC convention of capitalizing the first letter of an identifier when giving errors or warnings is painful. One can't use the capitalization. Indeed, the error/warning should always be using the current capitalization string! (This is a separate issue from the scope problem, but it also trips me up repeatedly since I like to use cut and paste to do searches in vi/vim.) > > The compiler already keeps track of scope for each variable. So > > keeping one copy of an identifier just (apparently) reveals > > Again: The warning is about *identifiers* (including keywords > actually), not about *declarations* (and it doesn't claim > otherwise). Fine. Any constant, type, variable, procedure, function name ... Frank Heckenbach wrote: > > that the > > GPC code is not efficient. > > Not really. This way, the capitalization can be checked right after > a word (identifier or keyword) is recognized. When doing it after > distinguishing between keywords and various kinds of declarations, > there would be more places to add the checks. You of course know the compiler guts and I don't. But what you are saying implies that the mechanisms for capitalization checking and scope checking are separated. In that sense the compiler appears not to be efficient. Frank Heckenbach wrote: > > In other words, the warning code could > > (should!) use the code already used for tracking the scope. > > As I said, I prefer to check the capitalization of identifiers. If > you prefer to check the capitalization of declarations, go ahead and > implement it (optionally). It's free software. But please contact > Waldek before about the details to avoid conflicts with his > qualified identifier changes. It's a matter of doing it right. I am not the best person to do this as I have not written the code in the first place. Frank Heckenbach wrote: > Because I don't see a "case sensitive interpretation" of Pascal > code. > > There may be other Pascal compilers which are case-sensitive, which > is obviously non-standard. Our general attitude to non-standard > compilers is to be at best backwards-compatible, which this warning > surely makes it. If there were (theoretically) a compiler that understood case with scope correctly, then this current design would not be compatible. Frank Heckenbach wrote: > > I recently recompiled a project containing some seven thousand lines > > of Pascal code distributed over some twenty units. A couple of years > > ago when it was last compiled, gpc didn't have the identifier-case > > checking feature. During the recent recompile, I was overwhelmed with > > casing complaints. Some of them were legitimate: same variable referred > > to by different casings. > > Again, Pascal isn't concerned with the capitalization of identifiers > referring to the same declaration any more than it is with that of > identifiers referring to different declarations. If you consider one > thing more "legitimate" than the other, that's your opinion, but > please don't state it as a fact. No, he means that some of the warnings were appropriate and some were not, according to the scope of the variable. The inappropriate ones get in the way of finding the legitimate ones. Frank Heckenbach wrote: > Well, I was about to write "these comparisons go too far" before I > read this paragraph, but now it's really too much! Emotions in a > Pascal program, eh? ;-) EMOTIONS ARE USED IN TEXT! (SorryForYelling.) Haven't you ever embedded something like that into your code? Frank Heckenbach wrote: > Let's stick to Pascal based arguments, perhaps? This is NOT a "Pascal" issue. It is a GPC issue. I think that we all agre that in the language Pascal itself, case is not relevant. The issue here is about programmers and what happens when they attempt to use capitalization to help them understand AND DOCUMENT the code better. If the capitalization does not follow the scope rules of the identifiers, then the programmer will OFTEN have trouble. Frank Heckenbach wrote: > > You forgot: > > - NamesConsistingOfMultipleWords (most frequent in my experience) > True. But using different concatenations resulting in the same > identifier (such as `FooBar' and `FoobAr' -- I know there are real > examples of this, I just don't have them in mind right now) is There's the case I mentioned above: http://www.gnu-pascal.de/crystal/gpc/en/mail7664.html Frank Heckenbach wrote: > asking for trouble in a case-insensitive language. In C, you can do > this and get away with it. In Pascal, sooner or later, you might use > those names in the same scope and get a conflict. No. If they are within the same scope, then there SHOULD be a conflict. Frank Heckenbach wrote: > So even here, I > prefer the current behaviour which warns me as soon as possible and > lets me choose another name for one of the things. No, that forces one to have a uniform capitalization scheme across the program. Then, for me and my students, we must have one across my lab. If I send you procedures, then you must follow OUR scheme. So ultimateLy, to avoId conflicTs, yOu muSt follOw oUr capitalizatiOn scheMe, whiCh, In thIs sentenCe, Is To capitaliZe tHe secoNd To laSt charactEr Of eveRy woRd ;-0. Frank Heckenbach wrote: > > - conventions like: > > globals capitalized, locals lowercase > > or > > agregates capitalized, scalars lowercase > > IMHO these are archaic conventions, coming from languages such as C > (where there's only one global and one local level, in contrast to > Pascal which has arbitrarily many levels, and a local variable of > level 1 can behave like a global variable, seen from a routine at > level 2, etc.), and assembler (where there's a general difference > between aggregates and scalars). So I don't care much for such > conventions. That misses the point. Within a chunk of code it may be appropriate to use a particular convention. The code that I was working on that started this discussion uses a series of X and Y variables to create a color density plotting program: http://www.lecb.ncifcrf.gov/~toms/delila/denplo.html using: cat denplo.p |\ wordlist |\ egrep 'X|Y' |\ sort |\ uniq |\ fmt |\ cat I got the variables: SymbolSizeX SymbolSizeY X XDisplayIntervals XDisplaySubIntervals XaxisLabel Xbin Xbinmax Xbinmin Xcolumn Xcorner Xhi Xin XinCount Xintervals Xlo XmaxValue XminValue Xminvalue XoutCount Xrange Xsize Xvalue Y YDisplayIntervals YDisplaySubIntervals YaxisLabel Ybin Ybinmax Ybinmin Ycolumn Ycorner Yhi Yin YinCount Yintervals Ylo YmaxValue YminValue Yminvalue YoutCount Yrange Ysize Yvalue graphXintervals graphYintervals jumpX jumpY keyX keyXsize keyY keyYsize nextX nextY shiftX shiftY shrinkfactorX shrinkfactorY startX startY tryX tryY As you can see from looking over this list, the X and Y capitalization really helps to distinguish the variables. It was very good that the compiler detected these (THANK YOU) as it allowed me to straighten out some incorrect ones. The convention helps me to tell which are the X and Y variables. The collision was with a lower case x and y nicely scoped into local variables in a procedure. To avoid other users of the code getting the inappropriate warning (and sending me email about it!), I was forced to change them to capitals. Frank Heckenbach wrote: > > And we should divide programmers into two groups, one that does not > > care about capitalization and the second that cares. The first group > > produces lot of meaningless variation, but they are irrelevant for > > the discussion since they wish no warning. The second group IMHO > > is much more likely to associate meaning with capitalization. > > So do I, yet I prefer to avoid different capitalizations of the same > identifier (see above). That's fine, but it does not suit everyone, and you apparently haven't run into a condition where there would be a conflict. Frank Heckenbach wrote: > So is the lack of `endif', and a few other things IMHO. We can't > change the fundamentals of Pascal, I'm afraid. Agreed! But this discussion is not about changing the fundamentals of Pascal. It's about changing how GFP reacts to case inconsistency when it is requested to check for case consistency. Programmers will expect the case usage to match the scope of the variable. Regards, Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/ ps: Sorry if I messed up some of the attributions! [View Less]

3 3

Re: GPC: daily digest V1 #540
by Tom Schneider 11 Sep '04

11 Sep '04

Waldek Hebisch wrote: > Note that your program consted of a single module (in other words it > contained just main program, without EP modules or units). I started writing in Pascal years before GPC and my programs have survived transition through four different Pascal compilers. When I started the CDC Pascal compiler had an insertion mechanism. I soon realized that this would cause me trouble in giving my programs to others, so I wrote a program in Pascal that does code insertion: … [View More]

1 0

GPC downloads are confusing
by Tom Schneider 09 Sep '04

09 Sep '04

Folks: We just upgraded to v. 2.1 (20020510). It turns out that this is the intermediate version that has a bug with the page() function. I handle this in my compile script by turning off the demand for standard Pascal, which leaves me slightly vulnerable to non-standard things creeping into my code by accident. On http://www.gnu-pascal.de/current/ is gpc-20020510.tar.gz which I think my sysadmin used. But that page also has gpc-2.1.tar.gz which seems to be more recent.… [View More]

3 2

Mac OS X Pascal Interfaces for GNU Pascal
by Adriaan van Os 09 Sep '04

09 Sep '04

Peter N. Lewis and Gale Paeper have been working hard on the Mac OS X Pascal Interfaces for GNU Pascal. The results are impressive: - added 59 new units, to a total of 268 units and 197731 lines of Pascal - added CFSTR support - added support for four char code constants - added compatible Interfaces for MetroWerks Pascal. The software can be downloaded from <http://www.microbizz.nl/gpc.html>. Detailed release notes are included. Regards, The Mac OS X Pascal Interfaces team: Peter … [View More]

6 9

A bug in passing strings by value
by Adam Naumowicz 07 Sep '04

07 Sep '04

Hi, I've just noticed that there is a bug in the string assignment if a string is passed by value to a procedure and then assigned to. See the excerpt below, the length of "a" after the assignment is still 1. I'm using: adamn@linux:~/pascal/bug/gpc>gpc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/specs Configured with: ../gcc-3.3.1/configure --enable-languages=pascal Thread model: posix gpc version 20040516, based on gcc-3.3.1 ------------------------… [View More]

2 3

mySQL
by Adriaan van Os 24 Aug '04

24 Aug '04

From <http://www.gnu-pascal.de/contrib/eike/> I downloaded GPC interfaces to mySQL, contributed by Eike Lange - thanks Eike for contributing them. With some necessary changes, I got things working on Mac OS X. > { This unit interfaces MySQL libs. > Copyright (C) 2003 by Eike Lange > Author: Eike Lange <eike(a)g-n-u.de> > > This unit is free software; you can redistribute it and/or modify > it under the terms of the GNU Library General Public License as … [View More]

4 13

GTK-unit
by David Righart 21 Aug '04

21 Aug '04

Arpa Intrabouw I am using Cygwin GPC version 20030830 and Red Hat Linux GPC version 20030830. Last week I downloaded GtkUnits-20010602.tar.gz from Nicola but I can't compile it. The tag asmname is used in the units which I replaced with external name. Does the tag asmname not work with GPC? Now, the linker is complaining with errors. Maybe the units are to old to use with this version of GPC? Is there a newer version of GPC GTK-units? Can anyone help me using Gtk under GPC?? Regards, David.

3 2

Dev Pascal (Bloodshed)
by Ian Miller 14 Aug '04

14 Aug '04

Hi, I know this isn't strictly a GPC question, but I thought someone here might be able to help with this: I recently installed the following version of Dev Pascal from gnu-pascal.de, under Windows XP:- Dev+GNU Pascal 1.94.2 + GPC 20040516 + Mingw runtimes + GCC support files (9.8mb: Win32 GUI self-extracting installer; 29 May 2004) The problem I am getting is that I am not able to click on compilation error message in the Compiler window at the bottom to take me to the corresponding line … [View More]

4 7

Stabs and line-numbers
by Adriaan van Os 13 Aug '04

13 Aug '04

I were doing some tests with SLINE line-numbers in stabs debugging info and it appeared to me that line-numbers in gpc version 20040516 (based on gcc-3.3.2) are less accurate than they were in gpc version 20030830 (based on gcc-3.3.2). Maybe there have been changes to the parser ? I could give a detailed example of course, if needed. Regards, Adriaan van Os

2 1

gpc on Mac OS X notes
by Adriaan van Os 07 Aug '04

07 Aug '04

The following relates to using gpc on Mac OS X with the tools that come with "Xcode 1.5" ------------------------------------------------------------------------ --- 1. There was a report that gpc issues the following error message: 'gpc: installation problem, cannot exec `c++filt3': No such file or directory" The Xcode installer doesn't install c++filt3, I reported this as a bug to Apple. The obvious solution is to type the following on the terminal command line: [G4:~] adriaan% … [View More]

1 0

position independent code generation
by Igor Marnat 03 Aug '04

03 Aug '04

Hello dear List! I use GPC for ARM7TDMI processor working under uCLinux of 2.26 version. I would like to use -fpic option to decrease memory usage (my filesystem lies in SDRAM so load program to RAM is just memory waste), but when I start program built with -fpic, it tells me "undefined instruction". I searched via the mail list but it seems to me that there is no great interest to this problem (I mean -fpic usage). I use arm-elf-gcc (2.95.3) and arm-elf-gpc (20021111) built together. It's a … [View More]

1 0

gpc-20040516 released
by Frank Heckenbach 22 Jul '04

22 Jul '04

I have uploaded a new beta version of GPC to <http://www.gnu-pascal.de/beta/>. This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work. Waldek Hebisch and I are currently working on some larger changes, including qualified identifiers, range checking and support for gcc-3.4.0. An alpha version with these changes, which might be less stable, will probably be … [View More]released in a few weeks. BUILD NOTE: If you modify the GPC sources, you now need bison-1.875c and flex-2.5.27 (<http://lex.sourceforge.net>) to rebuild. These versions must be matched exactly. Newer flex versions, in particular 2.5.31, might work as well, but contain a known unportability, so I did not test them, and I recommend 2.5.27. (Other programs such as yacc and lex instead of bison and flex also will not do.) I have included the files generated by bison and flex in the distribution (also in the "minimal" distribution), so you should not need these tools when you only want to build GPC. NOTE: The `Pipe' unit was renamed to `Pipes' because of a name conflict. Unfortunately, this requires a small change to all programs that use this unit. New features: * arithmetic expressions now work as lower array/subrange bounds (fjf248.pas, fjf293.pas, fjf336.pas, fjf346a.pas, fjf622.pas) * records/objects with many fields are processed faster * parameters of procedural types now support Standard Pascal procedural parameters, conformant/open arrays and `type of' inquiries (fjf939*.pas) * empty parameter lists can be written as `()' (chief54*.pas, delphi6*.pas) (D) * GMP unit: `mpf_sin', `mpf_cos' * the test suite output is now by default stored in DejaGnu compatible files `gpc.log' and `gpc.sum' in the `p/test/' directory; other available test targets are `pascal.check-short' and `pascal.check-long' (@) * new options `-W[no-]dynamic-arrays' (fjf931*.pas) * new argument to `_p_initialize' (@) * new function `UMask' * new option `--no-debug-source' * new lexer (no directly user-visible difference, but should allow for better handling of lexer-based problems in the future) Fixed bugs: * `pow' and `**' are really EP conformant now (in particular `x pow y' and `x ** y' are an error if x = 0 and y <= 0) (emil27*.pas) * `protected var' parameters must only accept references (unlike `const' parameters) (gale5*.pas) * `pack' must not pack the component type of arrays (fjf940[b-e].pas) * in some circumstances packed fields were allowed as `var' parameters (fjf940a.pas) * bugs with nonlocal gotos out of routines declaring file variables (nonloc*.pas) (fix involved a change in the internal representation of file variables) * 'foo'#42 must not be rejected in `--borland-pascal' (chief53.pas) * `--implementation-only' didn't work correctly (bo4-19.pas) * messages referring to object methods now point to the method declaration rather than the end of the object type declaration * initializers for types containing nested schemata now work (fjf914*.pas) * various smaller bugs 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: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 [View Less]

11 50

Re: problem building GPC 20040516 on AIX - continued
by Gert Doering 21 Jul '04

21 Jul '04

Hi, On Wed, Jun 16, 2004 at 08:30:38PM +0200, Frank Heckenbach wrote: > Gert Doering wrote: > > > I'm trying to build the gpc-20040516 "beta" snapshopt with GCC-3.3.x on > > AIX 5.1. GCC-3.x itself supports AIX 5, I have a working version on > > the system (binary install, not compiled-it-myself). [..] > > the line 511 is this one: > > > > TARGET_CPU_CPP_BUILTINS (); > > > > ...which fully escapes me as for why it might not … [View More]compile...!?? [..] > Unless you need very particular system conditionals (Pascal programs > usually don't), just insert the line > > #define rs6000_cpu_cpp_builtins(foo) > > in lang.c. Thanks for your quick reply. Unfortunately, I didn't see it before today because my spam filter didn't know about the GNU Pascal list yet (all e-mails with unknown To:/CC: headers are quarantained as "maybe spam". Stupid me.) I will try this approach over the weekend. In the meantime, I tried something else - gcc-3.2.3 with gpc-20040516, again on AIX 5.1 and additionally on AIX 5.2 (in case AIX 5.1 is broken). The effect is quite different here. It builds all of xgpc and the libgpc.a just fine, but then crashes in trying to build "binobj". The error is this: gmake[2]: Entering directory `/s1/gpc-build/gcc/p/utils' ../.././xgpc -B../.././ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" collect2: library libgpc not found gmake[2]: *** [binobj] Error 1 gmake[2]: Leaving directory `/s1/gpc-build/gcc/p/utils' gmake[1]: *** [pascal.utils] Error 2 gmake[1]: Leaving directory `/s1/gpc-build/gcc' If I change the -B invocation to use an absolute path, the library is found, but the (AIX) ld doesn't really like the result either: ../.././xgpc -B/s1/gpc-build/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status I've checked with "nm", and it looks like all the stuff should be there: gd@hilb3:/s1/gpc-build/gcc/p/utils> nm ../../libgpc.a | grep Tempdir Tempdirectory.1 U - Tempdirectory.1 d 37956 8 Tempdirectory.1.P8 d 37952 4 Tempdirectoryset.0 d 37948 4 Since I had the nagging suspicion that there might be something in the pascal libraries that the system ld doesn't understand, I tried installing the GNU binutils, ./configure'd again, and rebuilt. Built bombed in libgcc (gcc created stuff that gas didn't like). Removed gas, ./configure'd again, rebuilt. Same error as above (collect2 not finding libgpc). Trying again with absolute paths and GNU ld linked into the "-B" directory as "real-ld" led to a new error: ../.././xgpc -B/gnulocal/src/gcc-3.2.3/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/rts --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempdirectory.1' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempstr.4' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Buffer.8' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Zero.3' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Epoch.6' collect2: ld returned 1 exit status (the -B path is different from the example above, because it's a different system - the other one doesn't have the GNU binutils installed yet - but don't let that confuse you) --> so it seems that actually the library itself has unresolved symbols, and not the "binobj.pas" program it tries to link. "ranlib" doesn't help either. Any further ideas how to tackle this? The whole symbol format confuses me - being a C programmer, I'm used to errors about "_crypt" not found, but not without a "_" and neither with trailing numbers... thanks again, gert -- Gert Doering gd(a)medat.de MEDAT Muenchen Tel: 089/126808-0 Fax: -50 [View Less]

4 19

www.gnu-pascal.de up again
by Eike Lange 19 Jul '04

19 Jul '04

Hi Folks! The server is up again. Latest uptime was 394 days :-) The mainboard becomes too warm or the BIOS detects the wrong temperature. However, if you are a "contributor" with files on this server, please make a private backup. I'm going to backup the complete files to a cdrom. If someone would like to contribute a new server hardware, you are welcome. ;-) Please send me a private mail in this case. Eike -- http://www.gnushi.de

1 0

www.gnu-pascal.de down!
by Eike Lange 18 Jul '04

18 Jul '04

Hi folks! Currently our GPC-Server is down. As I do not know the reason, I cannot tell you the time to fix. I hope it will be soon. Yours Eike -- http://www.gnushi.de/

1 0

ANNOUNCEMENT: Unit for multithreading (and some more stuff)
by Markus Gerwinski 18 Jul '04

18 Jul '04

Markus Gerwinski proudly presents: GNU Application Libraries for Pascal, in short GNUALP, pre-release 0.1.4. The current status of the package contains units for - exception handling, - standard collection types (lists, hashtables etc.), - system time and calendar functions, - and last but not least: multithreading. You can download a tarball with the current sources from http://www.markus.gerwinski.de/gnualp/gnualp-0.1.4.tar.gz. The library is tested on SuSE Linux 8.0, 9.1, and … [View More]Windows XP with MinGW. You can install the tarball just the usual way, i.e. unpack it into your source directory, then run "./configure", "make", "make install", and everything will be in place. The API units will then be installed to a directory named /usr/local/units/gnualp-0.1. This also generates a shared library, libgnualp.so, which you'll have to link against. E.g. to compile a program foo.pas which uses the GNUALP library units, your gpc compiler call will have to look like this: gpc --automake --unit-path=/usr/local/units/gnualp-0.1 foo.pas -o foo -lgnualp This library is work under development and far from being complete, so it is all undocumented up to now. However, since several folks seemed to have a pressing urge for multithreading, I'll give a short introduction here on how to use the resp. features of the library: - Include `AlpThreads' into the uses clause of your program. Declare any threads you want to start as vars of type `pThread'. - To run some simple procedure as a thread, give it a parameter list like this: Procedure doingSomething ( thread: pThread; data: pointer ); You can then from anywhere in the program create a thread object for this procedure with the following statement: someThread:= new ( pSimpleThread, start ( doingSomething, nil ) ); The thread then starts running immediately and will automatically dispose itself after it is ready. It can be stopped from within the doingSomething procedure using the command `thread^.stop'. In this case, it will also dispose itself. For more sophisticated thread handling, derive an object type from the abstract tThread type and override the `work' method to do whatever the thread is supposed to do; if need be, you can also override the `cleanup' method. This one's always executed at the end of the thread, no matter if it was regularly ended or `stop'ped in-between. - Mutexes and semaphores are represented by the tMutex and tSemaphore object types. To create e.g. a mutex, just call mutex:= new ( pMutex, init ); To lock the mutex, call `mutex^.lock'; to unlock it, call `mutex^.unlock'. To dispose it after use, call `dispose ( mutex, fini )'. Just as simple. :-) Semaphores work in an analogous way; they only require an integer parameter in their constructor to determine the maximum count of threads they may be accessed by. For usage examples, see the files simplethreads.pas, mutexes.pas, and semaphores.pas in the demos/pas subdirectory of the gnualp package. They aren't documented or commented either, since I've only set them up as a test for myself, but I hope the code isn't too difficult to read. :-} Regards, Markus [View Less]

1 0

gpc+gcc-3.3.4
by Russell Whitaker 18 Jul '04

18 Jul '04

Hi downloaded gcc-3.3.4 today. building gcc-20040516 with Waldek's Make-lang.in patch, configure --enable-languages=c,c++,pascal test results: Unsupported: regextest.pas # of tests 3910 # of expected passes 3909 # of unsupported tests 1 gpc version 20040516, based on gcc-3.3.4 Good. Thanks, Russ

4 5

gpc-20040516, Mingw, gcc-3.4.1, and update27h.diff #2
by Prof A Olowofoyeku (The African Chief) 17 Jul '04

17 Jul '04

Hi again Following on my earlier post, I have discovered something else. "pascal.install" did not install "gpc1.exe". I had to copy it manually to its correct location. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

GPC and Threads
by Jose Pascual 15 Jul '04

15 Jul '04

Hi, I'm working in port some of my little application to linux. All of my application has been writting in pascal. My porting to linux is going ok but some of them use threads. I have read in GPC lists there are people working in a thread unit for GPC, aren't you? Could someone share this unit with me? I could help to debugging it. thank you so much best regards Jose Pascual

2 1

Out of town
by Frank Heckenbach 14 Jul '04

14 Jul '04

I'll be out of town for 2 1/2 weeks. I'll probably read and perhaps reply to email occasionally, but don't expect timely reponses from me ... As far as the integer type are concerned, I hope the discussion will be finished until I return (if there's anything more to say), so I can then make the necessary changes. 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: … [View More]

1 0

gpc-20040516 for AMD64 (Linux)
by Prof A Olowofoyeku (The African Chief) 12 Jul '04

12 Jul '04

Hi I have built gpc-20040516 for AMD64 (platform: Fedora Core 2, 64-bit). Binaries can be obtained here: http://gnu-pascal.de/contrib/chief/fedora-2/ Built and tested on an Athlon-64 3.2+, the testsuite ran fine, except for these: TEST asmtest.pas: SKIPPED: only for IA32 TEST az20.pas: ./test_run: line 334: 4929 Segmentation fault ./"$A_OUT" "$1" TEST confarr5.pas: ./test_run: line 334: 9516 Segmentation fault ./"$A_OUT" "$1" TEST fjf746.pas: ./test_run: line 334: 14662 … [View More]

6 29

Integers
by Prof. Harley Flanders 12 Jul '04

12 Jul '04

Tower of Babel! It later grows higher to CUnsignedLongLongLong, CUnsignedLongLongLongLong,... Ugh! The "C-like" names are makeshift and awful, with no room for expansion. Whatever the names are forced to be by historical considerations, why not the simple alternative nomenclature: Signed: Unsigned: Int8 UnsInt8 Int16 UnsInt16 Int32 UnsInt32 Int64 UnsInt64 Int128 UnsInt128 Int256 UbsInt256 ...... ......... With these names you … [View More]

2 1

gpc 20040516 binary on suse 9.x
by Matthias Schweinoch 12 Jul '04

12 Jul '04

hi all, i tried the gpc binary (20040516 with gcc backend, i686 pc linux) on my debian woody box, and it ran smooth. i then tried to get that same package running on a suse linux box (running 9.1, i believe), and this is what it gives me when i try to compile the very same pascal program that worked on my debian box: --- output starts --- uhle@linux:~> gpc kreis3.p /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/libgpc.a(rts.o)(.text+0x 5e3): In function `_p_UpCase': /home/frank/gpc/gcc-3.… [View More]

4 3

Re: page function
by Tom Schneider 11 Jul '04

11 Jul '04

Thanks Emil and Frank for clarifying the page function issue. > http://www.gnu-pascal.de/gpc/Page.html > as "Page is an ISO 10206 Extended Pascal extension." | Yes, the GPC docs are wrong, `page' is ISO 7185. I see that this is still there - is there a mechanism for making sure it gets fixed? Also, it would be very useful to have the ISO definitions listed all on one page and for the url given above and all others in the documentation to point to the definitions page. (A script could … [View More]

2 1

Bad stabs
by Adriaan van Os 10 Jul '04

10 Jul '04

The output below from objdump suggests that stabs debugging info from gpc is broken. Does this happen on other platforms also ? Regards, Adriaan van Os ------- [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c hello.pas -g [G4:~/gnu/testgpc/adriaan] adriaan% objdump -g hello.o hello.o: file format mach-o-be Bad stab: Datevalid:(0,5)=@s8;- 16;,0,1;Timevalid:(0,5),1,1;Year:(0,1),2,32;Month:(0,6)=r(0,1);1;12;,34, 4;Day:(0,7)=r(0,1);1;31;,38,5;Dayofweek:(0,8)=r(0,1);0;6;,43,3;Hour:(0,9 )=… [View More]r(0,1);0;23;,46,5;Minute:(0,10)=r(0,1);0;59;,51,6;Second:(0,11)=r(0,1) ;0;61;,57,6;Microsecond:(0,12)=r(0,1);0;999999;,63,20;Timezone:(0,1),83, 32;Dst:(0,5),115,1;Tzname1:(0,13)=s44Capacity:(0,14)=r(0,14);00000000000 00;0037777777777;,0,32;length:(0,14),32,32;_p_Schema_:(0,15)=ar(0,1);1;3 3;(0,2),64,264;;,128,352;Tzname2:(0,16)=s44Capacity:(0,14),0,32;length:( 0,14),32,32;_p_Schema_:(0,17)=ar(0,1);1;33;(0,2),64,264;;,480,352;; Last stabs entries before error: n_type n_desc n_value string SO 0 0000000000000000 /Users/adriaan/gnu/testgpc/adriaan/ SO 0 0000000000000000 hello.pas OPT 0 0000000000000000 gcc2_compiled. LSYM 0 0000000000000000 integer:t(0,1)=r(0,1);-2147483648;2147483647; LSYM 0 0000000000000000 char:t(0,2)=@s8;-20; LSYM 0 0000000000000000 Complex:t(0,3)=R4;16;0; LSYM 0 0000000000000000 Timestamp:t(0,4)=s104Datevalid:(0,5)=@s8;- 16;,0,1;Timevalid:(0,5),1,1;Year:(0,1),2,32;Month:(0,6)=r(0,1);1;12;,34, 4;Day:(0,7)=r(0,1);1;31;,38,5;Dayofweek:(0,8)=r(0,1);0;6;,43,3;Hour:(0,9 )=r(0,1);0;23;,46,5;Minute:(0,10)=r(0,1);0;59;,51,6;Second:(0,11)=r(0,1) ;0;61;,57,6;Microsecond:(0,12)=r(0,1);0;999999;,63,20;Timezone:(0,1),83, 32;Dst:(0,5),115,1;Tzname1:(0,13)=s44Capacity:(0,14)=r(0,14);00000000000 00;0037777777777;,0,32;length:(0,14),32,32;_p_Schema_:(0,15)=ar(0,1);1;3 3;(0,2),64,264;;,128,352;Tzname2:(0,16)=s44Capacity:(0,14),0,32;length:( 0,14),32,32;_p_Schema_:(0,17)=ar(0,1);1;33;(0,2),64,264;;,480,352;; [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs Configured with: ../gpc-332d1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, based on gcc-3.3.2 [G4:~/gnu/testgpc/adriaan] adriaan% objdump -v GNU objdump 2.13.90 20030128 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. [View Less]

4 10

AIX again
by Frank Heckenbach 10 Jul '04

10 Jul '04

More good news: A problem with `for' loops that I found in 2001 with gcc-2.95.x is apparently also fixed in gcc-3.3.3. So we can put this in statements.c to disable a work-around and perhaps produce slightly better code for `for' loops: #ifdef EGCS97 #define FOR_BUG_OK #endif 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: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

page function
by Tom Schneider 09 Jul '04

09 Jul '04

Hi folks: I'm using GNU Pascal version 20000707, based on gcc-2.95.2 19991024 (release). Copyright (C) 1987, 1989, 1992-2000 Free Software Foundation, Inc. while my student Ryan is using: GNU Pascal version 2.1 (20020510), based on gcc-2.95.3 20010315 (release). Copyright (C) 1987-2002 Free Software Foundation, Inc. I have no problem compiling with gpc --standard-pascal \ --transparent-file-names \ --no-mixed-comments \ -O0 \ -Wall \ $program.p -o $… [View More]

3 2

Compiling unit gives ld error
by Frank Brooks 08 Jul '04

08 Jul '04

I am running gpc version 20030830, based on gcc-3.3.2 on Mac OS 10.3. When attmpting to compile any unit, I get the following error: /usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status Any way for me to solve this problem by RTFM? I apologize if I missed it in my (as yet) futile but lengthy search of the GPC mail archive/documentation. Thanks so much, Frank

2 1

Gcc-3.4 & gpc II
by David Kredba 08 Jul '04

08 Jul '04

Hello. I ran into another problem. gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -fno-common -pedantic -Wno-long-long -o xgpc p/gpc.o prefix.o version.o \ intl.o ../libiberty/libiberty.a gcc -o p/diagnostic.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-… [View More]common -DHAVE_CONFIG_H -I. -Ip -I../../gcc-3.4-20040702/gcc -I../../gcc-3.4-20040702/gcc/p -I../../gcc-3.4-20040702/gcc/../include -DGPC ../../gcc-3.4-20040702/gcc/diagnostic.c echo "expect 16 shift/reduce and 30 reduce/reduce conflicts" >&2 expect 16 shift/reduce and 30 reduce/reduce conflicts cd ../../gcc-3.4-20040702/gcc/p && bison -o parse.c parse.y parse.y: conflicts: 16 shift/reduce, 295 reduce/reduce gcc -o p/parse.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -pedantic -Wno-long-long -I. -Ip -I../../gcc-3.4-20040702/gcc -I../../gcc-3.4-20040702/gcc/p -I../../gcc-3.4-20040702/gcc/../include -DGPC -DGPC_UNITS_DIR=\"/opt/gcc-3.4/lib/gcc/i686-pc-linux-gnu/3.4.1/units\" -I../../gcc-3.4-20040702/gcc/p ../../gcc-3.4-20040702/gcc/p/parse.c parse.c:380: warning: useless keyword or type name in empty declaration parse.c:380: warning: empty declaration parse.c: In function `yydoAction': parse.c:8160: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c:8160: error: (Each undeclared identifier is reported only once parse.c:8160: error: for each function it appears in.) parse.c: In function `yyglrReduce': parse.c:8276: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yysplitStack': parse.c:8314: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveStates': parse.c:8413: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveAction': parse.c:8444: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyprocessOneStack': parse.c:8637: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.y: At top level: parse.y:2837: warning: `locations' defined but not used make[2]: *** [p/parse.o] Error 1 make[2]: Leaving directory `/home/dave2/gcc/gcc-3.4/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/dave2/gcc/gcc-3.4/gcc' make: *** [bootstrap] Error 2 I use Gentoo 2004.1 default bison : bison -V bison (GNU Bison) 1.875 Thanks, David -- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024D/5B6B02DE Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE [View Less]

2 2

Gcc-3.4 & gpc
by David Kredba 08 Jul '04

08 Jul '04

Hello. I am trying to get gcc-3.4 working with gpc. I use gcc-3.4-20040702 and gpc-20040516. I ran : dave2@srv1 p $ patch -p2 < ../../update27h.diff cd ../../gcc-3.4-20040702 dave2@srv1 gcc-3.4-20040702 $ patch -p1 < ../gcc-3.4.diff8 I got one reject : patching file gcc/expr.c Hunk #2 succeeded at 5081 (offset 1 line). Hunk #3 succeeded at 5118 (offset 1 line). Hunk #4 succeeded at 5133 (offset 1 line). Hunk #5 FAILED at 5148. Hunk #6 succeeded at 5202 (offset 1 line). Hunk #7 … [View More]succeeded at 5584 (offset 1 line). 1 out of 7 hunks FAILED -- saving rejects to file gcc/expr.c.rej cd .. mkdir gcc-3.4 cd gcc-3.4 ../gcc-3.4-20040702/configure --prefix=/opt/gcc-3.4 --enable-shared --enable-threads=posix --enable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,ada,f77,objc,java,pascal --with-system-zlib make bootstrap && make -k -C gcc gnatlib_and_tools && make -k check <snip> gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.4-20040702/gcc -I../../gcc-3.4-20040702/gcc/. -I../../gcc-3.4-20040702/gcc/../include ../../gcc-3.4-20040702/gcc/c-common.c -o c-common.o ../../gcc-3.4-20040702/gcc/p/mk_lang_opt < ../../gcc-3.4-20040702/gcc/p/opts.sum > "../../gcc-3.4-20040702/gcc/p/lang.opt" /bin/sh: line 1: ../../gcc-3.4-20040702/gcc/p/mk_lang_opt: Přístup odmítnut make[2]: *** [../../gcc-3.4-20040702/gcc/p/lang.opt] Error 126 make[2]: Leaving directory `/home/dave2/gcc/gcc-3.4/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/dave2/gcc/gcc-3.4/gcc' make: *** [bootstrap] Error 2 There is lang.opt file with 0 Byte size in gcc-3.4-20040702/gcc/p folder. Mk_lang_opt has no executable flag. I ran tar xzf to unpack gpc archive an diffs to gpc and gcc. If I set executable flag to mk_lang_opt file, build process continues. I had never unpack gpc tarball with p option, like tar xzpf gpc-20040516.tar.gz and build process always works fine. I can see that mk_lang_opt comes from update27h.diff, so tar xzpf to gpc tarball is not needed. I don`t now if patch can set executable flag to mk_lang_opt file but I think that not. Is executable flag really on mk_lang_opt file needed to bootstrap compiler or I am doing some error ? Thanks very much, David -- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024D/5B6B02DE Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE [View Less]

1 0

gpc+gcc-3.4.1
by Russell Whitaker 06 Jul '04

06 Jul '04

Hi gcc-3.4.1 was released July 1. Should I try building gpc with it at this time? Thanks, Russ

2 1

Re: problem with writeln (or program
by Mingeborg＠aol.com 02 Jul '04

02 Jul '04

How embarrassing - -O -W -Wall indeed found the problem with the program. Thank you very much! - Inga In a message dated 7/1/2004 10:13:57 PM Eastern Daylight Time, Frank Heckenbach <ih8mj(a)fjf.gnu.de> writes: >What do you mean with register values? Assembler level registers? Of >course, almost every operation changes them. Pascal variables? If >they have a defined value, an operation without side-effects on them >shouldn't change them, of course. (Otherwise it's in fact … [View More]

1 0

problem with writeln (or program bug?)
by Mingeborg＠aol.com 02 Jul '04

02 Jul '04

Enclosed is a gzipped tar file containing program ind.p (298 lines.) As is, the program goes into infinite recursion, but it works correctly if you comment out a âwritelnâ statement on line 248, (the statement before ***************...) (gpc-20040516, Linux running on a Pentium 4 laptop.) I apologize for the size of the example, but I have been unable to reproduce the problem with a smaller example, and I don't understand what is happening. The following are lines 238 â 249 of the … [View More]

2 1

Re: GPC on AMD Opteron?
by Mingeborg＠aol.com 26 Jun '04

26 Jun '04

Thanks for the help! - Inga In a message dated 6/26/2004 2:33:39 AM Eastern Daylight Time, chiefsoft(a)bigfoot.com writes: > > On 25 Jun 2004 at 19:06, Mingeborg(a)aol.com wrote: > > > Does GPC compile on AMD Opteron processors (64 bit, GNU/Linux)? > > > > I saw in the archives that it's been done for Athlon processors, > > presumably that means, "yes"? Are there any caveats? > > I easily built a version for Fedora Core 2 for AMD64. There > is … [View More]

1 0

GPC on AMD Opteron?
by Mingeborg＠aol.com 26 Jun '04

26 Jun '04

Does GPC compile on AMD Opteron processors (64 bit, GNU/Linux)? I saw in the archives that it's been done for Athlon processors, presumably that means, "yes"? Are there any caveats? Thanks, - Inga

2 1

Re: GPC on AMD Opteron?
by Mingeborg＠aol.com 25 Jun '04

25 Jun '04

Thanks a lot, - Inga In a message dated 6/25/2004 7:15:41 PM Eastern Daylight Time, georges(a)its.caltech.edu writes: > > I assume you mean native AMD64? > > Yes it does (I recently repackaged a new wersion for Gentoo and tested it on > amd64). There doesn't seem to be anything special, just follow the > instructions. You can also take a look at the ebuild, > http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-lang/gpc/gpc-20040516.ebuild > which essentially contains … [View More]

1 0

recursion problem
by Mingeborg＠aol.com 24 Jun '04

24 Jun '04

I am getting a recursion problem I don't understand. (gpc-20040516, LINUX on a Pentium 4 laptop.) This is a (silly) example program (enclosed as a gzipped tar file.): program subset_problem(input,output); const setlimit = 4; type subset = set of 0..255; var seta, setb: subset; function recursive_setprint(set1: subset):subset; var i : integer; found : boolean; returned : boolean; begin if set1 <> [] then begin i:= 0; found := false; while ((i <= … [View More]

4 4

Re: recursion problem
by Mingeborg＠aol.com 23 Jun '04

23 Jun '04

Yes, it works. (That was an incredible turnaround time.) Thank you very much! - Inga In a message dated 6/22/2004 7:34:08 PM Eastern Daylight Time, ih8mj(a)fjf.gnu.de writes: > Thanks for the report. The attached patch will fix it. (inga1*.pas) > > 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: 51FF C1F0 1A77 C6C2 4482 … [View More]

1 0

Re: recursion problem
by Mingeborg＠aol.com 22 Jun '04

22 Jun '04

Thanks for verifying this so quickly! - Inga In a message dated 6/22/2004 5:35:05 PM Eastern Daylight Time, chiefsoft(a)bigfoot.com writes: > > On 22 Jun 2004 at 16:45, Mingeborg(a)aol.com wrote: > > > I am getting a recursion problem I don't understand. (gpc-20040516, > > LINUX on a Pentium 4 laptop.) > > > > This is a (silly) example program (enclosed as a gzipped tar file.): > > > > program subset_problem(input,output); > > const … [View More]

1 0

Re: GP 0.55 - limitations
by Waldek Hebisch 21 Jun '04

21 Jun '04

Can GP handle imports in implementation part? I can easily compile `tpyacc' using automake, but GP fails: /pom/kompi/gcc/tst26/gp-0.55/gp PC='/pom/kompi/gcc/tst26/gpc7-3.4/gcc/xgpc' -B/pom/kompi/gcc/tst26/gpc7-3.4/gcc/ --no-default-paths -O3 lex.pas /pom/kompi/gcc/tst26/tt2/p1/tply41a/lexmsgs.pas:99: error: module/unit interface `LexBase' could not be imported lexmsgs.gpd: GNU Pascal Preliminary Dependency File, Version 1 K 2 P x86_64-unknown-linux-gnu V 20040516, based on gcc-3.4.0 O -O3 g /… [View More]

2 1

threads status in GPC
by Igor Marnat 20 Jun '04

20 Jun '04

Dear All! As I have already read in archives, thread support in GPC is missing now. I know that I can "feel free to implement it myself" but, unfortunately, I am rather a compiler user than a creator, I'm not a such guru (at least, for the time being). Anyway, I've already built the program in GPC using pthreads library (using modules on C as an interface to pthreads library) and it works (at first glance). As far as I know, one of the potential damages with multithreaded programs written in … [View More]

8 19

ORB bindings for Pascal?
by Neil Santos 17 Jun '04

17 Jun '04

Does anybody know anyone working on ORB bindings for Pascal? I've looked into the omniORB project, but they don't support Pascal. Other ORB projects support Delphi, but I don't know if that could be dropped into a, eherm, virginal Pascal project. I'm interested in tying an ORB implementation into my project; any pointers as to where I should start looking would be greatly appreciated. Google hates me at the moment, for some reason, and would not accomodate me, no matter how much poking and … [View More]

1 0

problem building GPC-
by Gert Doering 16 Jun '04

16 Jun '04

Hi, I'm trying to build the gpc-20040516 "beta" snapshopt with GCC-3.3.x on AIX 5.1. GCC-3.x itself supports AIX 5, I have a working version on the system (binary install, not compiled-it-myself). I tried gcc-3.3.3 and gcc-3.3.1, and followed the INSTALL instructions, using a separate build directory, configuring with /gnulocal/src/gpc-build> /gnulocal/src/gcc-3.3.x/configure --enable-languages=pascal --prefix=/gnulocal which went well, including patching the respective compiler (tried … [View More]

2 1

Re: Questions about pointers
by Neil Santos 14 Jun '04

14 Jun '04

On 08:32 14/06/04, Peter N Lewis wrote: > >Yes, of course. My sincerest apologies. > > Not at all required. Pointer are a very confusing subject, in fact I > wrote an article on the subject for MacTech ages back (though it was > targeted more at specific Mac issues). > > I hope my post was useful. Yes, it was. I changed the implementation so that each object would just hold an instance of a TBank, instead of having to pass a PCredit to a TBank's constructor. … [View More]

1 0

porting Digital Pascal to Gnu Pascal - modules
by Mingeborg＠aol.com 13 Jun '04

13 Jun '04

Iâm a (fairly) new Pascal user, and I am trying to help a friend port a Digital Pascal application to GNU. I am now looking at one of two âbig (?)â programs, which contains about 3000-4000 functions/procedures in about 40 modules. Currently, this is organized as follows: There is one âenvironmentâ module (which every other module âinherits,â) containing type definitions, global variables, and a list of â[global]â functions and procedures, declared (here) as âexternalâ. … [View More]

4 3

Re: porting Digital Pascal to Gnu Pascal -
by Mingeborg＠aol.com 13 Jun '04

13 Jun '04

Yes, that works - thank you very much! - Inga >Try moving the `uses' to the implementation part. (You can remove >the attribute then, it won't hurt, but it's rather superfluous.) >If there are any types and constants used by several interfaces, you >can put them in a kind of `env' unit. >Frank

1 0

Re: porting Digital Pascal to Gnu Pascal -
by Mingeborg＠aol.com 13 Jun '04

13 Jun '04

Thank you for looking at this, and sorry if this question is really silly, but I don't understand your directions. If I make the following kind of changes to all modules: unit env; interface procedure proc1;external name 'proc1'; procedure proc2;external name 'proc2'; procedure proc3;external name 'proc3'; implementation end. unit unit3; interface uses env; procedure proc3; attribute (name = 'proc3'); implementation procedure proc3; begin writeln("running proc3"); proc1;… [View More]

2 1

Questions about pointers
by Neil Santos 13 Jun '04

13 Jun '04

While testing a few ideas with pointers, I bumped into a behavior not very clear to me. During the development of one of the modules I'll be using in a project of mine, there came a point where I decided I'll simply assign the address of a pointer variable passed as a paramater as the value of one of an object's fields. While writing the code for the said object's destructor, I decided to test what would happen to the variable, whose address I've assigned to an object's field, after I've … [View More]

4 7

Re: porting Digital Pascal to Gnu Pascal - modules
by Mingeborg＠aol.com 13 Jun '04

13 Jun '04

Thank you for looking at this. I am enclosing a gzipped tar file of 5 very small example files, (test.tar.gz.) This is the example code: unit env; interface procedure proc1;external; procedure proc2;external; procedure proc3;external; implementation end. unit unit1; interface uses env; procedure proc1; implementation procedure proc1; begin writeln("running proc1"); end; end. unit unit2; interface uses env; procedure proc2; implementation procedure proc2; … [View More]begin writeln("running proc2"); end; end. unit unit3; interface uses env; procedure proc3; implementation procedure proc3; begin writeln("running proc3"); proc1; proc2; end; end. program main; uses unit1, unit2, unit3; begin proc1; proc2; proc3; end. Digital Pascal allows this "structure" of the code via [global] modules, and this code worked in the last release. In the current release, I am getting the following error messages: > gpc --automake -o main main.p unit3.o(.text+0x52): In function `Proc3': : undefined reference to `proc1' unit3.o(.text+0x57): In function `Proc3': : undefined reference to `proc2' collect2: ld returned 1 exit status Before I start completely re-orgarnizing 3000+ modules, I would like to have confirmation that there currently is no alternative. Thanks, - Inga Mingeborg(a)aol.com wrote: > I have tried using the unit / uses syntax, (specifying that each unit âusesâ > this environment module,) but I still cannot get these units linked. The > compiler is complaining about several hundreds of âundefined referencesâI > am now assuming that it is expecting the âimportedâ modules to contain the > code for all of the procs/funcs called by each unit, rather than just the > âexternalâ definition. Is this correct, or might I be misunderstanding what > is happening? (I am currently running gpc-20040516, gcc-3.3.3, on Suse > Linux. I had previously run some tests using the last Gnu Pascal release > system running on cygwin.) > > I am hoping to avoid having to analyze dependencies and completely > re-organize the modules. Is there any other way? I don't know if you've already got an answer, so here's mine: Could you send a detailed error message from the compiler? It's especially interesting which references remain unresolved. My guess is that you are using some of the GPC standard units, and that you didn't add the according linking statements to the command line. For example, if you're compiling a source that "uses Crt", your command line will have to look like this: gpc foo.pas -o foo -lncurses -lpanel ... since crt.pas is based upon the shared libraries libncurses and libpanel. Regards, Markus [View Less]

1 0

Re: threads status in GPC
by Paul Davidson 07 Jun '04

07 Jun '04

However, I'm currently working on a (pthread-based) standard unit for GPC multithreading, so if you aren't in a hurry, maybe I can offer you a solution within a few weeks. :-) Please!

1 0

--language=Pascal
by Adriaan van Os 03 Jun '04

03 Jun '04

The question rises whether Pascal is written with an uppercase "p" or not [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c --language=Pascal hello.pas [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c --language=pascal hello.pas gpc: language pascal not recognized So, gpc expects an uppercase "p". On the other hand: - ada, fortran and c are written in all lowercase (see the man pages for gcc) - gdb writes Pascal lowercase - gp writes "--pascal=OPTION" lowercase. Because of this, it came to a surprise … [View More]

3 3

Version information
by Frank Thomas Braun 03 Jun '04

03 Jun '04

Could anybody kindly uodate the Webpage http://www.gnu-pascal.de/gpc/Current-version.html#Current%20version Frank BraunFrank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany Tel.: +49-941-943-4891 email: frank.braun(a)rz.uni-regensburg.de

2 1

GP
by Frank Heckenbach 02 Jun '04

02 Jun '04

I've put a new version of GP with the minor changes discussed here at <http://gnu-pascal.de/contrib/frank/misc/gp-0.55.tar.gz>. 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: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

13 45

Installation problem with gpc (djgpp, Windows XP)
by Frank Thomas Braun 01 Jun '04

01 Jun '04

I am working successfully with a gpc installation from 2002 and wanted to update to the current version. So I downloaded from "GNU Pascal download area: Current" / binaries / DJGPP (http://www.gnu-pascal.de/binary/djgpp/) all files. After unzipping and a successful installation (gpc -v is working) a try to compile even simple files results in: D:\xxy>gpc HALLO.PAS gpc.exe: Internal GPC problem: internal option `--amtmpfile' not given I read and followed any instructions of http://… [View More]

3 7

Re: gpascal (was: cgp? (was: GP ;-))
by Tom Verhoeff 01 Jun '04

01 Jun '04

And what about gpascal This is slightly longer, but leaves (almost) nothing to the imagination. We don't need a c in the name for compiler, do we? Tom

1 0

GNU Modula 2 binary for MinGW searched
by Gerrit P. Haase 31 May '04

31 May '04

Hello, I'm looking for a binary package of GNU Modula 2 for MinGW, is there one available? Gerrit -- =^..^=

1 0

Module madness
by Neil Santos 31 May '04

31 May '04

Hi guys. I've been scratching my head for about two hours now, trying to figure out what kind of incantation I need to do in order to compile a module whose interface and implementation sections reside in different files. -STOP- Okay, I've composed two other mails before this (with the first couple of paragraphs being part of the second), and I've finally found what I needed. It turns out that, in order to compile a module that has its interface and implementation sections in two different … [View More]

5 9

gp-0.54 released
by Frank Heckenbach 28 May '04

28 May '04

I have uploaded the first public beta version of GP to <http://gnu-pascal.de/contrib/frank/misc/gp-0.54.tar.gz>. GP is a utility to automate the building of Pascal programs using the GPC compiler. It is the intended replacement for GNU Pascal's problematic automake feature. If you have been using automake, please try building with GP instead. When GP works sufficiently, it will be included with GPC in one of the next releases, and automake support will later be dropped from GPC. If you … [View More]only ever used GPC without automake (e.g., using self-written Makefiles or otherwise manually) and do not plan otherwise, you probably do not need GP. Please read the included files REAMD and INSTALL, as usual. The GP Manual is contained in `gp.info' which you can read with any info reader. You can also make a printable documentation with `make dvi' if you have texi2dvi installed or `make pdf' using texi2pdf. Quick start: * Use `gp' instead of `gpc --automake --executable-file-name'. Most other GPC options can be used the same way with GP. * If the source file given on the command line is a unit or module, GP recognizes this automatically and does not try to link it, so you don't have to give the option `-c'. * If your compilers are not called `gpc' and `gcc' you can set `PC' and `CC' wither on the command line or as environment variables. This is mostly the same you would do when using `make'. * Note the new `.gpd' files, e.g. if you want to clean a build directory. (But you might want to consider using `gp --clean' or `gp --clean-objects' for this purpose.) The main features of GP are: * Automatically finds all dependencies, units used and include files as well as C, assembler and object files and libraries referenced in `{$L}' and `{$R}' directives. * Recompiles everything when necessary (no need to give `--automake'). * Avoids unnecessary recompilations if only the implementation of a unit used has changed since the last compilation, by comparing a MD5 value of the interfaces of units. Recompilation is even avoided if only comments in the interface have changed, but not when they influence line numbers - since the GNU tools store line number information in object and other files, this does constitute a small difference. * Supports `--autobuild' to recompile everything. * Does not use GPC's buggy automake feature, so it should work also on systems where automake doesn't. Also, in many cases, it will use less total memory than GPC's automake because it calls the compiler iteratively rather than recursively. * Recognizes and supports transparently cyclic unit dependencies (where, naturally, at least one dependency in each cycle must be in the implementation rather than the interface). * Uses the base name of the main program's file name as the executable name by default, rather than `a.out' (no need to give `--executable-file-name' or `-o foo', but these options are also supported). In the strange case that you want your output file to be called `a.out', you can use `-o a.out'. * Does not try to link a unit given on the command line (no need to give `-c' for units, but `-c' is also supported in case you want to compile, but not link, a program). * Tries appending a `.pas', `.p', `.pp' or `.dpr' suffix (in this order) to the file name given on the command line when necessary, i.e. you can invoke it as `gp foo.pas' or just `gp foo'. * Calls `gcc' rather than `cc1' (which GPC would call) to compile C files, so it also works if the versions of the installed GCC compiler and the backend the installed GPC is based on don't match. * Supports GPC's path options (`--unit-path', `--object-path', `--unit-destination-path', `--object-destination-path', `--executable-path') transparently, also for units given on the command line (where GPC ignores `--unit-destination-path'). * Supports `--include-path' and `--library-path' which work the same way as `-I' and `-L', respectively, but can be given multiple directories at once. * Uses all unit and object paths as include paths automatically, to simplify using units or C files with includes in other directories. * Stores the compiler version, target platform and options given (together with other dependency information) in files with suffix `.gpd' ("GNU Pascal Dependencies") and recompiles files when the compiler version, platform or options differ from those they were compiled with. * Compiles the main program to an object file before linking, so it does not have to be recompiled when only a unit's implementation changes, and you have it available in case you want to link it explicitly. * The options `--progress-messages' and `--progress-bar' are extended to give information on the progress of the compilation of the whole project (not only of a single source file as when calling `gpc' directly). Some limitations: * The handling of default options and simpler usage of dialect options (as discussed on the mailing list) is not yet included. This will be added in a later revision. However, this does not have any influence on the main functionality of building Pascal programs (you just have to give your options explicitly, as you do when calling `gpc'). * Extended Pascal module support is experimental. * More than one unit/module/program in one source file is not supported. * Modules with interface and implementation parts in separate source files are not supported. This seems to be difficult to do at all, since the information where to find the implementation module is simply missing from the source. If you have any good ideas on this topic, please send them to the GPC list. * Other more or less strange things may not be supported. If you find anything, let me know, so I can decide whether to support it or to document that it's not supported. GP is Copyright (C) 2000-2004 Free Software Foundation, Inc. It was written by Frank Heckenbach <frank(a)pascal.gnu.de>. It is distributed under the terms of the GNU General Public License, version 2. 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: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 [View Less]

8 25

`MacTypes' could not be imported
by Adriaan van Os 27 May '04

27 May '04

Arnaud Gautier wrote: > HI, > I think I have all installed ok on my mac (osX 10,2): > jack:~/gpc-332d1-build arnaudgautier$ gpc -v > Reading specs from > /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/> specs > Configured with: ../gpc-332d1/configure --enable-languages=pascal,c > --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix > --target=powerpc-apple-darwin > Thread model: posix > gpc version 20030830, based on gcc-3.3.2 … [View More]

1 0

Tree SSA
by Adriaan van Os 27 May '04

27 May '04

Tree SSA has been merged into gcc mainline, see <http://gcc.gnu.org/projects/tree-ssa/>. This seems to be a major change, e.g. the Ada and Fortran frontends are broken. Any comments from Frank or Waldek or from anybody else on the list ? Regards, Adriaan van Os

3 2

BP (in)compatibility
by Waldek Hebisch 27 May '04

27 May '04

I noticed that the following FPC code (claimed to be BP compatible) is not accepted by GPC: function b:string; begin b[1] := ' ' end; Similarely FPC accepts: type a = record i, j : integer end; function b(i, j: integer) : a; begin b.i := i; b.j := j end; I do not know if we want to implement that feature, but (assuming it is really accepted by BP) we should list it as known incompatiblity. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

5 9

BP OOP problem
by Frank Heckenbach 25 May '04

25 May '04

I just found another problem in BP's OOP. In the following program, `o.f' in oo.p is ambiguous. It could mean field f of the field o, or function f of the parent type o. Both BP and GPC (currently) do the former (i.e., say 99). I noticed this because the OOE draft forbids this case by requiring that object fields don't clash with parent type names. We do we do here? Allow it in BP mode with a warning, error otherwise? program Foo; type o = object function f: Integer; end; oo = … [View More]

4 17

BP question
by Frank Heckenbach 20 May '04

20 May '04

BP seems to allow overriding a public method with a private one (and vice versa). Does this seem reasonable? What do Delphi and other compilers do? At first sight, I'd rather forbid this in GPC (as usual, with an exception in `--borland-pascal', but perhaps a warning even there?). program Foo; type a = object procedure p; end; b = object (a) private procedure p; { ??? } end; procedure a.p; begin end; procedure b.p; begin end; begin end. Oh, wait a second, it gets … [View More]

5 11

Re: IEEE 754 Standard (was: gpc-20030830 released)
by Tom Verhoeff 20 May '04

20 May '04

Adriaan van Os wrote: > >Frank Heckenbach wrote: > >> ISO Pascal wants an error (though, in principle, I think we could >> use NaN and document the error as "not detected" -- we might do this >> sometime, perhaps optionally). For now, I'm making it runtime >> errors. (emil27*.pas) > >Special cases for the pow function in IEEE 754 (see e.g. Apple >Numerics Manual, second edition, page 64, or the PowerPC Numerics >manual available from ><… [View More]http://developer.apple.com/documentation/mac/PPCNumerics/PPCNumerics- >2.html>). > >Operation Result Exceptions raised [ List suppressed ] It would be a good thing if gpc provided full support of the IEEE 754 Standard. Unfortunatly (for numerical applications, at least), many compilers either provide no support at all, or provide only partial support. The latter is often even worse than the former. (Apple has indeed been a loyal supporter of the standard from the very beginning.) The need for some features in the IEEE 754 standard is less obvious to the uninitiated. Good articles in this respect are Kahan, W. Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic. May 1996. <http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF> and Kahan, W. Why do we need a floating-point arithmetic standard? Unpublished note, February 1981. <http://www.cs.berkeley.edu/~dbindel/class/cs279/why-ieee.pdf> William Kahan is the intellectual father of the standard. Another important references is (the title says it all): Goldberg, D. ``What every computer scientist should know about floating-point arithmetic'', Appendix~D in Numerical Computation Guide. Sun Microsystems, Revision A, May 2000; originally published in ACM Computing Surveys (March 1991). <http://docs.sun.com/source/806-3568/ncg_goldberg.html> The following (short) book is a good introduction to the use of IEEE 754: Overton, M. L. Numerical Computing with IEEE Floating Point Arithmetic. SIAM, 2001. For those with less time, I recommend an article I recently wrote: Gyula Horvath, Tom Verhoeff. ``Numerical Difficulties in Pre-University Informatics Education and Competitions'', Informatics in Education, Vol. 2, Number 1, pp.21-38. <http://www.win.tue.nl/~wstomv/publications/INFE012.pdf> Here is one simple example contained in that article, to explain the need for avoiding unnecessary exception raising. Suppose you want to write a piece of program to calculate the effective resistance of two (and later more than two) parallel resistors, R_1 and R_2, both non-negative real numbers (Ohms). The basic formula is 1 R_Eff = --------- (i.e. the "harmonic" mean of R_1 and R_2) 1 1 --- + --- R_1 R_2 Of course, it fails (under normal math rules), when R_1 or R_2 (or both) are zero. However, when either (or both) are zero, the effective resistance is well-defined, viz. zero. A slightly better formula may seem to be R_1 * R_2 R_Eff = --------- R_1 + R_2 because it also "works" when either of R_1 and R_2 are zero. However, there are two problems with that formula: (1) when both are zero, it gives 0/0, and (2) it does not generalize easily to more than two resistors. Now, under the IEEE 754 Standard, the first formula works perfectly well. Why? Because the standard includes signed infinities and NaN (not-a-number) that are well-behaved: 1 / +0 = +inf (zero is also signed!) a + inf = inf 1 / +inf = +0 0 / 0 = NaN 0 * +inf = NaN NaN <any-operator> a = NaN With these rules, the first formula works correctly under all circumstances, without requiring any case analysis in the program. However, if division by zero would raise an exception, then you need to catch it in the program, and you get a clumsy program. The second formula fails under these rules for R_1 = R_2 = 0, because it involves 0 / 0. In (numerical) practice, there are even "worse" examples (such as rational function with multiple "false" poles; see Kahan's articles), where a case analysis would be horrible compared to the straightforward approach via IEEE 754. All in all, the committee that developed the IEEE 754 Standard thought hard about the features, and they came up with a carefully balanced set. Partial implementation is not recommended, because it destroys some important properties. Tom [View Less]

4 3

Someone's getting old
by Neil Santos 19 May '04

19 May '04

Someone forgot to change the homepage on gnu-pascal.de about a month ago. Not that I'm complaining; the message is an important one. But maybe the stuff with dates should be taken out? But what do I know? ;b -- Political Dissident Neil Santos Free Software Advocate Jabber: nsantos(a)jabber.org Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

2 1

Re: gp-0.54 released
by Frank Heckenbach 18 May '04

18 May '04

Thorsten Glaser wrote: > Dixitur illum frank(a)g-n-u.de scribere... > > >one of the next releases, and automake support will later be dropped > >from GPC. > > Would it be too difficult to keep --automake support, Yes! > If one would add a feature that prints out the names > of the generated (or not, depending on if they have > been rebuilt) .o files, this feature integrated nicely > with BSD-style Makefile templates, and I was already > planning to … [View More]

2 1

Re: gp-0.54 released
by Frank Heckenbach 18 May '04

18 May '04

Thorsten Glaser wrote: > Dixitur illum ih8mj(a)fjf.gnu.de scribere... > > >Such a feature could also be added to GP. In fact, I've thought > >about it, any it may be faster than doing it with GPC/automake > >(because GP only takes a quick look at source files, whereas > >GPC/automake parses them fully). > > Hmm, but the pascal compiler is still gpc... To extract dependencies you don't need a compiler. > >But note that even if you use Makefiles, you … [View More]

1 0

Results for 3.3.4 20040516 (prerelease) testsuite on i686-pc-linux-gnu
by David Kredba 18 May '04

18 May '04

Native configuration is i686-pc-linux-gnu === gpc tests === Running target any === gpc Summary === # of tests 3910 # of expected passes 3907 # of unsupported tests 3 /home/dave/gcc/gcc-3.3.4/gcc/xgpc version 20040516, based on gcc-3.3.4 20040516 (prerelease) === gcc tests === Running target unix FAIL: gcc.dg/duff-2.c (test for excess errors) === gcc Summary === # of expected passes … [View More]21868 # of unexpected failures 1 # of expected failures 69 # of unsupported tests 100 /home/dave/gcc/gcc-3.3.4/gcc/xgcc version 3.3.4 20040516 (prerelease) === g++ tests === Running target unix FAIL: g++.other/decl5.C caused compiler crash XPASS: g++.other/init5.C Execution test === g++ Summary === # of expected passes 8242 # of unexpected failures 1 # of unexpected successes 1 # of expected failures 91 # of untested testcases 9 # of unsupported tests 15 /home/dave/gcc/gcc-3.3.4/gcc/testsuite/../g++ version 3.3.4 20040516 (prerelease) === g77 tests === Running target unix === g77 Summary === # of expected passes 1736 /home/dave/gcc/gcc-3.3.4/gcc/testsuite/../g77 version 3.3.4 20040516 (prerelease) === objc tests === Running target unix === objc Summary === # of expected passes 1166 /home/dave/gcc/gcc-3.3.4/gcc/xgcc version 3.3.4 20040516 (prerelease) === libjava tests === Running target unix WARNING: program timed out. FAIL: SyncTest execution - gij test WARNING: program timed out. FAIL: SyncTest execution - gij test FAIL: Thread_Interrupt output - source compiled test FAIL: Thread_Interrupt output - gij test FAIL: Thread_Interrupt -O output - source compiled test FAIL: Thread_Interrupt output - gij test === libjava Summary === # of expected passes 2983 # of unexpected failures 6 # of expected failures 16 # of untested testcases 14 === libstdc++-v3 check-abi Summary === # of added symbols: 3 # of missing symbols: 0 # of incompatible symbols: 0 === libstdc++-v3 tests === Running target unix FAIL: 22_locale/codecvt_members_char_char.cc execution test FAIL: 22_locale/codecvt_members_wchar_t_char.cc execution test FAIL: 22_locale/ctor_copy_dtor.cc execution test FAIL: 22_locale/ctype_to_char.cc execution test FAIL: 22_locale/ctype_to_wchar_t.cc execution test FAIL: 22_locale/facet.cc execution test FAIL: 27_io/filebuf_virtuals.cc execution test FAIL: 27_io/ostream_inserter_arith.cc execution test FAIL: 27_io/streambuf_members.cc execution test FAIL: 27_io/stringbuf_virtuals.cc execution test === libstdc++-v3 Summary === # of expected passes 443 # of unexpected failures 10 # of expected failures 28 Compiler version: 3.3.4 20040516 (prerelease) Platform: i686-pc-linux-gnu configure flags: --host=i686-pc-linux-gnu --prefix=/opt --enable-shared --enable-threads=posix --enable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,ada,f77,objc,java,pascal --with-system-zlib -- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024D/5B6B02DE Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE [View Less]

1 0

random number unit
by Toby Ewing 14 May '04

14 May '04

Hi, all I've been working with the Mersenne Twister random number generator for a while. I translated it from the original C to Pascal several years ago, and the GPC team incorporated it into the GPC unit. But since then the original authors have found and fixed a bug in their initilization procedures, and other users have suggested various speedups. I've now updated my original translation, validated it against the authors' test output, performed some other minor tests, and done what … [View More]small optimizations I know how to do. Source for the unit and a test program are appended below. I don't know much about optimization, and there may be some compiler directives that would greatly speed the unit. I'd appreciate any comments on that front: currently I only use: {$no-pack-struct, maximum-field-alignment 0} and more could probably be done. regards, Toby ------------------------------------------ Unit MTrand; { Mersenne Twister random number generator -- a Pascal unit. Based on code by Makoto Matsumoto, Takuji Nishimura, Shawn Cokus, Richard J. Wagner, and others. This code is based on the Jan 26 2002 version, found on Matsumoto's MT website: http://konatu.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html See also the original website: http://www.math.keio.ac.jp/~matumoto/emt.html Translation to a GPC unit by Toby Ewing (ewing(a)iastate.edu), March 2004, with assistance from James Houston (jhouston(a)tsargent.com). The Mersenne Twister is an algorithm for generating random numbers. It was designed with consideration of the flaws in various other generators. The period, 2^19937-1, and the order of equidistribution, 623 dimensions, are far greater. The generator is also fast; it avoids multiplication and division, and it benefits from caches and pipelines. Reference: M. Matsumoto and T. Nishimura, "Mersenne Twister: A 623-Dimensionally Equidistributed Uniform Pseudo-Random Number Generator", ACM Transactions on Modeling and Computer Simulation, Vol. 8, No. 1, January 1998, pp 3-30. Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The names of its contributors may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The original code included the following notice: When you use this, send an email to: matumoto(a)math.keio.ac.jp with an appropriate reference to your work. } {$no-pack-struct, maximum-field-alignment 0} Interface const mtN = 624; {length of state vector} type MTcard = cardinal attribute (Size = 32); PMTary = ^Buffary; Buffary(m : medCard) = array[0..m] of medCard; {Generate uniform random 32-bit cardinal} Function randInt : MTcard; {cardinal in [0,2^32-1]} Function randrInt(range : MTcard) : MTcard; {cardinal in [0,n-1]} {Generate uniform random double} Function rand : double; {double in [0,1]} Function randr(range : double) : double; {double in [0,r]} Function randEx1 : double; {double in [0,1)} Function randrEx1(range : double) : double; {double in [0,r)} Function randEx0 : double; {double in (0,1]} Function randrEx0(range : double) : double; {double in (0,r]} Function randDblExc : double; {double in (0,1)} Function randrDblExc(range : double) : double; {double in (0,r)} {Generate 53-bit uniform random double (capacity of IEEE double precision)} Function rand53 : double; {double in [0,1)} {Generate random double from normal distribution, given mean and stdev} Function randNorm(Mean, stdev : double) : double;{double from (mean, stdev)} {Initialization} Procedure SeedRand(RandSeed : MTcard); {initialize with an MTcard} Procedure SeedRandArray( keylen : medCard; {initialize with an array} var initkey : PMTary); Implementation const mtM = 397; {period parameter} vectA = 16#9908b0df; {constant vector a} UMask = 16#80000000; {most significant bits} LMask = 16#7fffffff; {least significant bits} TempB = 16#9d2c5680; {Tempering parameters B and C} TempC = 16#efc60000; type MTary = array[0..mtN] of MTcard; magary = array[0..1] of MTcard; var mt : MTary; {array for MT state vector} mti : MTcard; {array index} Procedure Reload; {This is the basic vector generator, making mtN random MTcards at a time} var y, kk : MTcard; mag01 : magary = (0, vectA); attribute (static); begin for kk := 0 to mtN-mtM-1 do begin y := (mt[kk] AND UMask) OR (mt[kk+1] AND LMask); mt[kk] := mt[kk+mtM] XOR (y shr 1) XOR mag01[y AND 16#00000001]; end; for kk := mtN-mtM to mtN-1 do begin y := (mt[kk] AND UMask) OR (mt[kk+1] AND LMask); mt[kk] := mt[kk+(mtM-mtN)] XOR (y shr 1) XOR mag01[y AND 16#00000001]; end; y := (mt[mtN-1] AND UMask) OR (mt[0] AND LMask); mt[mtN-1] := mt[mtM-1] XOR (y shr 1) XOR mag01[y AND 16#00000001]; mti := 0; end; Function RandInt : MTcard; {card in [0,2^32-1]} {This is the root function for returning a single random number: all of the other functions draw on this one.} var twist : MTcard; begin if (mti >= mtN) then reload; twist := mt[mti]; inc(mti); twist := twist XOR (twist shr 11); twist := twist XOR ((twist shl 7) AND TempB); twist := twist XOR ((twist shl 15) AND TempC); randInt := twist XOR (twist shr 18); end; {Real versions (in C) by Isaku Wada} Function rand : double; {double in [0,1]} begin rand := randInt * (1.0/4294967295.0); end; Function randr(range : double) : double; {double in [0,r]} begin randr := range * randInt * (1.0/4294967295.0); end; Function randEx1 : double; {double in [0,1)} begin randEx1 := randInt * (1.0/4294967296.0); end; Function randrEx1(range : double) : double; {double in [0,r)} begin randrEx1 := range * randInt * (1.0/4294967296.0); end; Function randEx0 : double; {double in (0,1]} begin randEx0 := (randInt + 1.0) * (1.0/4294967295.0); end; Function randrEx0(range : double) : double; {double in (0,r]} begin randrEx0 := range * (randInt + 1.0) * (1.0/4294967295.0); end; Function randDblExc : double; {double in (0,1)} begin randDblExc := (randInt + 0.5) * (1.0/4294967296.0); end; Function randrDblExc(range : double) : double; {double in (0,r)} begin randrDblExc := range * (randInt + 0.5) * (1.0/4294967296.0); end; Function randrInt(range : MTcard) : MTcard; {card in [0,n-1]} { Return a MTcard within [0..range-1]. The code first finds which bits are used within that range. Optimized by Magnus Jonsson (magnus(a)smartelectronix.com). } var used, i : MTcard; begin used := range; used := used OR (used shr 1); used := used OR (used shr 2); used := used OR (used shr 4); used := used OR (used shr 8); used := used OR (used shr 16); repeat i := randInt AND used {Draw numbers until one is found in [0,n]} until (i <= range); {toss unused bits to shorten search} randrInt := i; end; Function rand53 : double; {double in [0,1)} var a, b : MTcard; begin {code by Isaku Wada} a := randInt shr 5; b := randInt shr 6; rand53 := ((a * 67108864.0) + b) * (1.0/9007199254740992.0); end; Function randNorm(mean, stdev : double) : double;{double from (mean, stdev)} { Draw a double from a normal (Gaussian) distribution with specified mean and standard deviation, using the Box-Muller method. This method is adapted from Press et al.'s Numerical Recipes. Wagner used the following instead: r := sqrt(-2.0 * ln(1.0-randDblExc)) * variance; phi := 2.0 * PI * randEx0; randNorm := mean + (variance * r * cos(phi)); It is simpler, but it calls for (almost) twice as many randInts, and uses a trigonometric function. According to my time trials, the Wagner method takes approximately 3 times longer than the Box-Muller I use here. } var RF, r1, r2 : double; rsecond : double; attribute (static); bsecond : Boolean = False; attribute (static); begin if bsecond then begin bsecond := False; randNorm := rsecond; end else begin bsecond := True; repeat r1 := randr(2.0) - 1.0; r2 := randr(2.0) - 1.0; RF := sqr(r1) + sqr(r2); until ((RF < 1.0) and (RF <> 0.0)); RF := stdev * sqrt(-2.0 * ln(RF)/RF); rsecond := mean + (r2 * RF); randNorm := mean + (r1 * RF); end; end; Procedure SeedRand(RandSeed : MTcard); { Initialize generator state with seed. See Knuth TAOCP Vol 2, 3rd Ed, p.106 for multiplier. In previous versions, the most significant bits (MSBs) of the seed affected only the MSBs of the state array. Modified 9 Jan 2002 by Makoto Matsumoto. } begin mt[0] := RandSeed AND 16#ffffffff; for mti := 1 to mtN do mt[mti] := (1812433253 * (mt[mti-1] XOR (mt[mti-1] shr 30))+mti) AND 16#ffffffff; mti := mtN + 1; end; Procedure SeedRandArray( keylen : medCard; var initkey : PMTary); var i, j, k : MTcard; begin SeedRand(19650218); i := 1; j := 0; k := Max(mtN, keylen); repeat dec(k); mt[i] := (mt[i] XOR ((mt[i-1] XOR (mt[i-1] shr 30)) * 1664525)) + initkey^[j+1] + j; {non-linear} mt[i] := mt[i] AND 16#ffffffff; {if machine wordsize > 32} inc(i); inc(j); if (i >= mtN) then begin mt[0] := mt[mtN-1]; i := 1; end; if (j >= keylen) then j := 0; until (k = 0); for k := mtN-1 downto 0 do begin mt[i] := (mt[i] XOR ((mt[i-1] XOR (mt[i-1] shr 30)) * 1566083941)) - i; mt[i] := mt[i] AND 16#ffffffff; {if machine wordsize > 32} inc(i); if (i >= mtN) then begin mt[0] := mt[mtN-1]; i := 1; end; end; mt[0] := 16#80000000; {force MSB = 1} end; to begin do {Unit Initialization} begin {initialize state vector} SeedRand(5489); {this is Matsumoto's default} end; end. {unit MTrand} ------------------------------------------ program TestMTrand; uses MTrand, GPC; const big = 100000000; notsobig = 10000000; bin = 40; mean = 100.0; std = 20.0; type binary = array[1..bin] of longCard; var time1, time2, mult, i : longCard; m, s, rj : double; keylen, jj : medCard; bins : binary; init : PMTary; {This type is native to MTrand: PMTary = ^Buffary; Buffary(m : medCard) = array[0..m] of medCard;} begin writeln; writeln('Testing the Mersenne Twister Unit ''MTrand.pas'''); writeln; (* {This part passed March 23, 2004 in test against Matsumoto's original test output. Not implemented in this test program because of subsequent changes in the MT initialization procedures.} writeln('Precision: compare with Matsumoto''s 1000 original integer output'); SeedRand(4357); for i := 1 to 1000 do begin write(randInt:10, ' '); if ((i mod 5) = 0) then writeln; end; writeln; *) {This part passed March 24, 2004 in test against Matsumoto's output} writeln('Precision: compare with Matsumoto''s 1000 integer output, posted at'); writeln(' http://www.math.sci.hiroshima-u.ac.jp/~'); writeln(' m-mat/MT/MT2002/CODES/MTARCOK/mt19937ar-cok.out'); New(init, 4); init^[1] := 16#00000123; init^[2] := 16#00000234; init^[3] := 16#00000345; init^[4] := 16#00000456; keylen := 4; SeedRandArray(keylen, init); Dispose(init); for i := 1 to 1000 do begin write(randInt:10, ' '); if ((i mod 5) = 0) then writeln; end; writeln; {This part passed March 23, 2004} writeln('Uniformity of random 32-bit cardinals:'); for i := 1 to bin do bins[i] := 0; mult := bin; SeedRand(1234567890); for i := 1 to big do inc(bins[1+(randInt*mult) div 16#ffffffff]); for i := 1 to bin do begin write(i:2, ': ', bins[i]:7, ' '); if ((i mod 5) = 0) then writeln; end; writeln; writeln('Uniformity of range-specified cardinals:'); for i := 1 to bin do bins[i] := 0; mult := bin; SeedRand(1234567890); for i := 1 to big do inc(bins[1+(randrInt(bin))]); for i := 1 to bin do begin write(i:2, ': ', bins[i]:7, ' '); if ((i mod 5) = 0) then writeln; end; writeln; writeln; writeln('Distribution of doubles in [0..1]:'); for i := 1 to bin do bins[i] := 0; m := 0.0; s := 0.0; SeedRand(987654321); for i := 1 to notsobig do begin rj := rand; m := m + rj; s := s + sqr(rj); end; m := m/notsobig; s := sqrt((s-(notsobig*sqr(m))) / (notsobig-1)); writeln('Theoretical mean: 0.5000, standard deviation: 0.2886'); writeln('Returned mean : ', m:7:4, ', standard deviation: ', s:7:4); writeln; writeln('Distribution of Random normal deviates with known mean and standard deviation:'); for i := 1 to bin do bins[i] := 0; m := 0.0; s := 0.0; SeedRand(2468097531); for i := 1 to notsobig do begin rj := randNorm(mean, std); m := m + rj; s := s + sqr(rj); end; m := m/notsobig; s := sqrt((s-(notsobig*sqr(m))) / (notsobig-1)); writeln('Requested mean: ', mean:7:4, ', standard deviation: ', std:7:4); writeln('Returned mean: ', m:7:4, ', standard deviation: ', s:7:4); writeln; {This part tested and used to optimize the unit, March 23-24, 2004} writeln('Timing:'); SeedRand(1357908642); time1 := GetMicroSecondTime; for i := 1 to big do jj := randInt; time2 := GetMicroSecondTime; writeln('Time for ', big:1, ' randInts: ', ((time2-time1)*0.000001):7:2, ' seconds.'); SeedRand(564739201); time1 := GetMicroSecondTime; for i := 1 to big do rj := Rand; time2 := GetMicroSecondTime; writeln('Time for ', big:1, ' rands: ', ((time2-time1)*0.000001):7:2, ' seconds.'); SeedRand(1029384756); time1 := GetMicroSecondTime; for i := 1 to big do rj := randNorm(mean, std); time2 := GetMicroSecondTime; writeln('Time for ', big:1, ' randNorms: ', ((time2-time1)*0.000001):7:2, ' seconds.'); writeln; writeln('done.'); end. [View Less]

2 5

Building GPC as a cross compiler for AVR Target (Linux x86 host)
by antony 13 May '04

13 May '04

hi all , i'm a newbie in compiler compiling, and in this mailing list. I'am trying to build an AVR gpc pascal compiler. with gcc-3.2.2, binutils 2.14, and gpc-20330507 gcc c cross compiler builds fine (with ../gcc-3.2.2/configure --prefix=$prefix --target=$target --enable-languages=c -v; make all) BUT ../gcc-3.2.2/configure --prefix=$prefix --target=$target --enable-languages=pascal -v; make all ends after a while with CC="`echo /home/data/gcc-3.2.2/build/gcc/xgcc -B/home/data/gcc-3.… [View More]

2 1

gpc-20030830 released
by Frank Heckenbach 13 May '04

13 May '04

I've uploaded a new alpha to <http://www.gnu-pascal.de/alpha/>. IMPORTANT LICENSING NOTE: Due to the recent disputes over the GNU Free Documentation License by some parties, we made a detailed investigation of the license status of GPC's documentation. Thereby it turned out that the change to the FDL last November might not have been done absolutely correctly, since neither permission of some earlier authors nor of the FSF as the copyright holder was obtained for that change. To avoid … [View More]any possible problems resulting from that, we decided to rewind the complete documentation to the state of 2002-11-27, the last version licensed under the GPL, and redo all later changes with explicit permission of the respective authors under the GPL. As the result, the whole documentation is now licensed under the GPL (again), and the license status of GPC versions 20021128, 20030209, 20030323 and 20030507 remains dubious. (Note: This affects only the documentation. The compiler itself has not changed its license and is therefore safe. Neither are programs compiled by such a GPC version affected.) I am not a lawyer, so I can't give you any advice what to do if you have used such a version, but my personal suggestion (also for technical reasons) is to change to the current release as soon as possible. Therefore, we have removed the problematic distributions from our server. Those who have made available binaries of one of the problematic versions are suggested to do the same (which, I suppose, they will do anyway, replacing them by the new release). For the same reason, we do not offer a patch against gpc-20030507, so you will have to download the whole GPC distribution to upgrade. (A patch against gpc-20021111 would be safe, but probably rather large and not worth the effort, since many users might not have gpc-20021111 handy anymore.) To avoid similar problems, we do not plan another attempt to change the license in the nearer future. It may be required for GCC integration someday, but not until the disputes over the FDL are finally settled. If you have any suggestions regarding these matters, please contact Peter Gerwinski or me by private mail. BUILD NOTE: This GPC version requires quite a recent version of Bison. (And building CVS Bison again requires bleeding edge versions of some other utilities.) Therefore, I have included the Bison generated files in the distribution (also in the "minimal" distribution), so you won't need Bison at all unless you remove them or change parse.y. New features: * `CompilerAssert' (fjf904*.pas) * options `--[no]-assert' renamed to `--[no]-assertions' (necessary to avoid a conflict with GCC) (@) * new options `--[no-]range-checking', also as short compiler directives `{$R+}'/`{$R-}' (default is on) (C, E, B, @) * new options `--[no-]methods-always-virtual' (fjf903*.pas) (M) * new options `--[no-]pointer-arithmetic', `--[no-]cstrings-as-strings', `-W[no-]absolute' (all of which `--[no-]extended-syntax' implies) * `Integer2StringBase', `Integer2StringBaseExt' * new constants `NumericBaseDigits', `NumericBaseDigitsUpper' * allow assigning, passing by value and returning objects, with assignments of an object of derived type to one of a base type (chief35[ab].pas, fjf451*.pas, fjf696[ef].pas, fjf884*.pas), BP compatible except for a bug in the BP feature itself (see the comment in `p/test/fjf451h.pas') (B) * new options `-W[no-]object-assignment' * warn (except in `--borland-pascal') if a virtual method overrides a non-virtual one (chief52*.pas) * warn when an non-abstract object type has virtual methods, but no constructor (chief51*.pas) * `--maximum-field-alignment' does not apply to `packed' records * `ArcSin', `ArcCos' Note: Range checking options are recognized, but range checking in general is *not* yet implemented. Only some special cases are checked, such as sets and dynamic subranges (subranges in local declarations and array slice access). Fixed bugs: * open internal files with `O_EXCL' on `Rewrite' (as a protection against symlink attacks) * `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas) * `--enable-keyword'/`--disable-keyword' on the command-line makes GPC crash (david5.pas) * GPC accepts, but ignores, options with invalid suffixes (e.g. `--delphi-pascal') * wrong type-error when applying `Inc' to a type-casted pointer (peter3.pas) * with range checking enabled, check dynamic subrange/array size (fjf222*.pas, fjf813*.pas, fjf900*.pas) * GPC allows modification of conformant array bounds, result of `High'/`Low' etc. (fjf897*.pas) * don't allow linker names starting with a digit (fjf894.pas) * `SubStr' with constant arguments doesn't work in constants (gale1.pas) * handle `BitSizeOf' correctly for packed array fields, don't allow `SizeOf' on them (fjf891*.pas) * System: `BPReal' must be a packed record <3EE8A26D.C919BE7D(a)flexim.de> * schema types with initializers (drf1.pas, fjf886*.pas) * `Return' doesn't work for sets (fjf885.pas) * bug with arrays as fields of `packed' records (waldek6.pas) * don't allow duplicate imports in a module interface and implementation (nick1b.pas) * compensate for parser read-ahead in the lexer, so compiler directives don't become effective too early and error messages refer more closely to the correct source position (still not quite correct due to issues with Bison) * bug when dividing two integers with `/' (fjf481.pas) * don't allow `absolute' in type definitions * subranges with variable limits (couper[23].pas) 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: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707 [View Less]

9 23

Compiler crash
by Marten Jan de Ruiter 12 May '04

12 May '04

Dear all, The reason I tried to switch to a newer compiler is that the older compiler crashed on, I suspect, memory usage. Increasing a const that determines the size of a number of arrays causes the crash. Restoring the const to the old value gives a fine compilation. Compiler gpc 20030830, based on gcc-3.2.1 also crashes on a linux machine. The crashes are consistent in the following way: At a clean start, i.e. after removing all the object and gpi files, the compiler crashes after … [View More]line 86 in writestruct.p (see below). Subsequent compile runs, with the already compiled .o and .gpi files available, consistently show line 120 of the same file. Could be a --progress-messages thing, not related to the real cause of the crash, but I am not sure. I do not know how to single out the problem for this case. Aside of posting the backtrace, I am in the dark. Can anyone point me to information on how to attack this problem? Thanks for your consideration, Regards, Marten Jan % uname -a Linux so3 2.4.18-14smp #1 SMP Wed Sep 4 12:34:47 EDT 2002 i686 i686 i386 GNU/Linux % make_fem <snip> #progress# IO/writestruct.p (86) gpc: Internal error: Segmentation fault (program gpc1) Please submit a full bug report. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. gpc1: gpc exited with status 1 % gdb \ /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/gpc1 \ core.22274 GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/gpc1 /tmp/ccgaf2M'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 emit_library_call_value_1 (retval=0, orgfun=0x40014b60, value=0x0, fn_type=1076180224, outmode=VOIDmode, nargs=3, p=0xbfbddaf8 "�@~�\b�\b0۽ zC@\030\t>@\030B\001@") at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:3811 3811 memcpy (stack_usage_map, initial_stack_usage_map, (gdb) backtrace #0 emit_library_call_value_1 (retval=0, orgfun=0x40014b60, value=0x0, fn_type=1076180224, outmode=VOIDmode, nargs=3, p=0xbfbddaf8 "�@~�\b�\b0۽ zC@\030\t>@\030B\001@") at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:3811 #1 0x081020ed in emit_library_call (orgfun=0xbf7bd370, fn_type=3212563312, outmode=3212563312, nargs=-1082403984) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:4228 #2 0x080ac770 in emit_push_insn (x=0x403ecb40, mode=BLKmode, type=0x40294b60, size=0x403e0918, align=1, partial=0, reg=0x0, extra=0, args_addr=0x4024e070, args_so_far=0x527, reg_parm_stack_space=0, alignment_pad=0x40014210) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/expr.c:3467 #3 0x08102702 in store_one_arg (arg=0xbfffe2f8, argblock=0x4024e070, flags=0, variable_size=0, reg_parm_stack_space=0) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:4587 #4 0x080ffb23 in expand_call (exp=0x40437640, target=0x0, ignore=1) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:2968 #5 0x080b35f3 in expand_expr (exp=0x40437a20, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/expr.c:7379 #6 0x0825c05a in expand_expr_stmt_value (exp=0xbfffe2f8, want_value=1, maybe_last=1076180224) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/stmt.c:2247 #7 0x0825bf91 in expand_expr_stmt (exp=0xbf7bd370) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/stmt.c:2201 #8 0x08051e1b in yyuserAction (yyn=562, yyrhslen=3, yyvsp=0x840e650, yyvalp=0xbfffe88c, yylocp=0xbfffe890, yystack=0xbfffe8f0) at parse.c:4580 #9 0x08058367 in yydoAction (yystack=0xbfffe8f0, yyk=0, yyrule=562, yyvalp=0xbfffe88c, yylocp=0xbfffe890) at parse.c:8218 #10 0x08057ee9 in yyglrReduce (yystack=0xbfffe8f0, yyk=0, yyrule=562, yyforceEval=1 '\001') at parse.c:8290 #11 0x08057436 in main_yyparse () at parse.c:8991 #12 0x080e3954 in compile_file () at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:2124 #13 0x080e85e9 in do_compile () at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:5218 #14 0x080e8659 in toplev_main (argc=-1082403984, argv=0x0) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:5250 #15 0x080f168b in main (argc=-1082403984, argv=0xbf7bd370) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/main.c:35 #16 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 [View Less]

4 6

Protected Var parameter bug
by Gale Paeper 11 May '04

11 May '04

While investigating a different issue, I found what I think is a problem with GPC's enforcement of Extended Pascal's actual parameter requirements for formal protected var parameters. The problem is that GPC allows function-access expressions to be used as the actual parameter for a formal protected var parameter and the function-access isn't a variable-access as required by Extended Pascal. For formal variable parameters, Extended Pascal requires the actual-parameter ... "shall be variable-… [View More]access" (see paragraph 6.7.3.3) regardless of whether 'protected' is used in the formal parameter declaration. ('Protected' does not change the requirements for the actual-parameter. It just requires that no statements within the procedure/function shall threaten a protected formal-parameter identifier.) While GPC doesn't allow function-access expression actual-parameters for non-protected formal variable parameters, it incorrectly allows function-access expression actual-parameters to be used for protected formal variable parameters. A short test program that demonstrates the problem: {$extended-pascal} program ProtectVarParameterTest(input, output); var globalInt : Integer; function GetInteger: Integer; begin GetInteger := 1; end; procedure DoSomethingProtectedVar(protected var anInt : Integer); begin globalInt := anInt; end; procedure DoSomethingVar(var anInt : Integer); begin globalInt := anInt; end; begin globalInt := 0; DoSomethingProtectedVar(GetInteger); {WRONG} writeln('FAIL'); {DoSomethingVar(GetInteger); writeln('FAIL');} end. With the last two statements commented out, GPC compiles the program with no errors and running the compiled program produces and output of: FAIL. Uncommenting out the last two statements, GPC doesn't compile the program and generates error messages: ProtectVarParameterTest.pas: In main program: ProtectVarParameterTest.pas:26: error: type mismatch in argument 1 of `DoSomethingVar' ProtectVarParameterTest.pas:18: error: routine declaration (Note - the error messages in this test example are pretty obtuse. In the program where I initial found the problem, the error message of "error: reference expected, value given" is much clearer as to what the real cause of the problem is.) The command line and compiler information used on both versions of the test program were: gpc --automake -v ProtectVarParameterTest.pas -o ProtectVarParameterTest Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin/3.3/ -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__DYNAMIC__ ProtectVarParameterTest.pas -fautomake -famtmpfile=/var/tmp//cc2sio8x.gpa /var/tmp//ccmxZG89.i GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3 (Darwin/PowerPC) /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpc1 /var/tmp//ccmxZG89.i -fPIC -quiet -dumpbase ProtectVarParameterTest.pas -auxbase ProtectVarParameterTest -version -fautomake -famtmpfile=/var/tmp//cc2sio8x.gpa -o /var/tmp//ccPyvMwU.s GNU Pascal version is actually 20030507, based on gcc-3.3 GNU Pascal version 3.3 (powerpc-apple-darwin) compiled by GNU C version 3.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Gale Paeper gpaeper(a)empirenet.com [View Less]

2 1

Re: FlateDecode
by Prof A Olowofoyeku (The African Chief) 11 May '04

11 May '04

Frank Heckenbach wrote: >I suggest to link to the existing C libraries (libz and/or libpng). I >don't generally recommend translating standard libraries to Pascal. >The C libraries are tested by more people and (usually) maintained, >and writing a Pascal interface is much easier than translating the >whole library (especially if only a small part of the library >interface is actually needed, like in many cases I know). In principle, yes. However, the problem that I … [View More]

4 3

Linking libraries between C and pascal
by Marten Jan de Ruiter 11 May '04

11 May '04

Dear all, The default name for a pascal procedure does not work correctly anymore. (See the output for version number and so on below). Explicitly declaring the name works, so a workaround is available. That can be done as follows: procedure p_routine; attribute (name='P_routine') If I am making a mistake somewhere, I would be glad to hear. Regards, Marten Jan de Ruiter % gpc --version gpc 20030830, based on gcc-3.2.1 % cat c_unit.c #include <stdio.h> extern void c_routine()… [View More]

3 4

Noddy question
by John Ollason 11 May '04

11 May '04

I think that the following program ought to produce a run-time error but it doesn't. I have had a look at the GPC manual but I can't find any compiler directive that says Check array bounds, and I did rather think that the philosophy of Pascal was to prevent this sort of thing happening without the user having to take any special action. So, is there a way of generating the code that says 'Check array bounds' (I know other dialects of Pascal that do this by default). Version 2.95.2 19991024 (… [View More]

3 2

gpc compilation failed under BSD
by karim_f＠mysunrise.ch 11 May '04

11 May '04

Hello I had tried to compile gpc under freebsd last year. But didn`t get far. Now I`m trying with a newer version of the compiler. gpc-20030830 gcc-3.3.1 . This is the last make output : gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -Wtraditional -pedantic -Wnong-long -o xgpc p/gpc.o … [View More]

3 5

FlateDecode
by Adriaan van Os 10 May '04

10 May '04

Does anyone on the list know about source code in Pascal for FlateDecode compression ? It is used in PNG images and in PDF files. Regards, Adriaan van Os

4 3

Missing BP feature
by Prof A Olowofoyeku (The African Chief) 09 May '04

09 May '04

Hi I think I have a missing feature or incompatibility with BP. I am trying to compile the paszlib units with GPC. Given these declarations: { Data structure describing a single value and its code string. } type ct_data_ptr = ^ct_data; ct_data = record fc : record case byte of 0:(freq : ush); { frequency count } 1:(code : ush); { bit string } end; dl : record case byte of 0:(dad : ush); { father node in Huffman tree } 1:(… [View More]

2 1

gpc compilation failed under BSD
by karim_f＠mysunrise.ch 09 May '04

09 May '04

Hello Frank (and others) I don`t know which make is installed on my system. How can I check the "origin" or "brand" ? I`m sure, it is the default make that comes with a freebsd CD installation. Did you install a new make version when you tested the gpc compiler system on netbsd ? ...I don`t think so. Anyway, I didn`t find a bsd port of gnu make. Can I get it from the gnu webpage ? Greetings Karim ******************************************************************** Are you using … [View More]

2 1

Re: Say hello world... please... Solved
by Marten Jan de Ruiter 07 May '04

07 May '04

> use gpc -v to show invocation of collect2 OK, seems to see the right path (i.e. /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1 ), but no results. Checking the path shows an old library, dating from july of the previous year... weird, it cannot be found in the new build. Removal of libgpc.so resolves everyting :-) Thanks! Marten Jan /cluster3/deruiter 124 % ll /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1 total 21040 -rwxr-xr-x 1 deruiter staff … [View More] 8573062 May 7 16:34 cc1 -rwxr-xr-x 1 deruiter staff 355561 May 7 16:34 collect2 -rwxr-xr-x 1 deruiter staff 598881 May 7 16:34 cpp0 -rw-r--r-- 1 deruiter staff 1648 May 7 16:34 crtbegin.o -rw-r--r-- 1 deruiter staff 2036 May 7 16:34 crtbeginS.o -rw-r--r-- 1 deruiter staff 1952 May 7 16:34 crtbeginT.o -rw-r--r-- 1 deruiter staff 1216 May 7 16:34 crtend.o -rw-r--r-- 1 deruiter staff 1272 May 7 16:34 crtendS.o -rwxr-xr-x 1 deruiter staff 8431263 May 7 16:34 gpc1 -rwxr-xr-x 1 deruiter staff 186331 May 7 16:34 gpcpp drwxr-xr-x 7 deruiter staff 4096 May 7 16:34 include -rw-r--r-- 1 deruiter staff 1757576 May 7 16:34 libgcc.a -rw-r--r-- 1 deruiter staff 210436 May 7 16:34 libgcc_eh.a -rw-r--r-- 1 deruiter staff 600712 May 7 16:34 libgpc.a -rwxr-xr-x 1 deruiter staff 484434 Jul 25 2003 libgpc.so -rw-r--r-- 1 deruiter staff 6843 May 7 16:34 specs -rwxr-xr-x 1 deruiter staff 222854 May 7 16:34 tradcpp0 drwxr-xr-x 2 deruiter staff 4096 May 7 16:34 units /cluster3/deruiter 119 % gpc -v t.p -o t Reading specs from /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs Configured with: /cluster3/deruiter/system/src/gcc-3.2.1/configure --prefix=/cluster3/deruiter/system --enable-languages=pascal Thread model: posix gpc version 20030830, based on gcc-3.2.1 /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/gpcpp -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ t.p -famtmpfile=/tmp/cctInn8S.gpa /tmp/cc4FxSeC.i GNU Pascal Compiler PreProcessor version 20030830, based on gcc-3.2.1 (i386 Linux/ELF) /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/gpc1 /tmp/cc4FxSeC.i -quiet -dumpbase t.p -version -famtmpfile=/tmp/cctInn8S.gpa -o /tmp/cc9ISZwl.s GNU Pascal version is actually 20030830, based on gcc-3.2.1 GNU Pascal version 3.2.1 (i686-pc-linux-gnu) compiled by GNU C version 3.2.1. as -V -Qy -o /tmp/ccM54ZJ8.o /tmp/cc9ISZwl.s GNU assembler version 2.13.90.0.2 (i386-redhat-linux) using BFD version 2.13.90.0.2 20020802 /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o t /usr/lib/crt1.o /usr/lib/crti.o /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/crtbegin.o -L/cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1 -L/cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/../../.. /tmp/ccM54ZJ8.o -lgpc -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/crtend.o /usr/lib/crtn.o /tmp/ccM54ZJ8.o: In function `main': /tmp/ccM54ZJ8.o(.text+0x80): undefined reference to `__GPC_RTS_VERSION_20030830__' collect2: ld returned 1 exit status [View Less]

1 0

Say hello world... please...
by Marten Jan de Ruiter 07 May '04

07 May '04

Hi all, Trying to install gpc version 20030830 I ran into a problem with ld. Singling out the problem I have the following (trivial :-) pascal program t.p. The log shows all, I hope. including or excluding the line `uses gpc;' does not change the result. I do not know if I have to set things correct for ld, or that the system-wide install of gpc (version 20030507) interferes with my user-install in /cluster3/deruiter/system/bin Anyways, I do not get an executable, and all help is … [View More]

2 1

Size of 'Hello World'
by Claudiozm＠aol.com 07 May '04

07 May '04

I compiled two versions of 'Hello World!', one in C and the other in Pascal in the ctgwin environment, as follows: C source hello.c: int main() {printf("Hello World!\n");} command line: gcc hello.c -o helloc.exe Pascal source: program Hello; begin writeln('Hello World!') end. command line: gpc hello.pas -o hellopas.exe The sizes of the binaries I obtained were, respectively (copied from the DOS prompt dir command): HELLOC EXE … [View More]

6 13

How to avoid heap Marking
by Josef Urban 05 May '04

05 May '04

Hi, I am looking for a clean way, how to get rid of the heap marking in gpc-20030830. It seems to me that the simplest way how to do it now, is to comment the Mark (FirstMark) statement in system.pas:808 (initialization code), but I think that there should be a better way, particularly after reading this GPC posting: http://www.gnu-pascal.de/crystal/gpc/en/mail8202.html . It says: > PrepareDisposePointer shouldn't do much unless `Mark' is used > (anywhere in the program) which, e.… [View More]

2 6

How are objects saved to stream?
by Neil Santos 04 May '04

04 May '04

I've been using Pascal a while, but it was only recently that I decided to use Pascal for OO programming. Having only used records and typed files up to this point, I'm wondering how objects are saved to stream. Am I right in supposing that only instance variables are saved? If so, then what about the instance variables of objects inside an object? And the instance variables of objects inside an object, that's inside an object (and... you get the idea)? I know I should just try it and see … [View More]

4 4

Re: gpc compilation failed under BSD
by Thorsten Glaser 04 May '04

04 May '04

Dixitur illum ih8mj(a)fjf.gnu.de scribere... >> gpc-20030830 >> gcc-3.3.1 >Are you using GNU make? (If not, please do. You can install it in >parallel to BSD make, say as gmake, and invoke gmake instead of >make. You might have to restart building from scratch then.) Alternatively, you can use the port from MirOS (mirbsd.de), which uses BSD make, but only gcc-3.2.3 (propolice) with gpc-20030830. On the other hand, newer versions aren't officially supported anyways - plus … [View More]

1 0

MD5 unit
by Thorsten Glaser 01 May '04

01 May '04

Hello all! Recently I've discovered Frank (IIRC) telling us that the MD5 unit is, in contrast to all other units (I just double-checked), not licenced under the GNU LGPL, or GPL with library exception clause, but rather plain GPL because it contains code from Ulrich Drepper's glibc imple- mentation of the MD5 algorithm. I took the time and prepared a new, BSD-licenced, implementation of the code, while preserving the old framework (ie, interface), and having as few diffs against existing code … [View More]

5 18

Bug Report
by Frank D. Engel, Jr. 27 Apr '04

27 Apr '04

Not sure if this one has come up yet, but I have been experiencing some strange behavior in that some of my strings seem to disappear when used as parameters for procedure calls. I'm not in a position to offer a demo program, and unfortunately, this does not seem to happen in every situation, but here is in essence what is happening. Consider: TYPE STRING63 = STRING(63); FUNCTION x : STRING63; { returns a nonempty string } PROCEDURE y(z, t : STRING63); { ... } VAR a, b : … [View More]

4 8

write bug
by Russell Whitaker 26 Apr '04

26 Apr '04

Hi this program: program writebug; var b1, b2: string (80); f: Text; begin Assign (f, 'ref.txt'); Reset (f); readln (f, b2); while not eof(f) do begin ReadLn (f, b1); if b1 [ 1 ] = '=' then writeln( b2, ' ':64 - length( b2 ), 'bug') else WriteLn ( b2); b2 := b1; end; writeln ( b1); Close (f); end. Using either gpc built with gcc-3.3.3 or gcc-3.4.0 and this input file named ref.txt: The Alphabetical GPC Language Reference … [View More]

3 3

Re: gcc-3.4.0
by Russell Whitaker 26 Apr '04

26 Apr '04

Hi compiled & installed bison 1.875c, make check reported 7 errors. Traced problem to error in gcc-3.4: the default install of /usr/local puts libstdc++ in /usr/local/lib but the gcc code expects it to be in /usr/lib. Rebuilt gcc & installed using --prefix=/usr. Rebuilt bison & installed. Now make check reports all ok. So back to the patched version of gcc-3.4: rm -r * in the build directory to start clean. make -j3 bootstrap - it failed in p then "make bootstrap > emsgs 2… [View More]

4 8

Gcc-3.4
by David Kredba 25 Apr '04

25 Apr '04

Hello all, gpc seems to be very friendly with gcc-3.3.x, gpc testsuite is completely OK with it. How deep is change between gcc-3.3 and gcc-3.4 ? I don't study structure of gcc-3.4 thoroughly for the present, but i see that the build logic were changed. Configure scripts are now called by main Makefile after a little base configuration. Etc. Did you someone any research on it ? Thanks, David -- David Kredba <kredba at ibot.cas.cz> GPG: ID 1024/BB7FB39D Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE

6 19

gcc-3.4.0
by Russell Whitaker 23 Apr '04

23 Apr '04

Hi Grabbed Waldek's patches. Both gcc & gpc patched ok. Started bootstrap; found bison 1.35 was too old; Grabbed bison 1.875, & installed (there's a 1.875c - should I have used that instead? ). Then make bootstrap got this far: [..] make[3]: Nothing to be done for `generated-files'. make[3]: Leaving directory `/home/russ/src/gpc-20030830-3.4.0/p/rts' gcc -o p/parse.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -… [View More]

2 1

Re: Gcc-3.4
by Waldek Hebisch 23 Apr '04

23 Apr '04

Russell Whitaker wrote: > > > On Thu, 22 Apr 2004, Waldek Hebisch wrote: > [..] > > > > There are experimental patches on my gpc Web page... > > URL, please > http://www.math.uni.wroc.pl/~hebisch/gpc/ -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Re: Inaccurate information in `GNU' section
by Neil Santos 23 Apr '04

23 Apr '04

On 15:35 21/04/04, Peter N Lewis wrote: > >``Separate entity'' is rather vague; do you mean that it can run > >standalone, or do you mean that it does not contain code from any > >GPL-covered software? Both have to be true before you can consider > >releasing it under any license other than GPL. > > I'm confused by this. If it "does not contain code from any > GPL-covered software", then surely you can release it under any > license you feel like, … [View More]

3 2

Inaccurate information in `GNU' section of GPC info
by Neil Santos 23 Apr '04

23 Apr '04

While mulling over a confusing part of something I'm writing, I decided to browse the info pages of GPC. In the GNU section, I read this: When you modify a free program released under the GNU General Public License, e.g. the GNU Pascal compiler itself, your modified will become Free Software, too. I'm no lawyer, but I've read enough of RMS's articles regarding the GPL, as well as a few technical (but not necessarily legalese) discussions of the same, to understand that, when modifications … [View More]

5 11

Closing a file
by Andy Ball 22 Apr '04

22 Apr '04

Hello, Is there anything special that I need to do to commit a file to disk after I have written to it? My old Pascal book says to use... CLOSE(FILEHANDLE,LOCK); ...which gpc complains about. I have tried... CLOSE(FILEHANDLE); ...which compiles okay, but doesn't seem to commit the data (I wind up with a zero-length file. I've tried including the filename in the program parameters, which is suggested by the book, but gpc didn't seem to like that either. I'm also not sure … [View More]

8 21

Extended Pascal question
by Frank Heckenbach 21 Apr '04

21 Apr '04

Sometime ago I asked the following questions, but got no replies. What about the EP experts out there? ;-) A question to the EP experts. Are these things allowed? a) module m; export m = (a => a); const a = 1; end; end. b) module m; export m = (a => b, a => c); const a = 1; end; end. c) module m; export m = (a => b, a); const a = 1; end; end. Likewise for import (assuming m exports a): a) program p; import m (a => a); begin end. b) program p; import m (a => b, a => c)… [View More]

3 10

Re: MD5 unit
by Thorsten Glaser 20 Apr '04

20 Apr '04

Dixitur me scribere... >Okay, this is now a second try: ... this time for real, with attachement. //Thorsten -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r

1 0

Executable file size in MinGW environment
by André Eduardo Gabriel da Silva 20 Apr '04

20 Apr '04

Hello people! First of all, I'd like to thank you all that work on the development of the GPC compiler. It's a really good work. But I have a question, that I don't know exactly if it's run-time system's matter or a linker's matter. I'm using the following GPC (I've downloaded the binaries from the site): ----- gpc -v ----- Reading specs from c:\usr\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\specs Configured with: /src/mingw/gcc-3.2.3-20030504-1/configure --srcdir=/src/mingw/gcc-3.2.… [View More]

3 2

Re: Closing a file
by Scott Moore 19 Apr '04

19 Apr '04

I didn't see this appear in the list, sorry if it is redundant. > Scott Moore wrote: > > > UCSD has the form: > > > > close(filename, option) > > > > Where option is a "word": > > > > normal > > lock > > purge > > crunch > > > > Note that a filename (not handle or var file reference) is used, > > and that "word" as option pretty much requires close to be > > a compiler built-in statement. > > … [View More]

1 0

Re: separate
by Adriaan van Os 19 Apr '04

19 Apr '04

Prof. Harley Flanders wrote: > My memory is that it wasn't in the reference manual, but... > > If you used the word as an identifier in a program, the compiler > issued an error report (which of course I don't remember). > But I came to the conclusion that it was a secret reserved word. > > I think with UCSD even, you could redefine predefined identifiers. program test; type separate= integer; var i:separate; begin end. program test; var separate: integer; begin end. … [View More]

1 0

Delphi compatibility
by Prof A Olowofoyeku (The African Chief) 19 Apr '04

19 Apr '04

Hi I am not sure if we have discussed this before - but here goes anyway. Delphi (at least, from from version 2.0 onwards) allows routines that take no parameters to be called with empty brackets appended (e.g., "foo();"), much like C requires. See the test program below. GPC does not allow this. Is there any chance of supporting this in GPC? This program is valid in Delphi, but not in GPC ... program adelph; function bar : integer; begin bar := 1; end; procedure foo; begin Writeln … [View More]

7 24

separate
by Prof. Harley Flanders 19 Apr '04

19 Apr '04

To UCSD experts: If I remember right, Apple UCSD Pascal used to ahve a recerved word "separate". What did it mean? HF =========================================== Prof. Harley Flanders 3533 Windemere Court Ann Arbor, MI 48105-2867 Home: 734 668 1546 harley(a)umich.edu Visiting Professor University of Michigan Dept. of Mathematics, East Hall Ann Arbor, MI 48109 734 764 6451 Secretary: 734 764 6485 FAX: 734 763 0937 ===========================================

2 1

bug(s) and suggested improvements in gmp.pas
by Maurice Lombardi 15 Apr '04

15 Apr '04

Hi, all While using gmp for my own work gmp 4.1.2 for djgpp I have found small bugs in the interface gmp.pas which cause compiling errors when compiling for gmp 4 (it compiles fine with gmp 3) The diff file is attached: gmp.pas.minimal.diff While working with it I have found an other error in the provided arctan(x) function. It works only for |x| <= 1, diverges above. For |x|>1 the simplest way is to use arctan(x)+arctan(1/x)=pi/2 but the convergence of the corresponding series is … [View More]exceedingly slow at (near) |x|=1 I have programmed the same trick as in the QLib CEPHES library (which uses a home made 100 digits format instead of gmp), namely - use the previous formula to fold x above x=tan(3pi/8) = sqrt(2)+1 - use the formula arctan(x)=pi/4 +arctan((x-1)/(x+1)) to fold x comprised between tan(pi/8)=sqrt(2)-1 and tan(3pi/8)=sqrt(2)+1 The series has to be computed only for |x|<=0.414 where the speed of convergence is reasonable. In the CEPHES library Moshier uses a continuous fraction development instead of the series. I suppose this is a tradeoff speed/accuracy (not sure): the continuous fraction has only positive instead of alternating terms, which minimises rounding errors, but it is programmed with a fixed number of terms, of the order of the maximum number of terms in the series in the tests I have done, forbidding to benefit of the faster convergence for small |x|. I thus kept the series. Notice that pi included in these formulas is computed by a double call to arctan ! This is not a closed loop because pi needs only x=1/5 and x=1/239 below the lowest threshold. (Moshier uses a constant for pi because he has a fixed number of digits). I needed also the sin and cos functions. I have programmed the usual series development for sin, after reduction to the range [0,pi/2[, and cos(x)=sin(pi/2-x). All this is included in gmp.pas.full.diff, which includes also the diff contained in the minimal.diff (do not apply both). With this we have for gmp all the basic transcendental functions required for pascal (in the real type !) Hope this helps 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 --- gmp.pas.orig 2004-02-07 18:27:00.000000000 +0000 +++ gmp.pas 2004-04-10 16:06:24.000000000 +0000 @@ -330,7 +330,7 @@ {$endif} { New declarations in GMP 3.x. @@ Mostly untested! } -{$ifdef HAVE_GMP3} +{$if not defined (HAVE_GMP2)} { Available random number generation algorithms. } type @@ -359,8 +359,8 @@ end; procedure gmp_randinit (var State: gmp_randstate_t; Alg: gmp_randalg_t; ...); external name '__gmp_randinit'; -procedure gmp_randinit_lc (var State: gmp_randstate_t; a: {$ifdef HAVE_GMP4} protected var {$endif} mpz_t; c: MedCard; m: {$ifdef HAVE_GMP4} protected var {$endif} mpz_t); external name '__gmp_randinit_lc'; -procedure gmp_randinit_lc_2exp (var State: gmp_randstate_t; a: {$ifdef HAVE_GMP4} protected var {$endif} mpz_t; c: MedCard; M2Exp: MedCard); external name '__gmp_randinit_lc_2exp'; +procedure gmp_randinit_lc (var State: gmp_randstate_t; {$ifdef HAVE_GMP4} protected var {$endif} a: mpz_t; c: MedCard; {$ifdef HAVE_GMP4} protected var {$endif} m: mpz_t); external name '__gmp_randinit_lc'; +procedure gmp_randinit_lc_2exp (var State: gmp_randstate_t; {$ifdef HAVE_GMP4} protected var {$endif} a: mpz_t; c: MedCard; M2Exp: MedCard); external name '__gmp_randinit_lc_2exp'; procedure gmp_randseed (var State: gmp_randstate_t; Seed: mpz_t); external name '__gmp_randseed'; procedure gmp_randseed_ui (var State: gmp_randstate_t; Seed: MedCard); external name '__gmp_randseed_ui'; procedure gmp_randclear (var State: gmp_randstate_t); external name '__gmp_randclear'; --- gmp.pas.orig 2004-02-07 18:27:00.000000000 +0000 +++ gmp.pas 2004-04-10 17:17:52.000000000 +0000 @@ -330,7 +330,7 @@ {$endif} { New declarations in GMP 3.x. @@ Mostly untested! } -{$ifdef HAVE_GMP3} +{$if not defined (HAVE_GMP2)} { Available random number generation algorithms. } type @@ -359,8 +359,8 @@ end; procedure gmp_randinit (var State: gmp_randstate_t; Alg: gmp_randalg_t; ...); external name '__gmp_randinit'; -procedure gmp_randinit_lc (var State: gmp_randstate_t; a: {$ifdef HAVE_GMP4} protected var {$endif} mpz_t; c: MedCard; m: {$ifdef HAVE_GMP4} protected var {$endif} mpz_t); external name '__gmp_randinit_lc'; -procedure gmp_randinit_lc_2exp (var State: gmp_randstate_t; a: {$ifdef HAVE_GMP4} protected var {$endif} mpz_t; c: MedCard; M2Exp: MedCard); external name '__gmp_randinit_lc_2exp'; +procedure gmp_randinit_lc (var State: gmp_randstate_t; {$ifdef HAVE_GMP4} protected var {$endif} a: mpz_t; c: MedCard; {$ifdef HAVE_GMP4} protected var {$endif} m: mpz_t); external name '__gmp_randinit_lc'; +procedure gmp_randinit_lc_2exp (var State: gmp_randstate_t; {$ifdef HAVE_GMP4} protected var {$endif} a: mpz_t; c: MedCard; M2Exp: MedCard); external name '__gmp_randinit_lc_2exp'; procedure gmp_randseed (var State: gmp_randstate_t; Seed: mpz_t); external name '__gmp_randseed'; procedure gmp_randseed_ui (var State: gmp_randstate_t; Seed: MedCard); external name '__gmp_randseed_ui'; procedure gmp_randclear (var State: gmp_randstate_t); external name '__gmp_randclear'; @@ -395,6 +395,8 @@ procedure mpf_ceil (var Dest: mpf_t; protected var Src: mpf_t); external name '__gmpf_ceil'; procedure mpf_floor (var Dest: mpf_t; protected var Src: mpf_t); external name '__gmpf_floor'; +function mpf_get_si (protected var Src: mpf_t): MedInt; external name '__gmpf_get_si'; +function mpf_get_ui (protected var Src: mpf_t): MedCard; external name '__gmpf_get_ui'; procedure mpf_pow_ui (var Dest: mpf_t; protected var Src1: mpf_t; Src2: MedCard); external name '__gmpf_pow_ui'; procedure mpf_trunc (var Dest: mpf_t; protected var Src: mpf_t); external name '__gmpf_trunc'; procedure mpf_urandomb (ROP: mpf_t; var State: gmp_randstate_t; n: MedCard); external name '__gmpf_urandomb'; @@ -419,6 +421,8 @@ procedure mpf_pow (var Dest: mpf_t; protected var Src1, Src2: mpf_t); procedure mpf_arctan (var c: mpf_t; protected var x: mpf_t); procedure mpf_pi (var c: mpf_t); +procedure mpf_sin (var c: mpf_t; protected var x: mpf_t); +procedure mpf_cos (var Dest: mpf_t; protected var Src: mpf_t); implementation @@ -588,32 +592,57 @@ end; procedure mpf_arctan (var c: mpf_t; protected var x: mpf_t); -{ $$\arctan x = \sum_{n=0}^{\infty} (-1)^n \frac{x^{2n+1}}{2n+1}$$ } -var - p, mx2, c0, s: mpf_t; - Precision, n: MedCard; -begin - Precision := mpf_get_prec (c); - mpf_init2 (p, Precision); - mpf_set (p, x); - mpf_init2 (mx2, Precision); - mpf_mul (mx2, x, x); - mpf_neg (mx2, mx2); - mpf_init2 (c0, Precision); - mpf_init2 (s, Precision); - mpf_set (c, x); - n := 1; - repeat - mpf_mul (p, p, mx2); - mpf_div_ui (s, p, 2 * n + 1); - mpf_set (c0, c); - mpf_add (c, c, s); - Inc (n) - until mpf_eq (c0, c, Precision) <> 0; - mpf_clear (s); - mpf_clear (c0); - mpf_clear (mx2); - mpf_clear (p) +{ $$\arctan x = \sum_{n=0}^{\infty} (-1)^n \frac{x^{2n+1}}{2n+1}$$ + after double range reduction + around $\tan(3\pi/8)=\sqrt(2)+1$ with $\arctan x = \pi/2+\arctan(-1/x)$ + around $\tan(\pi/8)=\sqrt(2)-1$ with $\arctan x = \pi/4+\arctan((x-1)/(x+1))$ } +var + Precision, n: MedCard; + xx, mx2, a, b, aa, bb: mpf_t; +begin + Precision := mpf_get_prec (c); + mpf_init2 (xx, Precision); + mpf_init2 (mx2, Precision); + mpf_init2 (a, Precision); + mpf_init2 (b, Precision); + mpf_abs (xx, x); + mpf_sqrt_ui (a, 2); + mpf_sub_ui (b, a, 1); + mpf_add_ui (a, a, 1); + if mpf_cmp (xx, a) > 0 then begin + mpf_pi (c); + mpf_div_2exp (c, c, 1); + mpf_ui_div (xx, 1, xx); + mpf_neg (xx, xx) + end else if mpf_cmp (xx, b) > 0 then begin + mpf_pi (c); + mpf_div_2exp (c, c, 2); + mpf_init2 (aa, Precision); + mpf_init2 (bb, Precision); + mpf_sub_ui (aa, xx, 1); + mpf_add_ui (bb, xx, 1); + mpf_div (xx, aa, bb); + mpf_clear (aa); + mpf_clear (bb); + end else + mpf_set_ui (c, 0); + mpf_mul (mx2, xx, xx); + mpf_neg (mx2, mx2); + mpf_add (c, c, xx); + n := 1; + repeat + mpf_mul (xx, xx, mx2); + mpf_div_ui (a, xx, 2*n+1); + mpf_set (b, c); + mpf_add (c, c, a); + Inc (n) + until mpf_eq (b, c, Precision) <> 0; + if mpf_sgn (x) < 0 then + mpf_neg (c, c); + mpf_clear (xx); + mpf_clear (mx2); + mpf_clear (a); + mpf_clear (b); end; procedure mpf_pi (var c: mpf_t); @@ -633,4 +662,77 @@ mpf_clear (b) end; +procedure mpf_sin (var c: mpf_t; protected var x: mpf_t); +{ $$\sin x = \sum_{n=0}^{\infty} (-1)^n \frac{x^{2n+1}}{(2n+1)!}$$ + after reduction to range $[0,\pi/2[$ } +var + Precision, quadrant: MedCard; + sign: integer; + a, b, z, xx, c0: mpf_t; +begin + Precision := mpf_get_prec (c); + mpf_init2 (a, Precision); + mpf_init2 (b, Precision); + mpf_init2 (z, Precision); + mpf_init2 (xx, Precision); + mpf_init2 (c0, Precision); + sign := mpf_sgn(x); + mpf_abs (xx, x); + mpf_pi (z); + mpf_div_2exp (z, z, 1); + mpf_div (a, xx, z); + mpf_floor (xx, a); + if mpf_cmp_ui (xx, 4) >= 0 then begin + mpf_div_2exp (b, xx, 2); + mpf_floor (b, b); + mpf_mul_2exp (b, b, 2); + end else + mpf_set_ui (b, 0); + mpf_sub (b, xx, b); +{$if not defined (HAVE_GMP2)} + quadrant := mpf_get_ui (b); +{$else} + quadrant := round (mpf_get_d (b)); +{$endif} + mpf_sub (b, a, xx); + mpf_mul (xx, z, b); + if quadrant > 1 then + sign := -sign; + if (quadrant and 1) <> 0 then + mpf_sub (xx, z, xx); + mpf_mul (z, xx, xx); + mpf_neg (z, z); + mpf_set_ui (a, 1); + mpf_set_ui (b, 1); + mpf_set_ui (c, 1); + repeat + mpf_add_ui (a, a, 1); + mpf_div (b, b, a); + mpf_add_ui (a, a, 1); + mpf_div (b, b, a); + mpf_mul (b, b, z); + mpf_set (c0, c); + mpf_add (c, c, b); + until mpf_eq (c0, c, Precision) <> 0; + mpf_mul (c, c, xx); + if sign < 0 then + mpf_neg (c, c); + mpf_clear (a); + mpf_clear (b); + mpf_clear (z); + mpf_clear (xx); + mpf_clear (c0); +end; + +procedure mpf_cos (var Dest: mpf_t; protected var Src: mpf_t); +var Temp: mpf_t; +begin + mpf_init2 (Temp, mpf_get_prec (Dest)); + mpf_pi (Temp); + mpf_div_2exp (Temp, Temp, 1); + mpf_sub (Temp, Temp, Src); + mpf_sin (Dest, Temp); + mpf_clear (Temp); +end; + end. [View Less]

2 3

OT: SPAM in my name
by Eike Lange 12 Apr '04

12 Apr '04

Hi Folks! My sender address is used by spamers: > From: eike.lange(a)uni-essen.de > To: gpc(a)gnu.de > Subject: Re: [gpc] Protected Mail Request Please do not reply to me, as I receive hundreds of spams and reply to SPAM, which is sent in my name each day. I never send files or binary attachments to mailing lists. Please keep in mind, that your address might be used by spammers, too. Eike -- ::NETZ-STREIK:: http://www.gnushi.de/ ::NETZ-STREIK::

1 0

Re: Protected Mail Request
by eike.lange＠uni-essen.de 12 Apr '04

12 Apr '04

ESMTP [Secure Mail System #334]: Secure message is attached. ++++ Attachment: No Virus found ++++ F-Secure AntiVirus - www.f-secure.com

1 0

GPC ISO 7185 compliance data
by Scott Moore 09 Apr '04

09 Apr '04

I have posted ISO 7185 compliance data for GPC on my web site: http://www.moorecad.com/standardpascal/compiler.html I welcome any comments or corrections you might have. In addition, there is a section for the "makers comments" (I can't say "vendor" because some compilers are free :). If you wish for me to add your commentary for this section, please send it to me.

4 11

GPC and EP -- restriced types
by Waldek Hebisch 09 Apr '04

09 Apr '04

AFAIKS GPC implements resticted types quite unlike what EP requires. 1) Restriced types should be different then underlying type (6.4.1 says that restricted-type is a new-type, and new-type is different from other types. So according to rules for return values the following program (accepted by GPC in EP mode) is incorrect: program prog; type a=0..5; b= restricted a; var c:a; procedure foo(function bar:b); begin end; function baz:a; begin baz := c end; begin foo(baz) end . 2) … [View More]

5 8

Old mails in the archive
by Frank Heckenbach 04 Apr '04

04 Apr '04

Hi, some old mails (from the time 1999-2001) that Anja Gerwinski found on an old server are now available in the online archives of gpc-doc and gpc-announce. (They are numbered 0 and below, to avoid shifting the numbers of current mails.) Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

Problems building gpc-20030830 on mingw
by Markus Gerwinski 03 Apr '04

03 Apr '04

Hi folks, I'm currently trying to build gpc-20030830 on Windows XP with mingw. After unpacking, copying and `configure --enable-languages=pascal`ing, `make` aborts with the error message: make[1]: Circular libgcc.a <- pascal dependency dropped. In file included from config/i386/mingw32.h:31, from tconfig.h:16, from libgcc2.c:36: config/i386/cygwin.h:31:19: stdio.h: No such file or directory In file included from config/i386/mingw32.h:31, from tconfig.h:16, from … [View More]libgcc2.c:36: config/i386/cygwin.h:447: parse error before '*' token config/i386/cygwin.h:447: warning: function declaration isn't a prototype config/i386/cygwin.h:449: parse error before '*' token config/i386/cygwin.h:449: warning: function declaration isn't a prototype In file included from libgcc2.c:37: tsystem.h:63:19: stdio.h: No such file or directory tsystem.h:66:23: sys/types.h: No such file or directory tsystem.h:69:19: errno.h: No such file or directory tsystem.h:76:20: string.h: No such file or directory tsystem.h:80:20: stdlib.h: No such file or directory tsystem.h:81:20: unistd.h: No such file or directory In file included from C:/msys/1.0/mysoftware/gcc-3.2.1/gcc/include/limits.h:132, from C:/msys/1.0/mysoftware/gcc-3.2.1/gcc/include/syslimits.h:7, from C:/msys/1.0/mysoftware/gcc-3.2.1/gcc/include/limits.h:11, from tsystem.h:84, from libgcc2.c:37: include/limits.h:132:75: limits.h: No such file or directory In file included from libgcc2.c:37: tsystem.h:87:18: time.h: No such file or directory make[2]: *** [libgcc/./_muldi3.o] Error 1 make[1]: *** [libgcc.a] Error 2 make: *** [all-gcc] Error 2 After in the Makefile.in I added -I$(srcdir)/fixinc/tests/base to the include path, only this error message remained: rm: `include' is a directory rm: `include' is a directory config.h is unchanged hconfig.h is unchanged tm_p.h is unchanged In file included from config/i386/mingw32.h:31, from config.h:18, from cppdefault.c:25: config/i386/cygwin.h:447: parse error before '*' token config/i386/cygwin.h:447: warning: function declaration isn't a prototype config/i386/cygwin.h:449: parse error before '*' token config/i386/cygwin.h:449: warning: function declaration isn't a prototype make[1]: *** [cppdefault.o] Error 1 make: *** [all-gcc] Error 2 These lines in the source refer to a macro(?) named FILE that seemingly isn't defined anywhere. Does anyone have an idea what I'm doing wrong? -- My MinGW installation directory is just C:\MinGW, so all of the important system headers should be found in C:\MinGW\include. I'm compiling from within my msys directory tree, which is situated at C:\msys\1.0. Any ideas will be welcome. Thanks in advance, Markus [View Less]

3 20

Graph
by Prof. Harley Flanders 03 Apr '04

03 Apr '04

Does anyone know how to get the Graph unit to compile? Thank you, HF =========================================== Prof. Harley Flanders 3533 Windemere Court Ann Arbor, MI 48105-2867 Home: 734 668 1546 harley(a)umich.edu Visiting Professor University of Michigan Dept. of Mathematics, East Hall Ann Arbor, MI 48109 734 764 6451 Secretary: 734 764 6485 FAX: 734 763 0937 ===========================================

4 15

File names and ChDir
by Frank Heckenbach 03 Apr '04

03 Apr '04

Hi, there's a strange case when using relative file names and changing the directory. (Incidentally I was made aware of this by a bugfix in the ncurses library (C code) some while ago ... ;-) Consider this program: program Foo; var i: Integer; f: Text; begin Assign (f, 'test.dat'); Rewrite (f); WriteLn (f, 42); Close (f); ChDir ('..'); Reset (f); ReadLn (f, i); WriteLn (i) end. It fails under both GPC and BP because `Reset' tries to open a file `test.dat' in a different … [View More]

5 7

Re: internal error in gpc
by Adriaan van Os 02 Apr '04

02 Apr '04

In the Macintosh Pascal mailing list (<http://pascal-central.com/maillist.html>) Scott Lindhurst wrote: > I just started playing around with gpc, working on getting some old > code to work with it, and have found a bug. This is version 3.3.2d1, > just downloaded a few days ago with the accompanying GPCInterfacesB2, > on OS X 10.2.8. > > I get the message "gpc: Internal error: Illegal instruction (program > gpc1)" when compiling the following program: > > … [View More]program bug; > > uses > GPCMacOSAll, GPCStringsAll; {No error if remove GPCStringsAll} > > var > tix: UInt32; {No error if change to integer or longint} > begin > tix := 1; > > if tix > TickCount then {error while processing this line} > tix := 2; > end. > > My makefile generates this command line (which is going to be wrapped, > sorry): > gpc --automake --unit-path=./:/Developer/Pascal/GPCPInterfaces/ > --object-path=./build/ --unit-destination-path=./build/ > --executable-path=./build/ > -Wl,-framework,Carbon,-framework,ApplicationServices -o ./bug -Wl,-x > -O2 -Wall -Wno-identifier-case --ignore-garbage-after-dot > --longjmp-all-nonlocal-labels ./bug.pas > > but the internal error can be reproduced with just > gpc --unit-path=/Developer/Pascal/GPCPInterfaces/ ./bug.pas > > I have the workaround of using integer or longint instead of UInt32. Peter N. Lewis helped out by noting that "limit stacksize 8096" solves the problem. This is true, but still it is strange that the compiler needs such a huge amount of stack for compilation. So, I wonder if maybe there is indeed a problem in the compiler, solved only "by accident" by a stacklimit of nearly a megabyte. When I set "limit stacksize 4096", the backtrace reads: Date/Time: 2003-11-07 11:36:46 +0100 OS Version: 10.2.8 (Build 6R73) Host: G4.local. Command: gpc1 PID: 437 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7fff0 Thread 0 Crashed: #0 0x000a9dc8 in tree_size (tree.c:161) #1 0x000aa024 in make_node (tree.c:237) #2 0x000c6980 in alloc_node (stringpool.c:70) #3 0x0024b4b0 in ht_lookup (hashtable.c:162) #4 0x000c6b1c in get_identifier (stringpool.c:109) #5 0x0001bb04 in get_operator (expressions.c:425) #6 0x0001c7e4 in build_pascal_binary_op (expressions.c:661) #7 0x0001c514 in parser_build_binary_op (expressions.c:583) #8 0x0000dd48 in yyuserAction (parse.c:4580) #9 0x000136c8 in yydoAction (parse.c:8238) #10 0x00013190 in yyglrReduce (parse.c:8290) #11 0x000124d0 in main_yyparse (parse.c:8991) #12 0x000a49c0 in compile_file (toplev.c:2134) #13 0x000a9c38 in do_compile (toplev.c:5402) #14 0x000a9d04 in toplev_main (toplev.c:5432) #15 0x00001fa8 in _start (crt.c:267) #16 0x00001e28 in start PPC Thread State: srr0: 0x000a9dc8 srr1: 0x0200f930 vrsave: 0x00000000 xer: 0x20000000 lr: 0x000a9dc0 ctr: 0x000c6968 mq: 0x00000000 r0: 0x000aa024 r1: 0xbff80040 r2: 0x6c616773 r3: 0xbff80080 r4: 0x0000002a r5: 0x0000002a r6: 0x00000001 r7: 0x00000002 r8: 0x727900e4 r9: 0x002e8a28 r10: 0x02a4f000 r11: 0x00020000 r12: 0x48042447 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00387e40 r19: 0x002eb814 r20: 0x00000000 r21: 0x00000001 r22: 0xbff80200 r23: 0x0000002a r24: 0x0000b04b r25: 0xe972469b r26: 0x00883890 r27: 0x00000078 r28: 0x00000000 r29: 0x00011a6c r30: 0x00000001 r31: 0x000a9dc0 [G4:~] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs Configured with: ../gpc-332d1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, based on gcc-3.3.2 The same problem also occurs with the previous alpha and gcc-3.3, but the backtrace is different: Date/Time: 2003-11-07 11:34:03 +0100 OS Version: 10.2.8 (Build 6R73) Host: G4.local. Command: gpc1 PID: 404 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbff7ffe0 Thread 0 Crashed: #0 0x000c3b74 in alloc_page (ggc-page.c:660) #1 0x000c2b24 in ggc_alloc (ggc-page.c:1026) #2 0x0009c430 in make_node (tree.c:292) #3 0x000c25ac in alloc_node (stringpool.c:70) #4 0x0023cd30 in ht_lookup (hashtable.c:161) #5 0x000c2748 in get_identifier (stringpool.c:109) #6 0x000097d4 in get_operator (expressions.c:426) #7 0x0000a478 in build_pascal_binary_op (expressions.c:656) #8 0x0000a1ac in parser_build_binary_op (expressions.c:578) #9 0x0002d8d8 in main_yyparse (parse.c:2400) #10 0x00096e88 in compile_file (toplev.c:2134) #11 0x0009c03c in do_compile (toplev.c:5370) #12 0x0009c108 in toplev_main (toplev.c:5400) #13 0x000018a8 in _start (crt.c:267) #14 0x00001728 in start PPC Thread State: srr0: 0x000c3b74 srr1: 0x0000f930 vrsave: 0x00000000 xer: 0x00000000 lr: 0x000c3b6c ctr: 0x0009c3a0 mq: 0x00000000 r0: 0x000c2b24 r1: 0xbff80060 r2: 0x6c616773 r3: 0x00000023 r4: 0xbff80280 r5: 0x00000027 r6: 0x00000000 r7: 0x00000003 r8: 0xbff80100 r9: 0x002db53c r10: 0x00000001 r11: 0x0000002c r12: 0x88048444 r13: 0x00000003 r14: 0x000000c8 r15: 0xbfffec80 r16: 0x00000034 r17: 0x00000000 r18: 0x0036c9a0 r19: 0x002d94e4 r20: 0x00000000 r21: 0x02fa3e70 r22: 0x00000001 r23: 0xbff80280 r24: 0x00302ad0 r25: 0x00302ad0 r26: 0x00824890 r27: 0x0000008c r28: 0x03423e70 r29: 0x0000002c r30: 0x002fc69c r31: 0x000c3b6c The needed units can be found at <www.microbizz.nl/GPCMacOSAll.pas.bz2> and <www.microbizz.nl/GPCStringsAll.pas.bz2>. They were too large to include with this message. Regards, Adriaan van Os [View Less]

4 6

interface and implementation
by mkhaldi＠gosympatico.ca 02 Apr '04

02 Apr '04

I have a question about implementation and interface. If i want only to get the interface from a module which has an implementation module, how must I do to get also the symbol init_XXXXX?? example : ---------------------------------------------- module a interface; export a =all; type string80 = string(80); procedure p; end. module a implementation; procedure p; ...... ...... end. module b interface; export b =all; import a; end. module b impleementation; .... end. I just want to get the … [View More]

3 2

Open source tax
by Adriaan van Os 01 Apr '04

01 Apr '04

Today, the government in The Netherlands introduced a tax on free and open source software. The purpose of the tax is to "protect the local commercial software industry from unfair compettion from open source and free software projects". For details, see linux news at <http://www.nedlinux.nl/modules/news/index.php?action=showitem&id=1001>. Regards, Adriaan van Os

3 3

multiprocessor use w/ GPC compiled program (OT?)
by Boris Herman 01 Apr '04

01 Apr '04

Hi list, I have compiled a single-threaded (and quite non MP aware) pascal program that does a lot of numerical computations. One calculation takes about 5 days on my 1.25 GHz DDR G4 (single cpu) and I need about 200 computations to do. Well, when I run the program on my G4 it takes up all CPU time (cca 93%-95%). I thought of speeding the whole thing by running it on a dual processor machine so I got someone to run it on a dual 2 GHz G5. So here comes the problem. If only one instance is … [View More]

6 5

Re: Open source tax
by Theo.CarrBrion＠mitrefinch.co.uk 01 Apr '04

01 Apr '04

How about a tax on software that has an unfair monopoly. Theo Carr-Brion -----Original Message----- From: Adriaan van Os [mailto:gpc@microbizz.nl] Sent: 01 April 2004 14:56 To: gpc(a)gnu.de Subject: Open source tax Today, the government in The Netherlands introduced a tax on free and open source software. The purpose of the tax is to "protect the local commercial software industry from unfair compettion from open source and free software projects". For details, see linux news at … [View More]

1 0

packed records' address again
by Francesco Bonomi 31 Mar '04

31 Mar '04

I have been following the "cannot take address of packed record" thread and now I have a similar problem. I perfectly understand that doing a strcopy is an implicit conversion, but I think that the program gets carried away during checks :-) I had a VERY complex data structure and it took me quite a while to reduce it to the minimum, please bear with me if it's anyway a bit intricate. let's have the following definitions: type char_arr = array[1..30] of char; smallrec = RECORD arr : … [View More]

6 8

gpc reference reader
by Russell Whitaker 29 Mar '04

29 Mar '04

hi The attachment, readhelp.pas.gz, is a simple, fast reader for the reference portion of the gpc manual. Uncompress with gunzip. The first few lines after the start is a "readme". Be sure to read it before compiling. The plan here is to merge this program with an updated version of the simple Pascal Editor I contributated a little over a year ago. When done will contribute the result. Meanwhile, perhaps this little program will encourage someone to work on the gpc manual. russ

1 0

Mailing list problems (March 20-23)
by Frank Heckenbach 27 Mar '04

27 Mar '04

Hallo, due to a problem when installing spam and virus filters, the mailing lists were out of order from last Saturday till Tuesday. Incoming mails were probably dropped without notice. If you sent any mail to the lists in this time, please check in the archives to find out if it got through, and otherwise please resend it. Sorry for the inconvenience, 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-… [View More]

1 0

ISO 7185 compliance issue for GPC
by Scott Moore 25 Mar '04

25 Mar '04

Hello, My name is Scott A. Moore, I am the person who performed some of the ISO 7185 compliance testing on GPC. I have done a minor update to some of my ISO 7185 compliance testing material, and reran this against the current version of GPC (2.95). In the process, I have discovered a compliance problem with GPC. Please reference the program: ============================================================== program test(output); var f: text; c: char; begin rewrite(f); writeln(f, '… [View More]how now'); writeln(f, 'brown cow'); reset(f); write(''''); while not eof(f) do begin if eoln(f) then write('<eoln>'); read(f, c); write(c) end; write(''''); writeln(' s/b ''how now<eoln> brown cow<eoln> '''); rewrite(f); writeln(f, 'too much'); write(f, 'too soon'); reset(f); write(''''); while not eof(f) do begin if eoln(f) then write('<eoln>'); read(f, c); write(c) end; write(''''); writeln(' s/b ''too much<eoln> too soon<eoln> '''); end. ================================================================ The results from GPC for running this command are as follows: ================================================================ C:\TEST>test 'how now<eoln> brown cow<eoln> ' s/b 'how now<eoln> brown cow<eoln> ' 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> ' C:\TEST> ================================================================ The first section of the test verifies that eoln in text file is replaced with space, GPC passes this. The second section of the test verifies that eoln is automatically inserted at the end of a text file if it was terminated without a eoln. See ISO 7185 section 6.4.3.5: ===================================================================== There shall be a file-type that is denoted by the required structured-type-identifier text. The structure of the type denoted by text shall de ne an additional sequence-type whose values shall be designated lines. A line shall be a sequence cs ~S(end-of-line), where cs is a sequence of components possessing the char-type, and end-of-line shall represent a special component-value. Any assertion in clause 6 that the end-of-line value is attributed to a variable other than a component of a sequence shall be construed as an assertion that the variable has attributed to it the char-type value space. If l is a line, then no component of l other than l.last shall be an end-of-line. There shall be an implementation-defined subset of the set of char-type values, designated characters prohibited from text les; the effect of causing a character in that subset to be attributed to a component of either t.L or t.R for any text le t shall be implementation-dependent. A line-sequence, ls, shall be either the empty sequence or the sequence l ~ ls' where l is a line and ls' is a line-sequence. Every value t of the type denoted by text shall satisfy the following two rules: a) If t.M = Inspection, then t.L ~t.R shall be a line-sequence. b) If t.M = Generation, then t.L ~t.R shall be ls ~cs, where ls is a line-sequence and cs is a sequence of components possessing the char-type. ==================================================================== Basically, the rules say that a text file shall consist of either whole lines, or be entirely empty. Whole lines are defined as "~S(end of line)", or a series of arbitrary characters terminated by end of line. In effect, the program processor must arrange for eoln to be true at the end of a file, either by faking it while reading, or by forcing an eoln to be written at the end of a file during generation. Thank you for your attention. [View Less]

4 11

Minor issue: command line parameters
by Scott Moore 23 Mar '04

23 Mar '04

From: Scott A. Moore Hello, A minor "it would be nice" request for you all. I have been working on personally certifying the compliance of several ISO 7185 compilers this last week. You all are no doubt aware that the ISO 7185 specifies header parameters such as: program test(input, output, file1, file2); ... Although ISO 7185 does not specify the mechanisim, most implementors have given a means to connect the header parameter files to external, named files, including the original Wirth … [View More]implementation of Pascal on the CDC 6000 computer. GPC does this as well. Here is a roundup of the compilers that I have either tested or have seen the results of testing on: 1. Irie Pascal, header parameters are automatically connected to command line parameters in order of appearance, I.e., program test(input, output, file1, file2); appear on the command line: > ivm test thisfile thatfile 2. Compaq Pascal, header parameters can be connected to files by special command line syntax: > test $input=thisfile $output=thatfile 3. CDC 6000 Pascal (Wirths original), the command parameters are specified in a SCOPE operating system statement: EXECUTE,TEST(INPUT,OUTPUT,THISFILE,THATFILE) 4. GPC, each unfufilled program parameter is prompted for: > test Input file `File1': thisfile Input file `File2': thatfile 5. IP Pascal, header parameters are automatically connected to command line parameters in order of appearance, I.e., program test(input, output, file1, file2); appear on the command line: > test thisfile thatfile The ISO 7185 method of specifying program parameters is not much use without the (standard undefined) means of connecting them to outside parameters, so this is good. However, I also note that GPC does not provide a means to automatically connect these files, but requires operator intervention to do this. I wonder if I could talk you guys into implementing a slight enhancement to GPC, that is completely compatible with your present methodology ? The method of connecting program parameters to command line parameters is attractive. The FPC authors have expressed an interest in implementing it. For GPC, to keep compatibility with your present methods, I would suggest: If a program parameter file is present, and it can also be determined that a command line argument exists for it, then get that from the command line instead of prompting the user. This continues for as many parameters as exist in the program header. The command line parameters (argv/argc) can either be reduced at the left to remove the program parameters used as filenames, or the command line can be left alone. There are arguments for each method. Anyways, this would serve to further unify the operation methodologies of existing (and popular) ISO 7185 compilers, which is, I am happy to say, a growing club. Thank you for the consideration. [View Less]

2 2

Re: Dereferencing variables of type Pointer
by Neil Santos 18 Mar '04

18 Mar '04

[Resent because I forgot to change To: field again. Damn it.] * [100304 :: 0133] Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > > I apologize for the vagueness of my original post. It was written at > > the end of the very tiring day (or the start of one; depends on how you > > look at it). > > I know. :-) Sometimes I begin to despise my choice to try and become a programmer--or, rather, try to be competent enough in programming to fake being a programmer. … [View More]But then I remember that I know nothing else, and would have to feed my family with food bought through the money I'm hoping to earn through coding. :D > > inheritance for all the objects that need to be written to and read from > > a file, > > ... using a virtual method. That would be the OOP approach. I opted for a root object that has as a member an object that implements an interface for accessing data streams from a disk. Sounds more complicated than it is in code. :P > > but I'm lazy, and since these functions will be doing basically > > the same thing (managing binding types, reading to/writing from > > streams), > > Which could be done in a common ancestor's method. (No-one ever said > OOP would reduce the number of routines in total ... ;-) Aye. A teacher of mine tried to argue so; so I slapped him down. But, like I said, I'm lazy; so I still look for ways to have object orientation with reduced coding. I like having my cake and eating it, too. :) > BTW, if you don't want to be Extended Pascal conformant (and you > obviously don't), you can use GPC extensions such as: While I'll admit to not gunning for conformance, I like to stick to it as much as I can. But when I encounter limitations in the languages I use, I try to find ways that work around them. If there aren't, I try to make some. > There is no such thing as runtime type information in GPC. What you Which I sorely miss, coming from a Windows/Delphi background. [everything else snipped for brevity] I've been mulling over your suggestions for the past few days--and I must admit ignorance for a lot of the things you've said. Like I said, I'm lazy, and I like having my cake and being able to eat it, as well; so here's what I've done. I have a root object which implements a several functions that is common for all the Type 1* objects I have, and also has a member object that implements the disk-access functions I need. Part of the creation of a Type 1 object involves passing the parameters needed by the disk-access object's constructor, all of which are contained in a RRecdStream record. The RRecdStream record is declared as such: RRecdStream = record { pointer to the structure to be written } recd_ptr = pointer; { byte; denotes what kind of structure is held by recd_ptr } recd_type = TRecordType; { MAX_PATH_LEN is 2060 bytes; as defined in GPC 20030830. Is there any way to retrieve this at runtime? } file_name = string(MAX_PATH_LEN); end; And, oh, is there any way to turn a constructor into a function? :P The disk-interface module is *very* incomplete as of now, but I would gladly send it to anyone who's interested; or, for that matter, a tar-gzip'd file of the whole project. * A `Type 1' (made up term) object in this context is an object that has a member variable that gets written to/read from a stream. -- - Neil Santos Freelance Programmer & Web Designer - - http://nsantos.f2o.org/ Free Software advocate - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GAT d+@ s+:+ a? C++++ UL*++++ P++ L++ E--- W+++(--) N-- !o !K w(++) !O M-- V? PS++ PE-- Y++ PGP+ t* 5-- X- R++ tv+ b++>+++ DI+++ D--- G e>+++++ h r++ y? ------END GEEK CODE BLOCK------ Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html [View Less]

3 5

ld returned 1 exit status
by gunday＠poczta.onet.pl 17 Mar '04

17 Mar '04

The situation is just as follows: {----------- begin --------------} [ja@unicorn ja]$ cat test.pas program test; begin writeln('Hello World'); readln; end. [ja@unicorn ja]$ gpc test.pas /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x595): In function `_p_UpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:897: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-… [View More]

3 5

Re: ld returned 1 exit status
by Emil Jerabek 17 Mar '04

17 Mar '04

On Tue, Mar 16, 2004 at 07:14:51PM +0100, Tomasz Gandor wrote: > W li?cie z wto, 16-03-2004, godz. 17:44, Emil Jerabek pisze: > > > I've built Fedora binaries now (.tar.gz, I have no idea how to create > > rpm packages). Where can I upload it? > > There is no problem - if you have the tarball, you should use the > rpmbuild command (if you have installed all programmers packages, > as I did, you must have it). I guess it may be present in the > very basic … [View More]

1 0

Re: Building with non-GNU make(1)
by Frank Heckenbach 16 Mar '04

16 Mar '04

Thorsten Glaser wrote: > >exactly 22 leap seconds until then (since 1970-01-01), so if we > >treat both 48 and 26 as correct, will this be sufficient? > > Until the next leap second occurs, yes. But it seems like > there won't be another for a few semesters at the moment, > dur to changing earth rotation. But leap seconds are not inserted into the past, I suppose. As I said, it tests a fixed date (1999-11-29, for no particular reason, I think it was when the test was … [View More]

1 0

Re: Building with non-GNU make(1)
by Frank Heckenbach 16 Mar '04

16 Mar '04

Thorsten Glaser wrote: > >> Seems like there is some preprocessor work to do, but look at > >> that locate output below. I have no idea why the file isn't found. > > > >> tg@odem:/home/tg/gpc-20030830/p/test $ locate gpc-in-c.h > >> /usr/lib/gcc-lib/i386-ecce-mirbsd7/3.2.3/include/gpc-in-c.h > > > >Does `gpc --print-file-name=include/gpc-in-c.h' find it? > > tg@odem:/home/tg $ gpc --print-file-name=include/gpc-in-c.h > /usr/lib/… [View More]

1 0

Building with non-GNU make(1)
by Thorsten Glaser 15 Mar '04

15 Mar '04

Hello people, has anybody ever _successfully_ built gcc+gpc with BSD make? The hard I try, I only get a circular dependency which I don't find in the generated Makefile or the input graph (maybe I'm just too stupid tho). All other front-ends I have (c,c++,objc,fortran,ada) build with BSD make just fine (after minor, or - for ada - heavy, adjustments tho). If anybody would like to resolve that, I can send the Makefile or input graph before or after processing. Please tell me. cu, Thanks in … [View More]

2 7

Re: Dereferencing variables of type Pointer
by Neil Santos 09 Mar '04

09 Mar '04

[Resent; stupid me forgot to change the To: field, and I've been waiting for the past two days for a reply. :P ] I apologize for the vagueness of my original post. It was written at the end of the very tiring day (or the start of one; depends on how you look at it). Anyway, here's what I failed to provide the first time around. I hope this is much more useful. I have several objects with no common parent, though all of them have a private member called structure. With each object, `… [View More]

3 2

2025

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