Hi, >>> 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. > Well, I'm afraid of a future evolution where we change the module > format, update mio_symbol, and forget to change read_module as well, so > that the code reads something thinking it is the component list, but it > has become something else. > It is possible as empty parentheses `()' are common in the module > format, and it matches an empty component list. Moving the component > list earlier only makes it less likely. Another possibility to prevent > this is adding a recognizable pattern like "@# component-list #@" or > something, but the price to pay is the same: changing the module format. > >> 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 attach here a non-OOP variant, as well as the script that generated > it. You can see that i'm no good at writing shell scripts. ;-) > Anyway the principle is: the bugs happens when the symbols are read in > one particular (failing) order, so this script adds useless variables to > the modules to saturate the pointer tree and trigger a tree rebalance, > until it fails.
Good, thanks for checking. As written before, the patch is ok for trunk from my side. >> 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? >> > Oops, I thought it was a 4.7/4.8 regression. > Actually, the testcase provided here also fails with 4.8, so I was > actually right. :-) In fact your test case fails with all versions I tried (4.4, 4.6, 4.7, 4.8 and trunk). So, is it a regression at all? Cheers, Janus
