From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8917 invoked by alias); 17 Nov 2014 08:59:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 8906 invoked by uid 89); 17 Nov 2014 08:59:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: outpost2.zedat.fu-berlin.de Received: from outpost2.zedat.fu-berlin.de (HELO outpost2.zedat.fu-berlin.de) (130.133.4.90) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 17 Nov 2014 08:59:05 +0000 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XqI9F-002S3y-NT>; Mon, 17 Nov 2014 09:59:01 +0100 Received: from mx.physik.fu-berlin.de ([160.45.64.218]) by relay1.zedat.fu-berlin.de (Exim 4.82) with esmtps (envelope-from ) id <1XqI9F-0014mV-Lf>; Mon, 17 Nov 2014 09:59:01 +0100 Received: from squeeze64.physik.fu-berlin.de ([160.45.66.239] helo=login.physik.fu-berlin.de) by mx.physik.fu-berlin.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XqI98-000151-Ll; Mon, 17 Nov 2014 09:58:54 +0100 Received: from tburnus by login.physik.fu-berlin.de with local (Exim 4.72 #1 (Debian)) id 1XqI98-0001yX-J9; Mon, 17 Nov 2014 09:58:54 +0100 Date: Mon, 17 Nov 2014 08:59:00 -0000 From: Tobias Burnus To: Joel Brobecker Cc: gdb-patches@sourceware.org, sanimir.agovic@intel.com, Keven Boell Subject: Re: PING: [V3 00/21] Fortran dynamic array support Message-ID: <20141117085854.GA6766@physik.fu-berlin.de> References: <1410340929-20653-1-git-send-email-keven.boell@intel.com> <20141002083529.GA11298@physik.fu-berlin.de> <20141002150034.GF6927@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002150034.GF6927@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2014-11/txt/msg00398.txt.bz2 Hi Joel, On Thu, Oct 02, 2014 at 08:00:34AM -0700, Joel Brobecker wrote: > > I would like to ping the Fortran patch series at > > https://sourceware.org/ml/gdb-patches/2014-09/threads.html#00259 > > > > I think it would be useful if Sourceware's gdb would finally get > > support for Fortran 90 arrays. > > > > The patch might be not as clean as hoped for,* but it is the best > > what we currently have. Thus, I would be happy if someone could > > review it. > > I started looking at them a while ago, but unfortunately I am > in the middle of a lot of things, and I don't expect to have > much time until probably Dec. I know it is not quite December, but what's the situation time wise? Regarding the other comments, I leave them to Keven/Intel. Regards, Tobias, who works on the GCC side > My main issue about the patch series is that it adds new fields > in struct type which are only used occasionally. The problem with > that is that it is a memory-sensitive type, for which a lot of > work has gone into making as small as possible. It would be OK > if most instances were benefiting from it, but it's a lot less > attractive when you know it's only occasionally non-null. > > Ideally, we'd want to keep the type structure untouched, so that > only entities needing dynamic property handling get the size > increase, and only for those attributes that are in fact dynamic. > One idea I had was to manage that info right past the end of > struct type. But that may be very hacky, and I am not sure if > it is actually practical. The next idea is to add one pointer > to handle all future dynamic props. Either way, I need to explore > things a bit. > > Once we have the above figured out, one thing which I think > would help a lot is modify the way the patches have been > submitted. Instead of sending 20 patches, where we get a series > of code changes followed by a series of testsuite changes, > it would be useful to provide a testsuite change for every > patch that brings an improvement. This way, the testsuite change > shows what the patch does, and that way, I can review both changes > at the same time. > > -- > Joel