Hi Paul,

at first sight the patch seems to be the right approach, but
it breaks for the following two variations:

(1) LEN_TRIM is elemental, but the following is erroneously rejected:

  function g(n) result(z)
    integer,  intent(in) :: n
    character, parameter :: d(3,3) = 'x'
    character(len_trim(d(n,n))) :: z
    z = d(n,n)
  end

This is fixed here by commenting/removing the line

      expr->rank = 1;

as the result shall have the same shape as the argument.
Can you check?

(2) The handling of namespaces is problematic: using the same name
for a parameter within procedures in the same scope generates another
ICE.  The following testcase demonstrates this:

module m
  implicit none
  integer :: c
contains
  function f(n) result(z)
    integer,  intent(in) :: n
    character, parameter :: c(3) = ['x', 'y', 'z']
    character(len_trim(c(n)))  :: z
    z = c(n)
  end
  function h(n) result(z)
    integer,  intent(in) :: n
    character, parameter :: c(3,3) = 'x'
    character(len_trim(c(n,n)))  :: z
    z = c(n,n)
  end
end
program p
  use m
  implicit none
  print *, f(2)
  print *, h(1)
end

I get:

pr84868-z0.f90:22:15:

   22 |   print *, h(1)
      |               1
internal compiler error: in gfc_conv_descriptor_stride_get, at
fortran/trans-array.cc:483
0x243e156 internal_error(char const*, ...)
        ../../gcc-trunk/gcc/diagnostic-global-context.cc:491
0x96dd70 fancy_abort(char const*, int, char const*)
        ../../gcc-trunk/gcc/diagnostic.cc:1725
0x749d68 gfc_conv_descriptor_stride_get(tree_node*, tree_node*)
        ../../gcc-trunk/gcc/fortran/trans-array.cc:483
[rest of traceback elided]

Renaming the parameter array in h solves the problem.

Am 13.07.24 um 17:57 schrieb Paul Richard Thomas:
Hi All,

Harald has pointed out that I attached the ChangeLog twice and the patch
not at all :-(

Please find the patch duly attached.

Paul


On Sat, 13 Jul 2024 at 10:58, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

Hi All,

After messing around with argument mapping, where I found and fixed
another bug, I realised that the problem lay with simplification of
len_trim with an argument that is the element of a parameter array. The fix
was then a straightforward lift of existing code in expr.cc. The mapping
bug is also fixed by supplying the se string length when building character
typespecs.

Regtests just fine. OK for mainline? I believe that this is safe for
backporting to 14-branch before the 14.2 release - thoughts?

If you manage to correct/fix the above issues, I am fine with
backporting, as this appears a very reasonable fix.

Thanks,
Harald

Regards

Paul



Reply via email to