[Bug fortran/28526] 'end' is recognized as a variable incorrectly
--- 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=gccview=revrev=117034 Log: 2006-09-18 Paul Thomas [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
--- 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
--- 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
[Bug fortran/28526] 'end' is recognized as a variable incorrectly
--- 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
--- 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: [EMAIL PROTECTED]:~/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 [EMAIL PROTECTED]:~/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. [EMAIL PROTECTED]:~/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 [EMAIL PROTECTED]:~/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. [EMAIL PROTECTED]:~/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
--- 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
--- 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
--- 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|-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
--- 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
--- 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
