From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8889 invoked by alias); 30 Apr 2002 17:50:04 -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 8795 invoked from network); 30 Apr 2002 17:49:56 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 30 Apr 2002 17:49:56 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA27216; Tue, 30 Apr 2002 10:49:53 -0700 (PDT) Message-ID: <3CCED654.A753D4E2@redhat.com> Date: Tue, 30 Apr 2002 10:50:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Petr Sorfa CC: "gdb-patches@sources.redhat.com" Subject: Re: [RFC] FORTRAN95 Expression parser References: <3CCD99D3.66CD0B7E@caldera.com> <3CCDF533.4D5C2851@redhat.com> <3CCEA15F.A299E742@caldera.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg01156.txt.bz2 Petr Sorfa wrote: > > Hi Michael, > > > > I've created a FORTRAN95 expression parser for GDB. It is based off the > > > current FORTRAN expression parser, but has changed significantly in > > > source and functionality. I've developed it as a new separate parser > > > with the file prefix of f95-x as opposed to the existing f-x files. > > > > > > The question is whether I should submit the patch as the f95-x files > > > (which will leave the current FORTRAN parser untouched) or replace the > > > existing FORTRAN parser? > > > > > > Note that the F95 parser fully supports F77/F90/F95, but differs a bit > > > from the existing fortran gdb parser (which relies a bit heavily on C > > > notation.) > > > > How much does it differ? Functionally? In user-visible ways? > > How about test suites? > It differs considerably - it supports FORTRAN expressions, not C > expressions that handle FORTRAN stuff. It supports FORTRAN intrinsics > (KIND, SIZE, LEN, ALLOCATED, ASSOCIATED, etc..). Proper FORTRAN array > subscripts (including stride). Proper print out of FORTRAN types and > variables. Supports column major notation. Supports MODULES, CONTAINS, > TYPE records, and so on. > > User visible ways are considerably different, like I said, it treats > expressions like FORTRAN would. Hmmm, tough call. Sounds like your front end is considerably better, but who knows how many users may have grown accustomed/dependent on the old behavior? Any way you could merge the two? Otherwise, it sounds like we might need to keep both, perhaps with a mode switch.