February 2019 - ghc-tickets

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 11 Feb '19

11 Feb '19

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ahri): I've opened a ticket on the Clang bugtracker: https://bugs.llvm.org/show_bug.cgi?id=40689 I wonder if GHC should simply allow leading whitespace as "sh" seems happy enough to accept a file in this form. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 11 Feb '19

11 Feb '19

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ahri): Still broken on OSX - works fine on Linux and Win32 (64). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16302: A non-function coerced to a function can cause a stg_ap_pp_ret
by GHC 11 Feb '19

11 Feb '19

#16302: A non-function coerced to a function can cause a stg_ap_pp_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you create an function by unsafe coercing a non-function you can get some strange functions. If you then take one of these function and apply it something it crashes with a {{{stg_ap_pp_ret}}}. Here is a pretty minimal example. {{{ import Unsafe.Coerce main=(unsafeCoerce()::a->IO())1 }}} You can reproduce it online here: https://tio.run/##y0gszk7Nyfn/PzO3IL@oRCE0rzgxLVXPOT@1KDmVKzcxM89WoxQsBhHS0… Here is another one: {{{ import Unsafe.Coerce g=unsafeCoerce()::a->a main=print$g(g)1 }}} If you coerce functions this doesn't appear to happen. For example: {{{ import Unsafe.Coerce main=(unsafeCoerce id::a->IO())1 }}} is a fine program. Sometimes this causes a segmentation fault (particularly with higher airity functions): {{{ import Unsafe.Coerce main=(unsafeCoerce(+)::a->IO())1 }}} but I've never gotten it to make a {{{stg_ap_pp_ret}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16289: GHC thinks pattern match is exhaustive
by GHC 10 Feb '19

10 Feb '19

#16289: GHC thinks pattern match is exhaustive -------------------------------------+------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- {{{ {-# OPTIONS_GHC -Werror #-} module Lib where data Value = Finite Integer | Infinity deriving (Eq) instance Num Value where (+) = undefined (*) = undefined abs = undefined signum = undefined negate = undefined fromInteger = Finite isSpecial :: Value -> Bool isSpecial Infinity = True isSpecial 0 = True isSpecial 1 = True isSpecial _ = False }}} {{{ > ghc Lib.hs [1 of 1] Compiling Lib ( Lib.hs, Lib.o ) Lib.hs:19:1: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for ‘isSpecial’: isSpecial 1 = ... | 19 | isSpecial 1 = True | ^^^^^^^^^^^^^^^^^^^^^^^^^ Lib.hs:20:1: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for ‘isSpecial’: isSpecial _ = ... | 20 | isSpecial _ = False | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #16301: Additions to Control.Exception: withException, displaySomeExceptionType
by GHC 10 Feb '19

10 Feb '19

#16301: Additions to Control.Exception: withException, displaySomeExceptionType -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 libraries/base | 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: -------------------------------------+------------------------------------- Requires RankNTypes though. {{{#!haskell -- | Apply a function to whatever @Exception@ type is inside a -- @SomeException@. withException :: forall r. (forall e. Exception e => e -> r) -> SomeException -> r withException f (SomeException e) = f e -- | Use 'withException' to obtain the exception's type name. displaySomeExceptionType :: SomeException -> String displaySomeExceptionType = withException (show . typeOf) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16298: Awful(?) code in AArch64 stg_BLACKHOLE entry code
by GHC 10 Feb '19

10 Feb '19

#16298: Awful(?) code in AArch64 stg_BLACKHOLE entry code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's been a while since I've look at ARM assembler but this doesn't look right: {{{ Dump of assembler code for function stg_BLACKHOLE_info$def: 0x0000ffffb66d6118 <+0>: mov x23, x22 0x0000ffffb66d611c <+4>: ldr x22, [x22, #8] 0x0000ffffb66d6120 <+8>: tst x22, #0x7 0x0000ffffb66d6124 <+12>: b.ne 0xffffb66d6224 <stg_BLACKHOLE_info$def+268> // b.any 0x0000ffffb66d6128 <+16>: adrp x25, 0xffffb66fb000 0x0000ffffb66d612c <+20>: adrp x26, 0xffffb66fb000 0x0000ffffb66d6130 <+24>: adrp x27, 0xffffb66fb000 0x0000ffffb66d6134 <+28>: adrp x29, 0xffffb66fb000 0x0000ffffb66d6138 <+32>: ldr x25, [x25, #3880] 0x0000ffffb66d613c <+36>: ldr x26, [x26, #3888] 0x0000ffffb66d6140 <+40>: ldr x27, [x27, #3896] 0x0000ffffb66d6144 <+44>: ldr x29, [x29, #3904] 0x0000ffffb66d6148 <+48>: sub x24, x19, #0x18 0x0000ffffb66d614c <+52>: ldr x8, [x22] 0x0000ffffb66d6150 <+56>: cmp x8, x25 ... }}} Why do we `adrp` four times? Couldn't this be reused, with each `ldr` result going to a separate register? This was generated by LLVM 7. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

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

10 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