[Bug fortran/38312] New: poor error message

[Bug fortran/38312] New: poor error message

[jv244 at cam dot ac dot uk]

> cat test.f90
 SUBROUTINE S1(t1,t2,c0,n)
   REAL :: t1(n,n),t2(n,n),c0(n,n)
   INTEGER :: i,j,k
   DO i=1,n
   DO j=1,n
   DO k=1,n
      co(i,j)=t1(i,k)*t2(j,k)
   ENDDO
   ENDDO
   ENDDO
 END SUBROUTINE S1
> gfortran  test.f90
test.f90:7.29:

      co(i,j)=t1(i,k)*t2(j,k)
                            1
Error: Unexpected STATEMENT FUNCTION statement at (1)

I couldn't agree more, but some users might get confused. 
Imagine you take your 'Fortran 90/95 for Scientists and Engineers' book to
understand what the compiler really means.


-- 
           Summary: poor error message
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312

[Bug fortran/38312] poor error message

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2008-11-28 21:11 -------
Boy! I had o use ifort to see it!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312

[Bug fortran/38312] poor error message

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-11-28 21:26 -------
Confirmed.  At least we could get (1) pointing to the correct location of co(i,
j) instead of at the end of the overall expression.  I had to look twice to see
what was wrong.  co is not the same as c0.  o vs 0 :).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-11-28 21:26:16
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2008-12-11 18:58 -------
Change subject line.

Reduced test case

