This is the mail archive of the gcc@gcc.gnu.org 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]

Re: Checkin Policy


>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

    Craig> My suggestion would be to apply the above advice to patches
    Craig> that are not "clearly correct" as viewed by a programmer
    Craig> who thoroughly understands the module in question and its
    Craig> interactions.

I agree with this, in principle.  However, I don't think there's much
question that I understand the C++ front-end pretty well, and yet I
often find that my first attempt at a patch, which may appear "clearly
correct" to me, causes something to break.  As you point out, that's
not always the fault of my patch per se; rather, I've exposed some
other kludge or bug in the compiler, or revealed some misunderstanding
on my part.  Sometimes, though, my sense of things is just plain
wrong.  Sometimes there are extensions of which I was unaware.  But,
perhaps the g77 front-end is simpler, better written, or you're just
plain smarter!

My point, I guess, is that I'm happy to agree with your suggestion,
which, I think, boils down to something like:

  o Run the regression tests for appropriate pieces of the compiler
    unless you're 100% sure that what you're doing is the "clearly
    correct" thing to do.

Let's just make sure that "clearly correct" really means that, and not
"I don't see what could be wrong with this offhand".  I think you and
I agree on this.  As you say, almost no changes to reload, other than
typos, probably qualify.

But, I'm not really sure why the regression tests can't be run even
for those situations.  The full c-torture tests take less than 45
minutes on a one-generation behind Linux box that I have, and that
doesn't seem like so much overhead to me.  Although you're mostly
right when you say:

  In fact, a general rule of thumb about "clearly correct" patches is
  that their "clearly correct" status, in a programmer's view, is
  almost entirely impossible to change by the results of comparing
  test runs (between the patched and unpatched product) of any sort.
  As soon as one must point

I personally don't find it quite that simple.  I've certainly had
patches I felt sure were correct that broken several regression tests.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com


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