Help with module.c and free_pi_tree()

[Brendan Kochunas]

Hi all,

I'm currently encountering the ICE related to Bug tickets 47546, 53015, 
and 58007 (e.g. free_pi_tree(): Unresolved fix-up).

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.

I'm new to the list and I'm curious how much support via email I might 
be able to expect. It will generally involve questions along the lines 
of "how do I check this?" or "what is this data structure or where is it 
defined?" I have no qualms about putting forth effort digging through 
the code and reading comments and other documentation, so I hope 
whatever help I'll need is minimal. Again it'll mostly be help finding 
info on what I need to know to what I would like.

That said... I'm hoping to understand some of the following in as much 
detail as possible.
* The contents and layout of the *.mod files generated during compilation
* The structure of the pointer index tree and the node data types.
* How the read_module() routine in module.c populates the pi_tree.

If you just want to point me to existing documentation on these things 
I'm perfectly ok with that.


Now (for your interest, feel free to skip the rest if you're not 
interested) here's my understanding/thoughts on what may be happening to 
cause this ICE to show up when building my code.

First, we can use a parallel make in compiling our code. So consider 
this example.
* There are 4 source files each defining a Fortran module.
* Let's say the modules are called A, B, C, D.
* Let module A have no dependencies on the other modules.
* Let module B have a dependency on module A
* Let module C have a dependency on module A
* Let module D have dependencies on modules B and C.

Now module D could be compiled by compiling the other modules in the one 
of the following orders.
* First order
   1. Compile module A
   2. Compile module B
   3. Compile module C
   4. Compile module D
* Second order
   1. Compile module A
   2. Compile module C
   3. Compile module B
   4. Compile module D

The module file that gets created for module D will differ depending on 
which build order was used. (I have verified this in my code which is 
more complicated.)

Furthermore, if we assume we can do this "make" in parallel then the 
order in which the modules are compiled is non-deterministic, and 
therefore the .mod file for module D is non-deterministic.

Now suppose that the ICE happens for one of those build orders.

I believe that this is what is happening in my case. That some build 
orders do not ICE with free_pi_tree(), and other build orders do. (I 
have verified that in a serial build ICE does not occur.)

So what I hope to accomplish through debugging is to find a build order 
that does not ICE and a build order that does ICE and see if I can 
reliably reproduce this result (for given compiler version and 
platform). I also hope to observe exactly what happens in the ICE to see 
how the pi_tree becomes corrupted (I'm assuming this happens in 
read_module). This will allow me to fix my build order for a small 
subset of files and still be able to build quickly in parallel 
(prerequisite for the project I work on) and possibly to also develop a 
test case for you all to use and hopefully resolve this bug in the compiler.

Sorry that was a lot, but thanks for taking the time read it. Please let 
me know any thoughts you have.

Thanks,
-Brendan

Post-Doctoral Fellow
University of Michigan
Department of Nuclear Engineering and Radiological Sciences
Ann Arbor, MI 48105