August 2017 - ghc-tickets

[GHC] #14051: Unboxed sums-related panic: getUnboxedSumName 513
by GHC 25 Aug '17

25 Aug '17

#14051: Unboxed sums-related panic: getUnboxedSumName 513 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally reported [https://www.reddit.com/r/haskell/comments/6q6yau/unboxed_sums_ghc_panic/ here]. You'll need these two files: {{{#!hs -- Testing.hs {-# LANGUAGE UnboxedSums #-} module Testing where func :: s -> (# Bool | Bool #) func _ = (# True | #) }}} {{{#!hs -- Bug.hs {-# LANGUAGE UnboxedSums #-} module Main where import Testing main :: IO () main = print $ func 1 }}} And you must compile them like so (the `-c` and `-O2` flags are important): {{{ $ ghc -O2 -c Testing.hs $ ghc -O2 -c Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): getUnboxedSumName 513 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/prelude/KnownUniques.hs:104:5 in ghc:KnownUniques }}} Reproducible with GHC 8.2.1 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14125: Bogus unacceptable type in foreign declaration.
by GHC 25 Aug '17

25 Aug '17

#14125: Bogus unacceptable type in foreign declaration. -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I'm try to abstract FFI return type so that different errno scheme can work together, namely i create such a class: {{{ class Integral (IOErrno r) => IOReturn r where -- | The errno type associated with 'r' data IOErrno r :: * -- | Is this return value indicate an error? isError :: Integral a => r a -> Bool -- | How can i get a errno then? getErrno :: Integral a => r a -> IO (IOErrno r) -- | Is this errno indicate interrupted blocking call? isInterrupt :: IOErrno r -> Bool -- | Is this errno indicate no data on a non-blocking device? isBlock :: IOErrno r -> Bool -- | OK, i want my return value if no errno. getReturn :: Integral a => r a -> a -- | Read the errno name for me. nameErrno :: IOErrno r -> IO String -- | Read the errno description for me. descErrno :: IOErrno r -> IO String }}} But when i'm try to defining instance for it, such as a standard unix like: {{{ newtype UnixReturn a = UnixReturn a deriving (Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, Show, FiniteBits, Bits, Storable) instance IOReturn UnixReturn where newtype IOErrno UnixReturn = UnixErrno CInt deriving (Bounded, Enum, Eq, Integral, Num, Ord, Read, Real, Show, FiniteBits, Bits, Storable) isError (UnixReturn r) = r == (-1) isInterrupt e = e == eINTR isBlock e = e == eAGAIN || e == eWOULDBLOCK getErrno _ = get_errno getReturn (UnixReturn r) = r nameErrno = return . nameUnixErrno descErrno e = strerror e >>= peekCString eINTR = UnixErrno (CONST_EINTR) eWOULDBLOCK = UnixErrno (CONST_EWOULDBLOCK) ... foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) }}} I got a error on GHC 8.2: {{{ System/IO/Exception.hs:282:1: error: • Unacceptable argument type in foreign declaration: ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call • When checking declaration: foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString | 282 | foreign import ccall unsafe "string.h" strerror :: IOErrno UnixReturn -> IO CString | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/IO/Exception.hs:283:1: error: • Unacceptable result type in foreign declaration: ‘IOErrno UnixReturn’ cannot be marshalled in a foreign call • When checking declaration: foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) | 283 | foreign import ccall unsafe "HsBase.h __hscore_get_errno" get_errno :: IO (IOErrno UnixReturn) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} And at every place i want mark my FFI return got this error too. e.g. following code compiles without problem on GHC < 8.2 (Note that the type and constructor are both available): {{{ foreign import CALLCONV unsafe "HsNet.h recv" c_recv :: CInt -> Ptr Word8 -> CSize -> CInt -> IO (UnixReturn CSsize) }}} But on GHC 8.2 a `Unacceptable result type in foreign declaration` is emitted. And I think it's a regression. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14125> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14082: -ddump-json does not escape output properly
by GHC 25 Aug '17

25 Aug '17

#14082: -ddump-json does not escape output properly -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- == Steps to reproduce This program {{{#!hs module StringError where q = "string" + "string" }}} Compiled with `-ddump-json`, produces this JSON output: {{{ [ {"span": {"file": "tmp.hs","startLine": 3,"startCol": 5,"endLine": 3,"endCol": 24},"doc": "\u2022 No instance for (Num [Char]) arising f rom a use of \u2018+\u2019\n\u2022 In the expression: "string" + "string"\n In an equation for \u2018q\u2019: q = "string" + "string""," severity": "SevError","reason": null}] }}} It is not valid JSON, because `"string"` occured in a JSON string, but the quotes are not escaped. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14022: base and ghc-prim should depend upon libm
by GHC 25 Aug '17

25 Aug '17

#14022: base and ghc-prim should depend upon libm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Both `base` and `ghc-prim` have references to symbols provided by `libm`. This dependency should be manifest in their respective cabal files. It seems that some `ld.gold` versions are strict about this. See https://github.com/NixOS/nixpkgs/pull/27584. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor
by GHC 25 Aug '17

25 Aug '17

