August 2015 - ghc-tickets

[GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global"
by GHC 21 Sep '15

21 Sep '15

#10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ /usr/bin/opt: /tmp/ghc27119_0/ghc27119_272.ll:21159722:1: error: redefinition of global named '@c17Kd9_info' @c17Kd9_info = alias internal i8* bitcast (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c17Kd9_info$def to i8*) ^ <no location info>: ghc: phase `LLVM Optimiser' failed (exitcode = 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10459: -fsimple-tick-factor required
by GHC 21 Sep '15

21 Sep '15

#10459: -fsimple-tick-factor required -------------------------------------+------------------------------------- Reporter: mikehat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: fsimple- | Operating System: Linux tick-factor | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:Foreign.Storable.$fStorableWord8_$cpokeByteOff{v rsA} [gid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 10400 }}} -fsimple-tick-factor=115 was required See the 'css' branch of https://github.com/mikehat/blaze-markup.git -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10539: ghc internal error compiling simple template haskell + lens program
by GHC 21 Sep '15

21 Sep '15

#10539: ghc internal error compiling simple template haskell + lens program -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: lens | Operating System: Linux template-haskell | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following happens when compiling a piece of Haskell code with GHC 7.10.1 (code at the bottom of this report). Compilation is successful with GHC 7.8.4 -- both using lens-4.11, which makes this seem like a TH issue. {{{#!sh Building language-arithmetic-0.1.0.0... Preprocessing library language-arithmetic-0.1.0.0... [1 of 2] Compiling Language.Arithmetic.Syntax ( src/Language/Arithmetic/Syntax.hs, dist/build/Language/Arithmetic/Syntax.o ) ghc: internal error: stg_ap_v_ret (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} {{{#!hs module Language.Arithmetic.Syntax where import Control.Applicative hiding (Const) import Control.Lens hiding (Const) import Control.Lens.Plated import Prelude hiding (const) import Data.Data data Arith a b c = Plus { _left :: (Arith a b c), _right :: (Arith a b c) } | Minus { _left :: (Arith a b c), _right :: (Arith a b c) } | Times { _left :: (Arith a b c), _right :: (Arith a b c) } | Divide { _left :: (Arith a b c), _right :: (Arith a b c) } | Modulo { _left :: (Arith a b c), _right :: (Arith a b c) } | Parens { _subexp :: (Arith a b c) } | FunCall{ _name :: String, _subexp :: (Arith a b c) } | Const { _const :: a} | Var { _var :: b } | Embed { _embed :: c } deriving (Show, Eq, Ord, Data, Typeable) makeLenses ''Arith instance Plated (Arith a b c) where plate = uniplate }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10811: Template Haskell does associated types poorly (printing & quoting)
by GHC 21 Sep '15

21 Sep '15

#10811: Template Haskell does associated types poorly (printing & quoting) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices -dsuppress-uniques #-} module Bug where $([d| class C a where type F a type F a = a |]) }}} I get {{{ [d| class C a where type family F a F a = a |] ======> Bug.hs:6:7: Warning: Cannot desugar this Template Haskell declaration: class C a where type family F a F a = a }}} There are two problems here: 1. This really should work. 2. The pretty-printer here omits the `type` on the default definition for `F`. (The word `family` is optional there, but isn't actually wrong.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac/haskell-prime
by GHC 18 Sep '15

18 Sep '15

#10580: rejected emails for Trac registrations from https://ghc.haskell.org/trac /haskell-prime -------------------------------------+------------------------------------- Reporter: imz | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I can't receive the confirmation email for my registration as i_m_z_ (with email address imz at altlinux.org) from https://ghc.haskell.org/trac /haskell-prime . The reason apparently is the one that often comes up with automatically sent confirmation email from such site, and has been described at http://en.altlinux.org/Non- delivery_of_email_sent_by_automated_services_to_altlinux.org : your server doesn't pass "sender-callback-verification" Please make your service better and make possible for more people to receive their confirmation messages needed to complete their registration -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!)
by GHC 18 Sep '15

18 Sep '15

#8423: contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) -------------------------------------------+------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- attached is an example where the type checker isn't "computing" in the closed type families, or at least doing a one step reduction. this makes sense, given that type families only compute when instantiated... But if we could partially evaluate closed type families (or at least do a one step reduction), the attached example code would type check! interestingly, depending on what order the cases for the PSum are written, the type error changes! I guess I want an "eager matching" closed type family, that when partially instantiated will patch on the first pattern it satisfies, to complement ordered type families. attached is a toy example where I otherwise need an unsafeCoerce to make things type check -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9516: unsafeUnmask unmasks even inside uninterruptibleMask
by GHC 18 Sep '15

18 Sep '15

#9516: unsafeUnmask unmasks even inside uninterruptibleMask -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Control.Exception exports {{{#!hs allowInterrupt :: IO () allowInterrupt = unsafeUnmask $ return () }}} with documentation: ''When invoked inside `mask`, this function allows a blocked asynchronous exception to be raised, if one exists. It is equivalent to performing an interruptible operation, but does not involve any actual blocking. When called outside `mask`, or inside `uninterruptibleMask`, this function has no effect.'' However, this is not actually true: `unsafeUnmask` unmasks exceptions even inside `uninterruptibleUnmask`, as the attached test demonstrates (the test uses a foreign call just to have something non-interruptible but still observable; in particular, doing a `print` ''is'' interruptible because it uses an `MVar` under the hood). I think it is possible to define a better `unsafeUnmask` in user-land: {{{#!hs interruptible :: IO a -> IO a interruptible act = do st <- getMaskingState case st of Unmasked -> act MaskedInterruptible -> unsafeUnmask act MaskedUninterruptible -> act }}} but it still seems to be that we should either (i) change the behaviour of unsafeUnmask, or (ii) provide a version of `unsafeUnmask` with the behaviour as described and then change `allowInterrupt` to use that new version of `unsafeUnmask`, or at the very least (iii) change the documentation. (One question with the above definition of `interruptible` is what happens when we ''nest'' `mask` and `uninterruptibleMask`?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8707: Kind inference fails in data instance definition
by GHC 18 Sep '15

18 Sep '15

#8707: Kind inference fails in data instance definition ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | 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: | ------------------------------------+------------------------------------- Consider the following shenanigans: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs #-} data family SingDF (a :: (k, k2 -> *)) data Ctor :: k -> * data instance SingDF (a :: (Bool, Bool -> *)) where SFalse :: SingDF '(False, Ctor) }}} HEAD reports (with `-fprint-explicit-kinds`) {{{ Data constructor ‛SFalse’ returns type ‛SingDF Bool k '('False, Ctor k)’ instead of an instance of its parent type ‛SingDF Bool Bool a’ In the definition of data constructor ‛SFalse’ In the data instance declaration for ‛SingDF’ }}} I see two problems here: 1) Kind inference should fix the problem. If I add a kind annotation to `Ctor`, the code works. GHC should be able to infer this kind annotation for me. 2) The error message is not particularly helpful. GHC 7.6.3 had a more verbose, but more helpful message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9912: Allow access to full logs in Harbormaster builds
by GHC 17 Sep '15

17 Sep '15

#9912: Allow access to full logs in Harbormaster builds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Harbormaster helpfully tries building every commit and every differential revision. However, when it fails, we only get the tail of the output, with no way to get more information. A case in point is [https://phabricator.haskell.org/harbormaster/build/2736/ this build], where a performance test case failed with `[stat too good]`. In this particular case, the commit is intended to be an optimization, so this failure is not terribly unexpected. I wanted to update `all.T` with the new figure, but I couldn't get the figure that Harbormaster's configuration had. Instead, I had to run the test on my machine (a Mac), get a different number, and hope that Harbormaster's configuration fell within 5% of mine. It did, in this case, but might not next time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9976: Ignore newlines in code diffs on Phab
by GHC 17 Sep '15

17 Sep '15

#9976: Ignore newlines in code diffs on Phab -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.4 Component: Trac & Git | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Doing code reviews in Phab is great. However, the way that the lint feature works encourages patchers to split lines as they means that more attention is drawn to split lines than perhaps should be. As a concrete example, I'm reading Phab:D538 this morning, and looking at line 402 of !DsArrows. Alan has added a new field to a data structure and needed to insert a `_` to make the code remain well typed... but this forced a line split to avoid a lint error. Now, I have to check if there are any changes in the second half of the line manually, because the character-diff highlighting fails after the line split. Is there a way to improve this behavior? I can think of two approaches: * (Better option) Teach the character-diff highlighting feature to look across linebreaks. * (Worse option) Encourage patchers ''not'' to make new line breaks until their final commit. Suppress lint problems about line breaks by request. This is, of course, minor, but it would certainly be nice! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1