* Re: GCC-3.3.4 release status report
@ 2004-03-30 0:20 Wolfgang Bangerth
2004-03-30 18:56 ` Gabriel Dos Reis
0 siblings, 1 reply; 13+ messages in thread
From: Wolfgang Bangerth @ 2004-03-30 0:20 UTC (permalink / raw)
To: Joe Buck, Gabriel Dos Reis; +Cc: gcc
>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/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-30 0:20 GCC-3.3.4 release status report Wolfgang Bangerth
@ 2004-03-30 18:56 ` Gabriel Dos Reis
2004-03-30 19:19 ` Theodore Papadopoulo
2004-03-30 23:59 ` Joe Buck
0 siblings, 2 replies; 13+ messages in thread
From: Gabriel Dos Reis @ 2004-03-30 18:56 UTC (permalink / raw)
To: Wolfgang Bangerth; +Cc: Joe Buck, gcc
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-30 18:56 ` Gabriel Dos Reis
@ 2004-03-30 19:19 ` Theodore Papadopoulo
2004-03-30 23:59 ` Joe Buck
1 sibling, 0 replies; 13+ messages in thread
From: Theodore Papadopoulo @ 2004-03-30 19:19 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Wolfgang Bangerth, Joe Buck, gcc
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
--------------------------------------------------------------------
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-30 18:56 ` Gabriel Dos Reis
2004-03-30 19:19 ` Theodore Papadopoulo
@ 2004-03-30 23:59 ` Joe Buck
2004-03-31 2:50 ` Eric Botcazou
1 sibling, 1 reply; 13+ messages in thread
From: Joe Buck @ 2004-03-30 23:59 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: Wolfgang Bangerth, gcc
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-30 23:59 ` Joe Buck
@ 2004-03-31 2:50 ` Eric Botcazou
2004-03-31 3:10 ` Daniel Berlin
0 siblings, 1 reply; 13+ messages in thread
From: Eric Botcazou @ 2004-03-31 2:50 UTC (permalink / raw)
To: Joe Buck; +Cc: Gabriel Dos Reis, Wolfgang Bangerth, gcc
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-31 2:50 ` Eric Botcazou
@ 2004-03-31 3:10 ` Daniel Berlin
2004-03-31 11:24 ` Eric Botcazou
2004-03-31 12:42 ` Gabriel Dos Reis
0 siblings, 2 replies; 13+ messages in thread
From: Daniel Berlin @ 2004-03-31 3:10 UTC (permalink / raw)
To: Eric Botcazou; +Cc: Joe Buck, Wolfgang Bangerth, gcc, Gabriel Dos Reis
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.
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-31 3:10 ` Daniel Berlin
@ 2004-03-31 11:24 ` Eric Botcazou
2004-03-31 12:42 ` Gabriel Dos Reis
1 sibling, 0 replies; 13+ messages in thread
From: Eric Botcazou @ 2004-03-31 11:24 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Joe Buck, Wolfgang Bangerth, gcc, Gabriel Dos Reis
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-31 3:10 ` Daniel Berlin
2004-03-31 11:24 ` Eric Botcazou
@ 2004-03-31 12:42 ` Gabriel Dos Reis
1 sibling, 0 replies; 13+ messages in thread
From: Gabriel Dos Reis @ 2004-03-31 12:42 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Eric Botcazou, Joe Buck, Wolfgang Bangerth, gcc
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-30 18:46 ` Gabriel Dos Reis
@ 2004-03-31 1:15 ` Joe Buck
0 siblings, 0 replies; 13+ messages in thread
From: Joe Buck @ 2004-03-31 1:15 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-29 19:17 ` Joe Buck
2004-03-30 0:24 ` Richard Guenther
@ 2004-03-30 18:46 ` Gabriel Dos Reis
2004-03-31 1:15 ` Joe Buck
1 sibling, 1 reply; 13+ messages in thread
From: Gabriel Dos Reis @ 2004-03-30 18:46 UTC (permalink / raw)
To: Joe Buck; +Cc: gcc
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-29 19:17 ` Joe Buck
@ 2004-03-30 0:24 ` Richard Guenther
2004-03-30 18:46 ` Gabriel Dos Reis
1 sibling, 0 replies; 13+ messages in thread
From: Richard Guenther @ 2004-03-30 0:24 UTC (permalink / raw)
To: Joe Buck; +Cc: Gabriel Dos Reis, gcc
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: GCC-3.3.4 release status report
2004-03-27 21:26 Gabriel Dos Reis
@ 2004-03-29 19:17 ` Joe Buck
2004-03-30 0:24 ` Richard Guenther
2004-03-30 18:46 ` Gabriel Dos Reis
0 siblings, 2 replies; 13+ messages in thread
From: Joe Buck @ 2004-03-29 19:17 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* GCC-3.3.4 release status report
@ 2004-03-27 21:26 Gabriel Dos Reis
2004-03-29 19:17 ` Joe Buck
0 siblings, 1 reply; 13+ messages in thread
From: Gabriel Dos Reis @ 2004-03-27 21:26 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2004-03-31 9:40 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-30 0:20 GCC-3.3.4 release status report Wolfgang Bangerth
2004-03-30 18:56 ` Gabriel Dos Reis
2004-03-30 19:19 ` Theodore Papadopoulo
2004-03-30 23:59 ` Joe Buck
2004-03-31 2:50 ` Eric Botcazou
2004-03-31 3:10 ` Daniel Berlin
2004-03-31 11:24 ` Eric Botcazou
2004-03-31 12:42 ` Gabriel Dos Reis
-- strict thread matches above, loose matches on Subject: below --
2004-03-27 21:26 Gabriel Dos Reis
2004-03-29 19:17 ` Joe Buck
2004-03-30 0:24 ` Richard Guenther
2004-03-30 18:46 ` Gabriel Dos Reis
2004-03-31 1:15 ` Joe Buck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).