October 2015 - ghc-tickets

[GHC] #10973: Building git HEAD with a singe make job fails due to dependency problem
by GHC 17 Oct '15

17 Oct '15

#10973: Building git HEAD with a singe make job fails due to dependency problem -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I clone git HEAD and do: {{{ perl boot && ./configure && make }}} The build fails with: {{{ /usr/bin/ld: cannot find -lHSghc-boot-0.0.0.0 collect2: error: ld returned 1 exit status }}} and it keeps failing if I run `make` without any `-j` option. Building with `make -j<N>` where `N` is 2 or more is fine. Looks like some sort of dependency problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression
by GHC 17 Oct '15

17 Oct '15

#10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- At the end is a log of my ghci session reproducing the issue. It is expected that the splice should succeed, but GHC complains "Illegal data constructor name: `fromList' ... When splicing a TH expression". Full definitions being used can be found at http://hackage.haskell.org/package/regex-tdfa-quasiquoter-0.2.0.0 . Briefly, this is the splice being used. {{{#!hs [e|patternToRegex $patternExp $compOptsExp $execOptsExp|] where patternExp = dataToExpQ (const Nothing) pattern compOptsExp = dataToExpQ (const Nothing) compOpts execOptsExp = dataToExpQ (const Nothing) execOpts }}} Data and Typeable instances are derived (using -XStandaloneDeriving -XDeriveDataTypeable) as orphan instances in the Internal module. The issue occurs when using bracket expressions (in POSIX regular expressions). There may be other cases but I have not uncovered them. {{{ > ghci GHCi, version 7.8.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. >>> :set -XQuasiQuotes >>> import Text.Regex.TDFA.QuasiQuoter >>> :t [re|;[a]|] Loading package transformers-0.3.0.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package regex-base-0.93.2 ... linking ... done. Loading package text-1.2.0.3 ... linking ... done. Loading package parsec-3.1.9 ... linking ... done. Loading package regex-tdfa-1.2.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package regex-tdfa-quasiquoter-0.2.0.0 ... linking ... done. <interactive>:1:5: Illegal data constructor name: `fromList' When splicing a TH expression: Text.Regex.TDFA.TDFA.patternToRegex (GHC.Tuple.(,) (Text.Regex.TDFA.Pattern.POr ((GHC.Types.:) (Text.Regex.TDFA.Pattern.PConcat ((GHC.Types.:) (Text.Regex.TDFA.Pattern.PAny (Text.Regex.TDFA.Common.DoPa 1) (Text.Regex.TDFA.Pattern.PatternSet (Data.Maybe.Just (Data.Set.Base.fromList ((GHC.Types.:) 'a' GHC.Types.[]))) Data.Maybe.Nothing Data.Maybe.Nothing Data.Maybe.Nothing)) GHC.Types.[])) GHC.Types.[])) (GHC.Tuple.(,) 0 (Text.Regex.TDFA.Common.DoPa 1))) (Text.Regex.TDFA.Common.CompOption GHC.Types.True GHC.Types.True GHC.Types.True GHC.Types.True GHC.Types.False) (Text.Regex.TDFA.Common.ExecOption GHC.Types.True) >>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

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

16 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 rrnewton): For me, typical stack builds spend a huge amount of time bottlenecked on just one or two ghc compiles. Yes, we could push towards stack and other tools dynamically provisioning cores to GHC instances. But, in the short term GHC doesn't actually get decent parallel scaling anyway (#9221) so I really just want `-j2` or `-j3`. And that limited level of oversubscription I'm not very worried about (the overall builds spend so little their time with decent parallel utilization anyway). Do we have a policy for priorities of env vars versus flags in general? I think command line flags should take precedence. Then any smart tools that know how to manage "ghc -j" can override any system wide default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10911: Allow left ∨ (+++) as minimal definition of ArrowChoice instance
by GHC 16 Oct '15

16 Oct '15

#10911: Allow left ∨ (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: | Owner: mfdyck.google | Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Add default definitions of left, right in terms of (+++) to let one define an ArrowChoice instance in terms of (+++) rather than left, which is sometimes more elegant or convenient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

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

