July 2016 - ghc-tickets

[GHC] #12123: GHC crashes when calling typeRep on a promoted tuple
by GHC 25 Jul '16

25 Jul '16

#12123: GHC crashes when calling typeRep on a promoted tuple -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code (asking for the typeRep of a promoted tuple) causes GHC to crash. {{{ import Data.Typeable import Data.Proxy x = typeRep (Proxy::Proxy '(Int,Int)) }}} The error message is: {{{ [1 of 1] Compiling Main ( ../Bug.hs, interpreted ) GHC error in desugarer lookup in Main: Can't find interface-file declaration for variable $tc'(,) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160518 for x86_64-unknown-linux): initDs IOEnv failure }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12394: broken (obsolete?) links to user guide
by GHC 24 Jul '16

24 Jul '16

#12394: broken (obsolete?) links to user guide -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A lot of place (Haskell Wiki, etc., example: bottom of https://wiki.haskell.org/Language_Pragmas) have links like this https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghc- language-features.html which gives 404 now. Is there a systematic way of redirecting this? It seems not, because actual names did change, the correct link should now be https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/lang.html The old name (URL) was just the section heading? Which seemed reasonable. The new one just looks like a file name. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux
by GHC 22 Jul '16

22 Jul '16

#10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux -------------------------------------+------------------------------------- Reporter: aslpavel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we remove current executable or update it with a new one, getExecutablePath returns path with added " (deleted)" suffix. I think it is incorrect behavior , for example if you updated binary and want to exec a new one, the obvious way to go is to call getExecutablePath and use it. Moreover it is inconsistent between platforms. Problem stems from the fact the getExecutablePath is implemented as readlink on /proc/self/exe and it contains gibberish once file has been deleted. Example: {{{#!hs module Main (main) where import System.Environment (getExecutablePath) import System.Directory (removeFile) main :: IO () main = do before <- getExecutablePath putStrLn $ "Before: " ++ before removeFile before after <- getExecutablePath putStrLn $ "After: " ++ after }}} Output: {{{ $ ./getExecutablePath Before: /mnt/data/Maggot/getExecutablePath After: /mnt/data/Maggot/getExecutablePath (deleted) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12393: Poor error message with equational type constraints
by GHC 22 Jul '16

22 Jul '16

#12393: Poor error message with equational type constraints --------------------------------------+--------------------------------- Reporter: laneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- GHCi 8.0.1 is giving a poor error message when it can't derive a typeclass when there's an equational type constraint involved. A simple example: {{{#!hs {-# LANGUAGE TypeFamilies #-} class Foo a where type FooInner a fromInner :: FooInner a -> a newtype Bar = Bar { fromBar::Char } deriving (Show) instance Foo Bar where type FooInner Bar = Char fromInner = Bar myFunc :: (Foo foo, FooInner foo ~ Char) => String -> foo myFunc = fromInner . head }}} Many things work as expected: {{{ ghc> :t myFunc myFunc :: (FooInner foo ~ Char, Foo foo) => String -> foo ghc> :t (myFunc "z") (myFunc "z") :: (FooInner foo ~ Char, Foo foo) => foo ghc> (myFunc "z") :: Bar Bar {fromBar = 'z'} }}} but if I just evaluate the function without the typecast I get an error: {{{ ghc> myFunc "z" <interactive>:486:1: error: • Illegal equational constraint FooInner foo ~ Char (Use GADTs or TypeFamilies to permit this) • When checking the inferred type it :: forall foo. (FooInner foo ~ Char, Foo foo) => foo }}} Now, there should certainly be an error here: GHC doesn't know the exact type of {{{myFunc}}} so it can't check if it's an instance of {{{Show}}}. However, unless I'm not understanding what's going on, the error should be something like "Could not deduce Show", not "Illegal equational constraint". Even if that __is__ what's going on, the suggestion to "Use GADTs or TypeFamilies to permit this" is clearly wrong, as I am already using {{{TypeFamilies}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12375: type synonym to unboxed tuple causes crash
by GHC 21 Jul '16

21 Jul '16

#12375: type synonym to unboxed tuple causes crash -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!haskell {-# LANGUAGE UnboxedTuples #-} module Main where -- type Null = (# #) {-# NOINLINE showNull #-} showNull :: (# #) -> String showNull (# #) = "(# #)" {-# NOINLINE showNullPair #-} showNullPair :: (# (# #), (# #) #) -> String showNullPair (# n1, n2 #) = "(# " ++ showNull n1 ++ ", " ++ showNull n2 ++ "#)" main :: IO () main = do putStrLn (showNullPair (# (# #), (# #) #)) }}} If I use the `Null` type synonym here instead of `(# #)`, I get: {{{ [1 of 1] Compiling Main ( empty.hs, empty.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): unboxed tuple PrimRep Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Tried with: 8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12229: Narrow the scope of record wildcards notation slightly
by GHC 21 Jul '16

21 Jul '16

#12229: Narrow the scope of record wildcards notation slightly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As fallout from #12130 I narrowed the scope of record-wildcard notation slightly. Here's the commit {{{ commit 2f8cd14fe909a377b3e084a4f2ded83a0e6d44dd Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu Jun 23 09:02:00 2016 +0100 Narrow the use of record wildcards slightly In reviewing the fix to Trac #12130 I found the wild-card fill-in code for ".." notation in record constructions hard to understand. It went to great contortions (including the find_tycon code) to allow data T = C { x, y :: Int } f x = C { .. } to expand to f x = C { x = x, y = y } where 'y' is an /imported function/! That seems way over the top for what record wildcards are supposed to do. So I have narrowed the record-wildcard expansion to include only /locally-bound/ variables; i.e. not top level, and certainly not imported. I don't think anyone is using record wildcards in this bizarre way, so I don't expect any fallout. Even if there is, you can easily initialise fields with eponymous but imported values by hand. An intermediate position would be to allow /local/ top-level definitions. But I doubt anyone is doing that either. Let's see if there's any fallout. It's a local change, easy to revert, so I've just gone ahead to save everyone's time. }}} This ticket can be used for any commentary. I've also added a test. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12095: GHC and LLVM don't agree on what to do with byteSwap16#
by GHC 21 Jul '16

21 Jul '16

#12095: GHC and LLVM don't agree on what to do with byteSwap16# -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: codegen, llvm | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this test case (taken from [https://github.com/well-typed/binary- serialise-cbor/issues/67 here] and lightly modified to work on big/little endian machines): {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE CPP #-} module Main ( main -- :: IO () ) where #include "ghcconfig.h" import GHC.Prim import GHC.Word data T = T !Addr# t :: T #ifndef WORDS_BIGENDIAN t = T "\xcf\xb1"# #else t = T "\xb1\xcf"# #endif grabWord16 :: T -> Word64 grabWord16 (T addr#) = W64# (byteSwap16# (indexWord16OffAddr# addr# 0#)) trip :: Int trip = fromIntegral (grabWord16 t) main :: IO () main = print trip }}} With GHC 7.10.3 using the NCG, the results given are correct: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ ghc -Wall -fforce-recomp -O2 Issue67.hs && ./Issue67 [1 of 1] Compiling Main ( Issue67.hs, Issue67.o ) Linking Issue67 ... 53169 }}} This also is the same on GHC 8.0.1 using the NCG, on both PowerPC and AMD64 as well. This answer is correct: `53169` is `0xCFB1` in hex, so the `byteSwap16#` primitive correctly works to decode the swapped-endian number. However, the story is not the same with GHC 7.10.3+LLVM 3.5, or GHC 8.0.1+LLVM 3.7: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ llc --version | head -2 LLVM (http://llvm.org/) LLVM version 3.5.2 $ ghc -Wall -fforce-recomp -O2 Issue67.hs -fllvm && ./Issue67 [1 of 1] Compiling Main ( Issue67.hs, Issue67.o ) Linking Issue67 ... -12367 }}} Note: {{{#!hs -12367 == (fromIntegral (53169 :: Word16) :: Int16) }}} The relevant snippet looks like this at the CMM level (GHC 7.10.3): {{{ ==================== Output Cmm ==================== [section "data" { Main.main2_closure: const Main.main2_info; const 0; const 0; const 0; }, section "readonly" { c3rq_str: I8[] [207,177] }, section "readonly" { c3rr_str: I8[] [207,177] }, Main.main2_entry() // [R1] { info_tbl: [(c3ru, label: Main.main2_info rep:HeapRep static { Thunk }), (c3rD, label: block_c3rD_info rep:StackRep [])] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c3ru: ... c3ro: I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _c3rn::I64; (_c3rw::I64) = call MO_BSwap W16(%MO_UU_Conv_W16_W64(I16[c3rr_str])); I64[Sp - 24] = c3rD; R4 = GHC.Types.[]_closure+1; R3 = _c3rw::I64; R2 = 0; Sp = Sp - 24; call GHC.Show.$wshowSignedInt_info(R4, R3, R2) returns to c3rD, args: 8, res: 8, upd: 24; ... }}} Pre-optimized LLVM basic block: {{{ c3rB: %ln3sc = ptrtoint i8* @stg_bh_upd_frame_info to i64 %ln3sb = load i64** %Sp_Var %ln3sd = getelementptr inbounds i64* %ln3sb, i32 -2 store i64 %ln3sc, i64* %ln3sd, !tbaa !1 %ln3sf = load i64* %lc3rA %ln3se = load i64** %Sp_Var %ln3sg = getelementptr inbounds i64* %ln3se, i32 -1 store i64 %ln3sf, i64* %ln3sg, !tbaa !1 %ln3sh = ptrtoint %c3rE_str_struct* @c3rE_str$def to i64 %ln3si = inttoptr i64 %ln3sh to i16* %ln3sj = load i16* %ln3si, !tbaa !5 %ln3sk = zext i16 %ln3sj to i64 %ln3sl = trunc i64 %ln3sk to i16 %ln3sm = call ccc i16 (i16)* @llvm.bswap.i16( i16 %ln3sl ) %ln3sn = sext i16 %ln3sm to i64 store i64 %ln3sn, i64* %lc3rJ %ln3sp = ptrtoint void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c3rQ_info$def to i64 %ln3so = load i64** %Sp_Var %ln3sq = getelementptr inbounds i64* %ln3so, i32 -3 store i64 %ln3sp, i64* %ln3sq, !tbaa !1 %ln3sr = ptrtoint i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64 %ln3ss = add i64 %ln3sr, 1 store i64 %ln3ss, i64* %R4_Var %ln3st = load i64* %lc3rJ store i64 %ln3st, i64* %R3_Var store i64 0, i64* %R2_Var %ln3su = load i64** %Sp_Var %ln3sv = getelementptr inbounds i64* %ln3su, i32 -3 %ln3sw = ptrtoint i64* %ln3sv to i64 %ln3sx = inttoptr i64 %ln3sw to i64* store i64* %ln3sx, i64** %Sp_Var %ln3sy = bitcast i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* }}} Post-optimized block (`opt --enable-tbaa=true -O2 out-llvm-orig.ll -o out- llvm.bc`): {{{ c3rB: ; preds = %c3rU %ln3s8 = ptrtoint i8* %ln3s7 to i64 %ln3sd = getelementptr inbounds i64* %Sp_Arg, i64 -2 store i64 ptrtoint (i8* @stg_bh_upd_frame_info to i64), i64* %ln3sd, align 8, !tbaa !5 %ln3sg = getelementptr inbounds i64* %Sp_Arg, i64 -1 store i64 %ln3s8, i64* %ln3sg, align 8, !tbaa !5 store i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @"c3rQ_info$def" to i64), i64* %ln3rZ, align 8, !tbaa !5 tail call cc10 void bitcast (i8* @base_GHCziShow_zdwshowSignedInt_info to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)*)(i64* %Base_Arg, i64* %ln3rZ, i64* %Hp_Arg, i64 %R1_Arg, i64 0, i64 -12367, i64 add (i64 ptrtoint (i8* @ghczmprim_GHCziTypes_ZMZN_closure to i64), i64 1), i64 undef, i64 undef, i64 %SpLim_Arg) #0 ret void }}} Folds it right into a constant! I haven't spent time diagnosing this much further, yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12383: ghc: internal error: TSO object entered
by GHC 21 Jul '16

