Le 04/01/2014 16:35, Janus Weil a écrit : > 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. 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. For those who cannot afford updating their compilers, a variant of this script might be used to have this bug _not_ happen on their codes. This is left as an exercise; not sure how difficult it is. ;-) > >> 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? > It is, yes. > 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. :-) Mikael
module matrix type :: sparse_matrix integer :: max_degree end type end module module bsr use matrix type, extends(sparse_matrix) :: bsr_matrix end type integer :: i1 integer :: i2 integer :: i3 contains function get_neighbors (A) type(bsr_matrix), intent(in) :: A integer :: get_neighbors(A%max_degree) end function end module program main use matrix use bsr end
make_testcase.sh
Description: application/shellscript