16 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 nh2): @rrnewton: That may or may not be a good idea - since tools like stack already do a `-j` on the package level, it seems that the best results can be achieved if such tools are aware of GHC's `-j` and use it correctly (e.g. you'd probably not want full `-j` for both stack and GHC as that would give you N*N threads and a lot of overhead) - so it may be worth more pushing for these tools to use GHC's `-j`. Also, if there was a `GHC_MAKE_CORES` env var, and `-j` was also given, which one would take precedence? To answer one of your questions directly, most of these tools accept a `--ghc-options` flag, e.g. you can do `stack build --ghc-options="-j4"`. I think another reason why not all tools use `ghc -j` is because of #9221. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10978: Anonymous type instances
by GHC 16 Oct '15

16 Oct '15

#10978: Anonymous type instances -------------------------------------+------------------------------------- Reporter: | Owner: benjamin.hodgson | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | 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: -------------------------------------+------------------------------------- I find that commonly I write a `type family` (because it doesn't ''need'' to be a `data family`, and `type` families are more flexible), but I find myself writing `data` types for some of the instances anyway. Presently you're forced to use type synonyms for all the instances of a `type family`, even if you don't intend to refer to the type by any name other than that of the type family. I find this tiresome: {{{#!hs type family F a type instance F Char = Int newtype FBool = FBool Int type instance F Bool = FBool data FInt = A | B | ... type instance F Int = FInt }}} '''I want to write `data instance`s and `newtype instance`s for `type` families'''. These proposed constructs would introduce a new type without a name of its own (the only way to refer to it would be through the `type family`), just like the current design of `data` families. The above code would be roughly equivalent to: {{{#!hs type family F a type instance F Char = Int -- already legal newtype instance F Bool = FBool Int data instance F Int = A | B | ... }}} I call this idea ''anonymous type instances'' but I'm open to suggestions for a snappier name. Going the other way (writing a `type instance` for a `data family`) would remain illegal under this proposal. {{{#!hs data family G a type instance G Char = Int -- still illegal }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

16 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 rrnewton): I want to raise one more issue on this topic. Nowadays most people implicitly call ghc under layers of tooling (stack, cabal, ghc-mod, haskell-mode, etc). For example, with stack, at this particular moment in time I can't find a place to stick `-j3` such that all my builds on a machine will see it. This question of internal parallelism is an internal implementation issue, and shouldn't change semantics. Thus I think it would be safe for it to be optionally controlled by an environment variable. If I could just set "GHC_MAKE_CORES=3" on a given system, then I could get the desired behavior irrespective of what tools I'm using on top of GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:63> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10977: Arm: Undeclared indentifier when build un-registerised
by GHC 16 Oct '15

16 Oct '15

#10977: Arm: Undeclared indentifier when build un-registerised ----------------------------------+---------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: rts linker | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------+---------------------------------------- I have a Jenkins job which builds un-registerised on armhf and just got this: {{{ rts/Linker.c:6209:21: error: error: ‘target_shndx’ undeclared (first use in this function) if (oc->sections[target_shndx].kind == SECTIONKIND_OTHER) { ^ rts/Linker.c:6209:21: error: note: each undeclared identifier is reported only once for each function it appears in `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} Seems this is a result of 04e8366608 and the fix is pretty obvious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10977> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10882: Fix target tripe for Arm
by GHC 16 Oct '15

16 Oct '15

#10882: Fix target tripe for Arm -----------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------- LLVM IR code generated by GHC on Arm (Debian) uses a target triple of "arm-linux-gnueabi" which according the LLVM people is something like ARMv4 with software float. Clang on the other hand generates IR code with a target triple of "armv6 -linux-gnueablhf" which is ARMv6 and hardware float so it works on the original Raspberry Pi. GHC should either use the same target triple as Clang or at least make it configurable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2031: relocation overflow
by GHC 16 Oct '15

16 Oct '15

#2031: relocation overflow ---------------------------------+------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2031#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0