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
