GCC-3.3.4 release status report

GCC-3.3.4 release status report

[Gabriel Dos Reis]

Hi,

  The number of open PRs targetted for 3.3.4 has grown up to 46
(from 41 last report).  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
  c++/14507
  c++/14724
   
  middle-end/14711

  optimization/13653
  optimization/11841
  optimization/14640
  
  target/14040

Regression optimization/13653 was introduced very early in 3.3.0 and
seems to be hard to track and fix for 3.3.x.  It is already fixed in
3.4.0; if no progress can be made by the report, then I'll close it as
wontfix for 3.3.x.

Regression optimization/14640 seems to be caused the RTL_UNCHANGING_P
thingy.  Any help from those who finally understood that part of the
compiler would be appreciated.

Regression middle-end/14711 has been present since 3.0.  It occurs
only for large line numbers.  Here is a reduced testcase (from the
audit trail)

    # 4294967290
    void foo(void) { }

 
Regression c++/14724 seems to affect all versions of GCC since 3.2.x.


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.

Thanks,

-- Gaby

Re: GCC-3.3.4 release status report

[Joe Buck]

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.

Re: GCC-3.3.4 release status report

[Richard Guenther]

Joe Buck wrote:
> 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).
>>
>> 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:
>>
> ([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.

I'm the reporter of the bug (and there is another arch-specific for 
powerpc, maybe related, PR13222), and the bug looks indeed serious.  But 
I personally am using already 3.4 for production use and tree-ssa for 
testing - and POOMA based testcases are huge - even if this one was 
reduced a lot already.  Someone with good understanding of the loop 
unroller and rtl needs to look at this.  At least warn about use of 
-funroll-loops as it caused that many regressions in the past.

One problem is that we don't excercise those commonly (in scientific 
apps) used options in any -O level, so this gets too less beating on in 
regular C apps which would result in so much nicer testcases...

So, in conclusion, I'd be not too unhappy if this is _not_ fixed for 3.3.4.

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

Let's hope fixing one of 11841, 13222 or 13653 fixes the other cases. 
Or simply strip off handling of "unusual" cases from the unroller and 
rather pessimize the odd cases than producing wrong code.

Richard.

Re: GCC-3.3.4 release status report

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.COM> writes:

| 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.

Hi,

  I fully understand the potential risk of any single patch that gets
applied to branch.  You're right that I don't expect to fix that
number of regressions before releasing -- that is just unrealistic.

  However, If can get rid of the 8 regressions I listed,  I'll
be more than happy.

  With no intent to make Mark feel uncomfortable (the RM position is
where you get everybody wanting to eat you ;-)), I believe that the
gcc-3_3-branch was created too early.  Lots of bugs were found only
later and could not make it into early releases.  That explains a
large part of the impressive release note we got for 3.3.3.  Bugs
and regressions are still being found, that contributes to the
growing PRs; and some were unfortunately introduced in 3.3.3
at attempts to fix other bugs.  That is inevitable, and I trust
everybody commenting on GCC release process understand that.
 
  I think that the critical PR deserve a high priority (a truism,
but that probably needs stating);  however, I also feel that normal
PRs with no disruptive patches should be accepted.  It is true that
GCC-3.4.0 is going out very soon and that it contains an uncomensurable
number of fixes and functionalities.  But that is also the principal
reason why I volunteered to maintain GCC-3.3.x.  It is going to reject
lots of (C++) codes, not because it is much buggier but because it is
much stricter and has some ABI changes.  I do not believe that the set of
bug-fixes we should offer should come in a form of whole-or-nothing,
e.g take ABI change + various (non ABI) bug-fixes or nothing.
If I have simple patches/backports for those, I would be happy, but I
would not push hard to apply disruptive patches.

  I'll put resources to fulfill the release date and criteria for
GCC-3.3.4.

  I hope that clarifies things as your expectations are concerned.

-- Gaby

Re: GCC-3.3.4 release status report

[Joe Buck]

On Tue, Mar 30, 2004 at 01:43:23PM +0200, Gabriel Dos Reis wrote:
>   I fully understand the potential risk of any single patch that gets
> applied to branch.  You're right that I don't expect to fix that
> number of regressions before releasing -- that is just unrealistic.
> 
>   However, If can get rid of the 8 regressions I listed,  I'll
> be more than happy.

