[Bug fortran/99065] New: ASSOCIATE function selector expression "no IMPLICIT type" failure

pault at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Feb 10 18:17:52 GMT 2021


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


More information about the Gcc-bugs mailing list