Re: Criteria for GCC 4.0

[Steven Bosscher <stevenb at suse dot de>]

On Tuesday 01 June 2004 10:03, Phil Edwards wrote:
> [I'm on the list, no need to Cc me on replies.]
>
>
> Thought I'd post something inflammatory and controversial just before
> leaving for a week.  (And then encountering all the offended people in
> person in Ottawa, yay!)
>
> The recurring 3.5-vs-4.0 thing is sure to come up, so I thought I'd
> generate some discussion by providing my opinion, and talking points,
> on why we don't have 4.0 material yet.
>
>     http://www.jaj.com/space/phil/40.html
>
> See y'all in 14 hours or so.

Since I'm not going to see any of y'all 14 hours from now, I'll give
you the reaction my little insignificant brain produced.  Let me fuel
the fire you want to start! :-)


> I love tree-ssa. It's finally an internal representation that I can
> understand. Those developers put in a tremendous effort and I will
> be buying each of them beer at the Summit to show my appreciation.
> But it's not deserving of a major number change, for this reason:
> the users won't care.

Right.  This is a disputable observation because there are a ton of
user visible changes, most importantly in the generated code and in
the new flags, the new fortran front end and the (most likely)
missing Ada front end.  But indeed, if all you care about is C/C++
then there are not that many for the average Joe User.


> (...)there is little/no technical reason at present to call it 4.0,
> only marketing. I will go further and state that right now, we don't
> even have a good marketing reason to call the next release 4.0.

It's a shame you don't give a rationale for your statement. I believe
that there's too much resistance against marketing, because GCC is a
product that has to compete with compilers that _do_ change numbers
for marketing reasons.

(No this is not a technical argument, but a valid _economic_ argument.
Many of us make money by working on GCC, and we have to sell that
work as a "product".  Why can't GCC give a little help by not being so
anti-marketing.)


> Okay, what does deserve a 4.0?
>
> That's another easy one: a serious break in backwards compatability.
> Stuff that works in version x.y is expected to keep working in x.(y+1),
> but not necessarily in (x+1).0.

By your reasoning, GCC 3.4.0 should have been GCC 4.0, because of the
new C++ front end (which is undoubtedly a far more visible change than
the new fortran front end) which does break compatibility.

(In retrospect, I'm very disappointed that bumping the major version
number was never even considered for 3.4.)


> What are these changes you keep blathering about?
>
> Right, so here's a list. I'll keep the numbers the same and won't
> reassign them as the list changes.
>
> The driver needs to know what runtime libraries to link in on a
> per-language basis.

Excuse me, but I don't think this is even desirable.  We have the
special-purpose drivers for that and I would encourage people to use
them instead.  In fact, I would much rather see that the 'gcc' driver
would be _only_ the C compiler.
Also, this change is not much more user-visible than the new options
coming from tree-ssa, since most people use the language-specific
driver program already anyway.


> -Wall needs to mean all warnings. If we want to have a switch that
> means "most of the warnings," or "all of the warnings (that we like),
> " that's fine, and I think it's a good idea. But we shouldn't lie to
> the user. 

Again, I don't see this as a user-visible change that justifies a new
major number.  There is nothing about this change that would breaks
backward compatibility in Very Bad Ways.  It would only make things
work as expected, so in fact you just listed a simple bug fix here.


> The results of the Acovea project need to be studied carefully and
> taken into account. Perhaps -O2 should turn on a reasonably good set
> of optimizations for the platform at hand, rather than a static set.

And again, this change is no more user-visible than tree-ssa, so by
your own arguments it wouldn't justify a new major version number.
There is also a technical reason against making options depend on the
target platform: coverage.  It's no big secret that the majority of
gcc testing happens on only 3 or 4 platforms.  If some options were
disabled for these most-used platforms, bit rot would probably set in
rather quickly.


> The driver needs to help the user submit a bug report. Given the
> user's original command line, we know the exact commands to generate
> preprocessed source, -v output, etc.

The only user-visible change here is that it becomes easier to report
a bug.  How would that justify a new major version number?  I have to
admit, I don't like the idea of getting automated bug reports.  Think
of the tons of duplicates we would get.  But a little help from the
driver would certainly be a good idea.  IIUC RedHat already have such
a thing in their compiler???


> Our documentation needs to help, not hinder. (The tone and grammar is
> wildly inconsistent. The sections are in no clear order. Very little
> is up to date.)

And how does this break backaward compatibility?  I'm not going repeat
myself again...

IMHO you have given exactly _zero_ valid reasons that would justify a
new major version number.  The reasons you list that would justify it
have no more impact on the user than tree-ssa.  You say that  only "a
serious break in backwards compatability" justifies a new major version
number, and then you go on to list a bunch of reasons that don't break
backward compatibility very badly, if at all.

Let's face it: Technical reasons for a new major version number hardly
ever occur.  That is a good thing, a compiler is supposed to be stable,
the whole goal of compiler development typically is to _avoid_ breaking
backward compatibility.
But please notice that we _do_ have breakage of backward compatibility
in the next GCC release, at least for fortran with a new front end, for
Java because of the new ABI, and for Ada which probably will not be
included at all.  Also don't forget we now have variable tracking, which
means we require our users to upgrade to GDB 6.1 or better.

There can be other reasons than backward compatibility that justify a
new major version number.  Was there binary compatibility breakage from
gcc1 to gcc2?  Not really.  When I read its release announcement[1], it
seems that there were a lot of new features.  Lots of new features can
be a valid reason for a new major number.
For GCC-next-release-number, we have a large number of new features too,
with a completely new global optimizer that is tree-ssa, with all its
(user-visible!) changes in the generated code.

So for the next GCC release, we break backward compatibility, and we have
a major new feature in the form of a new optimization framework.  If the
sum of all this does not justify calling the next release GCC 4.0, then I
don't see what _ever_ will.

Gr.
Steven

[1] http://compilers.iecc.com/comparch/article/92-02-101