I don't think that we should try to fix c++/14507 and c++/14724 in the
old parser.  I'd say the same about c++/13663 though I don't feel as
strongly.  That would leave 5 or 6.  If someone comes up with a truly
easy fix for any of these, well, maybe, but we're talking about peturbing
a very kludge-filled C++ parser to fix low-priority problems.

Regardless of whether you agree with that, though, I think that only these
8 (or fewer) be left with a "3.3.4" target and any other bug fixed in
3.4.0 be closed.  As for remaining regressions targeted for 3.3.4, I think
that they should be targeted at 3.4.1.

Re: GCC-3.3.4 release status report

[Wolfgang Bangerth]

>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. 

Indeed. My feeling is that way too many patches are going into 3.3.4 without 
any analysis as to the risk of them. We already have some regressions with 
respect to previous 3.3.x releases due to this. See for example PR 14640.

I personally think that it is not a huge problem if we don't fix every single 
PR in 3.3.4 given that 3.4.0 is close. In fact, I find it a nuisance to have 
to look at all the PRs targeted for 3.3.x if I want to find out what needs to 
be done for 3.4. We should be more willing to retire PRs if they are already 
fixed in 3.4.

W.
 
-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: GCC-3.3.4 release status report

[Gabriel Dos Reis]

Wolfgang Bangerth <bangerth@ices.utexas.edu> writes:

| >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. 
| 
| Indeed. My feeling is that way too many patches are going into 3.3.4 without 
| any analysis as to the risk of them.

I believe that is too much a strong statement.  No patch is blindly
applied to GCC-3.3.4

If your point is that any single patch has a potential risk for
unconvering other bugs, yes that is true and I'm well aware of that.
By the very nature of GCC, it is not always easy to tell *all* the
implications that any arbitrary patch will have, as side-effects.
The easiest and not very useful, IMO, position would be to close
the branch.  After all, that is what had been decided. 
But, I think there are room for improvements;  I accept patches based
on their contents, descriptions of the problems they address and
impacts, and inputs from various maintainers.

I could come tomorrow with a release note saying that only two PRs are
targetted for 3.3.4; I doubt that would make GCC-3.3.4 better than it
looks now.  I could also come and say I have 100 open PRs for 
GCC-3.3.4; I doubt it would make GCC-3.3.4 worse than it is now.

-- Gaby

Re: GCC-3.3.4 release status report

[Theodore Papadopoulo]

bangerth@ices.utexas.edu said:
> I personally think that it is not a huge problem if we don't fix every
> single  PR in 3.3.4 given that 3.4.0 is close. In fact, I find it a
> nuisance to have  to look at all the PRs targeted for 3.3.x if I want
> to find out what needs to  be done for 3.4. We should be more willing
> to retire PRs if they are already  fixed in 3.4.

I, actually, believe that the reverse is true. Despite all the effort 
that have been made to make 3.4 as robust and good as possible, this 
release contains several improvements that have not been exposed to 
the wild yet. The better (more strict) C++ parser is certainly 
something that will make people encounter problems with 3.4.0, and I 
bet several regression will still be found after 3.4.0 is out (a lot 
of people out there also believe that the .0 releases are not for the 
mainstream).

Thus, in my opinion, a good 3.3.x is needed at least till 3.4 has got 
some much broader testing. Thus, the need to correct as much bug as 
possible on 3.3 (while keeping it as stable as possible). And I have 
no reasons to complain about the stability of 3.3 so far.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: GCC-3.3.4 release status report

[Joe Buck]

Gabriel Dos Reis wrote:
> | >>   The number of open PRs targetted for 3.3.4 has grown up to 46
> | >> (from 41 last report).

I wrote:
> | > 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. 

Wolfgang Bangerth <bangerth@ices.utexas.edu> writes:
> | Indeed. My feeling is that way too many patches are going into 3.3.4 without 
> | any analysis as to the risk of them.

Gabriel Dos Reis wrote:
> I believe that is too much a strong statement.  No patch is blindly
> applied to GCC-3.3.4

