Instability in successive builds of fortran mod files with f951

[Simon Baldwin <simonb at google dot com>]

I'm seeing an element of "instability" in files written by f951.
About one time in some tens or even hundreds of builds done with a
tight loop, the file libgomp/omp_lib.mod has a different checksum from
others.

This is slightly problematic because it means that binary
distributions of gcc can't be relied on to build bit-identically when
given identical source inputs.  Automated build processes that insist
on full reproducibility will therefore hiccup from time to time when
they run into this effect.

I've looked at fortran/module.c and at libgomp/omp_lib.mod, and this
is not a bug.  fortran/module.c builds a tree of pointers to symbols,
and then traverses that tree to serialize symbols for the module file.
 The tree is organized by pointer value because its function is fast
pointer lookup.  This means, however, that the order nodes are visited
in traversal will depend on the relative values of the pointers in it.
 If the pointer to symbol "A" on the first run is a lower address than
the pointer to symbol "B" on the first run of f951, but higher on the
second run, these serialized symbols will appear in different orders
in the output module files from the two runs.  Neither output module
file is invalid.  The ordering is irrelevant.  fortran/module.c
clearly indicates it writes symbols in no particular order.

This lack of bit-equivalence in module files across f951 invocations
could be caused by instability earlier in the compiler, perhaps
uninitialized memory (gcc is configured for powerpc 8540).  It seems
more likely though that these pointers are all allocated by malloc and
malloc addresses aren't reproducible.  Malloc returns pointers from
regions allocated by anonymous mmap.  And the kernel is under no
constraint to provide "predictable" addresses for mmap (and neither is
malloc, for that matter).  So every now and again the pattern of
allocated symbol pointers leads to a different (yet still valid)
output.  In a sense, looking for bit-equivalence in module files might
be asking for malloc/mmap to be completely deterministic, and they may
not be.

I've looked at fortran/module.c to try to find any simple way to force
a consistent ordering, but there doesn't seem to be anything that
wouldn't lead to massive and unnecessarily invasive change here.  Is
there one that I'm missing?  Or any known issues with instability in
gcc's front end or powerpc 8540 specific code?  Anyone else run across
this effect?

If not, does anyone have any other ideas for how I might ensure
complete determinism in f951?  Or is insisting on bit-equivalent files
from successive gcc builds just asking too much?

Thanks.

--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902