[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #10 from pault at gcc dot gnu dot org 2007-11-25 09:59 --- Subject: Bug 33499 Author: pault Date: Sun Nov 25 09:59:42 2007 New Revision: 130403 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130403 Log: 2007-11-25 Paul Thomas [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #11 from pault at gcc dot gnu dot org 2007-11-25 19:05 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #9 from patchapp at dberlin dot org 2007-11-24 11:10 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #7 from pault at gcc dot gnu dot org 2007-11-23 10:59 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #8 from pault at gcc dot gnu dot org 2007-11-23 14:13 ---
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
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-10-05 13:05:03 |2007-11-23 14:13:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-10-26 02:22 --- 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 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-10-26 03:15 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #3 from tobi at gcc dot gnu dot org 2007-10-10 20:12 --- 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. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
[Bug fortran/33499] Rejects valid module with a contained function with an ENTRY
--- Comment #4 from tobi at gcc dot gnu dot org 2007-10-10 20:15 --- Created an attachment (id=14337) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14337action=view) A small cleanup patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33499
