Procedure Pointers: a first patch

[Paul Richard Thomas]

Janus,


> I identified the place where this extra ADDR_EXPR is inserted
> (gfc_conv_variable, as mentioned earlier), and replaced it by
> something that I hope should do the right thing (patch attached).

Yes, I found this from the reverse engineering that I mentioned - you
notice the comment on the bit that you modified:)

> This new patch at least passes the gimplification, but then something
> goes wrong somewhere inside cgraph_finalize_function. The error
> message is:

+      /* Procedure pointers.  */
+      else if (sym->attr.flavor == FL_PROCEDURE
+	       && sym->attr.pointer)
+	{
+	  gcc_assert (se->want_pointer);
+	  gcc_assert (TREE_CODE (se->expr) == FUNCTION_DECL);
+	  se->expr = build_pointer_type (TREE_TYPE (se->expr));
+	  se->expr = build_decl (VAR_DECL, get_identifier (sym->name), se->expr);
+	  return;
+	}
+

This implies that something is wrong with the backend_decl, built when
the symbol is declared.  This is why I keep banging on about seeing
what other similar code does - after all, this job has been done at
least three times; procedure passing, Cray pointers and iso-c-binding.

trans-decl.c(gfc_get_symbol_decl) is central to this.  For external
procedures this calls gfc_get_extern_function_decl.

Anyway, I think that trans-decl.c(gfc_finish_cray_pointee) is the real
clue that you are after.  Campared with procedure pointers, Cray
pointers are a bit ass-backwards.  However, the "pointer" is in fact
an INTEGER of the same size as void*.  This is the DECL_VALUE_EXPR
field of the Cray pointee.  If you turn it around, when a procedure
pointer is declared, it can be looked upon as being the same as a Cray
pointee and should be finished in the same way.  The a variable should
be built, which becomes the DECL_VALUE_EXPR and it is this that should
be the lhs of the pointer assignment.

I'll come back to this tomorrow.

Cheers

Paul