- ghc-tickets - Haskell.org

Re: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate
by GHC 15 Dec '14

15 Dec '14

#3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4139 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): I'm having the same problem, `-Wall` reporting `Patterns not matched: Step _ (End _)` for some code but if I put that match in, I get `Inaccessible code in a pattern with constructor`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3927#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux
by GHC 15 Dec '14

15 Dec '14

#9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux ----------------------------+---------------------------------------------- Reporter: chrisfgl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- Trying to compile GHC 7.8.3 for ubuntu/arm. Was in Stage 1 for 8 hours before exiting with following message: dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped) make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 15 Dec '14

15 Dec '14

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): I got a test case: I took http-client, a library that was notorious for non-deterministic ABIs, found a small module without any internal imports and stripped it down. It seems that this can be exhibited by nearly any compilation as long as you are compiling more than one module at once: {{{ghc -O -j2 Foo}}} will, AFAICT, for the simple case, result in the same ABI pretty much always. {{{ghc -O -j2 Foo Bar}}} will often not, but how often depends on the content of each. {{{Foo}}} and {{{Bar}}} can be completely independent, not importing each other. Probably going to be looking at uniqs and that {{{unsafeInterleaveIO}}} (thanks to Duncan for pointing it out) but needed a test case first. I attach two modules, {{{T}}} and {{{S}}}: they are not ‘trivial’ modules because with those the ABI hash changes much less frequently. These modules only import the libraries that ship with GHC so it is easy to hack on. Follows a sample session with 7.8.3: {{{ [shana@lenalee:~/programming/ghc-nondeterminism]$ nix-shell -p haskellPackages.ghc --pure [nix-shell:~/programming/ghc-nondeterminism]$ ghc -fforce-recomp -O -j2 -outputdir tmpdir -odir tmpdir -hidir tmpdir -stubdir tmpdir T S && ghc --show-iface tmpdir/T.hi | grep ABI [1 of 2] Compiling S ( S.hs, tmpdir/S.o ) [2 of 2] Compiling T ( T.hs, tmpdir/T.o ) ABI hash: 801be37df642d815fae5f74aa0f56580 [nix-shell:~/programming/ghc-nondeterminism]$ ghc -fforce-recomp -O -j2 -outputdir tmpdir -odir tmpdir -hidir tmpdir -stubdir tmpdir T S && ghc --show-iface tmpdir/T.hi | grep ABI [1 of 2] Compiling S ( S.hs, tmpdir/S.o ) [2 of 2] Compiling T ( T.hs, tmpdir/T.o ) ABI hash: 59cd140ecf48d626231ac3f8ecb5291e [nix-shell:~/programming/ghc-nondeterminism]$ ghc -fforce-recomp -O -j2 -outputdir tmpdir -odir tmpdir -hidir tmpdir -stubdir tmpdir T S && ghc --show-iface tmpdir/T.hi | grep ABI [1 of 2] Compiling S ( S.hs, tmpdir/S.o ) [2 of 2] Compiling T ( T.hs, tmpdir/T.o ) ABI hash: 563ecab71f525a8aea21d4982ec67388 [nix-shell:~/programming/ghc-nondeterminism]$ l total 44K drwxr-xr-x 3 shana nogroup 4.0K Dec 14 19:59 . drwxr-xr-x 221 shana shana 12K Dec 14 19:58 .. -rw-r--r-- 1 shana nogroup 684 Dec 14 19:59 S.hs -rw-r--r-- 1 shana nogroup 18K Dec 14 19:59 T.hs drwxr-xr-x 2 shana nogroup 4.0K Dec 14 20:03 tmpdir }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:70> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8024: Dynamic linking not working on PowerPC Linux.
by GHC 14 Dec '14

14 Dec '14

#8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: D560 | ----------------------------------------------+--------------------------- Comment (by Sergei Trofimovich <siarheit@…>): In [changeset:"fa31e8f4a0f853848d96549a429083941877bf8d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fa31e8f4a0f853848d96549a429083941877bf8d" powerpc: fix and enable shared libraries by default on linux Summary: And fix things all the way down to it. Namely: - remove 'r30' from free registers, it's an .LCTOC1 register for gcc. generated .plt stubs expect it to be initialised. - fix PicBase computation, which originally forgot to use 'tmp' reg in 'initializePicBase_ppc.fetchPC' - mark 'ForeighTarget's as implicitly using 'PicBase' register (see comment for details) - add 64-bit MO_Sub and test on alloclimit3/4 regtests - fix dynamic label offsets to match with .LCTOC1 offset Signed-off-by: Sergei Trofimovich <siarheit(a)google.com> Test Plan: validate passes equal amount of vanilla/dyn tests Reviewers: simonmar, erikd, austin Reviewed By: erikd, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D560 GHC Trac Issues: #8024, #9831 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8024#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 14 Dec '14

14 Dec '14

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Oops, guess I forgot to put anything here. I've been tasked with fixing this some weeks ago and hope to make progress in this area within this week. Maybe even I'll have a small test case by later today. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:69> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 14 Dec '14

14 Dec '14

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by Fuuzetsu): * owner: => Fuuzetsu Comment: Oops, guess I forgot to put anything here. I've been tasked with fixing this some weeks ago and hope to make progress in this area within this week. Maybe even I'll have a small test case by later today. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:68> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9884: Compling on arm and getting "No native code generator, so using LLVM"
by GHC 14 Dec '14

14 Dec '14

#9884: Compling on arm and getting "No native code generator, so using LLVM" -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: arm | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Incorrect hour) | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Compiling GHC on Arm and I get a constant stream of warnings like: {{{ when making flags consistent: Warning: No native code generator, so using LLVM }}} This can be fixed with a simple patch to `mk/build.mk.sample`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9884> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc
by GHC 14 Dec '14

14 Dec '14

#7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9883 None/Unknown | Test Case: | Blocking: 9883 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * blocking: => 9883 * related: => #9883 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7495#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8024: Dynamic linking not working on PowerPC Linux.
by GHC 13 Dec '14

13 Dec '14

#8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: D560 | ----------------------------------------------+--------------------------- Changes (by slyfox): * status: infoneeded => patch * differential: => D560 Comment: The problem happened to be in code emitting prologs for basic block entries (also got fixed by https://phabricator.haskell.org/D560) Typically haskell function has single entry point (-fPIC -ddump-asm- native): {{{ M.f_info: _ci4: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... <HERE GOES ACTUAL CODE> ... ; offset to LCTOC from nearest '1:' .text .align 2 _nii: .long .LCTOC1-(1b)+0 }}} But sometimes runtime needs to return back into a middle of haskell function (try/catch primitives?) and prolog gets emitted at each such point using the same LCTOC offset: {{{ M.f_info: _ci4: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic ; REF 1 lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... <HERE GOES ACTUAL CODE> ... returns_here_later: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic ; REF 2 lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... ; offset to LCTOC from nearest '1:' .text .align 2 _nii: .long .LCTOC1-(1b)+0 }}} Here '_nii' contains offset to nearest '1:' label, not first one (as intended). It leads to miscomputation of LCTOC1 in function entry (around first '1:' which usually manifests in call to random location. It is fixed by using simpler prolog (similar to what modern gcc emits nowadays): {{{ bcl 20,31,1f 1: mflr %vI_ny4 addis %vI_ny4, %vI_ny4, .LCTOC1-(1b)@ha addi %vI_ny4, %vI_ny4, .LCTOC1-(1b)@l mr 30, %vI_ny4 }}} And it is safe to duplicate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8024#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 12 Dec '14

12 Dec '14

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I initially put this ticket into my internal notes as "Difficulty: Rocket Science", but I've changed my mind. I think this is actually straightforward to implement. GHC already has implication constraints, except that they're effectively all Wanteds. So, all we would need are to be able to make Given implication constraints. But, these should be rather straightforward, because we can view top-level instances as Given implication constraints. We can just adapt the current look-in-Givens algorithm to do some matching, just like the instance-selection algorithm does. When we find an implication-constraint Given that matches a Wanted, we use it to solve the Wanted and then emit new Wanteds for the antecedents of the Given implication. I was initially concerned about overlap here -- what if an implication Given's RHS overlaps with a global instance? -- but this was a red herring. Givens have always potentially overlapped with global instances, and very few people are bothered. For example: {{{ min :: Ord a => a -> a -> a }}} If we call `min` at type `Int`, the `Ord` constraint is potentially ambiguous: do we mean the dictionary supplied or the global `Ord Int` dictionary? Of course, we mean the local one, and we don't require `-XIncoherentInstances` to do so. So, worrying about overlap in the context of implication Givens is a red herring. We have a clear rule: local constraints always shadow global ones. That's nice, simple, and unsurprising. This also doesn't change the "GHC never backtracks" principle. If a local implication-constraint's RHS matches, it is used, just like if GHC finds a global implication constraint (read, global constrained instance). To implement this, GHC would also need to be able to produce the witness for an implication constraint, but this is just like inferring the lambdas for a higher-rank type. I don't see any challenge here. Of course, a niggling feeling tells me that this ''has'' to be harder than I'm seeing it. But, really, all I see standing in the way is a bit of plumbing. Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0