Gpc

gpc@gnu.de

5400 discussions

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 declaration of InstallSignalHandler and tried the same with aSig's type changed to CInteger. It compiled fine, except when the --delphi switch was on, because then CInteger seemed to be unknown ;-( Do you have any suggestions how to fix this problem? Any help appreciated. I used the freshly uploaded beta gpc version 20041218, based on gcc-3.3.3. Best, Adam Naumowicz ====================================================================== Department of Applied Logic fax. +48 (85) 745-7662 Institute of Computer Science tel. +48 (85) 745-7559 (office) University of Bialystok e-mail: adamn(a)mizar.org Sosnowa 64, 15-887 Bialystok, Poland http://math.uwb.edu.pl/~adamn/ ======================================================================

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 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)

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 Frank has already said that). //mirabile

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 function from incompatible pointer type gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 failed TEST pipetest.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 function from incompatible pointer type gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 failed" The same tests are failed under Mingw, regardless of the underlying gcc version. Any ideas? Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

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, it looks like that GPC is a part of the GNU project. <http://gnu-pascal.de/gpc/h-gnu.html> 2. So is GCC (obvious). 3. At one point, there was an item under the "GNU Help Wanted" list on Savannah: <http://savannah.gnu.org/people/?group=tasklist>, that asked for new languages for GCC. Unfortunately, I don't see this item there now. So why isn't GPC integrated? If the FSF has the copyright for the Pascal front-end, why can't anybody just take the available patches and start moving them over and getting them worked up? Eric

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

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

Jump to page:

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