Of course the patches are not being applied "blindly".  But I've been in
the biz long enough to expect that no matter how careful or skillful the
development team is, if it introduces 10 new bug fixes into a software
system as complex as GCC in a short time, it will introduce at least one
new significant failure (and often a "paper bag" failure, as in you'll
want to put a paper bag over your head if the new bug escapes testing).
In environments where fixes are done under tight deadline pressure the
number gets closer to 4 to 1 (and fortunately GCC does not have such
pressure).  That's why it would be a good idea to scale back your
ambitions, focus only on the truly most important bugs, and allow a long
enough shake-out period to allow time to find the newly introduced
failures before release.

> I could come tomorrow with a release note saying that only two PRs are
> targetted for 3.3.4; I doubt that would make GCC-3.3.4 better than it
> looks now.  I could also come and say I have 100 open PRs for 
> GCC-3.3.4; I doubt it would make GCC-3.3.4 worse than it is now.

The question boils down to how we want to manage point releases.  I think
that the user expectation should be that we see a montonically increasing
quality from x.y.z to x.y.z+1.  To achieve this, we should not be overly
ambitious and try to fix all regressions, though anything that works in
x.y.z and fails in the x.y branch can't be tolerated.  Regressions that
prevent distros from being built are most critical (e.g. 14640).  Almost
everything else can probably wait.

Given the volume of fixes that have gone into 3.3.4 already, I would
advise a long period of freeze, and encourage people to build whole
distros with the compiler on as many platforms as possible.  It should be
rock-solid, but it will inevitably still contain regressions with respect to
2.95.

Re: GCC-3.3.4 release status report

[Eric Botcazou]

> Of course the patches are not being applied "blindly".

Well, this one is IMHO not far:

2004-03-12  Gabriel Dos Reis  <gdr@integrable-solutions.net>

	Backport:
	2004-03-13  Eric Botcazou  <ebotcazou@libertysurf.fr>
        PR middle-end/14470
	* expr.c (store_expr): Call emit_queue before generating the move
	from the temporary to the original target.  Protect the temporary
	from emit_queue.


If I had been asked, I would have *strongly* recommended not to backport it 
because this is the hottest place in the middle-end you can think of (and I 
already had to write a follow-up patch to correct a nasty side-effect).  But 
I wasn't asked...

-- 
Eric Botcazou

Re: GCC-3.3.4 release status report

[Daniel Berlin]

On Mar 30, 2004, at 4:18 PM, Eric Botcazou wrote:

>> Of course the patches are not being applied "blindly".
>
> Well, this one is IMHO not far:
>
> 2004-03-12  Gabriel Dos Reis  <gdr@integrable-solutions.net>
>
> 	Backport:
> 	2004-03-13  Eric Botcazou  <ebotcazou@libertysurf.fr>
>         PR middle-end/14470
> 	* expr.c (store_expr): Call emit_queue before generating the move
> 	from the temporary to the original target.  Protect the temporary
> 	from emit_queue.
>
>

He also backported a patch from the future, which is odd.
>

Re: GCC-3.3.4 release status report

[Eric Botcazou]

> He also backported a patch from the future, which is odd.

I changed the date because it didn't match that of the patch on mainline and 
3.4 branch, which is confusing when you track regressions.  But the patch 
had indeed been "backported" before it was applied on mainline and 3.4 
branch.

-- 
Eric Botcazou

Re: GCC-3.3.4 release status report

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Mar 30, 2004, at 4:18 PM, Eric Botcazou wrote:
| 
| >> Of course the patches are not being applied "blindly".
| >
| > Well, this one is IMHO not far:
| >
| > 2004-03-12  Gabriel Dos Reis  <gdr@integrable-solutions.net>
| >
| > 	Backport:
| > 	2004-03-13  Eric Botcazou  <ebotcazou@libertysurf.fr>
| >         PR middle-end/14470
| > 	* expr.c (store_expr): Call emit_queue before generating the move
| > 	from the temporary to the original target.  Protect the temporary
| > 	from emit_queue.
| >
| >
| 
| He also backported a patch from the future, which is odd.

If you look at the audit trail of 14470 you'll see that Eric commented
(#17) on 2004-03-11 06:34 that the patch was approved for mainline. 

On 2004-03-13, I tested and applied the patch, which contains the date
you see in comment #19 (not 2004-03-13).

-- Gaby