[Patch, Fortran, F03] PR 40869: PPC assignment checking

Janus Weil janus@gcc.gnu.org
Tue Aug 25 22:34:00 GMT 2009

Hi all,

here is another patch concerning procedure pointer components
(hopefully one of the last). It fixes the last TODO item which was
left over from my initial PPC patch in May: Implementing interface
checking for pointer assignments involving PPCs.

For plain procedure pointers this interface check is done via
'gfc_compare_interfaces', which is also used for comparing procedures
as actual/formal arguments.

The only obstacle for PPCs is that gfc_compare_interfaces can only
operate on gfc_symbols and not on gfc_components. This type of problem
has appeared in other places before, since many gfc_... functions
acting on procedures traditionally assume that these are simple
gfc_symbols. In some of the cases this problem was solved by simply
duplicating the function, where the second version would act on a
gfc_component instead of a gfc_symbol (which in a way is not nice, but
practical for small functions). In other cases (e.g. large functions
like gfc_conv_procedure_call), it seemed more viable to add an
additional gfc_expr attribute (representing the PPC), which would be
used instead of the gfc_symbol which is usually passed.

In the case at hand (i.e. gfc_compare_interfaces), we have a function
comparing two procedures, where each of these procedures may be either
a 'plain' procedure (pointer), represented by a gfc_symbol, or a PPC,
represented by a gfc_component. Having four instances of this
function, each handling one of the four combinations didn't seem like
the most elegant solution to me. Also adding two additional arguments
would clutter things up a lot, especially since the function already
has six arguments.

So, what I did in this case was to simplify the problem by using not
the component itself for the comparison, but instead the symbol which
it gets its interface from (ts.interface). Since this is a normal
gfc_symbol, it can be passed to the existing gfc_compare_interfaces
without any problem. One drawback of this method is that the error
messages contain the wrong name, or an empty name (if the PPC was
declared like e.g. "procedure(real), pointer ..."). So far this is the
only drawback I see. And this method is a lot more elegant than any of
the other solutions I could think of.

If anyone has a better solution, I'd be glad to hear it.

[If we had gcc-in-cxx, I guess we could make gfc_component the base
class for gfc_symbol, and have functions which accept any of the two,
acting only on their common fields like ts, attr, name etc. Well,
nevermind ...]

The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?


2009-08-25  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/40869
	* expr.c (gfc_check_pointer_assign): Enable interface check for
	pointer assignments involving procedure pointer components.
	* interface.c (gfc_compare_interfaces): Don't rely on the proc_pointer
	attribute, but instead on the flags handed to this function.

2009-08-25  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/40869
	* gfortran.dg/proc_ptr_comp_20.f90: New.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr40869.diff
Type: text/x-diff
Size: 2251 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090825/61a65836/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_ptr_comp_20.f90
Type: application/octet-stream
Size: 940 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090825/61a65836/attachment.obj>

More information about the Gcc-patches mailing list