September 2018 - ghc-tickets

[GHC] #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just
by GHC 14 Feb '19

14 Feb '19

#10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just -----------------------------------+--------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------------- On 32-bit Red Hat Enterprise Linux 6.5, released on 11/11/2014 (available on [https://aws.amazon.com/marketplace/pp/B007NMF9O0/ Amazon EC2]), building `attoparsec-0.12.1.2` with GHC 7.8.4 causes a panic: {{{ Configuring attoparsec-0.12.1.2... Building attoparsec-0.12.1.2... Preprocessing library attoparsec-0.12.1.2... [ 1 of 21] Compiling Data.Attoparsec.Text.FastSet ( Data/Attoparsec/Text/FastSet.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/FastSet.o ) [ 2 of 21] Compiling Data.Attoparsec.Text.Buffer ( Data/Attoparsec/Text/Buffer.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/Buffer.o ) [ 3 of 21] Compiling Data.Attoparsec.Internal.Fhthagn ( Data/Attoparsec/Internal/Fhthagn.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal/Fhthagn.o ) [ 4 of 21] Compiling Data.Attoparsec.ByteString.Buffer ( Data/Attoparsec/ByteString/Buffer.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/Buffer.o ) [ 5 of 21] Compiling Data.Attoparsec.Zepto ( Data/Attoparsec/Zepto.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Zepto.o ) [ 6 of 21] Compiling Data.Attoparsec.Number ( Data/Attoparsec/Number.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Number.o ) [ 7 of 21] Compiling Data.Attoparsec.ByteString.FastSet ( Data/Attoparsec/ByteString/FastSet.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/FastSet.o ) [ 8 of 21] Compiling Data.Attoparsec.Internal.Types ( Data/Attoparsec/Internal/Types.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal/Types.o ) [ 9 of 21] Compiling Data.Attoparsec.Types ( Data/Attoparsec/Types.hs, dist/dist-sandbox-a9165fb6/build/Data/Attoparsec/Types.o ) [10 of 21] Compiling Data.Attoparsec.Internal ( Data/Attoparsec/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Internal.o ) [11 of 21] Compiling Data.Attoparsec.Combinator ( Data/Attoparsec/Combinator.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Combinator.o ) [12 of 21] Compiling Data.Attoparsec.ByteString.Internal ( Data/Attoparsec/ByteString/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/ByteString/Internal.o ) [13 of 21] Compiling Data.Attoparsec.Text.Internal ( Data/Attoparsec/Text/Internal.hs, dist/dist-sandbox- a9165fb6/build/Data/Attoparsec/Text/Internal.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for i386-unknown-linux): compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs:84:13-59: Irrefutable pattern failed for pattern Data.Maybe.Just live_set }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found
by GHC 14 Feb '19

14 Feb '19

#9277: GHCi panic: Loading temp shared object failed: Symbol not found ----------------------------------+--------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9034, #8935 | ----------------------------------+--------------------------------- When given a Objective-C object file referencing a symbol available in a system framework, GHCi panics saying it can't find the symbol the object file relies on. {{{ $ cat >foo.m <<EOF #import <Foundation/Foundation.h> BOOL is_main_thread() { return [NSThread isMainThread]; } EOF }}} {{{ $ clang -c -o foo.o foo.m }}} {{{ $ ghci -v -framework Foundation foo.o GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3 Using binary package database: /opt/ghc-7.8.2/lib/ghc-7.8.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99 wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. *** gcc: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 --print-file-name libiconv.dylib Loading package base ... linking ... done. Loading object (static) foo.o ... Created temporary directory: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0 *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -dynamiclib -o /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib foo.o -undefined dynamic_lookup -single_module -install_name '@rpath/ghc36377_1.dylib' -L/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/base-4.7.0.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -Wl,-rpath -Wl,/opt/ghc-7.8.2/lib/ghc-7.8.2/rts-1.0 -lHSbase-4.7.0.0-ghc7.8.2 -lHSinteger-gmp-0.5.1.0-ghc7.8.2 -lHSghc-prim-0.3.1.0-ghc7.8.2 -liconv *** Deleting temp files: Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib *** Deleting temp dirs: Deleting: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0 ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib, 9): Symbol not found: _OBJC_CLASS_$_NSThread Referenced from: /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib Expected in: flat namespace in /var/folders/26/0tzj1txn0vb_0061l4z4rsmr0000gn/T/ghc36377_0/ghc36377_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Note omitting `-framework Foundation` makes no difference to the output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13595: Should ‘coerce’ be levity polymorphic?
by GHC 14 Feb '19

