This is the mail archive of the 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-3.3.4 release status report

On Sat, Mar 27, 2004 at 11:09:52AM +0100, Gabriel Dos Reis wrote:
>   The number of open PRs targetted for 3.3.4 has grown up to 46
> (from 41 last report).

That is a *huge* number of bugs to attempt to fix in the fourth point
release; an attempt to fix even half that number will probably result in
3.3.4 being less stable than 3.3.3.  That's because any bug fix adds the
risk of introducing a new bug.  Of course, I recognize that you don't
seriously intend to fix that many, but we need to set everyone's
expectations correctly.

I would feel comfortable with adding fixes that have already been in the
Debian compiler for some time, because that compiler is being used to
build thousands of packages on many architectures.  But it's not a good
idea to keep whacking away.

I think it is time to scale back our ambitions considerably.  Fixes
included on the bug fix branch at this time should be extremely
conservative.  3.3.4 as it stands in the 3.3 branch today is an
improvement over 3.3.3; with excessive ambition we might wind up releasing
something that is worse.

>  Some PRs have been fixed, others are new.
> The set of critical PRs is now 8 and is different from what we got
> last report:
>   c++/13663

ICE on invalid code; attempt to backport a fix failed.  The 3.4 parser is
completely different, so backporting parser fixes is problematic.  The
only reason I'd consider this serious is that there is an infinite loop,
not just a segfault.  Just getting this case to blow up sooner would be
an improvement.

>   c++/14507

This is an ICE on valid code, but it's been around forever (since 3.0) and
it was things like this that led Mark to write a new C++ parser.  Trying
to fix this in the old parser is likely to be a thankless task.

>   c++/14724

Again, it has been around since 3.0, and the fix is likely to be
completely different for the old and new parsers.  I think it's a waste
of time to try to fix these in the old parser.  For this one, it would
be good to document it as a known bug.

>   middle-end/14711

You comment on this below.  It's fixed in 3.4.

>   optimization/13653

([3.3 regression] -O2 -funroll-loop miscompiles POOMA testcase)

Now *this* is one that I'd like to see fixed!  It's likely to be tractable
because 3.2.3 worked, and it's nasty.

>   optimization/11841

Likewise this one; could be related to 13653 (another -funroll-loop bug
new since 3.2.3)

>   optimization/14640

We need to understand this one as well.  It hasn't really been diagnosed
yet (which function is miscompiled).

>   target/14040

Mark says he is working on a fix for this.

> I'll be travelling to Europe (in a few hours) for a week.  I'll try to
> read emails, but I do not anticipate to have a reliable connection.

In my opinion, there are four critical bugs: the optimization bugs and the
ARM target bug.  As for the others, if someone comes up with a really
simple and obviously correct fix, great, but I think that a 3.3.4 that
fixes these four bugs, gets a huge amount of prerelease testing, and
doesn't try to do anything else would be great.

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