Hi Paul,
I tried to "break" your patch, but I failed. (I tried having same function in
both modules with identical signature; but I do not get a symbol collision). So
to me the patch looks fine now. But you may want to give Harald some time for a
look.
Thanks for the patch,
Andre
On Mon, 15 Jul 2024 10:41:45 +0100
Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote:
> I've done it again! Patch duly added.
>
> Paul
>
> On Mon, 15 Jul 2024 at 09:21, Paul Richard Thomas <
> paul.richard.tho...@gmail.com> wrote:
>
> > Hi Harald,
> >
> > Thank you for the review and for the testing to destruction. Both issues
> > are fixed in the attached patch. Note the new function 'h', which both
> > tests that the namespace confusion is fixed and that the elemental-ness of
> > LEN_TRIM is respected.
> >
> > The patch continues to regtest OK. If I don't receive anymore
> > comments/corrections, I will commit tomorrow morning.
> >
> > Regards
> >
> > Paul
> >
> >
> > On Sun, 14 Jul 2024 at 19:50, Harald Anlauf <anl...@gmx.de> wrote:
> >
> >> 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
> >> >>
> >> >
> >>
> >>
--
Andre Vehreschild * Email: vehre ad gmx dot de
