From: Jakub Jelinek <jakub@redhat.com>
To: Pierre-Marie de Rodat <derodat@adacore.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Enhance array types debug info. for Ada
Date: Tue, 07 Oct 2014 08:29:00 -0000 [thread overview]
Message-ID: <20141007082926.GF1986@tucnak.redhat.com> (raw)
In-Reply-To: <54339F77.7050300@adacore.com>
On Tue, Oct 07, 2014 at 10:08:23AM +0200, Pierre-Marie de Rodat wrote:
> >>gcc/fortran/
> >> * trans-types.c (gfc_get_array_descr_info): Use PLACEHOLDER_EXPR nodes
> >> instead of VAR_DECL ones in type-related expressions. Remove base_decl
> >> initialization.
> >
> >Ugh, I must say I don't like PLACEHOLDER_EXPRs at all.
>
> Why so? I know that as far as supported front-ends are concerned,
> PLACEHOLDE_EXPR nodes are used only in GNAT, but it seems to me they
> describe the best what object the bound/stride/allocated/associated
> expressions (self-)reference.
But isn't there a risk that you will have PLACEHOLDER_EXPRs (likely for Ada
only) in some trees not constructed by the langhook?
I mean, DW_OP_push_object_address isn't meaningful in all DWARF contexts,
in some it is forbidden, in others there is really no object to push, and as
implemented, you emit DW_OP_push_object_address (which emits the address of
a context related particular object) for any kind of PLACEHOLDER_EXPR with
RECORD_TYPE.
Thus, I'd feel safer, even if you decide to use a PLACEHOLDER_EXPR, that
the translation of that to DW_OP_push_object_address would be done only
if the PLACEHOLDER_EXPR is equal to some global variable, normally NULL,
and only changed temporarily while emitting loc for the array descriptor.
But then IMHO a DEBUG_EXPR_DECL is better.
That said, if Jason is fine with the patchset as is, I can live with it,
as other FEs don't use PLACEHOLDER_EXPRs, worst case it will affect Ada
only.
Also, please verify that with your patch the generated debug info for some
Fortran arrays is the same.
Jakub
next prev parent reply other threads:[~2014-10-07 8:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-03 8:36 Pierre-Marie de Rodat
2014-09-17 14:38 ` [PING] " Pierre-Marie de Rodat
2014-10-03 8:59 ` [PING 2] " Pierre-Marie de Rodat
2014-10-03 16:42 ` [PING] " Jason Merrill
2014-10-07 8:08 ` Pierre-Marie de Rodat
2014-10-03 9:19 ` [PATCH] " Jakub Jelinek
2014-10-03 9:20 ` Jakub Jelinek
2014-10-07 8:08 ` Pierre-Marie de Rodat
2014-10-07 8:29 ` Jakub Jelinek [this message]
2014-10-08 19:05 ` Pierre-Marie de Rodat
2014-10-22 8:55 ` [PING] " Pierre-Marie de Rodat
2014-11-05 16:37 ` [PING 2] " Pierre-Marie de Rodat
2014-11-26 16:13 ` [PING 3] " Pierre-Marie de Rodat
2014-11-26 18:07 ` [PATCH] " Jakub Jelinek
2014-12-01 15:29 ` Pierre-Marie de Rodat
2014-12-01 15:37 ` Jakub Jelinek
2014-12-01 16:41 ` Pierre-Marie de Rodat
2014-12-15 16:24 ` [PING] " Pierre-Marie de Rodat
2014-12-15 16:24 ` Jakub Jelinek
2014-12-17 16:36 ` Pierre-Marie de Rodat
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=20141007082926.GF1986@tucnak.redhat.com \
--to=jakub@redhat.com \
--cc=derodat@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
/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).