User account creation filtered due to spam.

Bug 24643 - Unclassifiable statement on implicitly typed character substring
Summary: Unclassifiable statement on implicitly typed character substring
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.1.0
: P3 normal
Target Milestone: 4.0.3
Assignee: Tobias Schlüter
URL: http://gcc.gnu.org/ml/fortran/2005-11...
Keywords: patch, rejects-valid
: 22048 (view as bug list)
Depends on:
Blocks: 19292
  Show dependency treegraph
 
Reported: 2005-11-02 20:34 UTC by Toon Moene
Modified: 2005-11-10 23:15 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-11-03 19:34:54


Attachments
Test case for this bug (142 bytes, text/plain)
2005-11-02 20:36 UTC, Toon Moene
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Toon Moene 2005-11-02 20:34:36 UTC
gfortran issues an "Unclassifiable statement" error when trying
to compile a statement with concatenation of substrings of
character variables.
Comment 1 Toon Moene 2005-11-02 20:36:05 UTC
Created attachment 10114 [details]
Test case for this bug

Test case added.
Comment 2 Andrew Pinski 2005-11-02 20:39:10 UTC
Confirmed.
Comment 3 Tobias Schlüter 2005-11-02 20:42:43 UTC
schluter@pcl247d:~/src/gcc> ../gcc/build/gcc/f951  -quiet -fsyntax-only
Warning: Reading file '<stdin>' as free form.
      PROGRAM TABLES
      IMPLICIT CHARACTER*8(Y)
        YBTABLE=Ylocal(1:2)
      END
schluter@pcl247d:~/src/gcc> ../gcc/build/gcc/f951  -quiet -fsyntax-only
Warning: Reading file '<stdin>' as free form.
      PROGRAM TABLES
      IMPLICIT CHARACTER*8(Y)
      WRITE(YLOCAL,'(I2.2)') ILOCAL
        YBTABLE=Ylocal(1:2)
      END
 In file :4

 YBTABLE=Ylocal(1:2)
1
Error: Unclassifiable statement at (1)
schluter@pcl247d:~/src/gcc> ../gcc/build/gcc/f951  -quiet -fsyntax-only
Warning: Reading file '<stdin>' as free form.
      PROGRAM TABLES
      IMPLICIT CHARACTER*8(Y)
      ybtable='b'
        YBTABLE=Ylocal(1:2)
      END
schluter@pcl247d:~/src/gcc> ../gcc/build/gcc/f951  -quiet -fsyntax-only
Warning: Reading file '<stdin>' as free form.
      PROGRAM TABLES
      IMPLICIT CHARACTER*8(Y)
      WRITE(YLOCAL,'(I2.2)') ILOCAL
      ybtable='b'
        YBTABLE=Ylocal(1:2)
      END
 In file :5

 YBTABLE=Ylocal(1:2)
1
Error: Unclassifiable statement at (1)
schluter@pcl247d:~/src/gcc> ../gcc/build/gcc/f951  -quiet -fsyntax-only
Warning: Reading file '<stdin>' as free form.
      PROGRAM TABLES
      IMPLICIT CHARACTER*8(Y)
      WRITE(YLOCAL,'(I2.2)') ILOCAL
      ybtable='b'
        YBTABLE=Ylocal
      END
schluter@pcl247d:~/src/gcc> 
Comment 4 Thomas Koenig 2005-11-02 21:13:23 UTC
g77 groks this:

$ cat grg.f
      PROGRAM TABLES
      IMPLICIT CHARACTER*8(Y)
      WRITE(YLOCAL,'(I2.2)') ILOCAL
        YBTABLE=Ylocal(1:2)
      END
$ g77 grg.f
$ 
Comment 5 Tobias Schlüter 2005-11-02 22:12:46 UTC
(In reply to comment #3)
> ...

I forgot to say that these are all syntactically valid variations of the same theme.
Comment 6 Toon Moene 2005-11-03 19:34:54 UTC
Mine ! All Mine !
Comment 7 Toon Moene 2005-11-05 11:51:03 UTC
I got some preliminary results from debugging.
By -fdump-parse-tree, YLOCAL does have the correct (implicitly
determined) type of CHARACTER*8 at statement "YLOCAL='A'".
However, by the time we reach gfc_match_rvalue for the next
statement "YBTABLE=YLOCAL(1:2)" its type is BT_UNKNOWN.
So something has to squash the correctly determined type.
How does one find out ?
Comment 8 Steven Bosscher 2005-11-07 23:29:47 UTC
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?
Comment 9 Tobias Schlüter 2005-11-07 23:43:10 UTC
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.
Comment 10 Tobias Schlüter 2005-11-08 20:55:54 UTC
Correction: implicit types are only assigned during resolution.  The issue is: why does it reject the second statement if the RHS object already exists, but not otherwise?
Comment 11 Tobias Schlüter 2005-11-08 23:58:18 UTC
Patch posted.
Comment 12 Tobias Schlüter 2005-11-10 21:49:33 UTC
Subject: Bug 24643

Author: tobi
Date: Thu Nov 10 21:49:29 2005
New Revision: 106753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106753
Log:
fortran/
PR fortran/24643
* primary.c (match_varspec): Check for implicitly typed CHARACTER
variables before matching substrings.

testsuite/
PR fortran/24643
* gfortran.dg/implicit_6.f90, gfortran.dg/implicit_7.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/implicit_6.f90
    trunk/gcc/testsuite/gfortran.dg/implicit_7.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/primary.c
    trunk/gcc/testsuite/ChangeLog

Comment 13 Tobias Schlüter 2005-11-10 23:10:55 UTC
Subject: Bug 24643

Author: tobi
Date: Thu Nov 10 23:10:51 2005
New Revision: 106757

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106757
Log:
Backport r106753

fortran/
PR fortran/24643
* primary.c (match_varspec): Check for implicitly typed CHARACTER
variables before matching substrings.

testsuite/
PR fortran/24643
* gfortran.dg/implicit_6.f90, gfortran.dg/implicit_7.f90: New.

Added:
    branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/implicit_6.f90
      - copied unchanged from r106753, trunk/gcc/testsuite/gfortran.dg/implicit_6.f90
    branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/implicit_7.f90
      - copied unchanged from r106753, trunk/gcc/testsuite/gfortran.dg/implicit_7.f90
Modified:
    branches/gcc-4_0-branch/gcc/fortran/ChangeLog
    branches/gcc-4_0-branch/gcc/fortran/primary.c
    branches/gcc-4_0-branch/gcc/testsuite/ChangeLog

Comment 14 Tobias Schlüter 2005-11-10 23:11:47 UTC
Fixed.
Comment 15 Tobias Schlüter 2005-11-10 23:15:35 UTC
*** Bug 22048 has been marked as a duplicate of this bug. ***