This is the mail archive of the
mailing list for the GCC project.
Re: GCC-3.3.4 release status report
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 29 Mar 2004 09:16:50 -0800
- Subject: Re: GCC-3.3.4 release status report
- References: <firstname.lastname@example.org>
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
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:
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
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.
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.
You comment on this below. It's fixed in 3.4.
([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.
Likewise this one; could be related to 13653 (another -funroll-loop bug
new since 3.2.3)
We need to understand this one as well. It hasn't really been diagnosed
yet (which function is miscompiled).
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.