This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[gfortran] Workaround PR 13372
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: GCC Fortran mailing list <fortran at gcc dot gnu dot org>,patch <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 02 Jun 2004 16:57:43 +0200
- Subject: [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;