* [gfortran] Workaround PR 13372
@ 2004-06-02 16:41 Tobias Schlüter
2004-06-09 1:20 ` Paul Brook
0 siblings, 1 reply; 2+ messages in thread
From: Tobias Schlüter @ 2004-06-02 16:41 UTC (permalink / raw)
To: GCC Fortran mailing list, patch
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;
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [gfortran] Workaround PR 13372
2004-06-02 16:41 [gfortran] Workaround PR 13372 Tobias Schlüter
@ 2004-06-09 1:20 ` Paul Brook
0 siblings, 0 replies; 2+ messages in thread
From: Paul Brook @ 2004-06-09 1:20 UTC (permalink / raw)
To: fortran; +Cc: Tobias Schlüter, patch
> If this patch is added I will add a new PR to keep track of these
> workarounds and make it depend on PR 15481.
I don't think we need a new bug, PR15481 and related comments in the source
should be sufficient.
> 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?
Please add the testcase and close the bug. I probably confused it with similar
rejects-invalid bugs (which should be left open).
> - 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.
Ok.
Paul
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-06-08 23:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-02 16:41 [gfortran] Workaround PR 13372 Tobias Schlüter
2004-06-09 1:20 ` Paul Brook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).