From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4642 invoked by alias); 27 Aug 2004 09:15: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 4617 invoked from network); 27 Aug 2004 09:15:02 -0000 Received: from unknown (HELO cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com) (81.105.116.12) by sourceware.org with SMTP; 27 Aug 2004 09:15:02 -0000 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com (8.12.11/8.12.11) with ESMTP id i7R9WTG0027259; Fri, 27 Aug 2004 10:32:30 +0100 Subject: Re: [PATCH/RFA] PR gdb/648 (eval.c approval reqd) From: David Lecomber To: Jim Blandy Cc: patches In-Reply-To: References: <1091830216.4188.23.camel@localhost> <1092659964.5816.5.camel@localhost> <1093009988.5529.40.camel@cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com> Content-Type: text/plain Message-Id: <1093599149.26156.19.camel@cpc4-oxfd5-5-0-cust12.oxfd.cable.ntl.com> Mime-Version: 1.0 Date: Fri, 27 Aug 2004 09:15:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00723.txt.bz2 Hi Jim On Fri, 2004-08-27 at 00:59, Jim Blandy wrote: > In your original post, you said, "G77 puts things in row-major order". > It looks to me as if G77 puts the *types* in row-major order (contrary > to the Dwarf spec, which wants them in the order they appear in source > code), but it locates the actual arrays in memory in column-major > order: [..] > This shows that varying the leftmost index yields the smallest change > in element address, which is column-major. So the arrays are actually > laid out correctly; it's just the types in the Dwarf 2 info that are > wrong. Yes -- I'm in agreement here, although I hadn't actually thought of that before. If that weren't the case, then it wouldn't be possible to link g77 output with other compilers,.. > If that's all correct, then this patch is approved. Good-o, > It seems to me that there's a separate bug in f-valprint.c. The > output below is incorrect, right? It's printed as a series of > columns, not a series of rows. Or is that what users of a Fortran > debugger would expect? > > (gdb) p twodi > $1 = (( 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, > 19, 20) ( 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, > 34, 36, 38, 40) ( 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, > [..] A Fortran user would expect this like this, so it's not a bug. Suppose a Fortran-er is working with an array of 3-d points, for some finite element application. To ensure the x,y,z are in adjacent memory for better cache behaviour, there'd be an array of REAL(3, 100000) -- which when printed by GDB will produce a list of points (x, y, z). They'd want that. Cheers David