14 Feb '19

#13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #13592 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not able to write `coerce @Int# @Int#` or `coerce :: Double# -> Double#`, just checking to see if its intentional or not {{{ >>> :set -XTypeApplications >>> :set -XMagicHash >>> import Data.Coerce >>> import GHC.Exts >>>> :t coerce @Int coerce @Int :: Coercible b Int => Int -> b >>> :t coerce @Int# <interactive>:1:1: error: Couldn't match a lifted type with an unlifted type When matching types b :: * Int# :: TYPE 'IntRep <interactive>:1:9: error: • Expecting a lifted type, but ‘Int#’ is unlifted • In the type ‘Int#’ In the expression: coerce @Int# }}} This was needed for #13592. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15219: Implement UnliftedNewtypes proposal
by GHC 14 Feb '19

14 Feb '19

#15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple UnliftedNewtypes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The unlifted newtypes proposal is described here: https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst I am going to be working on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed`
by GHC 11 Feb '19

11 Feb '19

#15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: base, | Operating System: Unknown/Multiple Data.Fixed | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello; I'm creating this email to propose a change to `Data.Fixed`. Full credit for this idea goes to Bhavik Mehta (@b-mehta on GitHub), who implemented it in this [https://github.com/dmcclean/exact-pi/pull/8 PR] for `exact- pi`. In `Data.Fixed` there are several `E`-prefixed datatypes used to represent a certain number of digits of precision in fixed-precision arithmetic. For example, `E1` has 1 decimal place, `E12` has 12. Each of them, `E{0,1,2,3,6,9,12}` is hardcoded. If more precision types are to be provided, they have to be hardcoded as well, and all of these types resemble each other. I think there is room for improvement here. Instead of having {{{#!hs data E0 instance HasResolution E0 where resolution _ = 1 }}} and repeating it as many times as there are `E` datatypes, I propose to add the following type: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} import GHC.TypeLits (Nat, KnownNat, natVal) data E (n :: Nat) }}} and then do {{{#!hs instance KnownNat n => HasResolution (E n) where resolution _ = 10^natVal (undefined :: E n) }}} just once, replacing `data E0` with `type E0 = E 0` (and the same for the rest of them) to continue reexporting these types. `E` should also be exported. I've sent an email to the Core Libraries Committee regarding this issue. This is my first contribution to GHC, if I'm doing something incorrectly please tell me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #14848: -XDuplicateRecordFields breaks record expression splices
by GHC 10 Feb '19

10 Feb '19

#14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# language TemplateHaskell #-} {-# language DuplicateRecordFields #-} module Lib where import Language.Haskell.TH import Language.Haskell.TH.Syntax data A = A {x :: Int, y :: String} a = A 3 "test" test = $([e|case a of A {x = b} -> b|]) }}} Without `DuplicateRecordFields` it compiles correctly so `test = 3` but with `DuplicateRecordFields` enabled it gives: {{{ • Illegal variable name: ‘$sel:x:A’ When splicing a TH expression: case Lib.a of (Lib.A {Lib.$sel:x:A = b_0}) -> b_0 • In the untyped splice: $([| case a of { A {x = b} -> b } |]) }}} Additionally, there doesn't seem to be a workaround for munging the name manually, since the `$sel:x:A` name is the one actually in scope, there is no `A.x` like there would be normally, even when the label is not a duplicate. Is there a way to get around this? Ex: by changing the binding name somehow manually? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15091: Better occurrence analysis for join points
by GHC 10 Feb '19

