[PATCH] PR fortran/87851 - [9/10/11/12 Regression] Wrong return type for len_trim

[Harald Anlauf]

Am 21.11.21 um 12:46 schrieb Mikael Morin:
> Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit :
>> Dear Fortranners,
>>
>> scalariziation of the elemental intrinsic LEN_TRIM was ICEing
>> when the optional KIND argument was present.
>>
>> The cleanest solution is to use the infrastructure added by
>> Mikael's fix for PR97896.  In that case it is a 1-liner.  :-)
>>
>> That fix is available on mainline and on 11-branch only, though.
>> My suggestion is to fix the current PR only for the same branches,
>> leaving the regression unfixed for older ones.
>>
>> Regtested on x86_64-pc-linux-gnu.  OK for mainline and 11-branch?
>>
> Your change itself is fine.
> The PR was originally about a type mismatch between the gfortran library
> and the call generated by the front-end.

The supposed type mismatch was due to Janne's commit r8-5772:

commit f622221ab42c4ca550059add89ffda00ed2b3c03
Author: Janne Blomqvist <jb@gcc.gnu.org>
Date:   Fri Jan 5 21:01:12 2018 +0200

     PR 78534 Change character length from int to size_t

     In order to handle large character lengths on (L)LP64 targets, switch
     the GFortran character length from an int to a size_t.

     This is an ABI change, as procedures with character arguments take
     hidden arguments with the character length.
[...]

LEN_TRIM is of course of type default integer, which is handled fine
in gfc_resolve_len_trim, setting f->ts.kind, the same way as it is
done in gfc_resolve_index_func or elsewhere, and conversions are
properly taken care of as far as I can tell.

Things work(ed) fine for the "scalar" version of LEN_TRIM, even if the
optional KIND argument was present, before the above commit.  But not
the elemental version working on rank>=1 with KIND present.  That did
not change.  See PR87711.

Thinking again, the patch primarily addresses PR87711 (for 11/12) and
fixes some of the comments in PR87851.  We'd need to find out what
exactly is left from the latter.

The dump-tree of the testcase looks fine to me, even when compiling
with -fdefault-integer-8, and I do not see any conversion warnings.

> As the code generated contains a cast, I think it’s fine as well.

Well, LEN_TRIM is of default integer, unless KIND is given.

> But please give Thomas (bug reporter) one more day to comment on this.

Sure.

> Then I think you can proceed.
>
> Thanks.
>

Thanks,
Harald