public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [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).