#4012: Compilation results are not deterministic
-----------------------------------+----------------------------------------
Reporter: kili | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.12.2
Resolution: | Keywords:
Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: Other | Patch: 0
-----------------------------------+----------------------------------------
Comment(by simonmar):
Replying to [comment:6 kili]:
> For example, if two persons are working on a ghc package for their
operating system, and also on updates for all the stuff that needs ghc
(xmonad, alex, happy, monadius, to mention the most important ones), it's
a pity if they're not able to exchange packages.
For this to work I think you'd really need stable ABIs, not just
deterministic compilation. If you only had deterministic compilation, it
would be hard to guarantee that all the inputs to the compilation were
identical between the two systems: there are a lot of ways that
differences can accidentally creep in (different optimisation flags,
system configuration settings, etc.).
See [wiki:Commentary/Packages#AllowingABIcompatibilty] for more on this.
> You mentioned that even a `make clean; make' may change the interfaces.
Indeed, I remember at least one case where ghc segfailted during the build
(this doesn't happen often, only every 20th or 30th build)
FWIW, we never see random segfaults in GHC here, so I expect that really
is a bug specific to your OS or system that needs investigating.
> and I just restarted the build -- and got interface changes.
Yes - unfortunate, but not unexpected.
> > Anyway, I do agree that having deterministic compilation results is a
desirable thing, so on second thoughts I've re-opened the bug and retitled
it.
>
> Thanks. But is this really *one* Bug? There are the problems with non-
determinisms, but I think that the CSE on inlined constants (like
cBooterVersion and cProjectVersion) is a separate problem.
Ian pointed out that you really have source differences here, which I
hadn't spotted. (Actually, I'm not sure why `cBooterVersion` isn't set to
the version of the stage1 compiler when building stage2, it doesn't seem
useful to record the stage0 version in the stage2 compiler.)
So the underlying problem leading to the CSE issue is that the compiler
doesn't use a deterministic ordering for bindings internally. It uses the
`Unique` ordering, which is semi-random. The results of CSE may depend on
the order of bindings, but it's entirely possible that there are other
non-deterministic consequences of the same kind elsewhere. Making the
order deterministic would fix all of them.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4012#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
