[Bug fortran/28526] New: 'end' is recognized as a variable incorrectly

[Bug fortran/28526] New: 'end' is recognized as a variable incorrectly

[iguchi at coral dot t dot u-tokyo dot ac dot jp]

In compiling the following program, I have got a error message.
I think it is a wrong behavior.

$ gfortran -v
Using built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ../gcc/configure --prefix=/usr/local/gfortran
--enable-languages=c,fortran --with-gmp=/tmp/gfortran-20060512/gfortran_libs
--enable-bootstrap
Thread model: posix
gcc version 4.2.0 20060512 (experimental)
$ cat end.f90
module m
  public end

  interface foo
    module procedure foo1
  end interface

  interface end
    module procedure foo2
  end interface

contains
  subroutine foo1
  end subroutine

  subroutine foo2
  end subroutine
end module
end program
$ gfortran end.f90
 In file end.f90:8

  interface end
              1
Error: VARIABLE attribute conflicts with PROCEDURE attribute at (1)
 In file end.f90:9

    module procedure foo2
                    1
Error: MODULE PROCEDURE at (1) must be in a generic module interface
 In file end.f90:10

  end interface
    1
Error: Expecting END MODULE statement at (1)


-- 
           Summary: 'end' is recognized as a variable incorrectly
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: iguchi at coral dot t dot u-tokyo dot ac dot jp


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-07-31 17:44 -------
Hmm, end is keyword.


-- 


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[kargl at gcc dot gnu dot org]

------- Comment #2 from kargl at gcc dot gnu dot org  2006-07-31 18:20 -------
Andrew,

end is a keyword, but Fortran does not have reserved keywords.

   integer end
   end = 1
   print *, end
   end

The two 'end's are distinct.  Yes, it's prudent not to use keywords
in some other way, but Fortran does it prevent one from possibly
shoot their foot.


-- 


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[tobi at gcc dot gnu dot org]

------- Comment #3 from tobi at gcc dot gnu dot org  2006-09-13 16:06 -------
This is intriguing.  Why would 'end' be treated any different from 'xxx'?


-- 

tobi 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         |2006-09-13 16:06:29
               date|                            |


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[tobi at gcc dot gnu dot org]

------- Comment #4 from tobi at gcc dot gnu dot org  2006-09-14 10:59 -------
The difference is that 'end' appears in other contexts, see e.g. the difference
between these two testcases:
schluter@pcl247d:~/src/pr/28526> cat t.f90
module m
  public function

  interface function
     module procedure foo4
  end interface


contains
  subroutine foo4
  end subroutine foo4

!  function foo5
!    foo5 = 0
!  end function foo5

end module
schluter@pcl247d:~/src/pr/28526> ~/src/gcc/build/gcc/f951 t.f90
 foo4
Execution times (seconds)
 TOTAL                 :   0.00             0.01             0.02              
 632 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --disable-checking to disable checks.
schluter@pcl247d:~/src/pr/28526> cat t.f90
module m
  public function

  interface function
     module procedure foo4
  end interface


contains
  subroutine foo4
  end subroutine foo4

  function foo5
    foo5 = 0
  end function foo5

end module
schluter@pcl247d:~/src/pr/28526> ~/src/gcc/build/gcc/f951 t.f90
 In file t.f90:13

  function foo5
         1
Error: Expected VARIABLE at (1)
 In file t.f90:14

    foo5 = 0
       1
Error: Symbol 'foo5' at (1) has already been host associated
 In file t.f90:15

  end function foo5
    1
Error: Expecting END MODULE statement at (1)

Execution times (seconds)
 TOTAL                 :   0.00             0.00             0.03              
 622 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --disable-checking to disable checks.
schluter@pcl247d:~/src/pr/28526> 

The symptoms in the original testcase can also be produced by e.g. replacing
'end' by 'module'.


-- 


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[paul dot richard dot thomas at cea dot fr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]



------- Comment #5 from paul dot richard dot thomas at cea dot fr  2006-09-14 15:23 -------
> module m
>   public function
>   interface function
>      module procedure foo4
>   end interface
> contains
>   subroutine foo4
>   end subroutine foo4
>   function foo5
>     foo5 = 0
>   end function foo5
> end module

If function foo5 is declared with a formal arglist or with empty brackets, this
example compiles correctly. The matcher is certainly behaving oddly!

This cures the original problem and does not seem to cause any regressions up
to "contained_1.f90" (I ran out of time this afternoon!).

