When I compile the module listed below I get the following messages: c.f90:9.28: MODULE PROCEDURE cx_cadr, cx_radc 1 Error: FUNCTION result cx_cadr can't be of type TYPE(cx) in FUNCTION cx_cadr at (1) c.f90:19.18: END MODULE complex 1 Error: Contained function 'master.0.cx_cadr' at (1) has no IMPLICIT type c.f90:9.37: MODULE PROCEDURE cx_cadr, cx_radc 1 Error: Contained function 'cx_radc' at (1) has no IMPLICIT type MODULE complex IMPLICIT NONE PRIVATE PUBLIC :: cx, OPERATOR(+) TYPE cx REAL :: imag END TYPE cx INTERFACE OPERATOR (+) MODULE PROCEDURE cx_cadr, cx_radc END INTERFACE CONTAINS FUNCTION cx_cadr(z, r) ENTRY cx_radc(r, z) TYPE (cx) :: cx_cadr, cx_radc TYPE (cx), INTENT(IN) :: z REAL, INTENT(IN) :: r cx_cadr%imag = z%imag END FUNCTION cx_cadr END MODULE complex
Confirmed - thanks for the report. Paul
Hmmm. It helps to actually confirm it.
The problem is that at the time we enter resolve_entries cx_radc has type BT_UNKNOWN. I have no idea why that's the case. Removing the interface fixes this. It's also a QOI issue that an error message about the master function gets printed. In the course of getting this far with debugging I've somewhat cleaned up resolve_etries(), I'm attaching this for the benefit of anyone wanting to take this further.
Created attachment 14337 [details] A small cleanup patch
FrRom my brief explorations, in resolve.c (resolve_entries) on or about line 560, we are NOT addressing the case for BT_DERIVED in the switch statement. If there we set sym = NULL for BT_DERIVED, we get past this section of code. Then we need to deal with the the same issue in resolve_unknown_f where we do not address setting the type for derived types, only, gfc_get_default_type which returns BT_UNKNOWN. I suspect we could fix this in more than one place. I was thinking in resolve_unknown_f .
I was in error, the function of interest is resolve_entries, here if the type is BT_UNKNOWN an attempt is made to get the type from the corresponding result. In this case the result is also BT_UNKNOWN.
A workaround is to put the ENTRY declaration after the type specification: MODULE complex IMPLICIT NONE PRIVATE PUBLIC :: cx, OPERATOR(+) TYPE cx REAL :: imag END TYPE cx INTERFACE OPERATOR (+) MODULE PROCEDURE cx_cadr, cx_radc END INTERFACE CONTAINS FUNCTION cx_cadr(z, r) TYPE (cx) :: cx_cadr, cx_radc TYPE (cx), INTENT(IN) :: z REAL, INTENT(IN) :: r ENTRY cx_radc(r, z) cx_cadr%imag = z%imag END FUNCTION cx_cadr END MODULE complex This is a dead giveaway as to where the problem is. I'm onto it! Paul
This is not regtested yet but seems to be OK: Index: gcc/fortran/decl.c =================================================================== *** gcc/fortran/decl.c (révision 130286) --- gcc/fortran/decl.c (copie de travail) *************** get_proc_name (const char *name, gfc_sym *** 715,723 **** if (*result == NULL) rc = gfc_get_symbol (name, NULL, result); ! else if (gfc_get_symbol (name, NULL, &sym) == 0 ! && sym ! && sym->ts.type != BT_UNKNOWN && (*result)->ts.type == BT_UNKNOWN && sym->attr.flavor == FL_UNKNOWN) /* Pick up the typespec for the entry, if declared in the function --- 715,721 ---- if (*result == NULL) rc = gfc_get_symbol (name, NULL, result); ! else if (!gfc_get_symbol (name, NULL, &sym) && sym && (*result)->ts.type == BT_UNKNOWN && sym->attr.flavor == FL_UNKNOWN) /* Pick up the typespec for the entry, if declared in the function *************** get_proc_name (const char *name, gfc_sym *** 727,733 **** --- 725,742 ---- to the local version. This latter ensures a correct clearing of the symbols. */ { + /* If the ENTRY proceeds its specification, we need to ensure + that this does not raise a "has no IMPLICIT type" error. */ + if (sym->ts.type == BT_UNKNOWN) + sym->attr.untyped = 1; + (*result)->ts = sym->ts; + + /* Put the symbol in the procedure namespace so that, should + the ENTRY preceed its specification, the specification + can be applied. */ + (*result)->ns = gfc_current_ns; + gfc_find_sym_tree (name, gfc_current_ns, 0, &st); st->n.sym = *result; st = gfc_get_unique_symtree (gfc_current_ns); Paul
Subject: Bug number PR33499 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01273.html
Subject: Bug 33499 Author: pault Date: Sun Nov 25 09:59:42 2007 New Revision: 130403 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130403 Log: 2007-11-25 Paul Thomas <pault@gcc.gnu.org> PR fortran/33499 * decl.c (get_proc_name): If ENTRY statement occurs before type specification, set the symbol untyped and ensure that it is in the procedure namespace. 2007-11-25 Paul Thomas <pault@gcc.gnu.org> PR fortran/33499 * gfortran.dg/entry_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk Paul