public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Tobias Burnus <tobias.burnus@physik.fu-berlin.de>
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: Thu, 02 Oct 2014 15:00:00 -0000	[thread overview]
Message-ID: <20141002150034.GF6927@adacore.com> (raw)
In-Reply-To: <20141002083529.GA11298@physik.fu-berlin.de>

> 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.

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

  reply	other threads:[~2014-10-02 15:00 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 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 08/21] vla: get Fortran dynamic strings working 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 07/21] vla: changed string length semantic 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 12/21] test: evaluate dynamic arrays using Fortran primitives 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 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-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 05/21] vla: use value constructor instead of raw-buffer manipulation 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-10-02  8:35 ` PING: [V3 00/21] Fortran dynamic array support Tobias Burnus
2014-10-02 15:00   ` Joel Brobecker [this message]
2014-11-17  8:59     ` Tobias Burnus
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=20141002150034.GF6927@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keven.boell@intel.com \
    --cc=sanimir.agovic@intel.com \
    --cc=tobias.burnus@physik.fu-berlin.de \
    /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).