November 2013 - ghc-tickets

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 22 Nov '13

22 Nov '13

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: 7.8.1 => 7.10.1 Comment: I've temporarily fixed this in HEAD by lowering the unfolding threshold for the stage2 build on windows. We're still extremely close to the symbol limit, but it should stay OK for 7.8. I'm leaving this highest priority and bumping to 7.10.1 - we must find a better fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8551: Fix formatting in docs at one place
by GHC 22 Nov '13

22 Nov '13

#8551: Fix formatting in docs at one place ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- See to-be-attached patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr
by GHC 22 Nov '13

22 Nov '13

#8380: Numerous testsuite failures on ARM due to missing mkJumpToAddr ----------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: patch | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- Numerous ghci tests in the testsuite currently fail on ARM due to the lack of a `mkJumpToAddr` definition. These failures look like, {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130927 for arm-unknown-linux): mkJumpToAddr not defined for ArchARM {armISA = ARMv7, armISAExt = FPv3,NEON], armABI = HARD} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As it turns out `mkJumpToAddr` is fairly straightforward to implement. I've done this in https://github.com/bgamari/ghc/tree/arm. This brings the number of unexpected failures in `tests/ghci` from 44 to 4. These four failures are segmentation faults that I need to look more closely at. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #5013: sporadic failures during compilation under solaris
by GHC 22 Nov '13

22 Nov '13

#5013: sporadic failures during compilation under solaris ----------------------------------+--------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: worksforme | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+--------------------------- Changes (by maeder): * status: new => closed * resolution: => worksforme Comment: This change improved the situation for me. I did not observe the failure again for a patched ghc-6.8.3, but also only twice for the original ghc-6.8.2 (running 400 test compilations each). I don't know if the change makes a difference for other architectures. At least others may find a solution if they observe a similar behavior. Therefore I close this ticket now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5013#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS
by GHC 22 Nov '13

22 Nov '13

#8533: Extend new getPhysicalMemorySize ifdef to ios_HOST_OS -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Other Architecture: arm | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- A very tiny patch to extend thoughtpoice's recent commit "Fix getPhysicalMemorySize on OS X (#8481)" to extend the ifdef to ios_HOST_OS, which also requires the fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 22 Nov '13

22 Nov '13

#5987: Too many symbols in ghc package DLL -------------------------------------+------------------------------------ Reporter: igloo | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 3658 | Related Tickets: -------------------------------------+------------------------------------ Comment (by Austin Seipp <austin@…>): In [changeset:"9bb909bbcf280f137c7a379d05acf5bc21268e5b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9bb909bbcf280f137c7a379d05acf5bc21268e5b" Temporarily lower unfolding threshold on Windows This is a very temporary, very unsatisfactory hack to fix #5987 (for now.) The included comments essentially say it all: we lower the unfolding threshold to minimize some amount of exported symbols from the GHC stage2 DLL. I unfortunately had to lower it quite substantially for the dynamic stage2 build to pass. As of this writing, the DLL split between ghc.dll and ghc-0.dll is something like 26,000 vs 63,000 exported symbols, respectively. So we're still quite in danger of tripping it, but I think we will be OK at this exact moment. Signed-off-by: Austin Seipp <austin(a)well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1460: Problem with Monoid instance of Data.Map
by GHC 21 Nov '13

21 Nov '13

#1460: Problem with Monoid instance of Data.Map -------------------------------+------------------------------------------- Reporter: ahey@… | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: | Version: 6.6.1 libraries/base | Keywords: Data.Map Monoid Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * failure: => None/Unknown Comment: This comes up regularly, e.g. April 2012 as well (http://www.haskell.org/pipermail/libraries/2012-April/017743.html) and right now again (here, locally). Just saying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1460#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8554: kindFunResult panic when type checking wrongly-kinded function
by GHC 21 Nov '13

21 Nov '13

#8554: kindFunResult panic when type checking wrongly-kinded function -------------------------------------+------------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: MacOS X Keywords: | Type of failure: Compile-time Architecture: x86_64 (amd64) | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- While working on some writing about recursion schemes and morphisms, I wrote the following well-known catamorphism: {{{ import Control.Arrow newtype Fix f = Fix { unFix :: f (Fix f) } bottomUp f = unFix >>> fmap (bottomUp f) >>> Fix >>> f }}} On a lark, I decided to reverse the direction of the arrows in the above statement and see what the typechecker had to say about it: {{{ nonsense f = unFix <<< fmap (nonsense f) <<< Fix <<< f }}} This function is (I think) not well-kinded, but during type checking (both from ghci and ghc) I get the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-apple-darwin): kindFunResult <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I am running 32-bit GHC 7.6.3 (from the Haskell Platform) on an x86_64 machine running OS X 10.9. I have attached the output of ghc -v. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work
by GHC 21 Nov '13

21 Nov '13

#2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by simonpj): Richard can you explain in more detail what "doesn't work2 in your example? Without the signatures of the class methods in C it's hard to makes sense of it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2850#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work
by GHC 21 Nov '13

21 Nov '13

#2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -------------------------------------------------+------------------------- Reporter: ajd | Owner: Type: feature request | Status: Priority: normal | closed Component: Compiler | Milestone: 6.12 Resolution: fixed | branch Operating System: Unknown/Multiple | Version: Type of failure: None/Unknown | 6.10.1 Test Case: | Keywords: indexed_types/should_compile/T2850 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by goldfire): Almost, but not quite, due to the lack of informative roles on data/newtype instance representation tycons. I do think the fix for #8548 would fix the example in this ticket, but not something like {{{ data family D a data instance D (Maybe a) = MkDMaybe a class C (D (Maybe Int)) where ... newtype instance D [a] = MkDList (D (Maybe a)) deriving instance C (D [Age]) }}} That's all rather confusing, but I ''think'' it should work. And it would require informative roles on data/newtype instance representation tycons. These roles are currently all nominal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2850#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0