PR fortran/51727: make module files reproducible, question on C++ in gcc

[Tobias Schlüter]

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