May 2015 - ghc-tickets

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 11 May '15

11 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The return/pure thing presumably arises because we have `return = pure`, or vice versa, and one is "shorted out" in favour of the other. See `SimplCore.shortOutIndirections`. Would someone like to see if this is true? If someone cares to confirm this, then perhaps `shortOutIndirections` could choose whether to elminate `return` or eliminate `pure` based on a lexicographic comparison of their names? Would someone like to see if this would work? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:81> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 11 May '15

11 May '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: #8977 => #8977, #10298 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 11 May '15

11 May '15

#2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D395 -------------------------------------+------------------------------------- Comment (by rodlogic): Replying to [comment:19 zilinc]: > I feel it's too late to object, so I'll ask a question instead. I'm developing a software, in which I use the `VersionTags` field to store the git commit hash in order to know under which git revision my software is compiled. It's implemented by a hook in `Setup.hs`. So that the `showVersion` function can print something like `MySoftware 2.3.0.0-ce78942aed`, which is really handy for development. With the new changes in GHC, is there anywhere that I can put this piece of info? Or are you going to create another field in `PackageDescription` to keep extra notes? I also share the same feeling and sorry for being late to comment here. This is quite a common pattern out there. Removing versionTags to avoid the Eq/Ord inconsistency seems like the easiest approach but not the best one, imho. Why not stick to semver.org: MAJOR.MINOR.PATCH(-PRERELEASE)?(+tag)*, where: * "Pre-release versions have a lower precedence than the associated normal version" * "Build metadata SHOULD be ignored when determining version precedence" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2496#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries"
by GHC 11 May '15

11 May '15

#10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This was originally spotted and [https://mail.haskell.org/pipermail/ghc- devs/2015-February/008407.html posted to the ghc-devs mailing list] by Joachmin Breitner, but apparently since nobody has submitted a ticket for this relatively serious issue, here it is. I am quoting Joachim: {{{ while the index at http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/index.… exists, navigating to http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/Data- Char.html yields a 404 error. Same for http://haskell.inf.elte.hu/docs/latest/html/libraries/Data-Char.html }}} And [https://mail.haskell.org/pipermail/ghc-devs/2015-February/008408.html I have replied] the following to his initial email (I am involved in this because I am doing daily snapshots of the documentation through my FreeBSD GHC builders): {{{ Yes, I can confirm this bug. For what it is worth, the files are all there, the link appears to be broken: it is missing the subdirectory with the name of the package. That is, the proper link should be something like that: http://haskell.inf.elte.hu/docs/7.9.20141222.noWin32/html/libraries/base-4.… /Data-Char.html (Note the missing "base-4.8.0.0".) I have checked this with GHC 7.8.3, and everything is right there, while this problem seems to appear with GHC 7.10 RC2 and GHC-HEAD (starting from somewhere between mid-September and November -- that is what a quick bisecting tells me). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10302: 7.10.1 documenation is incorrect wrt llvm
by GHC 11 May '15

11 May '15

#10302: 7.10.1 documenation is incorrect wrt llvm -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: llvm | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As documented in [#9929] ghc 7.10.1 only supports llvm 3.5. This should be documented in the release notes section of the GHC Users's Guide, Version 7.10.1. In addition, the following in the Known bugs section needs to be changed to mention this also: GHC’s LLVM backend is currently incompatible with LLVM 3.4 (issue #9929). The following in section 4.11.2 should also be changed from: Currently LLVM 2.8 and later are supported. to Only LLVM 3.5 is supported. from Secondly, if you are running Mac OS X with LLVM 3.0 or greater to Secondly, if you are running Mac OS X with LLVM 3.5 from In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X. to In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X and then install LLVM 3.5 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 11 May '15

