- ghc-tickets - Haskell.org

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 17 Jun '15

17 Jun '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10532: Unnecessary constraints when using overlapping instances
by GHC 17 Jun '15

17 Jun '15

#10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code compiles just fine: {{{ class Foo a where foo :: a -> Int instance Foo a where foo _ = 5 f :: a -> Int f = foo }}} But if we modify the code to use overlapping instances like so: {{{ class Foo a where foo :: a -> Int instance {-# OVERLAPS #-} Foo Int where foo = id instance {-# OVERLAPPABLE #-} Foo a where foo _ = 5 f:: a -> Int f = foo }}} We get the following compiler message: {{{ Overlapping instances for Foo a arising from a use of ‘foo’ Matching instances: instance [overlappable] Foo a -- Defined at ... instance [overlap ok] Foo Int -- Defined at ... (The choice depends on the instantiation of ‘a’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) }}} Including the constraint in the type signature makes the problem go away, but the constraint shouldn't be needed. In most use cases this wouldn't be a big deal, but it's making my type signatures much messier looking than they actually are. Adding IncoherentInstances as the error message suggests gives the instance I don't want. Weirdly, I get different instances depending on whether the constraint is in the type signature or not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10451: Constraint tuple regression in HEAD
by GHC 17 Jun '15

17 Jun '15

#10451: Constraint tuple regression in HEAD -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple ConstraintKinds | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following file works in GHC 7.10.1, but fails in HEAD: {{{ {-# LANGUAGE ConstraintKinds #-} module ConstraintKinds where type ManyEq a = (Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a ,Eq a -- Comment this line to make compilation succeed in HEAD ) }}} This is most likely due to ffc21506894c7887d3620423aaf86bc6113a1071, which has set a limit on constraint tuples to size `8`. I think we should either: - increase the size limit on constraint tuples to be the same as normal tuples (`62`), or, - automatically nest constraint kinds beyond 8-tuples, or, - carefully document this limitation for the next release. Note that I encountered this limitation in my own code that I and others actually use: http://hackage.haskell.org/package/clash- prelude-0.7.5/docs/src/CLaSH-Sized-Fixed.html#ENumSFixedC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr
by GHC 17 Jun '15

17 Jun '15

#10508: comipleExpr or :def in GHCi rejects valid multiline expr or accepts invalid expr -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHC rejects Test Case: | valid program Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- dynComipleExpr will accept invalid expr or reject valid expr because it compiles the expr as `"let _dynComipleExpr = (" ++ expr ++ ")"`. {{{#!hs -- tail -n 15 Test.hs forM_ exprs $ \expr -> handleSourceError printException $ do dyn <- dynCompileExpr expr liftIO $ print dyn where exprs = [ "" , "(),()" , "()" , "\"test\"" , unlines [ "[()]" , " :: [()]" ] ] -- ./Test /lib/ghc <<()>> <<((),())>> <<()>> <<[Char]>> <interactive>:2:2: parse error (possibly incorrect indentation or mismatched brackets) }}} As `:def` and `:cmd` uses `compileExpr`, they have the same problem: {{{ GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :{ Prelude| :cmd return $ unlines Prelude| [ "1" Prelude| , "2" Prelude| ] Prelude| :} <interactive>:2:3: parse error (possibly incorrect indentation or mismatched brackets) Prelude> import Prelude (return, id, ShowS, IO) Prelude> :cmd return "0" <interactive>:1:42: Not in scope: type constructor or class ‘String’ Prelude> type String = ShowS Prelude> :cmd return id zsh: segmentation fault (core dumped) ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 16 Jun '15

16 Jun '15

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications] Section 2.3, for why types can (legitimately I fear) blow up. I'm not say that is what is happening here, but it might be similar. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8785: Replace hooks API in the RTS with something better
by GHC 16 Jun '15

16 Jun '15

#8785: Replace hooks API in the RTS with something better ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hooks rely on static linking behaviour which doesn't always work: we have to disable -Bsymbolic for the RTS on Linux (see `compiler/main/SysTools.lhs`) and it apparently doesn't work at all on Mac (#8754). So instead of hooks we should be passing in information when we initialize the RTS, like we already do for some other things (`-rtsopts` etc.). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 16 Jun '15

