This is the mail archive of the
mailing list for the GCC project.
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
- From: "Tobias dot Schlueter at physik dot uni-muenchen dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 7 Nov 2005 23:43:10 -0000
- Subject: [Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
- References: <email@example.com/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-11-07 23:43 -------
Subject: Re: Unclassifiable statement on implicitly typed
steven at gcc dot gnu dot org wrote:
> ------- Comment #8 from steven at gcc dot gnu dot org 2005-11-07 23:29 -------
> We get to "check_substring:" in match_varspec:
> PROGRAM P
> IMPLICIT CHARACTER*8 (Y)
> if (primary->ts.type == BT_CHARACTER)
> switch (match_substring (primary->ts.cl, equiv_flag, &substring))
> case MATCH_YES:
> if (tail == NULL)
> primary->ref = substring;
> But at this point, while we have matched YLOCAL in the second assignment, we
> still haven't picked up a type for it. So primary->ts.type == BT_UNKNOWN and
> we never even try to match the substring.
> I'm not sure if YLOCAL should have just picked up a type earlier. Thoughts,
It should have picked up a type in the first assignment. Why it doesn't, I
don't know. Apparently, the failure is conditional on the facts that A) there
already exists a symbol and B) this symbol doesn't have a type at that point.
I'll look into this in more depth tomorrow. I remember that last time I
looked into these issues (back before Jakub fixed PR18833), I noticed that the
matching of primaries had been completely reworked in g95, and I can't think
of any other bug relating to that than this one, so this bug might well turn
out to be a snake pit.