11 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > There are some issues with non-determinism in the output of GHC, which > means that compilations are not repeatable. This affects some users > (e.g. Debian packagers) who need to be able to get repeatable hashes for > the packages of a GHC build. > > The cases we know about that lead to non-deterministic results are: > > * The `spec_ids` (specialised Ids) attached to an Id have a non- > deterministic ordering > * CSE can give different results depending on the order in which the > bindings are considered, and since the ordering is non-deterministic, the > result of CSE is also non-deterministic. e.g. in `x = z; y = z; z = 3`, > where `y` and `x` are exported, we can end up with either `x = y; y = 3` > or `y = x; x = 3`. > * There seems to be something unpredictable about the order of arguments > to SpecConstr-generated specialisations, see > [http://www.haskell.org/pipermail/glasgow-haskell- > users/2011-April/020287.html] > * The wrappers generated by the `CApiFFI` extension have non- > deterministic names. (see comment:15 below). > > '''Old ticket description follows''' > > Short story: if you use ghc-6.12.1.20100318 (or similar, probably > ghc-6.12.1 release will produce the same results) to bootstrap > ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12, > those two instances of ghc-6.12 will have different ABI hashes and > interfaces in the ghc package. If you use ghc-6.10 for the > bootstrapping, you'll even get differences in the ghc, base and > Cabal packages. > > Long story: see logfiles and descriptions at http://darcs.volkswurst.de > /boot-tests/ (note that the logfiles are quite large, I really don't want > to attach 150 MB of logs to this ticket). New description: There are some issues with non-determinism in the output of GHC, which means that compilations are not repeatable. This affects some users (e.g. Debian packagers) who need to be able to get repeatable hashes for the packages of a GHC build. The cases we know about that lead to non-deterministic results are: * The `spec_ids` (specialised Ids) attached to an Id have a non- deterministic ordering * CSE can give different results depending on the order in which the bindings are considered, and since the ordering is non-deterministic, the result of CSE is also non-deterministic. e.g. in `x = z; y = z; z = 3`, where `y` and `x` are exported, we can end up with either `x = y; y = 3` or `y = x; x = 3`. * There seems to be something unpredictable about the order of arguments to SpecConstr-generated specialisations, see [http://www.haskell.org/pipermail/glasgow-haskell- users/2011-April/020287.html] * The wrappers generated by the `CApiFFI` extension have non- deterministic names. (see comment:15 below). * See comment:76 for another, different, example '''Old ticket description follows''' Short story: if you use ghc-6.12.1.20100318 (or similar, probably ghc-6.12.1 release will produce the same results) to bootstrap ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12, those two instances of ghc-6.12 will have different ABI hashes and interfaces in the ghc package. If you use ghc-6.10 for the bootstrapping, you'll even get differences in the ghc, base and Cabal packages. Long story: see logfiles and descriptions at http://darcs.volkswurst.de /boot-tests/ (note that the logfiles are quite large, I really don't want to attach 150 MB of logs to this ticket). -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:80> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 11 May '15

11 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for bringing this up Mateusz. The ticket description lists four sources of non-deterministic outputs. I think you are saying that 7.10.1 has a fifth (as yet uncharacterised) source, which somehow bites more often than the preceding four. Is that right? Is comment:76 the single exemplar of the difficulty, or are there others? Mateusz says that we should not release 7.10 until comment:76 is fixed. Do others agree? Does anyone feel able to characterise what is going on with comment:76? Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:79> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 11 May '15

11 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Mateusz [https://mail.haskell.org/pipermail/ghc-devs/2015-May/008992.html says]: I'd like to bring some attention to ticket #4012 about non- determinism. As many of you may know, the nix package manager distributes binaries throughout its binary caches. The binaries are shared as long as the hash of some of their inputs matches: this means that we can end up with two of the same hashes of inputs but thanks to #4012 means that the actual contents can differ. You end up with machines with some packages built locally and some elsewhere and due to non-determinism, the GHC package IDs don't line up and everything is broken. The situation was pretty bad in 7.8.4 in presence of parallel builds so we switched those off. Joachim's a477e8118137b7483d0a7680c1fd337a007a023b helped a great deal there and we were hopeful for 7.10. Now that 7.10.1 is out and people have been using and testing it, the situation turns out to be really bad: daily we get multiple reports from people about their packages ending up broken and our only advice is to do what we did back in 7.8 days which is to purge GHC and rebuild everything locally or fetch everything from a machine that already built it all, as long as the two don't mix. This is not really acceptable. See comment:76 on #4012 for an example of a rather simple file you can compile right now with nothing extra but -O and get different interface hash. This e-mail is just to raise awareness that there is a serious problem. If people are thinking about cutting 7.10.2 or whatever, I would consider part of this ticket to be a blocker as it makes using GHC reliably while benefitting from binary caches pretty much impossible. Of course there's the ‘why don't you fix it yourself’ question. I certainly plan to but do not have time for a couple more weeks to do so. For all I know right now, the fix to comment:76 might be easy and someone looking for something to hack on might have the time to get to it before I do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:78> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10210: Documentation link to 7.10.1 migration guide broken
by GHC 11 May '15

11 May '15

#10210: Documentation link to 7.10.1 migration guide broken -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple Documentation | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When publishing the users guide to https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1…, several users reported the 'Migration Guide' hyperlinks were broken. Turns out they were; the HTML looked something like this: {{{ </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> GHC has implemented "The Applicative Monad Proposal", meaning the <code class="literal">Applicative</code> typeclass is now a superclass of <code class="literal">Monad</code>. This is a breaking change and your programs will need to be updated. Please see the <a class="ulink" href="" target="_top">GHC 7.10 Migration Guide</a> on the GHC wiki. }}} with an empty `href`. This ticket is so we don't lose track of this bug for 7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10263: Role annotation should never be ambiguous
by GHC 11 May '15

11 May '15

#10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ [ezyang@hs01 ghc-backpack]$ cat A.hs {-# LANGUAGE RoleAnnotations #-} module A where data Maybe a = AF type role Maybe representational [ezyang@hs01 ghc-backpack]$ ghc -c A.hs A.hs:4:11: Ambiguous occurrence ‘Maybe’ It could refer to either ‘A.Maybe’, defined at A.hs:3:1 or ‘Prelude.Maybe’, imported from ‘Prelude’ at A.hs:2:8 (and originally defined in ‘GHC.Base’) }}} This is silly because roles can only ever be defined with the declaration, so only one reference makes sense. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6