- ghc-tickets - Haskell.org

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

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

15 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

[GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files
by GHC 14 Jun '15

14 Jun '15

#8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files ------------------------------------+---------------------------- Reporter: janm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Keywords: ghc-pkg race | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages. I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache. In my case, the following things happened: ("Building" indicates a start, "Built" indicates completion, "Installing" is setup in a separate chroot'd environment and is isolated) The FreeBSD ports system is used to drive the Haskell build system. The process works single threaded and fails intermittently when done in parallel. Building: devel/hs-data-default-instances-base Building: devel/hs-data-default-instances-containers Building: devel/hs-data-default-instances-old-locale Built: devel/hs-dlist Building: devel/hs-data-default-instances-dlist Built: devel/hs-temporary Built: jail-image-full Installing: system-image__jail-image-full Built: devel/hs-base64-bytestring Built: archivers/hs-zlib Building: security/hs-digest Built: devel/hs-syb Building: textproc/hs-hs-bibutils Building: textproc/hs-pandoc-types Built: devel/hs-utf8-string Built: devel/hs-data-default-instances-old-locale Built: devel/hs-data-default-instances-containers Built: devel/hs-data-default-instances-base Built: devel/hs-data-default-instances-dlist Building: devel/hs-data-default Built: devel/hs-random Installed: system-image__lang/ghc Installing: system-image__archivers/hs-zlib Installing: system-image__devel/hs-utf8-string Installing: system-image__devel/hs-syb Installing: system-image__devel/hs-base64-bytestring Installing: system-image__devel/hs-data-default-class Installing: system-image__devel/hs-dlist Installing: system-image__devel/hs-random Installing: system-image__devel/hs-temporary Installing: system-image__devel/hs-extensible-exceptions Built: devel/hs-data-default FAILED The error from the Haskell data-default build was: setup: At least the following dependencies are missing: data-default-instances-base -any Looking in the in the package.conf.d directory shows that the data- default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running "ghc-pkg list" did not show data-default- instances-base Running /usr/local/lib/cabal/ghc-7.6.3/data-default-instances- base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base. To me this looks like a race condition between multiple instances of ghc- pkg causing the cache to become inconsistent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9511: Remove deprecated -fglasgow-exts from NoFib suite
by GHC 14 Jun '15

14 Jun '15

#9511: Remove deprecated -fglasgow-exts from NoFib suite -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: low | Milestone: Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Someone on #ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command line, whether necessary or not. This will increase the time needed to parse the command lines, but presumably by a trivial amount. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas
by GHC 14 Jun '15

14 Jun '15

#4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: terrelln Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by terrelln): * owner: => terrelln Comment: I'll checkout out toArgs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4931#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

overlapping instances in 7.10.1
by Sergei Meshveliani 14 Jun '15

14 Jun '15

Dear GHC developers, This request overrides my previous one of "7.10.1-err..." (it is simpler and more precise). The archive http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2… presents a question about ghc-7.10.1. Make it, please, with ghc-7.10.1 by ghc $doconCpOpt -O --make Main , $doconCpOpt = -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 as it is written there in README.txt. README.txt explains which two instances are wrongly resolved -- as I expect. In ghc-7.8.2 they are resolved in a correct way (and there is a different pragma syntax). I conclude this from running the test in docon-2.12. Am I missing something? Please, advise, ------ Sergei

2 1