16 Jun '15

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I may be missing something obvious here but I'm not convinced that the problem is in `CorePrep` or `TidyCore`. If one looks at the `hi` file or `-ddump-simpl` output from even a relatively shallow four-layer transformer stack one finds quite large types that appear to be growing quadratically in the depth. This is supported by the fact that `Type` and `IfaceType` show up strongly in the heap profiles as well as the fact that, in my runs, `core2core` shows up about as strongly in the profiles as `addFingerprints`. Looking at the types in the Core, it seems that the inliner may be over- zealous in its work. Due to the CPS style of the example, the types snowball extremely quickly. Most of the damage comes in the first two simplifier iterations. Many of the larger of these types are coercions and their signatures. I'm not sure I see what is failing here. The question then is what measure is supposed to prevent this snow-balling and why is it not working? I'll have another look tomorrow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Jun '15

16 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): (1) and (2) are done(will push commits soon). For (3), I think it may break some things. I found this NOTE in compiler/types/TyCon.hs: {{{ Note [Enumeration types] ~~~~~~~~~~~~~~~~~~~~~~~~ We define datatypes with no constructors to *not* be enumerations; this fixes trac #2578, Otherwise we end up generating an empty table for <mod>_<type>_closure_tbl which is used by tagToEnum# to map Int# to constructors in an enumeration. The empty table apparently upset the linker. Moreover, all the data constructor must be enumerations, meaning they have type (forall abc. T a b c). GADTs are not enumerations. For example consider data T a where T1 :: T Int T2 :: T Bool T3 :: T a What would [T1 ..] be? [T1,T3] :: T Int? Easiest thing is to exclude them. See Trac #4528. }}} See also trac #2578. Relevant commits: {{{ commit 409e4d9f59dece1c21434191459c96b3e355faa9 Author: Ian Lynagh <igloo(a)earth.li> Date: Sat Feb 27 17:24:29 2010 +0000 Add a test for #2578 commit a251cba370c9bfb291159c4deea20226a87eeac3 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Mon Mar 1 09:55:25 2010 +0000 expand comments for #2578 fix commit 09d2b3b2e1f9d0a4c4b938dc6ff6a0b068138445 Author: Ian Lynagh <igloo(a)earth.li> Date: Sat Feb 27 17:39:51 2010 +0000 Fix trac #2578 We define empty datatypes as not being enumerations, which means the empty blocks aren't generated. }}} This is the fix: {{{ - = DataTyCon { data_cons = cons, is_enum = all isNullarySrcDataCon cons } + = DataTyCon { + data_cons = cons, + is_enum = -- We define datatypes with no constructors to not be + -- enumerations; this fixes trac #2578 + not (null cons) && + all isNullarySrcDataCon cons + } }}} `Note [Enumeration types]` mentions some kind of linker failure related with some table(??), but I don't have a lot of ideas about what it's talking about. I don't have a Mac so I can't try with latest linker/GHC. Any ideas about (3)? How should we proceed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #10375, #10438, #10053, #10205, #10301, #10506
by GHC 15 Jun '15

15 Jun '15

Batch modification to #10375, #10438, #10053, #10205, #10301, #10506 by thoughtpolice: milestone to 7.10.3 Comment: Moving to 7.10.3 milestone - if you think this is an error (or a showstopping bug), please remilestone it to 7.10.2 and let us know why. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10375%2C10438%2C10053%2C10205%2C10…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants
by GHC 15 Jun '15

15 Jun '15

#10518: unregisterised GHC generates incorrect 0xUL literals for certain onstants -------------------------------------+------------------------------------- Reporter: slyfox | Owner: slyfox 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: | -------------------------------------+------------------------------------- jakzale reports: 21:47:27 < int-e> Oh, nice. Yes, indeed pprHexVal (2^32) W32 (function from cmm/PprC.hs) would result in 0xU. 21:50:29 < jakzale> int-e: yes, truncInt takes module 2^32, then go returns empty string (I guess) Here comes the test: {{{ $ cat a.cmm foo() { bits64 a; a = 0x10000000000000000; // overflows 64 bits return (a); } $ inplace/bin/ghc-stage2 -c a.cmm /tmp/ghc8580_0/ghc_2.hc: In function 'foo': /tmp/ghc8580_0/ghc_2.hc:8:7: error: error: invalid suffix "xUL" on integer constant _c0 = 0xUL; ^ }}} I've broke it with commit:43f1b2ecd1960fa7377cf55a2b97c66059a701ef when introduced truncation that can generate more zeroes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7