From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17093 invoked by alias); 7 Nov 2005 23:43:14 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17065 invoked by alias); 7 Nov 2005 23:43:10 -0000 Date: Mon, 07 Nov 2005 23:43:00 -0000 Message-ID: <20051107234310.17064.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/24643] Unclassifiable statement on implicitly typed character substring In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "Tobias dot Schlueter at physik dot uni-muenchen dot de" X-SW-Source: 2005-11/txt/msg01030.txt.bz2 List-Id: ------- 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 character substring 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) > YLOCAL='A' > YBTABLE=YLOCAL(1:2) > END > > check_substring: > 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, > Tobi? 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643