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
Fortran: Fix class/derived type function associate selectors [PR87477]
2024-01-06 Paul Thomas
gcc/fortran
PR fortran/87477
PR fortran/89645
PR fortran/99065
* class.cc (gfc_change_class): New function needed for
associate names, when rank changes or a derived type is
produced by resolution
* dump-parse-tree.cc (show_code_node): Make output for SELECT
TYPE more comprehensible.
* gfortran.h : Add 'gfc_association_list' to structure
'gfc_association_list'. Add prototypes for
'gfc_find_derived_types', 'gfc_fixup_inferred_type_refs' and
'gfc_change_class'. Add macro IS_INFERRED_TYPE.
* match.cc (copy_ts_from_selector_to_associate): Add bolean arg
'select_type' with default false. If this is a select type name
and the selector is a inferred type, build the class type and
apply it to the associate name.
(build_associate_name): Pass true to 'select_type' in call to
previous.
* parse.cc (parse_associate): If the selector is a inferred type
the associate name is too. Make sure that function selector
class and rank, if known, are passed to the associate name. If
a function result exists, pass its typespec to the associate
name.
* primary.cc (gfc_match_varspec): If a scalar derived type
select type temporary has an array reference,
