*Ping*
> Gesendet: Dienstag, 03. August 2021 um 23:17 Uhr
> Von: "Harald Anlauf" <anl...@gmx.de>
> An: "Harald Anlauf" <anl...@gmx.de>
> Cc: "Tobias Burnus" <tobias_bur...@mentor.com>, "Bernhard Reutner-Fischer"
> <rep.dot....@gmail.com>, "Harald Anlauf via Gcc-patches"
> <gcc-patches@gcc.gnu.org>, "fortran" <fort...@gcc.gnu.org>
> Betreff: Re: [PATCH] PR fortran/100950 - ICE in
> output_constructor_regular_field, at varasm.c:5514
>
> Here's now my third attempt to fix this PR, taking into account
> the comments by Tobias and Bernhard.
>
> > > On 10.06.21 20:52, Harald Anlauf via Fortran wrote:
> > > > +static bool
> > > > +substring_has_constant_len (gfc_expr *e)
> > > > +{
> > > > + ptrdiff_t istart, iend;
> > > > + size_t length;
> > > > + bool equal_length = false;
> > > > +
> > > > + if (e->ts.type != BT_CHARACTER
> > > > + || !e->ref
> > > > + || e->ref->type != REF_SUBSTRING
> > >
> > > Is there a reason why you do not handle:
> > >
> > > type t
> > > character(len=5) :: str1
> > > character(len=:), allocatable :: str2
> > > end type
> > > type(t) :: x
> > >
> > > allocate(x%str2, source="abd")
> > > if (len (x%str)) /= 1) ...
> > > if (len (x%str2(1:2) /= 2) ...
> > > etc.
> > >
> > > Namely: Search the last_ref = expr->ref->next->next ...?
> > > and then check that lastref?
>
> The mentioned search is now implemented.
>
> Note, however, that gfc_simplify_len still won't handle neither
> deferred strings nor their substrings.
>
> I think there is nothing to simplify at compile time here. Otherwise
> there would be a conflict/inconsistency with type parameter inquiry,
> see F2018:9.4.5(2):
>
> "A deferred type parameter of a pointer that is not associated or
> of an unallocated allocatable variable shall not be inquired about."
>
> > > * * *
> > >
> > > Slightly unrelated: I think the following does not violate
> > > F2018's R916 / C923 – but is rejected, namely:
> > > R916 type-param-inquiry is designator % type-param-name
> > > the latter is 'len' or 'kind' for intrinsic types. And:
> > > R901 designator is ...
> > > or substring
> > > But
> > >
> > > character(len=5) :: str
> > > print *, str(1:3)%len
> > > end
> > >
> > > fails with
> > >
> > > 2 | print *, str(1:3)%len
> > > | 1
> > > Error: Syntax error in PRINT statement at (1)
> > >
> > >
> > > Assuming you don't want to handle it, can you open a new PR?
> > > Thanks!
>
> I tried to look into this, but there appear to be several unrelated
> issues requiring a separate treatment. I therefore opened:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735
>
> > > > + istart = gfc_mpz_get_hwi (e->ref->u.ss.start->value.integer);
> > > > + iend = gfc_mpz_get_hwi (e->ref->u.ss.end->value.integer);
> > > > + length = gfc_mpz_get_hwi
> > > > (e->ref->u.ss.length->length->value.integer);
> > > > +
> > > > + if (istart <= iend)
> > > > + {
> > > > + if (istart < 1)
> > > > + {
> > > > + gfc_error ("Substring start index (%ld) at %L below 1",
> > > > + (long) istart, &e->ref->u.ss.start->where);
> > >
> > > As mentioned by Bernhard, you could use HOST_WIDE_INT_PRINT_DEC.
> > >
> > > (It probably only matters on Windows which uses long == int = 32bit for
> > > strings longer than INT_MAX.)
>
> Done.
>
> The updated patch regtests fine. OK?
>
> Thanks,
> Harald
>
>
> Fortran - simplify length of substring with constant bounds
>
> gcc/fortran/ChangeLog:
>
> PR fortran/100950
> * simplify.c (substring_has_constant_len): New.
> (gfc_simplify_len): Handle case of substrings with constant
> bounds.
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/100950
> * gfortran.dg/pr100950.f90: New test.
>
>