21 Jul '16

#12383: ghc: internal error: TSO object entered -------------------------------------+------------------------------------- Reporter: aufheben | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just ran into this build failure for the first time: {{{ ghc: internal error: TSO object entered! (GHC version 7.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm not sure how to reproduce this bug or obtain more debugging information but this is how it happened: I was working with Yesod and trying to edit a .hamlet template file. When the file was saved Yesod tried to recompile the project and the build failed with that output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12414: Ill-formed or incorrect multiline string in compiler/main/GHC.hs
by GHC 21 Jul '16

21 Jul '16

#12414: Ill-formed or incorrect multiline string in compiler/main/GHC.hs -------------------------------------+------------------------------------- Reporter: ifigueroap | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Dear all, After trying to (indirectly) parse GHC.hs using hothasktags, I kept getting an "Illegal character in string gap" error. After reconstructing the file using cpphs I found that the issue is caused by an incorrect multiline string in the raw (i.e. before cpp includes) GHC.hs, that trips the (perhaps stricter?) parser in haskell-src-exts... The following part of the code: {{{#!hs Nothing -> panic "compileToCoreModule: target FilePath not found in\ module dependency graph" }}} should be {{{#!hs Nothing -> panic "compileToCoreModule: target FilePath not found in\ \module dependency graph" }}} It seems the issue goes back to several other versions of the file. Of course it is not really a big deal, but it was hard to trigger (try to parse the file with haskell-src-exts), and to hunt!! Best regards -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #7662: Improve GC of mutable objects
by GHC 21 Jul '16

21 Jul '16

#7662: Improve GC of mutable objects -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 7.7 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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7662#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0