https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99065
Bug ID: 99065
Summary: ASSOCIATE function selector expression "no IMPLICIT
type" failure
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: pault at gcc dot gnu.org
Target Milestone: ---
Created attachment 50164
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50164&action=edit
Testcase illustrating the failure
This bug was detected in testing variations of the testcase in PR98897.
The attached fails with:
../pr98897/foo1.f90:9:20:
9 | print *, var%i
| 1
Error: Symbol ‘var’ at (1) has no IMPLICIT type
If the contained procedures 'foo' and 'bar' are interchanged it compiles and
produces the intended result.
All component references suffer from this problem. Intrinsic types are fixed up
by parse.c(gfc_fixup_sibling_symbols) but there is no simple way to do this for
derived type or class selectors.
Certain operator expressions also suffer from this problem.
It is caused by parsing and matching in gfortran being single pass. This means
that unless the specification of 'bar', in this case, has been obtained, the
type of 'var' cannot be determined and primary.c(gfc_match_varspec) is bound to
return MATCH_NO.
I am looking at either two passes for contained procedures (specification
blocks first, followed by code blocks) or a fixup in gfc_match_varspec that
looks through the derived types for successful matches.
Paul
