This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/13575] [gfortran] ICE for wrong code
- From: "tobi at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 May 2004 18:59:47 -0000
- Subject: [Bug fortran/13575] [gfortran] ICE for wrong code
- References: <20040105231628.13575.schnetter@aei.mpg.de>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From tobi at gcc dot gnu dot org 2004-05-16 18:59 -------
This bug has a very simple fix:
--- resolve.c 14 May 2004 13:00:04 -0000 1.3
+++ resolve.c 15 May 2004 22:33:10 -0000
@@ -3711,7 +3711,7 @@ resolve_symbol (gfc_symbol * sym)
if (sym->ts.type == BT_UNKNOWN)
{
if (sym->attr.flavor == FL_VARIABLE || sym->attr.flavor == FL_PARAMETER)
- gfc_set_default_type (sym, 0, NULL);
+ gfc_set_default_type (sym, 1, NULL);
if (sym->attr.flavor == FL_PROCEDURE && sym->attr.function)
{
This is obviously correct, because if at this point a variable can't be given a
type it's an error.
Unfortunately, the parser's behavior which makes it create symbols where it
shouldn't, breaks this: with this "fix" COMMON /x/ a will give an error for x,
because x has been added to the namespace of our function, but can't be given a
name at this place. Similar for SELECTED_REAL_KIND(p=5), here it will complain
about the "symbol" p. Because of this it also related to PR 13372.
I believe there are two options:
1. fix the frontend and apply my patch. The Right Thing, but definitely
involved. I looked at how g95 deals with this, and it looks like a rewrite of
symbol handling.
2. traverse the namespaces and eliminate all symbols which don't have a type
after this place. I believe this would work, but it seems like very hackish
patchery.
If I can convince myself that the second option wouldn't break anything, I will
prepare a patch to this effect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13575