Re: [PATCH] Fix loop_iterations mishandling of multiple conditionalized exit tests

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 05:12 05.10.2001, Jim Wilson wrote:
>I don't think it is a good idea to try to force patches into gcc 3.0.2 at
>the last minute.  That isn't the way to produce a high quality release.

Well, you know as going for a high quality release we would have to default 
to -fno-strength-reduce on the branch then, there are to many obscure 
corner cases lurking in that area. But since we don't want to do that for 
performance reasons, I think it's best to fix important bugs as they come 
along.

>As a more practical matter, I'm already on the hook for other patches and
>bugs, and can't work on all of them at the same time.  I'm already looking
>at the Zoltan Hidvegi patches.  I could look at this patch instead of Zoltan's
>patches, but his were submitted 3 months ago, and shouldn't be delayed any
>longer than necessary.  This does look like a more important problem than
>the ones fixed by Zoltan's patches though.  I've also got other stuff: a
>combine patch in progress, a linker patch in progress, and a report yesterday
>of a compiler bug that is causing kernel panics.  If we are willing to delay
>3.0.2 a couple of weeks, then I can get through this stuff OK.  Otherwise, we
>need to decide which bugs we want fixed now and which we can live with for 
>now.
>I think we should draw the line at Monday when the freeze went into affect,
>which means this one came in too late for gcc 3.0.2.

You can be sure I'm quite aware of the release procedure, but in this case 
I think the bug is important enough to at least look shortly if we can fix 
it easily. For my taste this list is long enough:

- regression from gcc-2.95.4
- important database applications affected (actually it leads to database 
corruption, eg. duplicate keys)
- patch is small and non-invasive
- patch only disables a wrong optimization (makes loop_iterations() return 
early)

So if the patch is correct, it should be applied. If you think the patch is 
the wrong way to tackle the  problem, I'll take my request back and will 
come back with a better patch for 3.0.3 then.

>Reviewing patches for gcc 3.0.2 is much harder than reviewing patches for
>mainline, since patches for 3.0.2 must be absolutely correct, whereas a
>patch for mainline only needs to be reasonably correct.  It takes me much
>longer to review a patch for gcc 3.0.2, and thus the number of patches I
>can review is much smaller when I need to review patches for gcc 3.0.2.
>If you just want the patch in mainline, I can get through the review
>faster.

If you could review/approve it for the mainline, that would be very nice. 
If you think the patch is wrong, at least approve the testcase.

Thanks,
Franz.