Hi Harald,

Please find an updated version of the patch that rolls in Steve's patch for
PR114141, fixes unlimited polymorphic function selectors and cures the
memory leaks. I apologise for not working on this sooner but, as I informed
you, I have been away for an extended trip to Australia.

The chunks that fix PR114141 are picked out in comment 14 to the PR and the
cures to the problems that you found in the first review are found at
trans-stmt.cc:2047-49.

Regtests fine. OK for trunk, bearing in mind that most of the patch is ring
fenced by the inferred_type flag?

Cheers

Paul


On Mon, 8 Jan 2024 at 21:53, Harald Anlauf <anlauf@gmx.de> wrote:

> Hi Paul,
>
> your patch looks already very impressive!
>
> Regarding the patch as is, I am still trying to grok it, even with your
> explanations at hand...
>
> While the testcase works as advertised, I noticed that it exhibits a
> runtime memleak that occurs for (likely) each case where the associate
> target is an allocatable, class-valued function result.
>
> I tried to produce a minimal testcase using class(*), which apparently
> is not handled by your patch (it ICEs for me):
>
> program p
>    implicit none
>    class(*), allocatable :: x(:)
>    x = foo()
>    call prt (x)
>    deallocate (x)
>    ! up to here no memleak...
>    associate (var => foo())
>      call prt (var)
>    end associate
> contains
>    function foo() result(res)
>      class(*), allocatable :: res(:)
>      res = [42]
>    end function foo
>    subroutine prt (x)
>      class(*), intent(in) :: x(:)
>      select type (x)
>      type is (integer)
>         print *, x
>      class default
>         stop 99
>      end select
>    end subroutine prt
> end
>
> Traceback (truncated):
>
> foo.f90:9:18:
>
>      9 |     call prt (var)
>        |                  1
> internal compiler error: tree check: expected record_type or union_type
> or qual_union_type, have function_type in gfc_class_len_get, at
> fortran/trans-expr.cc:271
> 0x19fd5d5 tree_check_failed(tree_node const*, char const*, int, char
> const*, ...)
>          ../../gcc-trunk/gcc/tree.cc:8952
> 0xe1562d tree_check3(tree_node*, char const*, int, char const*,
> tree_code, tree_code, tree_code)
>          ../../gcc-trunk/gcc/tree.h:3652
> 0xe3e264 gfc_class_len_get(tree_node*)
>          ../../gcc-trunk/gcc/fortran/trans-expr.cc:271
> 0xecda48 trans_associate_var
>          ../../gcc-trunk/gcc/fortran/trans-stmt.cc:2325
> 0xecdd09 gfc_trans_block_construct(gfc_code*)
>          ../../gcc-trunk/gcc/fortran/trans-stmt.cc:2383
> [...]
>
> I don't see anything wrong with it: NAG groks it, like Nvidia and Flang,
> while Intel crashes at runtime.
>
> Can you have another brief look?
>
> Thanks,
> Harald
>
>
> On 1/6/24 18:26, Paul Richard Thomas wrote:
> > These PRs come about because of gfortran's single pass parsing. If the
> > function in the title is parsed after the associate construct, then its
> > type and rank are not known. The point at which this becomes a problem is
> > when expressions within the associate block are parsed. primary.cc
> > (gfc_match_varspec) could already deal with intrinsic types and so
> > component references were the trigger for the problem.
> >
> > The two major parts of this patch are the fixup needed in
> gfc_match_varspec
> > and the resolution of  expressions with references in resolve.cc
> > (gfc_fixup_inferred_type_refs). The former relies on the two new
> functions
> > in symbol.cc to search for derived types with an appropriate component to
> > match the component reference and then set the associate name to have a
> > matching derived type. gfc_fixup_inferred_type_refs is called in
> resolution
> > and so the type of the selector function is known.
> > gfc_fixup_inferred_type_refs ensures that the component references use
> this
> > derived type and that array references occur in the right place in
> > expressions and match preceding array specs. Most of the work in
> preparing
> > the patch was sorting out cases where the selector was not a derived type
> > but, instead, a class function. If it were not for this, the patch would
> > have been submitted six months ago :-(
> >
> > The patch is relatively safe because most of the chunks are guarded by
> > testing for the associate name being an inferred type, which is set in
> > gfc_match_varspec. For this reason, I do not think it likely that the
> patch
> > will cause regressions. However, it is more than possible that variants
> not
> > appearing in the submitted testcase will throw up new bugs.
> >
> > Jerry has already given the patch a whirl and found that it applies
> > cleanly, regtests OK and works as advertised.
> >
> > OK for trunk?
> >
> > Paul
> ...snip...