From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6113 invoked by alias); 12 Aug 2004 15:34:59 -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 6106 invoked from network); 12 Aug 2004 15:34:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 12 Aug 2004 15:34:58 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7CFYme3010660 for ; Thu, 12 Aug 2004 11:34:53 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7CFYla04609; Thu, 12 Aug 2004 11:34:47 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D05E62B9D; Thu, 12 Aug 2004 11:34:37 -0400 (EDT) Message-ID: <411B8E0D.50609@gnu.org> Date: Thu, 12 Aug 2004 15:34:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: What should we do with rs6000? References: <20040811221554.GG25562@gnat.com> <411AA437.1060702@gnu.org> <20040812033326.GP25562@gnat.com> <411B5D77.1080906@gnu.org> <20040812151240.GW25562@gnat.com> In-Reply-To: <20040812151240.GW25562@gnat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2004-08/txt/msg00462.txt.bz2 >>>Do I understand correctly that you're saying that we should remove >>>> >xm-rs6000.h as well? >> >>> >>> Yep. The infrastructure is going. > > > Hmm, sorry, my fault. Can I ask again, just to make sure I am not > misinterpreting you: This is a configuration I can not test - we > should be able to remove blindly these xm­ files without breaking > anything, but since I can't test them, it may break. Should we go > ahead now anyway? Correct. We can't reasonably require you or anyone else to test on such extremely old configurations. Instead we go with the working assumption that the new code is sufficient to replace the old. Andrew