troutmask:sgk[204] cat pr38312.f90 
 SUBROUTINE S1(t1,t2,c0,n)
   REAL :: t1(n),c0(n)
   INTEGER :: i,j,k
   DO i=1,n
      co(i)=t1(i)*2
   ENDDO
 END SUBROUTINE S1


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|poor error message          |Unexpected STATEMENT
                   |                            |FUNCTION statement


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2008-12-11 18:59 -------
*** Bug 37793 has been marked as a duplicate of this bug. ***


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[bdavis at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312

Bud Davis <bdavis at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bdavis at gcc dot gnu.org

--- Comment #7 from Bud Davis <bdavis at gcc dot gnu.org> ---
18 months since any comments were made...

If I had a vote, it would be close as a "WONT FIX".

--bud

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-11-12 22:41:06 UTC ---
On Sat, Nov 12, 2011 at 10:03:49PM +0000, kargl at gcc dot gnu.org wrote:
> 
> --- Comment #5 from kargl at gcc dot gnu.org 2011-11-12 22:03:49 UTC ---
> I've looked at this issue, and I have come to the conclusion
> that it should be closed as WONTFIX.  First, an error is 
> issued, so one can fix their Fortran code.
> 
> Now, for the problem.  The matchers are called from the 
> parser according this diagram (parse.c line 1717).
> 
>         +---------------------------------------+
>         | program  subroutine  function  module |
>         +---------------------------------------+
>         |                use                    |
>         +---------------------------------------+
>         |                import                 |
>         +---------------------------------------+
>         |         |        implicit none        |
>         |         +-----------+-----------------+
>         |         | parameter |  implicit       |
>         |         +-----------+-----------------+
>         | format  |           |  derived type   |
>         | entry   | parameter |  interface      |
>         |         |   data    |  specification  |
>         |         |           |  statement func |
>         |         +-----------+-----------------+
>         |         |   data    |    executable   |
>         +---------+-----------+-----------------+
>         |                contains               |
>         +---------------------------------------+
>         |      internal module/subprogram       |
>         +---------------------------------------+
>         |                end                    |
>         +---------------------------------------+
> 
> As one can see, a DATA statement and a statement function are
> parsed at the same level.  A programmer can use an implied
> do-loop within a DATA statement.  Unfortunately, an implied
> do-loop is parsed by the same code that parses a regular
> do-loop.  It appears that insufficient information is contained
> within the parser at the point where the error is issued
> to determine that the do-loop is in an executable portion of
> the program.
> 

I can generate

laptop:kargl[230] gfc4x -c foo.f90
foo.f90:6.19:

      co(i)=t1(i)*2
                   1
Warning: Line at (1) parsed as a STATEMENT FUNCTION
foo.f90:6.8:

      co(i)=t1(i)*2
        1
Error: Variable type is UNKNOWN in assignment at (1)

with this very ugly kludge.

Index: parse.c
===================================================================
--- parse.c    (revision 181307)
+++ parse.c    (working copy)
@@ -1723,30 +1723,30 @@ unexpected_statement (gfc_statement st)
    valid before calling here, i.e., ENTRY statements are not allowed in
    INTERFACE blocks.  The following diagram is taken from the standard:

-        +---------------------------------------+
-        | program  subroutine  function  module |
-        +---------------------------------------+
-        |         use           |
-        +---------------------------------------+
-        |         import        |
-        +---------------------------------------+
-        |    |    implicit none     |
-        |    +-----------+------------------+
-        |    | parameter |  implicit    |
-        |    +-----------+------------------+
-        | format |       |  derived type    |
-        | entry  | parameter |  interface       |
-        |    |   data    |  specification   |
-        |    |       |  statement func  |
-        |    +-----------+------------------+
-        |    |   data    |    executable    |
-        +--------+-----------+------------------+
-        |        contains           |
-        +---------------------------------------+
-        |      internal module/subprogram       |
-        +---------------------------------------+
-        |           end         |
-        +---------------------------------------+
+        +---------------------------------------+
+        | program  subroutine  function  module |
+        +---------------------------------------+
+        |                use                    |
+        +---------------------------------------+
+        |                import                 |
+        +---------------------------------------+
+        |         |        implicit none        |
+        |         +-----------+-----------------+
+        |         | parameter |  implicit       |
+        |         +-----------+-----------------+
+        | format  |           |  derived type   |
+        | entry   | parameter |  interface      |
+        |         |   data    |  specification  |
+        |         |           |  statement func |
+        |         +-----------+-----------------+
+        |         |   data    |    executable   |
+        +---------+-----------+-----------------+
+        |                contains               |
+        +---------------------------------------+
+        |      internal module/subprogram       |
+        +---------------------------------------+
+        |                end                    |
+        +---------------------------------------+

 */

@@ -3381,7 +3381,10 @@ loop:
    handled inside of parse_executable(), because they aren't really
    loop statements.  */

-static void
+static bool in_execute_state;
+void parse_do_block (void);
+
+void
 parse_do_block (void)
 {
   gfc_statement st;
@@ -3442,7 +3445,13 @@ loop:
       break;

     default:
-      unexpected_statement (st);
+      if (!in_execute_state)
+    unexpected_statement (st);
+      else
+    {
+      gfc_warning ("Line at %C parsed as a STATEMENT FUNCTION");
+          accept_statement (ST_ASSIGNMENT);
+    }
       goto loop;
     }

@@ -3810,7 +3819,9 @@ parse_executable (gfc_statement st)
       break;

     case ST_DO:
+      in_execute_state = true;
       parse_do_block ();
+      in_execute_state = false;
       if (check_do_closure () == 1)
         return ST_IMPLIED_ENDDO;
       break;

[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org 2011-11-12 22:03:49 UTC ---
I've looked at this issue, and I have come to the conclusion
that it should be closed as WONTFIX.  First, an error is 
issued, so one can fix their Fortran code.

Now, for the problem.  The matchers are called from the 
parser according this diagram (parse.c line 1717).

        +---------------------------------------+
        | program  subroutine  function  module |
        +---------------------------------------+
        |                use                    |
        +---------------------------------------+
        |                import                 |
        +---------------------------------------+
        |         |        implicit none        |
        |         +-----------+-----------------+
        |         | parameter |  implicit       |
        |         +-----------+-----------------+
        | format  |           |  derived type   |
        | entry   | parameter |  interface      |
        |         |   data    |  specification  |
        |         |           |  statement func |
        |         +-----------+-----------------+
        |         |   data    |    executable   |
        +---------+-----------+-----------------+
        |                contains               |
        +---------------------------------------+
        |      internal module/subprogram       |
        +---------------------------------------+
        |                end                    |
        +---------------------------------------+

As one can see, a DATA statement and a statement function are
parsed at the same level.  A programmer can use an implied
do-loop within a DATA statement.  Unfortunately, an implied
do-loop is parsed by the same code that parses a regular
do-loop.  It appears that insufficient information is contained
within the parser at the point where the error is issued
to determine that the do-loop is in an executable portion of
the program.