[GHC] #12935: Object code produced by GHC is non-deterministic

[GHC]

#12935: Object code produced by GHC is non-deterministic
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nh2):

 @niteria: First, I think there's a misunderstanding here. Hashes would be
 used only for hashing the module name, to determine another N-bit prefix
 similiar as for the tag (for example, you could have 8 bits for the tag,
 28 bits for the hash of the module name, and 28 bits for the actual
 uniques). Within this sub-namespace (per-module) uniques would continue to
 be allocated in a (+1) fashion, counting up from 0 to `2^26-1`. So there
 would never be the risk of a "uniques collision" as you describe, only the
 risk of a "module name hash colision".

 Second, to avoid module name hashes colliding: You just check them for
 uniqueness. This is easy, because you can do it ahead of time, before the
 build, where you already know all modules in the project. If they collide,
 you just use the next bigger integer. The point of that module name
 hashing (under the assumption that we have only 64 bits) is not to
 guarantee separate namespaces in all cases , just to make it very likely
 while also being stable against adding a new module to the project (you
 could also just enumerate the modules from 1 to N, but then if you add one
 in the middle, all modules get new subnamespaces assigned, and with name
 hashing that doesn't happen this way). If there's a collision, that's not
 the end of the world or a critical error, it just means you'll get
 different uniques next time (relatively unlikely with `2^28`).

 And you still have the property that given the same project with same
 modules and same compiler, you're guaranteed to be fully deterministic.
 Just not between changes that add a module.

 If we want to guarantee to be fully deterministic for individual modules
 even across additions of modules, all uniques have to be prefixed with the
 full module name (which might also be a good option).

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12935#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler