https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98890

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org
           Keywords|                            |ice-on-invalid-code

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Likewise for the following, which uses an assignment:

  implicit none
contains
  real function bar(x)
    real :: x(2,2)
    bar = bar          ! OK
    bar = baz          ! ERROR: function name not reference
    bar = get_funptr() ! ERROR: proc-pointer returning function

    bar = bar * x(1,1) ! OK
    bar = baz * x(1,1) ! error - as above but as operator
    bar = get_funptr() * x(1,1) ! likewise
  end function bar      
  function get_funptr() result(ptr)
    procedure(bar), pointer :: ptr
    ptr => bar
  end
  real function baz(x) result(bazr)
    real :: x(2,2)
    bazr=x(1,1)
  end function baz      
end module foo

  * * *

I am not sure whether the problem is that expr_type == EXPR_VARIABLE instead of
expr_type == EXPR_FUNCTION
or whether the proper fix should be inside both resolve_ordinary_assign() and
resolve_operator() a check like:

  symbol_attribute rhs_attr = gfc_expr_attr (rhs);
  if (rhs_attr.function && ...)
    {
      gfc_error ("Unexpected function name at %L", &rhs->where);
      return false;
    }
  if (rhs_attr.proc_pointer)
    {
      gfc_error ("Unexpected procedure pointer at %L", &rhs->where);
      return false;
    }

where "..." detects that the rhs may be used as result name in this context.

This check always confuses me. And a quick try failed:

I tried rhs_attr – but it is identical for 'bar' and baz'; and also
'sym->result = sym' is the same (if changing 'baz' to use no result variable).
I also thought about the namespace but thanks to BLOCK and contained procedures
(which may access their parent's result variable) it is not that simple.

 * * *

I have not checked but, e.g., for 'call foo(baz)' a similar issue may pop up. I
think not occurring, but to check: proc_pointer_comp (should be resolved
already at parse time?) and derived-type procedures returning proc pointers
(same check as for other functions).

Reply via email to