This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Janus Weil wrote:
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.
I think this solution is ok.  You could of course add two arguments for the
names for error messages to gfc_compare_interfaces to fix that problem, but
I'm not sure if that's really needed (at least not for now).

Actually only one argument is needed, since only one name is used. I have already discussed this with Tobias, and I think this is what we should do (updated patch attached), even if it only shows the name of the component, and not the whole thing (obj%ppc). But I think this is ok for the purpose.

If no one objects, I will commit the updated patch later today or tomorrow.

Ok with me.



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). I did this for instance in my first type-bound operator patch (parsing/verifying) for check_operator_interface (or like this, don't remember the exact name).


Yours,
Daniel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]