Help with module.c and free_pi_tree()

[Brendan Kochunas]

So I feel I've made some progress in debugging my issue. And I have a 
couple questions. Briefly the questions are:

1) In general what global variables (if any) change between calls to 
gfc_use_module (being called from gfc_use_modules in module.c)?

2) Is there something that would cause the structure of pi_root to 
change based on the order in which the USE statements are processed by 
the gfc_use_module routine? (When looking at gfc_use_module it appears 
that the pi_root variable will be in the uninitialized or NULL state on 
entry to and exit from this routine).

Now read on for more context if you're interested...

First my test case and observations:
I am attempting to compile a main program and it has two use statements 
(none of which are intrinsic modules). The two module files being loaded 
that were generated by the compiler are each about 50K lines. For the 
purposes of discussion let us call the modules A and B. I am building 
with the 4.7.1 release branch in Ubuntu. I can provide more config info 
if needed, but basically I didn't change any of the options when calling 
configure.

What I observe is the following:
* If the compiler encounters the "free_pi_tree(): Unresolved fixup",
   it happens when calling free_pi_tree() inside of gfc_use_module.
* I only get the error when listing the USE statements in a particular
   order. e.g. "USE A; USE B" would produce the ICE while "USE B; USE A"
   would not.
* When the ICE happens I print out the current pointer_info objects
   state and it is basically the following attributes (which aren't
   particularly helpful):
     p->priority = 38911
     p->type = COMPONENT
     p->u.rsym.true_name = '(null)'
     p->u.rsym.module = '(null)'
     p->u.rsym.binding_label = '(null)'
     p->u.rsym.state = UNUSED
     p->u.rsym.ns = 0
     p->u.rsym.referenced = 0
     p->u.rsym.renamed = 0
     p->u.rsym.where.line = 0
     p->u.rsym.where.column = 0
     p->fixup is not NULL and should be

Presently, I'm trying to determine what global variables/data structures 
change between calls to gfc_use_module. In gfc_use module the code is:
------------------------------
   init_pi_tree ();
   init_true_name_tree ();

   read_module ();

   free_true_name (true_name_root);
   true_name_root = NULL;

   free_pi_tree (pi_root);
   pi_root = NULL;
------------------------------

I haven't dug into read_module yet, but from this snippet, I would 
expect pi_root (and true_name_root) to be in an uninitialized NULL state 
for each call to gfc_use_module prior to executing this block. So it 
doesn't make any sense to me why changing the order of my USE statements 
in source code would affect this.

So if anyone can point me to or provide me with more info for my 
questions at the top of this email it'd be greatly appreciated. I'll 
keep digging in the mean time.

Thanks,
-Brendan

On 12/7/2013 1:00 PM, Janus Weil wrote:
> Hi,
>
>>>> I'm currently encountering the ICE related to Bug tickets 47546, 53015,
>>>> and
>>>> 58007 (e.g. free_pi_tree(): Unresolved fix-up).
>>>
>>>
>>> unfortunately these bugs have turned out to be quite elusive and
>>> sometimes hard to reproduce. The first two have been fixed by now
>>> (because they are not reproducible any more), and for the third one a
>>> patch has been posted. Are you able to build gfortran yourself, and if
>>> yes have you tried the patch?
>>>
>> I can build gfortran, but I did not see this patch. I'll track it down.
>
> unfortunately it seems that the patch does not fix all cases (or even
> makes things worse in some), see comment 9.
>
>
>>>> I have a few hypothesis as to what conditions cause this ICE to show up
>>>> when
>>>> building my code.
>>>>
>>>> I would like to spend some time debugging the compiler for my particular
>>>> use
>>>> case/code to see if I can understand what is going on.
>>>
>>>
>>> It would be nice if you could figure out what is going on, but this is
>>> certainly not the easiest PR to start with if you are a newbie to
>>> gfortran.
>>>
>> I agree with this sentiment, but I'm still going to give it a shot :)
>
> I certainly did not want to put you off. Just giving a word of
> warning. Good luck!
>
> Cheers,
> Janus
>