Procedure Pointers: a first patch

[Janus Weil]

Hi all,

after fixing a few bugs related to PROCEDURE and INTERFACE statements,
I think it's time for me to return to my procedure pointer patch
(recent version attached), which still produces the same old
regressions it did a few weeks ago.

> The remaining failures now are:
>
> FAIL: gfortran.dg/f2c_6.f90
> FAIL: gfortran.dg/value_4.f90
> FAIL: gfortran.fortran-torture/execute/entry_7.f90

These are due to my present inability to distinguish between:

> interface
>  function f()
>    integer, pointer :: f
>  end function
> end interface
>
> ***
>
> interface
>  function f()
>    integer :: f
>  end function
> end interface
> pointer :: f
>
> The first one is a pointer-valued function, the second one a procedure
> pointer to an integer-valued function. No ambiguity here, right?
>
> But how does gfortran know? Presently I'm identifying procedure
> pointers as having
> 1) the "attr.pointer" attribute
> 2) one of these:
>    i) attr.procedure
>    ii) attr.external
>    iii) attr.flavor == FL_PROCEDURE && att.if_source == IFSRC_BODY
>
> If those criteria are met, I delete the pointer attribute and set the
> proc_pointer attribute (to distinguish it from normal pointers). The
> problem is that this identifies both of the above cases as procedure
> pointers.

My idea for solving this would be to make the proc_pointer field
wider, so that it can hold an additional state, which would indicate
that the symbol can definitely *not* be a procedure pointer. E.g. one
could use an enumeration like

typedef enum
{
  PROCPTR_MAYBE = 0,
  PROCPTR_NO,
  PROCPTR_YES
}
is_procptr;

So if a symbol has attr.pointer, then the default value PROCPTR_MAYBE
would indicate that this symbol *could* be a procedure pointer (e.g.
in the second case above). At some late resolving stage we would have
to convert this into PROCPTR_YES and delete attr.pointer.
For the first test case above, we would have to detect that the
POINTER attribute is specified inside the function body, which means
that it can not be a procedure pointer, and set PROCPTR_NO. With the
present patch we cannot make this distinction (i.e. we have no way to
remember this state).

I need some opinions on this solution. Do you think it makes sense? Is
there a case where it does not work? Or is there some easier way to
make the distinction?

Cheers,
Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: procptr136717.diff
Type: text/x-patch
Size: 15256 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20080613/2250d16a/attachment.bin>