This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: PING: [V3 00/21] Fortran dynamic array support
- From: Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org, sanimir dot agovic at intel dot com, Keven Boell <keven dot boell at intel dot com>
- Date: Mon, 17 Nov 2014 09:58:54 +0100
- Subject: Re: PING: [V3 00/21] Fortran dynamic array support
- Authentication-results: sourceware.org; auth=none
- References: <1410340929-20653-1-git-send-email-keven dot boell at intel dot com> <20141002083529 dot GA11298 at physik dot fu-berlin dot de> <20141002150034 dot GF6927 at adacore dot com>
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