August 2013 - ghc-tickets

Re: [GHC] #5724: Confusing warning message for incomplete patterns
by GHC 31 Aug '13

31 Aug '13

#5724: Confusing warning message for incomplete patterns -------------------------------------+------------------------------------ Reporter: AntoineLatter | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by leroux): * cc: leroux@… (added) * status: new => infoneeded Comment: As igloo asked 20 months ago, did you have an alternative message in mind? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5724#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #703: all binaries built by ghc have executable stacks
by GHC 30 Aug '13

30 Aug '13

#703: all binaries built by ghc have executable stacks ----------------------------+---------------------------------------------- Reporter: duncan | Owner: ezyang Type: merge | Status: merge Priority: normal | Milestone: 6.6.1 Component: | Version: 7.6.3 Compiler (NCG) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Moderate (less than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | ----------------------------+---------------------------------------------- Comment (by ezyang): Sorry about not following up sooner. If any object that will be linked in has executable stack set, then the whole binary will have an executable stack. So it would seem HSbase*.o is at fault. However, in GHC HEAD I have no problem: {{{ ezyang@javelin:~/Dev/ghc-build-alloc$ readelf -W -l libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130830.so | grep GNU_STACK GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8 }}} Perhaps some library HSbase is using has an executable stack? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/703#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2841: Ghci + foreign export declarations result in undefined symbols
by GHC 30 Aug '13

30 Aug '13

#2841: Ghci + foreign export declarations result in undefined symbols -----------------------------------+------------------------------------ Reporter: fasta | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by ezyang): I don't have a Mac or Windows GHC build machine handy, so I haven't attempted to do it for those platforms, but it should be quite similar. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2841#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2841: Ghci + foreign export declarations result in undefined symbols
by GHC 30 Aug '13

30 Aug '13

#2841: Ghci + foreign export declarations result in undefined symbols -----------------------------------+------------------------------------ Reporter: fasta | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Changes (by ezyang): * owner: => ezyang * failure: => None/Unknown Comment: It's not explicitly stated anywhere, but the reason this doesn't work is because foreign exports are implemented using `__attribute__(constructor)`, but GHC's linker doesn't run the functions in init/init_array. #7746 is related (profiling uses init as well). I believe this should work fine if you use dynamic objects, in which case the system dynamic linker will properly handle this invocation for you. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2841#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 30 Aug '13

30 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: 8184 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): Replying to [comment:35 rrnewton]: > By the way, I've had various hard-to-pin-down problems with changing capabilities at runtime myself. > > Is it possible in this case to just disable the use of that feature for the initial release? That is, you would have to use +RTS -N to get real speedup. But, hey, it's kind of an advanced compilation feature anyway. In this scenario we could get a lot of testing experience with parallel builds without setNumCapabilities and then combine them when there is higher confidence. > > I don't mind going that route if the issue doesn't get sorted out soon. A subsequent point release of GHC could reinstate the feature (automatically setting the number of capabilities for the user), then. But I think I could fix it on time. ---- Replying to [comment:34 simonmar]: > The changes to handle loops look OK to me, but I would test it on a GHC build to be sure. You want to build the whole of ghc/compiler with --make -O2; the build system doesn't do this so you have to make a command line by hand. At first I couldn't even get GHC to compile itself via `--make -O2` without `-j` (see #8184). Since that's been fixed I was able to build GHC via `--make -O2 -j` after a minor tweak in the code, so the loop handling should be solid now. On to the `setNumCapabilities` issue... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8204: Impossible when deriving Read for empty data declaration
by GHC 30 Aug '13

30 Aug '13

#8204: Impossible when deriving Read for empty data declaration ------------------------------------+------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | 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: | ------------------------------------+------------------------------------- Remember #4302? Me: {{{ data X deriving Read main :: IO () main = return () }}} GHC: {{{ [1 of 1] Compiling Main ( deriving.hs, deriving.o ) deriving.hs:2:17: Can't make a derived instance of `Read X': `X' must have at least one data constructor Possible fix: use a standalone deriving declaration instead In the data declaration for `X' }}} Me: {{{ -- Ugh, fine... {-# LANGUAGE StandaloneDeriving #-} deriving instance Read X main :: IO () main = return () }}} GHC: {{{ [1 of 1] Compiling Main ( deriving.hs, deriving.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): Prelude.foldr1: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} And so I did. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8204> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2184: if findExecutable finds a file that matchs the argument, check if it is an executable
by GHC 30 Aug '13

30 Aug '13

#2184: if findExecutable finds a file that matchs the argument, check if it is an executable -------------------------------------+------------------------------------- Reporter: iago | Owner: leroux Type: bug | Status: patch Priority: lowest | Milestone: 7.6.2 Component: | Version: 6.8.2 libraries/directory | Keywords: findExecutable Resolution: | check executable Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by leroux): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2184#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2184: if findExecutable finds a file that matchs the argument, check if it is an executable
by GHC 30 Aug '13

30 Aug '13

#2184: if findExecutable finds a file that matchs the argument, check if it is an executable -------------------------------------+------------------------------------- Reporter: iago | Owner: leroux Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: | Version: 6.8.2 libraries/directory | Keywords: findExecutable Resolution: | check executable Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by leroux): * owner: => leroux * failure: => None/Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2184#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 30 Aug '13

30 Aug '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thoughtpolice): Yes, the patch unfortunately can't go in for now when it will totally break bootstrapping. We'll have to see if we can get a fix into Happy. FWIW, I created the 7.10 ticket because I like keeping tickets for things that we eventually remove. It normally happens when people glance over the code, but I find having a ticket is an easier trail to follow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 30 Aug '13

30 Aug '13

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0