10 Feb '19

#15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 {{{ let x = ... in join j y = x+y in case v of A -> x B -> j 1 C -> j 2 D -> 3 }}} What does `OccAnal` say about `x`'s usage? It says `ManyOccs`! But it's plain as a pikestaff that `x` is used at most once: * Either in the `A` branch, * or in the `B` or `C` branches via `j`. If instead we had inlined `j` we'd have {{{ let x = ... in join j y = x+y in case v of A -> x B -> x + 1 C -> x + 2 D -> 3 }}} and now it's all more obvious: `x`'s occurrence info should be `OneOcc { occ_one_br = False }`, not `ManyOccs`. Does this matter? Not a great deal, but there is a reason for having `OneOcc` with `occ_one_br = False`, and it seems a shame not to take advantage. One case in point is the definition of `SimplUtils.isExitJoinId {{{ isExitJoinId :: Var -> Bool isExitJoinId id = isJoinId id && isOneOcc (idOccInfo id) && occ_in_lam (idOccInfo id) }}} Something does not cease to be an exit-join-point if it is mentioned in multiple places as above. Another use for this info is `postInlineUnconditionally`. Could we improve this situation? I think it'd be quite easy. For non- recursive join points `j = rhs` * Gather occurrence info from the RHS * Bind `j` to its occurrence info * Unleash that occurrence info at each jump-site for `j`, just as if it had been inlined. See Trac #14152, comment:40. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1
by GHC 09 Feb '19

09 Feb '19

#15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC releases 8.2.1 through 8.4.3 exhibit various crashes when invoked with '-jn' where n > 1. GHCHQ's binary releases have this behavior, as well as GHCs I've cross-built on my own. In order to reproduce this issue there must be some parallelism in the module dependency graph; I've attached a test package for easily reproducing this. Use of deriving in the test modules isn't necessary to trigger this; it merely gives the compiler some work to do. The 'hscolour' package also triggers this issue reliably. To trigger the bad behavior, simply run: ghc --make -jn Main.hs -o test with n > 1 in the test-package. Running this repeatedly (removing .hi and .o files in between runs, of course), I've observed these outcomes with varying frequencies: - Segmentation fault. - Bus fault. - Compiler process sleeps indefinitely. - {{{ <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for aarch64-unknown-linux): Binary.UserData: no put_binding_name }}} - {{{ ghc: internal error: MUT_VAR_CLEAN object entered! (GHC version 8.4.3 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} - And most strangely: {{{ A.hs:3:1: error: • Kind signature on data type declaration has non-* return kind * • In the data declaration for ‘A’ | 3 | data A = A | ^^^^^^^^^^... }}} I have not noticed issues with any other concurrent Haskell programs on aarch64. I'm using the NVIDIA Jetson TX2 for these tests. I have not yet tried GHC 8.0.x, 8.6.x, or HEAD. I'm having trouble reproducing this in GDB; I'll report back when I've got that working. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15449> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270
by GHC 09 Feb '19

09 Feb '19

#12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 --------------------------------+--------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------------- This happened when building http-link-header. {{{ ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8 (GHC version 7.10.3 for powerpc_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Sometimes it segfaults instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15336: ./System/IO.hs accidentally overridden when running ghci
by GHC 08 Feb '19

08 Feb '19

#15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior. {{{ % mkdir System % touch System/IO.hs % ghci GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help <interactive>:1:19: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:43: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. <interactive>:1:60: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:99: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:123: error: Not in scope: ‘System.IO.stdout’ No module named ‘System.IO’ is imported. <interactive>:1:140: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:179: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:203: error: Not in scope: ‘System.IO.stderr’ No module named ‘System.IO’ is imported. <interactive>:1:220: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7