Re: patch rereview requested for PRs 6860, 10467 and 11741

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    I still stand by these words.  Once a patch has satisfied all the
    prerequisites specified in contributing.html, including regression
    tests and full explanation of why it works, that should be sufficient.

I strongly disagree.

Those are *minimum requirements*, nothing more.

There can be numerous reasons why patches that meet these requirements
are not acceptable.

    Neither submitter nor reviewer should be considered at fault, 

I don't see it as an issue of "fault".

    even if the reviewer doesn't understand the changes but agrees they are
    compatible with the goals of the GCC project.

A major goal of the GCC project is to create a piece of software that
can be cooperatively maintained.  I'm not talking about your patch
specifically (or any other ones), but if the reviewer can't understand
the changes, it's unlikely that people reading the code will be able to
understand it either and understanding the code is a critical part of
the success of the GCC project.

    Remember that if a regression is subsequently found, including latent
    bugs in completely unrelated parts of the compiler or only triggered
    on obscure platforms, it is the patch submitter and not the patch
    reviewer who is responsible for fixing the new failure, or reverting
    the original patch.  

Not completely correct.  It's the responsibity of the patch submitter
to get the problem fixed, but that does not necessarily mean
personally fixing it.  However, I don't see the relevance of that to
the rest of what you're saying.

    Again it is unreasonable to hold up a patch that in itself is
    completely correct, under the fear that there is or maybe a bug
    elsewhere in the compiler.  

The depends on the definition of "completely correct".  It may be, for
example, that there are many competely correct ways doing the same
thing.  We want to choose the best.  If there are unknown bugs in a related
area, it's much easier to figure out which is best once they are fixed.

    Once a patch has been shown not to break anything by the best of our
    knowledge, it should be assumed innocent until proven guilty.

Certainly false.  For example, it must also improve something.

    Or put another way, If someone with RTH's history of regression fixing
    patches, GCC design and code improvements can't come up with a failing
    test case, isn't that an incredibly strong argument that the patch is
    sound?

No.  If I have a gut feeling that something is wrong and I ask a submitter
to show me why I'm wrong, it's unreasonable to expect that I be able to
come up with a test case.