Re: Will tree-ssa be GCC 3.5?

[Ian Lance Taylor <ian at wasabisystems dot com>]

"Zack Weinberg" <zack@codesourcery.com> writes:

> > 1) Loss of Ada support, until such time as the Ada front end is
> > gimplified.  This will be a major problem for all Ada users.
> > 2) Replacing the f77 front end with the f95 front end.  This will be
> > noticed by many Fortran users.
> > 3) Loss of all externally maintained front ends, such as Pascal and
> > Mercury, until such time that they are all gimplified.
> > 4) The addition of new infrastructure, which will require all gcc
> > developers to re-educate themselves.
> > 5) The addition of new optimization passes which are likely to cause new
> > classes of bugs for users, and also probably new classes of features.
> 
> 4 is of interest only to developers; that's not a reason to change
> the major version number, which is an advertisement to end users.

Well, we're talking about gcc here.  The end users of gcc, at least
those who care enough to look at the version number, are themselves
developers.  Granted, they are not necessarily gcc developers, but the
internal structure of the compiler does matter to them, because it has
a significant effect on available options and, more importantly, on
option behaviour.

For a relatively trivial example, there was a major gcc change in the
handling of inline functions.  It used to be that only functions used
after the definition were inlined.  But now functions can be inlined
even if they are used before the definition, at least when using
-funit-at-a-time which is now the default for -O2.  That may seem like
an internal structure change mainly of interest to gcc developers, but
it was a significant change for me as a gcc user, not merely as a
developer, because it completely changed the code quality and size.

I haven't been following the tree-ssa work closely, but it seems
likely to be a significant change which will affect all serious users
of gcc, because it will change the basic behaviour which one can
expect from the compiler.  People have certain expectations of gcc,
based on years of experience.  Changes to those expectations are not a
minor matter.

> 1,3,5 are adequately addressed by warning people that version 3.5 will
> be more buggy and support fewer languages than version 3.4, and people
> may want to hold off on using it in production immediately.  I expect
> that Ada will be gimplified by the time 3.5 is out, anyway.

There is a very easy way to warn people that a new release will be
more buggy, and that is make it a .0 release.  That is a much more
reliable way to warn people than anything in the README or in the
official announcement.


More generally, your objection to making the next release be 4.x seems
to be that you set a very high bar to changing the major version
number.  But why do you set that high bar?  What bad things will
happen if the next gcc release is 4.0 rather than 3.5?  That is, is
your objection purely philosophical, or is there an objective basis
for it?  When saying this, I don't mean to discount philosophical
objections; those do matter, particularly in community projects like
this one.  I just want to clarify.

Ian