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: Loop unroll fixes


In article <200109140157.VAA25844@makai.watson.ibm.com> you write:
>	The maintainer of the part of the compiler affected by the patch
>has not responded to repeated requests for his feedback.  One other
>developer has asked for the approval of the patch to be delayed until he
>reviewed it, but has not done so.

The subject line says "Loop unroll fixes", and the MAINTAINERS file says
that I am the loop unroll maintainer, so this might lead someone to think
that I have been negligent.  I haven't.

I only recall getting two direct messaages on this topic.  One said nothing
interesting:
http://gcc.gnu.org/ml/gcc-bugs/2001-07/msg00775.html

The other apparently wasn't sent to the lists, but it is archived in
PR 3384.  I quote:
	If Michael Hayes does not review the patch by Tuesday and
	Jim Wilson does not object, Mark Mitchell and I have agreed
	to approve the patch for the mainline. Assuming no problems
	appear, we will approve the patch for the gcc-3.0 branch
	by the time Mark creates the tarball for testing
Any reasonable person named Jim Wilson seeing this would assume that
a) a response is optional
b) whether or not a response is sent, someone else has accepted responsibility
   for resolving the problem

I see no other evidence on the gcc web site that other messsages were sent to
me.

Perhaps you were referring to Michael Hayes, but I see no evidence that Michael
Hayes is guilty of negligence either.  In fact, he did give a partial approval
for one of the patches in one of his messages.
http://gcc.gnu.org/ml/gcc-bugs/2001-07/msg01101.html
I quote:
	The doloop part of this patch is OK.

Michael Hayes recieved and replied to a number of messages on this thread.
I see no evidence on the gcc web site that there were repeated requests for
feedback that were ignored.

There is other relevant evidence from other peoples mail mesasges.
There was a message from Geoff Keating saying he would put it on his queue.
http://gcc.gnu.org/ml/gcc-bugs/2001-07/msg00769.html

There was also a message from Bernd Schmidt claiming to have checked in a
patch that fixed the problem.
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01056.html

So we have a case where at least 6 different gcc maintainers looked at the
patch, 3 of them making some claim to have contributed to a fix.  It is no
surprise then that something might have gone wrong.  Everyone assumed someone
else was going to fix it, so no one did.

There was a brief dialog about the problem in August, but it was requested
to resubmit after gcc 3.0.1.
http://gcc.gnu.org/ml/gcc/2001-08/msg00845.html
http://gcc.gnu.org/ml/gcc/2001-08/msg00848.html
http://gcc.gnu.org/ml/gcc/2001-08/msg00908.html

The problem was then dormant again until resubmitted today.
http://gcc.gnu.org/ml/gcc/2001-09/msg00526.html
At this point, you claim that because others have been negligent, you have
the authority to check in the patch even though it hasn't been approved.
There is however no evidence that anyone has been negligent, and much
evidence that there has been miscommunication.

>	If there is no specific, documented, technical objection to this
>patch within one week, it will be approved.  Any problems will be handled
>by the GCC policy for patches which have been committed.  If anyone has
>concerns about this patch, review it now.

I object.  My objection is detailed above.  It is specific, and well
documented.

I also object on the grounds that you are overstepping your authority.
I know of no part of the gcc development process that gives you the
authority to check in the patch.  If there is one, please state it.

I also object to the way that you are setting short deadlines, and threatening
to check in the patch if no one reviews it at your own convenience.
The gcc development process does not work that way.  Sometimes it does take
months before someone has time to review a patch.  You can't check in a
patch just because someone didn't review it fast enough to make you happy.

I also object on the grounds that you have done this twice now.  Once in
PR 3384 as described above, and once in todays mail.  You are trying to
bully people into reviewing a patch that furthers your own personal agenda.
I would expect better of someone who is a GCC Steering Committee member.

I also object on the grounds that you have not provided any technical evidence
to support the patch.  I see no evidence that you have tested the patch.
I see no evidence that you have reviewed the patch.  I see no evidence
that you have said anything good about the patch.  All I see of substance
are the two requests trying to bully people into reviewing the patch for you.

No, I didn't forget about the patch.  I am willing to review it, but in
protest of the heavy handed tactics being used, and the complexity of the
problem, I will defer taking action for one week.

Jim


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