December 2016 - ghc-tickets

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 13 Dec '16

13 Dec '16

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8248: GHCi should not warn if group writable
by GHC 13 Dec '16

13 Dec '16

#8248: GHCi should not warn if group writable ----------------------------+---------------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Any number of Linux distros support the idea of user groups, whereby when a new user is created there is also simultaneously a group created with the same name; ie, instead of {{{ -rw-r--r--. 1 andrew users 19 Sep 5 08:29 ghci.conf }}} as us old traditionalists would have it, you get {{{ -rw-rw-r--. 1 andrew andrew 19 Sep 5 08:29 ghci.conf }}} because the umask in such cases is 0002 instead of 0022. There is entirely nothing unusual or incorrect about this approach, and it is followed, for example, in the Fedora family of distros. GHC, however, is being a bit silly in emitting the following: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. *** WARNING: /home/andrew/.ghc/ghci.conf is writable by someone else, IGNORING! Prelude> }}} Foremost the fact that the file is group writable is not a problem and the user's choice, //particularly// in this case because it's group writable in the user's group! Regardless of that, GHCi should not be ignoring files with other than 0644 permissions; this isn't `.ssh/`. Can this check and attendant behaviour be removed? AfC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #12955: Confusing error (module is not loaded) when more hsigs provided than -instantiated-with
by GHC 13 Dec '16

13 Dec '16

#12955: Confusing error (module is not loaded) when more hsigs provided than -instantiated-with -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: backpack | 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: 1. Create an `A.hsig` file with `signature A where` 2. Try to build it with `ghc --make A.hsig` Expected: Some error indicating an unexpected signature (you need to specify `-instantiated-with` Actual: This error: {{{ [1 of 1] Compiling A[sig] (.hsig -> .o) attempting to use module ‘main:A’ (A.hsig) which is not loaded }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function
by GHC 12 Dec '16

12 Dec '16

#12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: feature | Status: new request | 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: #12962 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Feature request: give `-fexpose-all-unfoldings` the same semantics as `INLINABLE` on each function. For simplicity, for the principle of least surprise and for usability of `-fexpose-all-unfoldings`, so that it can actually replace tons of `INLINABLE` that are needed, e.g., for code with lots of abstract class constraints to force it to specialize to the single class that is actually used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12942: Add infix flag for class and data declarations
by GHC 12 Dec '16

12 Dec '16

#12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: #3384 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment, data and type declarations using infix formatting produce the same AST as those using prefix. So {{{#!hs type a ++ b = c }}} and {{{#!hs type (++) a b = c }}} cannot be distinguished in the parsed source, without looking at the `OccName` details of the constructor being defined. Having access to the `OccName` requires an additional constraint which explodes out over the entire AST because of its recursive definitions. In keeping with moving the parsed source to more directly reflect the source code as parsed, add a specific flag to the declaration to indicate the fixity, as used in a `Match` now too. Note: this flag is to capture the fixity used for the lexical definition of the type, primarily for use by `ppr` and `ghc-exactprint`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12942> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12936: Type inference regression in GHC HEAD
by GHC 12 Dec '16

12 Dec '16

