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: 2 x86-64 ABI bugs in gcc 3.3 and 3.4

Gerald Pfeifer <> writes:

| On Tue, 18 May 2004, Gabriel Dos Reis wrote:
| > The cases Gerald pointed in the past are
| >
| >    (1) regressions from very early versions of GCC.
| >
| >    (2) they are present in both 3.3.x, 3.4.x (and sometime in
| >        mainline).
| >
| >    (3) whether they are fixed in 3.3.x not, they are going to be
| >        regressions in 3.4.x.  So the only question is where we
| >        put the regression point.
| >
| >    (4) Given the above, and given the submission of patches that cure
| >        the problem, I believe it would be a mistake not to accept the
| >        patch in the name that it would introduce a regression.
| >        That won't be a regression, because the regression is _ealredy_
| >        present _before_ the problem got fixed in 3.3.x.
| 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

| I agree that, in a formal sense, the situation above will not add a
| regression to 3.4, but still think we shouldn't backport a fix to 3.3,
| but not to 3.4.

This sets that either I indirectly direct which patch goes in 3.4.x or
3.4.x blocks fixes for 3.3.x.  We can examine some specific situations
on case by case basis, but I think in general that is not good.

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


| Just my personal 4c, though!

And I appreciate it.

-- Gaby

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