#13947: GHC 8.2 gives misleading error message for out-of-scope infix type constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeOperators #-} module Bug where f :: () -> Int :~: Int f = undefined }}} GHC 8.0.2 gives a reasonable error message: {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:12: error: Not in scope: type constructor or class ‘:~:’ }}} But GHC 8.2.1's error message is much more confusing: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:6: error: Precedence parsing error cannot mix ‘(->)’ [infixr 0] and ‘:~:’ [infixl 0] in the same infix expression | 4 | f :: () -> Int :~: Int | ^^^^^^^^^^^^^^^^^ Bug.hs:4:12: error: Not in scope: type constructor or class ‘:~:’ A data constructor of that name is in scope; did you mean DataKinds? | 4 | f :: () -> Int :~: Int | ^^^^^^^^^^^ }}} I was thrown akilter by the claim that `:~:` was `infixl 0`, since it was displayed before the real cause of the error (that it's out-of-scope). Adding `import Data.Type.Equality` fixes the error, but GHC really shouldn't be making claims about the fixities of out-of-scope type constructors in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14081: 8.2.1 runghc from Windows x32 segfaults an all programs
by GHC 25 Aug '17

25 Aug '17

#14081: 8.2.1 runghc from Windows x32 segfaults an all programs --------------------------------+---------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------- I'd like to report pretty severe issue with `runghc` executable from latest `8.2.1` release. Namely, `runghc` does not work at all on x32 Windows - it produces segmentation faults even on hello world program {{{ $ cat HW.hs module HW (main) where main :: IO () main = do putStrLn "Hello, world" $ runghc HW.hs Access violation in generated code when reading 77dbffff }}} I managed to reproduce this issue on 3 mildly different hosts already - two of them were running `Windows 7` and the third one was `Windows Server 2008` or `2012` (I forgot which but can look it up if it's crucial). In all 3 cases I used ghc from `https://downloads.haskell.org/~ghc/8.2.1/ghc-8.2.1-i386-unknown- mingw32.tar.xz`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #14079: Failure to do CPR in the presence of a local letrec
by GHC 25 Aug '17

25 Aug '17

#14079: Failure to do CPR in the presence of a local letrec -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code: {{{ {-# LANGUAGE BangPatterns #-} module NoCPR (e) where e :: (Int, Int) -> Int -> Int -> (Int, Int) e x y n = je x y where je !x y | y > 0 = x | otherwise = je x (y + n) }}} (which is adapted from #5949). We get this Core: {{{ -- RHS size: {terms: 38, types: 27, coercions: 0, joins: 1/1} e :: (Int, Int) -> Int -> Int -> (Int, Int) [GblId, Arity=3, Caf=NoCafRefs, Str=<S,1*U(U,U)><S(S),1*U(U)><L,U(U)>m, Unf=OtherCon []] e = \ (x [Occ=Once!] :: (Int, Int)) (y [Occ=Once!] :: Int) (n [Occ=OnceL!] :: Int) -> case x of { (ww1 [Occ=Once], ww2 [Occ=Once]) -> case y of { I# ww4 [Occ=Once] -> joinrec { $wje [InlPrag=[0], Occ=LoopBreakerT[3]] :: Int -> Int -> Int# -> (Int, Int) [LclId[JoinId(3)], Arity=3, Str=<L,U><L,U><S,U>m, Unf=OtherCon []] $wje (ww5 [Occ=Once*] :: Int) (ww6 [Occ=Once*] :: Int) (ww7 :: Int#) = case ># ww7 0# of { __DEFAULT -> case n of { I# y1 [Occ=Once] -> case +# ww7 y1 of sat { __DEFAULT -> jump $wje ww5 ww6 sat } }; 1# -> (ww5, ww6) }; } in jump $wje ww1 ww2 ww4 } } }}} Why is there no CPR happening for `e`? In fact, why is there no unboxing happening – it was for the following similar code: {{{ e :: (Int, Int) -> Int -> (Int, Int) e x y = x `seq` if y > 10 then x else e x (y + 1) }}} (This is a spin-off of the dicussion at https://phabricator.haskell.org/D3811#107708) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #1460: Problem with Monoid instance of Data.Map
by GHC 25 Aug '17

25 Aug '17

#1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I absolutely agree that making the change in a way that silently introduces errors would be bad. That's why my proposal was to remove the instance first and then replace it later. With a major-version bump, the `Monoid` instance would be removed entirely. Then, everything depending on in would fail loudly. There would be no `Monoid` instance at all for probably 18-24 months. Let's say that it was `containers-0.6.0` that removed the instance. Eventually, stackage, nixpkgs, and the Haskell Platform would all pick up `containers-0.6.0` and put some pressure of their users to stop using the `Monoid` instance for `Map`. Then, after everyone's code was updated, the next release could introduce the new instance. Most of the breakage would be really easy to fix. Additionally, it should all be compile-time failures. The only silent breakage that could happen would be if someone didn't update their dependencies for two years and then tried to switch straight from the old `containers` to the newest one. I suspect this situation would be uncommon (although, as someone would is primarily an application developer, I certainly cannot speak for everyone on this, and I may be wrong about this, which would destroy my argument for this approach). So basically, I just wanted to clarify that while there would be breakage, none of it would be silent. Obviously, this still has to be weighed, but I think it's much less bad than the undetectable semantic changes you describe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 25 Aug '17

25 Aug '17

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nad): I managed to make the test case a bit smaller: {{{ $ cat Main.hs import System.Exit main = exitSuccess $ ghc --make -prof Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main +RTS -hb Main: internal error: Invalid object in processHeapClosureForDead(): 7 (GHC version 8.2.1 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb
by GHC 25 Aug '17

25 Aug '17

#7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: profiling osx Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #9640 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nad): I managed to trigger this bug using Agda version 2.6.0-439fe3e, built using GHC 8.2.1 with profiling enabled and `-fprof-auto`: {{{ $ agda_p --version +RTS -hb Agda version 2.6.0-439fe3e agda_p: internal error: Invalid object in processHeapClosureForDead(): 7 (GHC version 8.2.1 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7836#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0