This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[gfortran] Workaround PR 13372



This fixes the problem exposed by PR 13372.


In
MODULE test
IMPLICIT NONE
INTEGER, PARAMETER :: n = SELECTED_REAL_KIND(P=2,R=3)
END MODULE
we added p to the module's namespace. This can never be given a type, as we have implicit typing. This patch works around this code, by explicitly excluding typeless variables from modules.


This doesn't fix all problems, as removing the IMPLICIT NONE would give p the type REAL, and it would then still be added to the module's namespace, possibly causing problems later on. For the same underlying bug, this also changes PR 13575 from ice-on-invalid to accepts-invalid. I think this is an enhancement nonetheless, because 1) it allows people to test gfortran with a wider range of compliant code and 2) the invalid code which is now accepted can't invoke unspecified behavior AFAICT.

WRT PR13372, the real fix lies in the parser, because p should not be added to the namespace at all, and we could port it over from Andy's tree, but this work is fairly hairy, as symbol handling has changed quite a bit in his tree, and I'm still thinking about a way to do this in several independent steps.

Compiled & tested on i686-pc-linux. I also verified that both the reduced and the complete testcase from the PR now compile and will add the reduced testcase to the testsuite.

If this patch is added I will add a new PR to keep track of these workarounds and make it depend on PR 15481.

BTW PR13249 is also fixed, but this is due to a prior checkin by Paul. Paul, do you want to keep this open until it's properly fixed, or should I close this PR and add the testcase from it to the testsuite?

- Tobi

2004-06-02 Tobias Schlueter <tobias.schlueter@physik.uni-muenchen.de>

	PR fortran/13372
	* module.c (write_symbol, write_symtree): Don't write symbols
	wrongly added to namespace.
	* trans-decl.c (gfc_create_module_variable): Don't create a
	backend decl for a symbol incorrectly added to namespace.

Index: module.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fortran/module.c,v
retrieving revision 1.5
diff -u -p -r1.5 module.c
--- module.c 27 May 2004 12:35:12 -0000 1.5
+++ module.c 2 Jun 2004 14:38:28 -0000
@@ -3137,6 +3137,13 @@ write_symbol (int n, gfc_symbol * sym)
if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_LABEL)
gfc_internal_error ("write_symbol(): bad module symbol '%s'", sym->name);


+
+  if (sym->attr.flavor == FL_VARIABLE && sym->ts.type == BT_UNKNOWN)
+    /* TODO: this is a workaround for some of the problems in PR15481,
+       and fixes the dependent bug PR13372. In an ideal frontend, this
+       should never happen.  */
+    return;
+
   mio_integer (&n);
   mio_internal_string (sym->name);

@@ -3260,6 +3267,12 @@ write_symtree (gfc_symtree * st)
          && !sym->attr.subroutine && !sym->attr.function))
     return;

+  if (sym->attr.flavor == FL_VARIABLE && sym->ts.type == BT_UNKNOWN)
+    /* TODO: this is a workaround for some of the problems in PR15481,
+       and fixes the dependent bug PR13372. In an ideal frontend, this
+       should never happen.  */
+    return;
+
   if (check_unique_name (st->name))
     return;

Index: trans-decl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fortran/trans-decl.c,v
retrieving revision 1.10
diff -u -p -r1.10 trans-decl.c
--- trans-decl.c        30 May 2004 14:37:24 -0000      1.10
+++ trans-decl.c        2 Jun 2004 14:38:30 -0000
@@ -1788,6 +1788,12 @@ gfc_create_module_variable (gfc_symbol *
       && (sym->attr.flavor != FL_PARAMETER || sym->attr.dimension == 0))
     return;

+  if (sym->attr.flavor == FL_VARIABLE && sym->ts.type == BT_UNKNOWN)
+    /* TODO: This is a workaround for the issue outlined in PR 15481,
+       and it fixes the bug in PR13372. This should never happen in an
+       ideal frontend.  */
+    return;
+
   /* Don't generate variables from other modules.  */
   if (sym->attr.use_assoc)
     return;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]