From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11556 invoked by alias); 25 Mar 2004 22:14:19 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11544 invoked from network); 25 Mar 2004 22:14:18 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 25 Mar 2004 22:14:18 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5E7602B92; Thu, 25 Mar 2004 17:14:18 -0500 (EST) Message-ID: <406359BA.9000302@gnu.org> Date: Thu, 25 Mar 2004 22:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: cgd@broadcom.com Cc: Richard Sandiford , gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Second go at vr5500 hilo hazard fix References: <87oequw5xw.fsf@redhat.com> <87znadvpr7.fsf@redhat.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00640.txt.bz2 >>> As for having to tag each individual entry in the .igen file with an >>> explicit CPU. Yes, that sux. However, I also believe that it has >>> significantly reduced the overall error rate (no more breaking one >>> target by editing another) and that benefit vastly outweighs the short >>> term pain. > > > I still take issue with the latter ("short term pain"), for such > additions have to stay in for the life of support for the arch in the > simulator, which *should* be quite long term. Look at it this way, if the igen mechanism is used, gcc is able to eliminate everything :-) If there's another way of achieving the same effect, I'm interested. >>> But that was exactly what Andrew objected to: > > > And he and I (strongly, IMO) disagreed at that time. (IIRC, I think I > mentioned at the time that the right solution to this is better > testing. I still think that's true.) > > Of course, in August of last year, (unprompted by me!) he decided to > stop being MIPS co-maintainer. So, at this point, I'm the approval > authority, and I like my style of patch most. 8-) > > I would like to see it augmented to include some test code (now that > there's a prelim test framework for mips, with what, 1 test? 8-), but > as long as you commit to actually doing that I'm OK with it waiting a > little bit. Your call. Andrew