From: Tobias Burnus <tobias.burnus@physik.fu-berlin.de>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org, sanimir.agovic@intel.com,
Keven Boell <keven.boell@intel.com>
Subject: Re: PING: [V3 00/21] Fortran dynamic array support
Date: Mon, 17 Nov 2014 08:59:00 -0000 [thread overview]
Message-ID: <20141117085854.GA6766@physik.fu-berlin.de> (raw)
In-Reply-To: <20141002150034.GF6927@adacore.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
next prev parent reply other threads:[~2014-11-17 8:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 9:22 Keven Boell
2014-09-10 9:22 ` [V3 20/21] test: test sizeof for dynamic fortran arrays Keven Boell
2014-09-10 9:22 ` [V3 06/21] vla: get dynamic array corner cases to work Keven Boell
2014-09-10 9:22 ` [V3 17/21] test: accessing dynamic array history values Keven Boell
2014-09-10 9:22 ` [V3 10/21] vla: add NEWS entry for dynamic array support Keven Boell
2014-09-10 17:03 ` Eli Zaretskii
2014-09-10 9:22 ` [V3 12/21] test: evaluate dynamic arrays using Fortran primitives Keven Boell
2014-09-10 9:22 ` [V3 04/21] vla: reconstruct value to compute bounds of target type Keven Boell
2014-09-10 9:22 ` [V3 11/21] test: basic tests for dynamic array evaluations in Fortran Keven Boell
2014-09-10 9:22 ` [V3 16/21] test: dynamic arrays passed to functions Keven Boell
2014-09-10 9:22 ` [V3 07/21] vla: changed string length semantic Keven Boell
2014-09-10 9:22 ` [V3 19/21] test: basic MI test for the dynamic array support Keven Boell
2014-09-10 9:22 ` [V3 08/21] vla: get Fortran dynamic strings working Keven Boell
2014-09-10 9:22 ` [V3 14/21] test: correct ptype of dynamic arrays in Fortran Keven Boell
2014-09-10 9:22 ` [V3 09/21] vla: add stride support to fortran arrays Keven Boell
2014-09-10 9:22 ` [V3 02/21] vla: make dynamic fortran arrays functional Keven Boell
2014-09-10 9:22 ` [V3 18/21] test: dynamic string evaluations Keven Boell
2014-09-10 9:22 ` [V3 05/21] vla: use value constructor instead of raw-buffer manipulation Keven Boell
2014-09-10 9:22 ` [V3 15/21] test: evaluating allocation/association status Keven Boell
2014-09-10 9:22 ` [V3 21/21] test: stride support for dynamic arrays Keven Boell
2014-09-10 9:22 ` [V3 03/21] vla: make field selection work with vla Keven Boell
2014-09-10 9:22 ` [V3 13/21] test: dynamic arrays passed to subroutines Keven Boell
2014-09-10 9:22 ` [V3 01/21] vla: introduce allocated/associated flags Keven Boell
2014-10-02 8:35 ` PING: [V3 00/21] Fortran dynamic array support Tobias Burnus
2014-10-02 15:00 ` Joel Brobecker
2014-11-17 8:59 ` Tobias Burnus [this message]
2014-11-17 10:05 ` Joel Brobecker
2014-12-09 8:00 ` Tobias Burnus
2014-12-09 9:18 ` Joel Brobecker
2014-12-09 10:03 ` Keven Boell
2015-02-04 13:22 ` Tobias Burnus
2015-02-04 14:18 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141117085854.GA6766@physik.fu-berlin.de \
--to=tobias.burnus@physik.fu-berlin.de \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=keven.boell@intel.com \
--cc=sanimir.agovic@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).