[Patch, fortran] PR28526 - 'end' is recognized as a variable incorrectly

["THOMAS Paul Richard 169137" <Paul dot Richard dot THOMAS at cea dot fr>]

:ADDPATCH fortran:

This PR turned out to be a so-and-so to diagnose. In the end, though, the fix was easily
implemented.

module m
  public :: end                 ! This would make a symbol 'end'

  interface foo
    module procedure foo1
  end interface                ! This would try to match an assignment with lhs 'end'

  interface end                ! and would bomb out here because 'end' had become a variable.
    module procedure foo2
  end interface
.....snip......

The core of the problem lies in parse.c(decode_statement), which calls all the matchers
in turn.  The assignment matchers are called before gfc_match_end.  These, of course,
fail on 'END INTERFACE' but they create a candidate variable behind; in this case, called
'end'.  Since the PUBLIC declaration has made a symbol 'end' in the module namespace,
this is host associated to the potential lhs in the interface.  This modifies the symbol to
be a variable with the implicit type.  The variable, being host associated, is not backed
up by save_symbol_data.  In consequence, when the match to the assignments fails,
the modifications to the symbol remain and the match to 'INTERFACE END' fails because
'end' is now a variable.

Several remedies have been tried:
(i) To move gfc_match_end earlier in decode_statement.  This does not fix Tobi's version
of the problem (see the PR itself).
(ii) Suppressing the assignment matchers in module specification blocks, interface bodies
or contains sections, fixes all the manifestations of the PR but breaks the diagnostics for
assignments in these places.
(iii) Since an assignment cannot legally take place in these sections, primary.c
(match_variable) can be manipulated to correctly effect the cure.  One version, directly
prevents the symbol from being modified, returns a MATCH_YES and an expression.
(iv) The solution chosen is a variant on (iii); in these places where l-values cannot
happen, the host_flag is set to zero, which forces the mechanism to backup the
symbol.

The PR gives a reasonably good account of the progression to this solution.  The test
case reflects the various wrinkles described in (i)-(iv) above.

Regtested on FC5/Athlon - OK for trunk and 4.1?

Paul

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

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

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

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

Attachment: pr25056.diff
Description: pr25056.diff

Attachment: Change.Logs
Description: Change.Logs