October 2015 - ghc-tickets

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 26 Oct '15

26 Oct '15

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 8184, 8235 | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Wearing my GHC developer's hat: I don't like environment flags controlling the compiler's behavior, since they make it harder to reproduce or identify issues. It's very helpful if I can tell the user to run `cabal build -v` and extract the ghc command line and know that everything that affects ghc's operation is specified on that command line or in the input files. Implicit global state is bad, right? Of course, in reality there is already implicit global state (versions of installed packages, versions of C compiler/CPP/LLVM/etc.), but the less the better. Compare for example [https://gcc.gnu.org/onlinedocs/gcc /Environment-Variables.html Environment Variables Affecting GCC], which roughly amounts to LANG, TMPDIR and where to look for headers and libraries. In principle `-jN` should not affect ghc's behavior, and then I would not really be against adding an environment variable for it, but in practice it does: see #9370, which I think is still unfixed, not to mention the possibility of bugs in `-jN` itself. Wearing my GHC user's hat: I don't really see the need for an environment variable here. Doesn't the `stack build --ghc-options="-j4"` that nh2 mentioned solve your immediate problem? And using this environment variable doesn't strike me as the Right Solution to any problem: if you are invoking ghc directly then you don't need the environment variable, while if you are invoking it from a larger build system then ideally you would make the build system aware of the amount of parallelism ghc is using, and at that point you might as well make the build system aware of the `-jN` flag as well. In summary, I don't think there is a good case for adding such an environment variable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking
by GHC 26 Oct '15

26 Oct '15

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/595#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10370: Compile time regression in OpenGLRaw
by GHC 26 Oct '15

26 Oct '15

#10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As reported by Paolo Veronelli: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. I've had a look and indeed the file takes way more memory to compile with HEAD. Looking at the heap profiles, it seems that the problem is in GHC itself (space leak somewhere?). I'll attach the heap profiles (from compiling the single module itself, i.e., `touch`ing the file and running prof GHC on it). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #7169: Warning for incomplete record field label used as function
by GHC 24 Oct '15

24 Oct '15

#7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: Warnings => Warnings, newcomer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 24 Oct '15

24 Oct '15

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): Another user of aeson also [https://github.com/bos/aeson/issues/309 ran into this] (or something which looks like this). However, instead of a big sum type he has a big product type. The other interesting thing is that the issue only seems to appear with aeson-0.10.0.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10979: Phab linter trips on ReStructuredText formatting
by GHC 23 Oct '15

23 Oct '15

#10979: Phab linter trips on ReStructuredText formatting -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I made changes to the User's Guide and now Phab linter complains: {{{ >>> Lint for docs/users_guide/glasgow_exts.rst: Error (MERGECONFLICT1) Unresolved merge conflict This syntax indicates there is an unresolved merge conflict. 10555 .. _pragmas: 10556 10557 Pragmas >>> 10558 ======= 10559 10560 .. index:: 10561 single: pragma LINT ERRORS Lint raised errors! Lint issued unresolved errors! Provide explanation to continue or press Enter to abort. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10979> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7316: GHC segfaults on ARM
by GHC 23 Oct '15

23 Oct '15

#7316: GHC segfaults on ARM -------------------------------------+------------------------------- Reporter: laney | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: 7623 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: laney, as of 7.10.3 ARM support should be reasonable stable (with the exception of distributions using Thumb binaries) as #10375 is resolved. Given that we don't really know what happened in this particular bug I'm going to close this. Feel free to open another ticket if you are still having trouble with 7.10.3 or later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7316#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled
by GHC 23 Oct '15

23 Oct '15

#10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: type Test | Blocked By: family = family | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following is as far as I know correct H2010 code, but breaks in GHC: {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> type Test family = family <interactive>:2:11: parse error on input `family' Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#
by GHC 22 Oct '15

22 Oct '15

#4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: tkn.akio@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4092#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 22 Oct '15

22 Oct '15

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Replying to [comment:23 songzh]: > I am so curious that I want to ask for the case "You have an instance of Monad, but not Applicative" > why cann't we add default implementation to Applicative typeclass? > {{{ > class Functor f => Applicative f where > pure :: a -> f a > default pure :: Monad f => a -> f a > pure = return At least in the case of `pure` and `return` we have the default definition of `return` in terms of `pure`. That flow the 'right' way through the class hierarchy and doesn't require an extension. Doing both that and this yields a cycle with no way to detect it through `MINIMAL` pragmas and the like, which can't straddle two classes. > (<*>) :: f (a -> b) -> f a -> f b > default (<*>) :: Monad f => f (a -> b) -> f a -> f b > (<*>) f a = ap > }}} This one could be done. It'd require a willingness to have an attempt to implement `Applicative` that doesn't supply a `(<*>)` to be a compile error rather than a warning, however. (A state that can arise as you write incrementally.) It is a fairly minor concern, but given the difficulty of pushing through Prelude related changes one that __may__ be a sufficient blocker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0