http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
--- Comment #10 from janus at gcc dot gnu.org --- Hi Mikael, sorry for the very late reply ... (In reply to Mikael Morin from comment #8) > I'll need the help from an OOP expert. > > Janus, what is the rationale for using so many different types for class > containers? well, actually I think the initial design of the class containers was mainly dreamed up by Paul, so don't blame it all on me ;) Anyway, the implementation basically follows the idea that the class containers are generated rather early on in the front-end (i.e. directly at parsing stage, if possible). Therefore one needs a way to store the attributes of the original declaration (other than in the original symbol). Currently the allocatable, pointer, rank and corank attributes are encoded directly in the naming of the class container (cf. gfc_build_class_symbol). As you have discovered above, it might help to also treat the 'target' attribute (there are a few other PRs which deal with the same issue). In principle there might even be more attributes that need to be treated (not sure about this). > It confuses the middle-end when assigning class containers. > For example in the case: > class_ptr => class_target > > class_ptr's container has type '__class_(blah)p' while class_target has type > '__class_(blah)', so we can't do the assignment. > However, even if the types are different the types' contents seems to be the > same, so they could be merged? Possibly, if you manage to keep track of the corresponding attributes in a different way. Another thing that might help would be to generate the class containers at a later stage (resolution or translation time). Then one could just store the attributes in the straightforward way. I had started working on this at some point, but never fully managed to pull it through. Unfortunately I have little time for this at the moment, but if you are willing to work on it, I could at least try to give a bit of feedback on the current implementation. Cheers, Janus
