Roger Sayle wrote:
On Wed, 25 Oct 2006, David Daney wrote:
The patch is fully tested and ready to go for the 4.2 branch.
The last thing I want is for this fix to get delayed whilst we argue
over patch testing/approval policy. This fix addresses the known
wrong-code issue, and at worst may r
Eric Botcazou wrote:
Finally before I finish the retrospective part of this e-mail, I'll
point out this isn't a sudden recent unilateral policy decision, but
purely a crystallization of the prescribed GCC work-flow outlined in
contributing.html that has been refined over many years.
I've review
> Finally before I finish the retrospective part of this e-mail, I'll
> point out this isn't a sudden recent unilateral policy decision, but
> purely a crystallization of the prescribed GCC work-flow outlined in
> contributing.html that has been refined over many years.
I disagree. I've been work
On Wed, 25 Oct 2006, David Daney wrote:
> The patch is fully tested and ready to go for the 4.2 branch.
The last thing I want is for this fix to get delayed whilst we argue
over patch testing/approval policy. This fix addresses the known
wrong-code issue, and at worst may replace it with missed
On Wed, 25 Oct 2006, Richard Sandiford wrote:
> Roger Sayle <[EMAIL PROTECTED]> writes:
> > Once explained, I'd expect most maintainers would make precisely the
> > same call?
>
> I suppose the counter-argument is that we shouldn't ship 4.2 in its
> current state. We should either back out the pa
David Daney wrote:
Eric Botcazou wrote:
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 v
Eric Botcazou wrote:
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 versi
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> 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 a
> 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 re
Roger Sayle <[EMAIL PROTECTED]> writes:
> Once explained, I'd expect most maintainers would make precisely the
> same call?
I suppose the counter-argument is that we shouldn't ship 4.2 in its
current state. We should either back out the patch that made
REG_POINTER more prominent or go with the fi
Hi Andrew,
On Wed, 25 Oct 2006, Andrew Haley wrote:
> I must admit to being a little perplexed by this.
>
> We have an unsafe optimization that causes bad code to be generated on
> at least one platform. However, we want to continue to perform this
> unsafe optimization on our release branch unt
Andrew Haley wrote:
Roger Sayle writes:
>
> Hi David,
>
> On Sun, 22 Oct 2006, David Daney wrote:
> > 2006-10-22 Richard Sandiford <[EMAIL PROTECTED]>
> > David Daney <[EMAIL PROTECTED]>
> >
> > PR middle-end/29519
> > * rtlanal.c (nonzero_address_p): R
Roger Sayle writes:
>
> Hi David,
>
> On Sun, 22 Oct 2006, David Daney wrote:
> > 2006-10-22 Richard Sandiford <[EMAIL PROTECTED]>
> > David Daney <[EMAIL PROTECTED]>
> >
> > PR middle-end/29519
> > * rtlanal.c (nonzero_address_p): Remove check for values
13 matches
Mail list logo
