ih8mj at fjf.gnu.de
Sun Dec 19 01:24:03 CET 2004
Steven Bosscher <stevenb at 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
> 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:
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
> > 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
> 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
- 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.
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
> > 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 Heckenbach, frank at g-n-u.de
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
More information about the Gpc