#12936: Type inference regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noticed in https://ghc.haskell.org/trac/ghc/ticket/12790#comment:8. This causes `parsec-3.1.11` to fail to build with GHC HEAD. Here is as small of a test case that I can manage, with no dependencies: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} module Parsec (makeTokenParser) where import Data.Char (digitToInt) data ParsecT s u (m :: * -> *) a instance Functor (ParsecT s u m) where fmap = undefined instance Applicative (ParsecT s u m) where pure = undefined (<*>) = undefined instance Monad (ParsecT s u m) where return = undefined (>>=) = undefined fail = undefined parserZero :: ParsecT s u m a parserZero = undefined infixr 1 <|> (<|>) :: (ParsecT s u m a) -> (ParsecT s u m a) -> (ParsecT s u m a) (<|>) = undefined class (Monad m) => Stream s m t | s -> t where digit :: (Stream s m Char) => ParsecT s u m Char digit = undefined hexDigit :: (Stream s m Char) => ParsecT s u m Char hexDigit = undefined octDigit :: (Stream s m Char) => ParsecT s u m Char octDigit = undefined option :: (Stream s m t) => a -> ParsecT s u m a -> ParsecT s u m a option = undefined many1 :: (Stream s m t) => ParsecT s u m a -> ParsecT s u m [a] many1 = undefined data GenTokenParser s u m = TokenParser { float :: ParsecT s u m Double, naturalOrFloat :: ParsecT s u m (Either Integer Double) } makeTokenParser :: (Stream s m Char) => GenTokenParser s u m makeTokenParser = TokenParser{ float = float_ , naturalOrFloat = naturalOrFloat_ } where ----------------------------------------------------------- -- Numbers ----------------------------------------------------------- naturalOrFloat_ = lexeme natFloat float_ = lexeme floating -- floats floating = do{ n <- decimal ; fractExponent n } natFloat = zeroNumFloat <|> decimalFloat zeroNumFloat = do{ n <- hexadecimal <|> octal ; return (Left n) } <|> decimalFloat decimalFloat = do{ n <- decimal ; option (Left n) (fractFloat n) } fractFloat n = do{ f <- fractExponent n ; return (Right f) } fractExponent n = do{ fract <- fraction ; expo <- option "" exponent' ; readDouble (show n ++ fract ++ expo) } <|> do{ expo <- exponent' ; readDouble (show n ++ expo) } where readDouble s = case reads s of [(x, "")] -> return x _ -> parserZero fraction = do{ digits <- many1 digit ; return ('.' : digits) } exponent' = do{ e <- decimal ; return (show e) } -- integers and naturals decimal = number 10 digit hexadecimal = number 16 hexDigit octal = number 8 octDigit number base baseDigit = do{ digits <- many1 baseDigit ; let n = foldl (\x d -> base*x + toInteger (digitToInt d)) 0 digits ; seq n (return n) } ----------------------------------------------------------- -- White space & symbols ----------------------------------------------------------- lexeme p = do{ x <- p; whiteSpace; return x } whiteSpace = return () }}} In GHC 8.0.1 and 8.0.2, this compiles without issue. But on GHC HEAD: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Parsec.hs [1 of 1] Compiling Parsec ( Parsec.hs, Parsec.o ) Parsec.hs:83:27: error: • Could not deduce (Stream s m t0) arising from a use of ‘option’ from the context: Stream s m Char bound by the type signature for: makeTokenParser :: Stream s m Char => GenTokenParser s u m at Parsec.hs:53:1-60 The type variable ‘t0’ is ambiguous Relevant bindings include decimalFloat :: ParsecT s u1 m (Either Integer Double) (bound at Parsec.hs:82:5) fractFloat :: forall b a1 u a2. (Read b, Show a2) => a2 -> ParsecT s u m (Either a1 b) (bound at Parsec.hs:87:5) fractExponent :: forall a1 u a2. (Show a2, Read a1) => a2 -> ParsecT s u m a1 (bound at Parsec.hs:91:5) fraction :: forall u. ParsecT s u m [Char] (bound at Parsec.hs:105:5) exponent' :: forall u. ParsecT s u m String (bound at Parsec.hs:109:5) decimal :: forall u. ParsecT s u m Integer (bound at Parsec.hs:114:5) lexeme :: forall b. ParsecT s u m b -> ParsecT s u m b (bound at Parsec.hs:127:5) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) • In a stmt of a 'do' block: option (Left n) (fractFloat n) In the expression: do { n <- decimal; option (Left n) (fractFloat n) } In an equation for ‘decimalFloat’: decimalFloat = do { n <- decimal; option (Left n) (fractFloat n) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12936> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11739: Simplify axioms; should be applied to types
by GHC 12 Dec '16

12 Dec '16

#11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But the example shows that the new expressiveness is not expressive enough! Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F <Int> co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the ax[1] is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #876: Length is not a good consumer
by GHC 12 Dec '16

12 Dec '16

#876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: fixed | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/876#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12960: New haddock seems to be segfaulting
by GHC 11 Dec '16

11 Dec '16

#12960: New haddock seems to be segfaulting -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 61932cd3eb0d5d22cb35d118fb9f87298881cd77 bumped up haddock. This seems to be segfaulting randomly on Windows and OSX or just dies. compiler/ghc.mk:581: recipe for target 'compiler/stage2/doc/html/ghc/ghc.haddock' failed make[1]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12961: Duplicate exported functions?
by GHC 11 Dec '16

11 Dec '16

#12961: Duplicate exported functions? -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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: -------------------------------------+------------------------------------- In my paper on Call Arity, I wrote > Unfortunately it also means that adding a top-level function to the export list of the module can prevent Call Arity from eta-expanding it and other functions in the module. and a reviewer asked > Why don’t you duplicate and specialize the function? And that is an interesting question, which I don’t want to pursue at the moment in detail, but note down. Obviously, if the the function can be inlined in all uses in the current module, we essentially do that already. But if not (for example, because it is recursive), then this could indeed improve the performance of the in-module uses. The question is: Is it worth it? Questions on the way: Do we have more analyses like Call Arity that gather information form the use sites, and that need to make pessimistic assumptions for exported functions, or is it the only one? In terms of final code size: Will CSE reliably undo the duplication of possible large swathes of code if both copies of the function were compiled identically? Maybe instead of duplicating all exported functions opportunistically, Call Arity could analyze them twice and only if it gets useful data from the use-sites cause them to be duplicated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12961> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1