This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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]

[Bug fortran/41242] [4.5 Regression] PPC call rejected (related to user-defined assignment?)



------- Comment #15 from domob at gcc dot gnu dot org  2009-09-10 19:27 -------
I can again only speak for TBPs (operator/assignment and generic ones) here,
but those somehow rely on multiple resolution (at least, sort of).  The
assignment gets translated into a generic call, and that one must be resolved
in turn to find the matching specific binding (and also transform it into an
ordinary procedure call, at least for now without dynamic dispatch).

I have to admit that some of the original concept of resolution does escape me,
but I believe when we move on to implement more stuff "in the front-end",
transforming it as necessary during resolution, it is indeed better to do
resolves on anything generated, because we run the (theoretical) risk of
propagating some front-end structures to the backend that should have been
transformed.  Even if you know for now that some code that is generated does
not need resolution, it may well be changed in the future to build a construct
that needs; well, maybe not practically, but I hope you see what I mean.

If on the other hand the original point of resolution (I think that's about
matching up symtrees/symbols that should refer to the same entity?) does
require resolving only once, maybe the real way to go is splitting these
"front-end code transformations" into yet another phase; then resolution would
carry on just as now with once-per-everything, and the possibly recursive code
transformations would be seperate.  Just some thoughts, though.

And to come back to the matter, I think I added two resolve-calls in
gfc_extend_assign with my patch:  The one resolving code generated really from
a type-bound operator; this one is crucial for my patch to work.  And the one
for otherwise generated code, which is (presumably, without further checking in
detail) the one Janus' patch removes.  And for this I would have guessed that
just removing it is alright, so I also don't see why this introduces the
ICEs...  Will look further at this when I find time (at the weekend,
hopefully).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41242


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