From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27980 invoked by alias); 27 Aug 2004 15:57:22 -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 27972 invoked from network); 27 Aug 2004 15:57:22 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 27 Aug 2004 15:57:22 -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 i7RFvLS2023610 for ; Fri, 27 Aug 2004 11:57:22 -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 i7RFvL317505; Fri, 27 Aug 2004 11:57:21 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 569502B9D; Fri, 27 Aug 2004 11:56:12 -0400 (EDT) Message-ID: <412F599C.3060902@gnu.org> Date: Fri, 27 Aug 2004 15:57: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: Michael Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] PR gdb/648 (eval.c approval reqd) References: <1091830216.4188.23.camel@localhost> <1092659964.5816.5.camel@localhost> <1093009988.5529.40.camel@cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com> <1093599149.26156.19.camel@cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com> <412F3C47.9060904@gnu.org> <412F3E1D.nailDK31KTUQZ@mindspring.com> <412F4175.3060502@gnu.org> <412F4BD3.nailEEQ135PPF@mindspring.com> In-Reply-To: <412F4BD3.nailEEQ135PPF@mindspring.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00745.txt.bz2 I can see your point, and it's valid. I was thinking of a very simple procedure: proc deprecated_compile_with_gnu_fortran { program } { .... } and have the fortran tests use that. Attatched to the procedure would be a comment stating that anyone wanting to modify the testsuite to support non-GNU fortran will need to implement the infrastructure you describe described. That way the fortran test directory can be populated with tests simultaneous to, or even prior to, adding the feature. While at the same time, establishing a very clear acceptance criteria for anyone wanting to hack things for non-GNU compilers. how does this sound? Andrew