[Patch, fortran] PR58007: unresolved fixup hell

Mikael Morin mikael.morin@sfr.fr
Sat Jan 11 12:18:00 GMT 2014


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tmp.f90
Type: text/x-fortran
Size: 399 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140111/56aef969/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_testcase.sh
Type: application/x-shellscript
Size: 1131 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20140111/56aef969/attachment-0001.bin>


More information about the Gcc-patches mailing list