[Patch, fortran] PR25058 & PR25090 - was Re: CPU2000/191.fma3d compilation failure

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

Dear All,

:ADDPATCH fortran:

This patch cures the regression that I caused with the patch for PR25090.
At the same time, it fixes PR25058. 

>
> That is definitely all that it's sensible to try for, indeed!  (There 
> are good reasons that the standard doesn't require compilers to 
> diagnose most things like this....)

Brooks, 'tis what I have done.

The problem with the first version of the patch to fix PR25090 was that 
it emitted an error if a specification expression was not preceeded by 
all the variables, as dummies, in the first entry.  The standard does 
not demand this.  Rather, 12.5.2.5 requires:  "If a dummy argument is 
used in a specification expression to specify an array bound or 
character length of an object, the appearance of the object in a 
statement that is executed during a procedure reference is permitted 
only if the dummy argument appears in the dummy argument list of the 
procedure name referenced and it is present(12.4.1.5). "

This cannot easily be implemented.  However, this paragraph does imply 
that a reference to the variable, in whose declaration the specification 
expressions appear, should be preceeded by the appearance of the 
requisite variables as dummy argments.  Furthermore, it follows that if 
any one of the variables appear, they all must.   This is what I have 
implemented.

In addition, the standard requires that "In a subprogram, a name that 
appears as a dummy argument in an ENTRY statement shall not appear in an 
executable statement preceding that ENTRY statement, unless it also 
appears in a FUNCTION, SUBROUTINE, or ENTRY statement that precedes the 
executable statement."  This has been implemented at the same time as 
the repair, thereby dispatching PR25058.

The first part is to be found, for the most part in resolve_variable.  
cs_base != NULL is used to detect code resolution.  A new int field for 
gfc_symbol, entry_id, is checked against the last entry ID seen.  This 
was done to prevent this check from being done for every reference to 
the symbol in every line of code.   If the extra field is thought to be 
too high a price to be paid,  I can add an attribute bit that is reset 
for each entry.

The second part of the patch ensures that if one variable from a
specification expression appears as a parameter of an entry, then all
the variables in that expression must be parameters of the entry. This
is done by resolve_index_entries, which is called during symbol
resolution.  It uses existing calls to gfc_resolve_expr to collect the
variables used in the specification expression. Using this list, the
new function checks the variables against each of the entry formal
argument lists.

Please note that the provisional patch that I posted on the PR
yesterday segfaults with alternate returns in entries. This has been
fixed.

Regtested on FC5/Athlon.  OK for trunk and for 4.1, when reopened?

Paul

2006-05-19  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/25090
	PR fortran/25058
	* gfortran.h : Add int entry_id to gfc_symbol.
	* resolve.c : Add static variables current_entry_id and
	gfc_formal_arglist spec_vars.  Rename resolving_index_expr to
	specification_expr to reflect its function.
	(entry_parameter): Delete this function.
	(resolve_variable): During code resolution, check if a
	reference to a dummy variable in an executable expression
	is preceded by its appearance as a parameter in an entry.
	Likewise check its specification expressions.
	(gfc_resolve_expr): Remove the call to entry_parameter and
	add variables to a gfc_formal_arglist, if a specification
	expression is being resolved.
	(resolve_code): Update current_entry_id on EXEC_ENTRY.
	(resolve_index_entries): New function to check that all or
	none of the variables in a list are parameters of the
	entries in the namespace.
	(resolve_charlen, resolve_fl_variable): Call it.
	(is_non_constant_shape_array): Do not return on detection
	of a variable but continue to resolve all the expressions.

2006-05-19  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/25090
	PR fortran/25058
	* gfortran.dg/entry_dummy_ref_1.f90: Change messages.
	* gfortran.dg/entry_dummy_ref_2.f90: New test.

Attachment: check0519.diff
Description: check0519.diff

Attachment: ChangeLogs
Description: ChangeLogs