This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.2.0 Status Report (2007-02-19)


On Mon, 19 Feb 2007, Joe Buck wrote:

> On Tue, Feb 20, 2007 at 12:27:42AM +0000, Joseph S. Myers wrote:
> >...  *All* releases seem to have the
> > predictions that they are useless, should be skipped because the next
> > release will be so much better in way X or Y, etc.; I think the question
> > of how widely used a release series turned out to be in practice may be
> > relevant when deciding after how many releases the branch is closed, but
> > simply dropping a release series after the branch is created is pretty
> > much always a mistake.  (When we rebranded 3.1 as 3.2 in the hopes of
> > getting a stable C++ ABI, I think that also with hindsight was a mistake,
> > given that the aim was that the stable ABI would also be the correct
> > documented ABI but more ABI bugs have continued to turn up since then.)
>
> I agree.  To me, the only issue with 4.2 is the performance drop due to
> aliasing issues; whether to address that by reverting patches to have 4.1
> performance + 4.1 bugs, or by backporting fixes from 4.3, I would leave
> for the experts to decide (except that I don't think it's shippable
> without some solution to the performance drop).


Agreed on all counts, especially the prevalence of prior (wrong)
predictions about release usefulness. :-D

And we don't want to arm our detractors with bad SPEC numbers.  I can just
imagine the FUD spreading... we've got to fix it or backout.



> > In addition, the 4.2 release series serves the necessary purpose of
> > providing deprecation warnings for incompatible changes in 4.3 (for
> > example, the proposed diagnostics in 4.2 for extern inline in
> > c99/gnu99 mode); dropping a release series would require associated
> > reversions in mainline and delays to changes needing deprecation
> > periods.

On a similar note, 4.2 is the first release to warn about the newer MPFR
version requirements, whereas 4.3 yields a hard error.  Given how much
complaining I've heard about MPFR WRT mainline, we should warn users for
one release the same way we do for deprecated features.  Hopefully by the
time 4.3 is out (a year from now based on history) it'll be less of an
issue because a new enough version of MPFR will be included in most
distros.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]