Hi Paul, I am missing an attachment or is the change to small, that I've overlooked it :-)
- Andre On Mon, 15 Jul 2024 09:21:54 +0100 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
