ps I forgot to mention that I also changed write_generic to traverse the
tree in defined order, this is the same in the C++ and the C-only patch.
Cheers,
- Tobi
On 2012-10-13 15:26, Tobias Schlüter wrote:
Hi,
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include <map>"? In system.h?
Now to the patch-specific part: in this PR, module files are produced
with random changes because the order in which symbols are written can
depend on the memory layout. This patch fixes this by recording which
symbols need to be written and then processing them in order. The patch
doesn't make the more involved effort of putting all symbols into the
module in an easily predicted order, instead it only makes sure that the
order remains fixed across the compiler invocations. The reason why the
former is difficult is that during the process of writing a symbol, it
can turn out that other symbols will have to be written as well (say,
because they appear in array specifications). Since the module-writing
code determines which symbols to output while actually writing the file,
recording all the symbols that need to be written before writing to the
file would mean a lot of surgery.
I'm putting forward two patches. One uses a C++ map to very concisely
build up and handle the ordered list of symbols. This has three problems:
1) gfortran maintainers may not want C++isms (even though in this case
it's very localized, and in my opinion very transparent), and
2) it can't be backported to old release branches which are still
compiled as C. Joost expressed interested in a backport.
3) I don't know where to #include <map> (see above)
Therefore I also propose a patch where I added the necessary ~50 lines
of boilerplate code and added the necessary traversal function to use
gfortran's GFC_BBT to maintain the ordered tree of symbols.
Both patches pass the testsuite and Joost confirms that they fix the
problem with CP2K. I also verified with a few examples that they both
produce identical .mod files as they should.
Is the C++ patch, modified to do the #include correctly, ok for the
trunk? If not, the C-only patch? Can I put the C-only patch on the
release branches? And which?
Cheers,
- Tobi
