From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steve Kargl Newsgroups: gmane.comp.gcc.fortran,gmane.emacs.devel Subject: Re: Emacs and GFortran Date: Wed, 1 Nov 2006 15:26:34 -0800 Message-ID: <20061101232634.GA44475@troutmask.apl.washington.edu> References: <200611011037.12356.wt@atmos.colostate.edu> <20061101180354.GA62686@troutmask.apl.washington.edu> <20061101203931.E775C4401A@Psilocybe.Update.UU.SE> <20061101213056.GA63890@troutmask.apl.washington.edu> <20061101215142.51A0944013@Psilocybe.Update.UU.SE> <20061101223548.GA72295@troutmask.apl.washington.edu> <20061101224912.ED10144013@Psilocybe.Update.UU.SE> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1162423772 12601 80.91.229.2 (1 Nov 2006 23:29:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 1 Nov 2006 23:29:32 +0000 (UTC) Cc: wt@atmos.colostate.edu, fortran@gcc.gnu.org, emacs-devel@gnu.org Original-X-From: fortran-return-15399-gcgf-fortran=m.gmane.org@gcc.gnu.org Thu Nov 02 00:29:29 2006 Return-path: Envelope-to: gcgf-fortran@gmane.org Original-Received: from sourceware.org ([209.132.176.174]) by ciao.gmane.org with smtp (Exim 4.43) id 1GfPW8-0005iu-5L for gcgf-fortran@gmane.org; Thu, 02 Nov 2006 00:29:08 +0100 Original-Received: (qmail 3068 invoked by alias); 1 Nov 2006 23:29:04 -0000 Original-Received: (qmail 2903 invoked by uid 22791); 1 Nov 2006 23:29:02 -0000 X-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Original-Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.208.78.105) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Nov 2006 23:28:58 +0000 Original-Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.8/8.13.8) with ESMTP id kA1NQYWM035243; Wed, 1 Nov 2006 15:26:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Original-Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id kA1NQY6F035242; Wed, 1 Nov 2006 15:26:34 -0800 (PST) (envelope-from sgk) Original-To: "Alfred M. Szmidt" Content-Disposition: inline In-Reply-To: <20061101224912.ED10144013@Psilocybe.Update.UU.SE> User-Agent: Mutt/1.4.2.2i X-IsSubscribed: yes Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Post: List-Help: , Original-Sender: fortran-owner@gcc.gnu.org Xref: news.gmane.org gmane.comp.gcc.fortran:15368 gmane.emacs.devel:61583 Archived-At: On Wed, Nov 01, 2006 at 11:49:12PM +0100, Alfred M. Szmidt wrote: > > > | l.inc:1: > > | > > | Included at l.f90:2 > > | > > | integer i > > | 1 > > | l.f90:3: > > | > > | call i(j) > > | 2 > > | Error: 'i' at (1) has a type, which is not consistent with the CALL at (2) > > > > Which will work with any program that parses GNU style error > > messages by producing two places where one can go to; the user > > can choose which place to edit. It doesn't have to catch the > > exact place, it is after all not a substitute for a brain. > > What about the third location? You need to parse "Included at > l.f90:2" to jump to that location to remove the included file. > > The error is not in the included file. What do you mean the error is not the included file? The include statement may have been leftover from a debugging session and should have been removed to not conflict with the CALL statement. > > Can you please apply one of those patches? They both fix the > > problem. > > But it does not fix the nonconformance to the GNU standard. The > above message would need to become > > No, this is not needed. As has been repeated several times by various > people. The patch fixes the problem to the same extent that g77 fixed > it. Such extra conformance is not needed at this point. First, you and others ask us to make gfortran conform to the GNU standard for error formats. I point out it is not trivial and gfortran's error reporting mechanism works. Someone comes up with a bandaid patch that doesn't yield conformance but makes some people happy because it makes their immediate problem go away. I again point out the bandaid patch does not yield conformance, and now your saying "Well, it's good enough. We really did not mean that gfortran should conform to the GNU standard." -- Steve