Index: gcc/fortran/parse.c
===================================================================
*** gcc/fortran/parse.c (révision 116697)
--- gcc/fortran/parse.c (copie de travail)
*************** decode_statement (void)
*** 110,115 ****
--- 110,120 ----
        input "REALFUNCTIONA(N)" can mean several things in different
        contexts, so it (and its relatives) get special treatment.  */

+   if (gfc_match_end (&st) == MATCH_YES)
+     return st;
+   gfc_undo_symbols ();
+   gfc_current_locus = old_locus;
+
    if (gfc_current_state () == COMP_NONE
        || gfc_current_state () == COMP_INTERFACE
        || gfc_current_state () == COMP_CONTAINS)
*************** decode_statement (void)
*** 208,215 ****
        match ("else if", gfc_match_elseif, ST_ELSEIF);
        match ("enum , bind ( c )", gfc_match_enum, ST_ENUM);

-       if (gfc_match_end (&st) == MATCH_YES)
-       return st;

        match ("entry% ", gfc_match_entry, ST_ENTRY);
        match ("equivalence", gfc_match_equivalence, ST_EQUIVALENCE);
--- 213,218 ----
*************** parse_derived (void)
*** 1499,1504 ****
--- 1502,1509 ----
    int compiling_type, seen_private, seen_sequence, seen_component,
error_flag;

    gfc_statement st;
    gfc_state_data s;
+   gfc_symbol *sym;
+   gfc_component *c;

    error_flag = 0;

The matching of END can be moved after the next if block but no more.  One or
more of the matchers are not cleaning up after figuring "END" to be a variable
(a LHS?) and trying a match to an assignment or data statement.

Paul


-- 


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[pault at gcc dot gnu dot org]

------- Comment #6 from pault at gcc dot gnu dot org  2006-09-14 20:05 -------
Iguchi-san and Tobi,

This has proven to be an "absorbing" bug and is indicative of a rather serious
malaise in the gfortran parser.  As I surmised in the previous comment, it is
the assignments that are the culprits.  In fact, these are being matched in
compiler states where an assignment should not be present; eg. in the
specification part of a module, an interface or the contains part.

I am just now regtesting a trial:

parse.c:127

  /* Match statements whose error messages are meant to be overwritten
     by something better.  */
  if (gfc_current_state () != COMP_INTERFACE
      && gfc_current_state () != COMP_MODULE
      && gfc_current_state () != COMP_CONTAINS)
    {
      match (NULL, gfc_match_assignment, ST_ASSIGNMENT);
      match (NULL, gfc_match_pointer_assignment, ST_POINTER_ASSIGNMENT);
      match (NULL, gfc_match_st_function, ST_STATEMENT_FUNCTION);
    }

This regtests OK on trunk.

I am not suggesting that this is the fix but it is indicative of the right way
to go, I think.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobi at gcc dot gnu dot org
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-09-13 16:06:29         |2006-09-14 20:05:51
               date|                            |


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[patchapp at dberlin dot org]

------- Comment #7 from patchapp at dberlin dot org  2006-09-15 10:05 -------
Subject: Bug number PR28526

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00582.html


-- 


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[pault at gcc dot gnu dot org]

------- Comment #8 from pault at gcc dot gnu dot org  2006-09-18 20:20 -------
Subject: Bug 28526

Author: pault
Date: Mon Sep 18 20:19:50 2006
New Revision: 117034

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117034
Log:
2006-09-18 Paul Thomas <pault@gcc.gnu.org>

        PR fortran/28526
        * primary.c (match_variable): If the compiler is in a module
        specification block, an interface block or a contains section,
        reset host_flag to force the changed symbols mechanism.

        PR fortran/29101
        * trans-stmt.c (gfc_trans_character_select): Add the post block
        for the expression to the main block, after the call to
        select_string and the last label.


2006-09-18 Paul Thomas <pault@gcc.gnu.org>

        PR fortran/28526
        * gfortran.dg/keyword_symbol_1.f90: New test.

        * gfortran.dg/spread_shape_1.f90: Add missing warning with
        pedantic compilation option.

Added:
    trunk/gcc/testsuite/gfortran.dg/keyword_symbol_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/primary.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/spread_shape_1.f90


-- 


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[pault at gcc dot gnu dot org]

------- Comment #9 from pault at gcc dot gnu dot org  2006-09-18 22:25 -------
    integer, allocatable :: x(:)
    integer :: i, j(2)
    allocate (x(kind(i)), stat=i)
    print *, size(x)
    allocate (x(size(j)), stat=j(1))
    print *, size(x)
  end


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

[pault at gcc dot gnu dot org]

------- Comment #10 from pault at gcc dot gnu dot org  2006-09-18 22:26 -------
Fixed on trunk and 4.1

Paul


-- 


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