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

[Brooks Moses <bmoses at stanford dot edu>]

THOMAS Paul Richard 169137 wrote:
> 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.
[...]
> 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.

I'm not sure I'm completely understanding this -- are you saying that it 
will give an error on the following code, because b appears in the bar 
entry, but a does not, and they are both used in the specification 
expression for c?

  subroutine foo(a,b,c)
    integer a, b
    integer c(a+b)
    ...
  entry bar(b)
    ...
  end subroutine

I would interpret the standard to imply that that's legal code (assuming 
that a and c are never referenced via the bar entry).

- Brooks


P.S. As a completely different thing: Is "parameters of the entry" the 
phrasing the standard uses?  Fortran uses "parameter" for something 
quite different, so this seems likely to be confusing if it shows up in 
an error message or such.