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

[Janus Weil <jaydub66 at googlemail dot com>]

>>> Or, for all of these problems you could try to rework
>>> gfc_compare_interfaces
>>> to work only on some common part of the things it is passed (similar to
>>> your
>>> polymorphism approach for gcc-in-cxx) where possible, I tried this some
>>> times for TBPs
>>
>> You just thought about doing this, or you actually did? If you did,
>> can you point me at the place in the source?
>>
>> I'm not completely sure what you mean, though. Like passing e.g.
>> sym->ts and sym->attr instead of sym? Or rather passing an actual
>> gfc_component for a formal gfc_symbol? (This currently won't work,
>> since common things like ts and attr have a different offset in both.)
>
> I meant things like passing only whats needed (say sym->ts and sym->attr in
> your example), and possibly adapting the routine so this works out nicely...
> ?Of course this does depend a lot on the circumstances and is not always
> practical (probably in this case it isn't).

Here it really is not practical, because we have *two* symbols, and
for each we would at least need ts, attr and formal, which makes six
arguments in total.

In general I don't like this idea too much, because it picks apart the
larger units of information we have in the gfortran front end (like
gfc_symbol or gfc_component) and ungroups its constituents.

I'd very much prefer to leave these units intact and follow an
OOP-like approach, where both data structures would have common base
type, or one would be the parent type of the other, containing a
subset of its components. (This is actually a point where the gfortran
source could benefit a bit from C++.)

One may think about trying something like this in C (but I guess it
would be rather dirty). At a minimum, the common components of
gfc_symbol and gfc_component would have to be aligned to each other,
so that pointers could be recast from one type to the other.

Cheers,
Janus