Steven Bosscher stevenb@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