[Patch, fortran] PR84868 - [11/12/13/14/15 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208
Harald Anlauf
anlauf@gmx.de
Sun Jul 14 18:50:54 GMT 2024
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.thomas@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
>>
>
More information about the Fortran
mailing list