Hi Mikael, > this patch fixes PR58007, where the compiler was not able to relate a > component pointer to any loaded derived type symbol. > The problem came from an optimization avoiding loading again a symbol > which had already been loaded, skipping by the way the association of > component pointers (if the symbol was a derived type) with the > corresponding module indexes. > > The attached patch fixes this by reading the derived type symbol dump's > component list and do the pointer<->integer association by hand. Then > the regular on demand module loading code works properly and some code > in mio_component_ref that was forcing the module loading of the > containing derived type can be removed. > To associate the component pointers with the module integers, one has to > parse the symbol, or at least its components. It is done by hand in > this patch and to reduce the maintainance burden (for possible future > evolutions of symbol dumping format/content) the component list is moved > at the beginning. More exactly just after the symbol attributes, > because the check_for_ambiguous function relies on the symbol attributes > appearing first in a symbol. > This changes the module format, so MOD_VERSION is bumped. > > Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
Basically your patch looks ok to me. However, I don't quite see the necessity for changing the module format (apart from the fact that it makes your patch slightly simpler). Anyway, since the module format has been changed already in 4.9, I think it doesn't matter much if we do it once more, so okay with me. One question, though: I don't understand how the problem is specific to OOP code (and why it did not come up before with F95-style code). Do you think it would be possible to find a non-OOP case where it fails? If not, could there be some problem in gfortran's OOP implementation which causes the failure? > I plan to submit a variant that doesn't change the module format for the > branches (doing more parsing by hand). Isn't that what you posted in comment 12 of the PR? Which branches did you have in mind? The PR contains various test cases which fail on either 4.7 or 4.8 and sometimes both, so potentially both of them are affected by the bug, I guess? Cheers, Janus
