This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: Richard Sandiford <richard at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, Roger Sayle <roger at eyesopen dot com>, Andrew Haley <aph at redhat dot com>, David Daney <ddaney at avtrex dot com>
- Date: Wed, 25 Oct 2006 20:51:17 +0200
- Subject: Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions
- References: <Pine.LNX.4.44.0610250925260.11491-100000@www.eyesopen.com> <87iri8uw4s.fsf@talisman.home>
> Lots of people seem to test release branches -- probably more than mainline
> -- and I would hope that using the fix from this PR is by far the strongest
> contender.
Definitely. People report bugs against released versions and expect fixes for
these versions, not for versions that will be released one year from now.
> I think we'd be doing ourselves a favour by going with what we
> expect to be the final fix and getting as much testing of it as possible.
> After all, it's not difficult to test & apply a patch to a branch at the
> same time as mainline, or to revert it in the same way.
Exactly my position. :-)
> Also, having patches on mainline and not a release branch can cause
> quite a bit of confusion. Witness what happend with PR 28243, where I
> fixed something on mainline, but it was not directly approved for a
> release branch. Then Eric B. worked around the same problem on the
> release branch and forward-ported the work-around to mainline, where
> it wasn't really needed.
I'd have said: "fixed a subcase" but the picture is globally correct.
Btw, what about backporting your fix? Or is it too late now?
> I just don't think it's as obvious a call as your question above makes out.
> There are downsides to this approach too, especially when no one person
> is in overall charge of repository (mainline and branch).
Right. And, in my opinion, these downsides are easily underestimated.
--
Eric Botcazou