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