July 2015 - ghc-tickets

[GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm
by GHC 20 Jul '15

20 Jul '15

#8131: T7571 with WAY=llvm fails, but not WAY=optllvm ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Test case (#7571 just will not die, it seems) {{{ $ make TEST=T7571 WAY=llvm ... ====> Scanning ./all.T =====> T7571(llvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -fllvm -no-hs-main >T7571.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-07 22:18:14.132934017 -0500 +++ ./T7571.comp.stderr 2013-08-14 01:26:33.942103723 -0500 @@ -0,0 +1 @@ +WARNING: Non constant alignment value given for memcpy! Please report to GHC developers *** unexpected failure for T7571(llvm) }}} However, this test case does not fail under WAY=optllvm, which I think is worth investigating probably: {{{ $ make TEST=T7571 WAY=optllvm ... ====> Scanning ./all.T =====> T7571(optllvm) 6 of 7 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -O -fllvm -no-hs-main >T7571.comp.stderr 2>&1 OVERALL SUMMARY for test run started at Wed Aug 14 01:25:42 CDT 2013 7 total tests, which gave rise to 28 test cases, of which 27 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures }}} However, there is another way to trigger this bug in *both* cases: {{{ #include "Cmm.h" testMemcpy (W_ dst, W_ src, W_ l, W_ sz) { prim %memcpy(dst, src, l, sz); return (); } }}} will fail both ways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10578: ghci line numbers are off by one
by GHC 20 Jul '15

20 Jul '15

#10578: ghci line numbers are off by one -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ rwbarton@morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> 3 : 'a' <interactive>:2:5: Couldn't match expected type ‘[a]’ with actual type ‘Char’ Relevant bindings include it :: [a] (bound at <interactive>:2:1) In the second argument of ‘(:)’, namely ‘'a'’ In the expression: 3 : 'a' In an equation for ‘it’: it = 3 : 'a' Prelude> 3 : 'a' <interactive>:3:5: Couldn't match expected type ‘[a]’ with actual type ‘Char’ Relevant bindings include it :: [a] (bound at <interactive>:3:1) In the second argument of ‘(:)’, namely ‘'a'’ In the expression: 3 : 'a' In an equation for ‘it’: it = 3 : 'a' Prelude> }}} Why are the errors reported as being on lines 2 and 3? And no, I don't buy that line 1 was the GHCi welcome message :) Apparently it's been like this since at least GHC 7.4 and I've never noticed. `ghc -e cmd1 -e cmd2` reports every command as beginning on a new line 1, which is also weird. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9571: nofib should use criterion-style bootstrapping/sampling
by GHC 20 Jul '15

20 Jul '15

#9571: nofib should use criterion-style bootstrapping/sampling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.9 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As I discovered when investigating situations like #9570, in some cases, test-cases in nofib are giving nonsense, and it's hard to tell unless you run nofib several times and notice that percentage differences are fluctuating up and down. The quality of the numbers we get for uninformed users would be better if we ran some statistical analysis to tell how many times to run the benchmark, and if there were lots of outliers (rather than just blindly summarizing all the runs using an average.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8123: GHCi warns about -eventlog even though it's sometimes necessary
by GHC 19 Jul '15

19 Jul '15

#8123: GHCi warns about -eventlog even though it's sometimes necessary -------------------------+------------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: GHCi | Operating System: Linux Keywords: | Type of failure: Incorrect warning at Architecture: | compile-time x86_64 (amd64) | Test Case: Difficulty: | Blocking: Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- If I invoke GHCi as {{{ghci -eventlog}}}, it says: {{{Warning: -debug, -threaded and -ticky are ignored by GHCi}}}. However, the flag does make a difference, in that GHCi will be able to load object files that were compiled using {{{-eventlog}}}. For this reason, I don't think {{{-eventlog}}} should trigger the warning. Also runghc has the same issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7919: Heap corruption (segfault) from large 'let' expression
by GHC 18 Jul '15

18 Jul '15

#7919: Heap corruption (segfault) from large 'let' expression -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"dcaa4865a4ee99888e90a80b7f09e11e71689f6c/ghc" dcaa4865/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dcaa4865a4ee99888e90a80b7f09e11e71689f6c" Testsuite: mark T7919 expect_broken_for(#7919, ['optasm','dyn','optllvm']) It fails with a segmentation fault. Occasionally also for WAY=threaded2. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7919#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 18 Jul '15

18 Jul '15

#3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10656 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * related: => #10656 Comment: Currently this is being worked on in D963. I am going to close this ticket as the original issue of GHC binaries lacking debug information has been resolved. I have opened #10656 to track the process of exposing this debug information to Haskell programs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:76> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10655: Add wildcards (from partial type signatures) to template-haskell
by GHC 18 Jul '15

18 Jul '15

#10655: Add wildcards (from partial type signatures) to template-haskell -------------------------------------+------------------------------------- Reporter: abbradar | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Ditto. I imagine `WildcardT` added to the `Language.Haskell.TH.Syntax.Type`, though I have no idea of exact volume of needed work. Looking at [https://github.com/ghc/ghc/blob/master/libraries/template- haskell/Language/Haskell/TH/Syntax.hs#L1465], this is unresolved in HEAD, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10655> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10654: Better error message regarding type synonyms and PolyKinds
by GHC 18 Jul '15

18 Jul '15

#10654: Better error message regarding type synonyms and PolyKinds -------------------------------------+------------------------------------- Reporter: abbradar | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Followup of https://mail.haskell.org/pipermail/haskell- cafe/2015-July/120505.html {{{ ghci> :set -XPolyKinds ghci> type Test a = a ghci> type Huh = Test <interactive>:6:1: Type synonym ‘Test’ should have 2 arguments, but has been given 1 In the type declaration for ‘Huh’ }}} (Notice the number of arguments reported) Jonas Scholl at haskell-cafe suggested that the additional invisible argument is a kind argument, which indeed looks to be the case, as he demonstrated: {{{ Prelude> :set -XPolyKinds -XDataKinds -XKindSignatures Prelude> type Test a = a Prelude> type Huh a = Test (a :: Bool) Prelude> type Bar = Huh <interactive>:5:1: Type synonym ‘Huh’ should have 1 argument, but has been given none In the type declaration for ‘Bar’ }}} A better error message may be desirable here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10224: Partial type signatures generate typed hole warnings
by GHC 17 Jul '15

17 Jul '15

#10224: Partial type signatures generate typed hole warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHCi generates typed hole warnings in type signatures even when PartialTypeSignatures is enabled: {{{ > :set -XPartialTypeSignatures > :t (==) :: Char -> _ <interactive>:1:17: Warning: Found hole ‘_’ with type: Char -> Bool In an expression type signature: Char -> _ In the expression: (==) :: Char -> _ (==) :: Char -> _ :: Char -> Char -> Bool > :set -XNoPartialTypeSignatures > :t (==) :: Char -> _ <interactive>:1:17: Found hole ‘_’ with type: Char -> Bool To use the inferred type, enable PartialTypeSignatures In an expression type signature: Char -> _ In the expression: (==) :: Char -> _ }}} Similarly, GHC 7.10.1, when given the following source, {{{ {-# LANGUAGE PartialTypeSignatures #-} f = (==) :: Char -> _ main = return () }}} mentions that it "found a hole". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface
by GHC 17 Jul '15

17 Jul '15

#9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface -------------------------+------------------------------------------------- Reporter: | Owner: ezyang | Status: new Type: bug | Milestone: Priority: | Version: 7.9 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- With the latest `-fwrite-interface` enhancements, a build directory can contain interface files independently of object files. In cases like this, we would like to have recompilation avoidance avoid typechecking files whose interface files are up-to-date. However, this does not currently work: we always re-typecheck: {{{ t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc- backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface [1 of 1] Compiling A ( A.hs, nothing ) t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc- backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface [1 of 1] Compiling A ( A.hs, nothing ) }}} The reason for this is that recompilation avoidance logic in `compileOne` (in `DriverPipeline.hs`) seems to rely exclusively on "linkables" in order to figure out if source has been modified or not. We never generate an object file with `-fwrite-interface`, so the compiler always concludes that we need to retypecheck. However, recompilation avoidance for hs-boot does work. The reason for this is because we create a dummy o-boot linkable. We can't use this strategy for `-fno-code`, because the dummy object file would imply that we actually compiled the file (which we didn't). The upshot is that to fix this problem, it looks like we might have to rejigger all of the logic in `compileOne`, which why I gave up on this for now. Related to https://github.com/haskell/cabal/issues/1179 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11