June 2015 - ghc-tickets

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

15 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 15 Jun '15

15 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

[GHC] #10525: Enable SMP and GHCI on aarch64 in 7.10.2
by GHC 15 Jun '15

15 Jun '15

#10525: Enable SMP and GHCI on aarch64 in 7.10.2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 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: | -------------------------------------+------------------------------------- Given that the patches from #9673 were merged as well, it would be nice to have https://phabricator.haskell.org/D859 i.e. changeset:1e8c9b81a819da8eb54405a029fc33a9f5220321/ghc included in 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10526: Overlapping instances, incoherence, and optimisation
by GHC 15 Jun '15

15 Jun '15

#10526: Overlapping instances, incoherence, and optimisation -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Segei Meshveliani reports that his `docon` library has rather unexpected behaviour with GHC 7.10. See [https://mail.haskell.org/pipermail/glasgow- haskell-users/2015-May/025916.html his email]. The effect is that his test module `Main` has different runtime behaviour when compiling with and without `-O`. This sounds pretty bad. The reason is this: * He has overlapping instances for a class, say * `instance ... => C (T a)`, call it (A) * `instance C (T Int)`, call it (B) The actual situation is more complicated of course * The instances are defined in different modules. * In one module `Spec` * instance (B) is not visible * there is a function `f :: C a => a -> a` * `f` is called at type `T Int`. So GHC specialises `f`, to `f_spec :: T Int -> T Int`, and exports a RULE {{{ RULE "SPEC" f = f_spec :: T Int -> T Int }}} The idea is that any other module that calls `f` at type `T Int` can simply re-use the specialised (and presumably much faster) version of `f`. `C (T Int)` but (B) is not visible, so GHC finds a solution using (A). * In another module, `Use`, which ''can'' see (B), we call `f` at type `T Int`. In the absence of the cross-module specialisation rule, or without `-O`, GHC would solve the constraint `C (T Int)`, this time using (B). But because of the rule, with `-O`, it re-uses `f_spec`. Result: different runtime behaviour. There is a more detailed discussion on [https://mail.haskell.org/pipermail /glasgow-haskell-users/2015-June/025970.html this thread]. Files to reproduce. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

15 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 simonpj): Responding to Phab here, because the design discussion is less likely to get lost here. 1. Thank you for the user manual update. Can you add a paragraph or two explaining the design choice? After all, if I did `deriving( Eq )` on an empty data type, or standalone deriving, I would expect a static error; the generated code is never useful. But on the contrary, we now propose to give a dynamic error, postponing a crash until runtime. Why is this good? Explain either in the user manual or on a wiki page that discusses. comment:6 seems relevant, but is cryptic. 2. I'm certain that standalone deriving and `deriving(...)` on a data type declaration should behave the same. Imagine trying to explain the difference in the user manual, if they differed! Can you make it so? 3. For Ix, Enum, Bounded, the [https://www.haskell.org/onlinereport/haskell2010/haskellch19.html#x27-22700… 2010 report] uses words like "derived instance declarations for the class Ix are only possible for enumerations (i.e. datatypes having only nullary constructors) and single-constructor datatypes". It seems odd to make them fail with a static error if Eq etc fail with a dynamic error. We can interpret the words "having only nullary constructors" as true for an empty data type; after all all the constructors it has are nullary. So let's make `isEnumeration` true for empty types too. (Make a `Note` to explain; and the user manual.) Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9991: runghc shows the value produced by main when its type is a non-() Show instance
by GHC 14 Jun '15

14 Jun '15

#9991: runghc shows the value produced by main when its type is a non-() Show instance -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When running a program like this: {{{#!hs main :: IO Int main = return 5 }}} With `runghc`, it'll print a value, which is contrary to expected behavior and to compiled program behavior: {{{ $ runghc Main.hs 5 $ ghc Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main $ }}} This is the same as `ghci`'s behavior with an IO action, so presumably `runghc` is taking a shortcut here. But a program should behave the same way in both cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9991> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10517: Unexpected behavior of unsafeCoerce converting Word32 to Word8
by GHC 14 Jun '15

14 Jun '15

#10517: Unexpected behavior of unsafeCoerce converting Word32 to Word8 -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The function `unsafeCoerce` behaves unexpected if it is used to convert `Word32` to `Word8`: {{{#!hs main = do -- prints 135 print (fromIntegral (1234567 :: Word32) :: Word8) -- prints 1234567 print (unsafeCoerce (1234567 :: Word32) :: Word8) }}} On the other hand coercing `Ptr Word32` to `Ptr Word8` or the other way around works perfectly fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9769: ghc-7.8.3-x86_64-unknown-mingw32.tar.xz missing User's Guide
by GHC 14 Jun '15

14 Jun '15

#9769: ghc-7.8.3-x86_64-unknown-mingw32.tar.xz missing User's Guide -------------------------------------+------------------------------------- Reporter: Dangthrimble | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Difficulty: Unknown | Documentation bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Context: I am relatively new to Haskell and am trying to build a Haskell IDE around `Sublime Text`. I have been using `Haskell Platform` but have encountered a number of problems using `cabal`. Consequently I have been advised to uninstall `Haskell Platform` and download `ghc`. I have just downloaded and extracted `ghc-7.8.3-x86_64-unknown- mingw32.tar.xz`. Hoping for advice on setting up `ghc`, I have opened `ghc-7.8.3\doc\html\index.html` in Firefox and clicked on "The User's Guide". Unfortunately the `ghc-7.8.3/doc/html/users_guide` folder is missing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4