From: "Dominique d'Humières" <dominiq@lps.ens.fr>
To: louis.krupp@zoho.com
Cc: GNU GFortran <fortran@gcc.gnu.org>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: Possible patch for pr62242 -- follow-up
Date: Tue, 15 Sep 2015 13:41:00 -0000 [thread overview]
Message-ID: <B8D16AD4-5EFC-432C-AE1A-1ED62ED778EA@lps.ens.fr> (raw)
Louis,
A few comments:
(1) your patch fixes pr62242 and, as said in a previous mail, pr62246, pr60110, and some variants of pr52332. I have updated pr52332 and marked pr62246 and pr60110 as duplicate. Could you please add
PR fortran/52332
to the ChangeLog entry?
(2) You need a ChangeLog entry for the tests in gcc/testsuite.
(3) The usual way to attract attention is a PING in the subject.
(4) AFAICT your patch boils down to
--- ../_clean/gcc/fortran/trans-array.c 2015-08-29 10:47:51.000000000 +0200
+++ gcc/fortran/trans-array.c 2015-09-15 15:21:16.000000000 +0200
@@ -1835,8 +1835,6 @@ get_array_ctor_all_strlen (stmtblock_t *
gfc_add_block_to_block (block, &se.pre);
gfc_add_block_to_block (block, &se.post);
-
- e->ts.u.cl->backend_decl = *len;
}
}
@@ -2226,6 +2224,7 @@ trans_array_constructor (gfc_ss * ss, lo
if (expr->ts.type == BT_CHARACTER)
{
bool const_string;
+ gfc_charlen *new_cl;
/* get_array_ctor_strlen walks the elements of the constructor, if a
typespec was given, we already know the string length and want the one
@@ -2251,7 +2250,9 @@ trans_array_constructor (gfc_ss * ss, lo
and not end up here. */
gcc_assert (ss_info->string_length);
- expr->ts.u.cl->backend_decl = ss_info->string_length;
+ new_cl = gfc_new_charlen (gfc_current_ns, expr->ts.u.cl);
+ new_cl->backend_decl = ss_info->string_length;
+ expr->ts.u.cl = new_cl;
type = gfc_get_character_type_len (expr->ts.kind, ss_info->string_length);
if (const_string)
@@ -2589,7 +2590,8 @@ gfc_add_loop_ss_code (gfc_loopinfo * loo
if (expr->ts.type == BT_CHARACTER
&& ss_info->string_length == NULL
&& expr->ts.u.cl
- && expr->ts.u.cl->length)
+ && expr->ts.u.cl->length
+ && expr->ts.u.cl->length->expr_type == EXPR_CONSTANT)
{
gfc_init_se (&se, NULL);
gfc_conv_expr_type (&se, expr->ts.u.cl->length,
with two questions:
(a) Is the line
e->ts.u.cl->backend_decl = *len;
needed? It does not for my own tests (although this may be masked by errors or other ICEs)
(b) A long question for the hunk at 2251 I don’t understand (thus cannot answer).
Thanks for the patch,
Dominique
next reply other threads:[~2015-09-15 13:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-15 13:41 Dominique d'Humières [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-09-09 7:37 Possible patch for pr62242 Louis Krupp
2015-09-15 6:39 ` Possible patch for pr62242 -- follow-up Louis Krupp
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=B8D16AD4-5EFC-432C-AE1A-1ED62ED778EA@lps.ens.fr \
--to=dominiq@lps.ens.fr \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=louis.krupp@zoho.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).