Re: 2 x86-64 ABI bugs in gcc 3.3 and 3.4

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On Thu, May 20, 2004 at 02:54:05AM +0200, Gabriel Dos Reis wrote:
> | I believe this is the point where we have to agree to disagree on this
> | specific issue.  In my opinion, having an oscillation (broken in 3.2,
> | fixed in 3.3, broken in 3.4, fixed on mainline) is somehow worse, because
> | it gives the user less certainty on how the compiler (mis)behaves.
> 
> I believe a variable is forgotten here:  The sequencing of the
> releases.  The fixes are included in consequentive releases.  3.3.3
> comes before 3.4.0 which comes before 3.3.4 which comes before 3.4.1.
> So saying, it is broken in 3.2, fixed in 3.3 and 3.4 is not entirely
> accurate.  

True.  But there's another problem; if you try to make 3.3.4 better than
3.4.0 in some respects, there's a sense in which the compiler development
is forking: there are suddenly two competing lines of development with
advantages to either one.

Despite that, I wouldn't restrain 3.3.4 from accepting a simple, obvious,
near-risk-free patch that fixes a bug still present in 3.4.0.

But I am concerned that the policy for allowing fixes into 3.3.x is more
permissive than the policy for 3.4.x.  That is, Mark is being more
cautious than you are.  Note that by saying so, I'm not saying that one of
you is right and the other is wrong, just that it seems peculiar.

By the time the third digit gets to 4, we should be ultra, ultra
conservative as to what fixes go in, fixing only the most critical
problems.  If we aren't, no matter how skilled and careful you are (and
you are both), and how much pre-release testing is done, it becomes
likely that serious new bugs will be introduced.  This gets worse as time
goes on, as divergence between 3.4.x and 3.3.x make it increasingly tricky
to back-port bug fixes.

> To arrive to the point where we fixed those many bugs in 3.3.x I had
> to use rules less stricter than for 3.4.x -- because I think the
> branching was cut too early, and those fixes should have been in.

I think that you did an excellent job on 3.3.3; it was a very high quality
release.  The problem is, precisely because 3.3.3 is a good release, I'm a
bit nervous about all the 3.3.4 changes, though I'm willing to trust the
care that you took.  I'm ready, though, to back off now; we shouldn't be
pressing our luck.

> After 3.3.4, the rules will be slightly stricter -- because we've
> attained some stability --, but I don't believe we could have made
> 3.3.3 and 3.3.4 that useful if we applied the same rules as 3.4.x.  
> I'm not pretending, it is easy or without risks.

I would like to see you get a *lot* stricter after 3.3.4; certainly by
then it should be considered very risky to backport bug fixes without
careful consultation with the GWP developers to make sure that the bug
fix doesn't depend on aspects of the compiler that have completely
changed.

If 3.3.4 should turn out to have one or more major regressions with
respect to 3.3.3 (and I hope it does not), it would be appropriate to
alter the schedule and put out a 3.3.5 that fixes those problems and ONLY
those problems, quickly (but with enough time to allow for testing).  If
not, then your proposal of a scheduled release in a few months' time would
be fine.