From: Harald Anlauf <anlauf@gmx.de>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: jakub@redhat.com, "H.J. Lu" <hjl.tools@gmail.com>,
Tobias Burnus <tobias@codesourcery.com>,
Harald Anlauf via Gcc-patches <gcc-patches@gcc.gnu.org>,
fortran <fortran@gcc.gnu.org>
Subject: Aw: Re: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
Date: Fri, 20 Aug 2021 14:17:48 +0200 [thread overview]
Message-ID: <trinity-9e4a13d5-7919-4569-8bff-7bae9a658e23-1629461868330@3c-app-gmx-bap33> (raw)
In-Reply-To: <dedfaa1b-8b24-836d-46fd-5fbf8525db17@codesourcery.com>
> Gesendet: Freitag, 20. August 2021 um 14:01 Uhr
> Von: "Tobias Burnus" <tobias@codesourcery.com>
> On 20.08.21 12:53, Harald Anlauf wrote:
>
> > I played with variations of the testcase by specifying illegal
> > substring bounds, but all these cases were caught in a different
> > spot with similar error messages.
>
> I can confirm this. – I think in order to reduce the clutter, the
> diagnostic probably should be removed.
I am unable to prove that we will never that check. So how about:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index eaabbffca4d..04722a8640c 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4552,27 +4552,13 @@ substring_has_constant_len (gfc_expr *e)
if (istart <= iend)
{
- char buffer[21];
- if (istart < 1)
- {
- sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, istart);
- gfc_error ("Substring start index (%s) at %L below 1",
- buffer, &ref->u.ss.start->where);
- return false;
- }
-
/* For deferred strings use end index as proxy for length. */
if (e->ts.deferred)
length = iend;
else
length = gfc_mpz_get_hwi (ref->u.ss.length->length->value.integer);
- if (iend > length)
- {
- sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, iend);
- gfc_error ("Substring end index (%s) at %L exceeds string length",
- buffer, &ref->u.ss.end->where);
- return false;
- }
+
+ gcc_assert (istart >= 1 && iend <= length);
length = iend - istart + 1;
}
else
Or skip the gcc_assert and cross fingers... (we then would not even need to
verify ref->u.ss.length in that depth).
Harald
next prev parent reply other threads:[~2021-08-20 12:17 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 21:39 Harald Anlauf
2021-06-10 10:24 ` Bernhard Reutner-Fischer
2021-06-10 12:47 ` Bernhard Reutner-Fischer
2021-06-10 18:52 ` Harald Anlauf
2021-06-11 6:02 ` Bernhard Reutner-Fischer
2021-06-21 12:12 ` Tobias Burnus
2021-07-12 21:23 ` Harald Anlauf
2021-08-03 21:17 ` Harald Anlauf
2021-08-11 19:28 ` *PING* " Harald Anlauf
2021-08-18 10:22 ` Tobias Burnus
2021-08-18 21:01 ` Harald Anlauf
2021-08-19 7:52 ` Tobias Burnus
2021-08-19 19:11 ` Harald Anlauf
2021-08-20 0:21 ` H.J. Lu
2021-08-20 6:48 ` Harald Anlauf
2021-08-20 9:16 ` Jakub Jelinek
2021-08-20 9:45 ` Aw: " Harald Anlauf
2021-08-20 10:12 ` Jakub Jelinek
2021-08-20 10:53 ` Aw: " Harald Anlauf
2021-08-20 10:59 ` Jakub Jelinek
2021-08-20 11:43 ` [PATCH, committed] Fix bootstrap breakage caused by r12-3033 (PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514) Harald Anlauf
2021-08-20 12:01 ` Aw: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514 Tobias Burnus
2021-08-20 12:17 ` Harald Anlauf [this message]
2021-08-20 14:19 ` Aw: " Tobias Burnus
2021-08-20 19:43 ` Harald Anlauf
2021-08-20 11:50 ` [Patch] c-format.c/Fortran: Support %wd / host-wide integer in gfc_error (Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514) Tobias Burnus
2021-08-20 11:56 ` Jakub Jelinek
2021-08-20 13:47 ` Tobias Burnus
2021-08-20 13:53 ` Jakub Jelinek
2021-08-20 9:29 ` [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514 Tobias Burnus
2021-06-18 20:47 ` PING " Harald Anlauf
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=trinity-9e4a13d5-7919-4569-8bff-7bae9a658e23-1629461868330@3c-app-gmx-bap33 \
--to=anlauf@gmx.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=jakub@redhat.com \
--cc=tobias@codesourcery.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).