- ghc-tickets - Haskell.org

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 18 Mar '14

18 Mar '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Changes (by awson): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2283: WIndows: loading objects that refer to DLL symbols
by GHC 18 Mar '14

18 Mar '14

#2283: WIndows: loading objects that refer to DLL symbols ---------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7097 #7568 ---------------------------------+------------------------------------ Changes (by awson): * priority: high => highest * status: closed => new * resolution: fixed => * architecture: x86 => Unknown/Multiple Comment: That fix above was insufficient. It resolved linking of decorated function, but any attempt of some foreign code to call it lead to segfault because such foreign code want to call it *indirectly*, while we give it a direct address. This patch fixes things finally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2283#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8855: LLVM backend needs to use `-globalopt` explicitly
by GHC 17 Mar '14

17 Mar '14

#8855: LLVM backend needs to use `-globalopt` explicitly ------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- While `-O1` and `-O2` includes a `-globalopt` pass, for reasons I don't entirely understand the location of the pass is such that not all aliases are eliminated. My `ghc-7.8` branch includes a patch fixing this (as well as removing ARM from the dynamic linking blacklist)[1]. [1] https://github.com/bgamari/ghc/commits/ghc-7.8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8855> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #7874: segfault 11 on mac os x when building compiler for ghc 7.7.20130430
by GHC 17 Mar '14

17 Mar '14

#7874: segfault 11 on mac os x when building compiler for ghc 7.7.20130430 ----------------------------------------+---------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by carter): * status: new => closed * resolution: => fixed Comment: I believe this is resolved. closing -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7874#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools)
by GHC 17 Mar '14

17 Mar '14

#8164: GHC HEAD panics in testsuite on OS X 10.8 with cc=Clang (using newest xcode 5 dev tools) ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I got the following panics when I ran the GHC test suite per ticket #8148 (using xcode 5 CLI dev preview tools released as of august 21st on OS X 10.8) =====> ghcilink003(normal) 889 of 3736 [8, 195, 0] cd ./ghci/linking && $MAKE -s --no-print-directory ghcilink003 </dev/null >ghcilink003.run.stdout 2>ghcilink003.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> EnumFromToP(normal) 564 of 3736 [0, 82, 0] cd ./dph/enumfromto && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c EnumFromToP.hs -O -fno-enable-rewrite-rules -package dph-lifted-vseg >EnumFromToP.comp.stderr 2>&1 Actual stderr output differs from expected: --- /dev/null 2013-08-22 16:09:56.000000000 -0400 +++ ./dph/enumfromto/EnumFromToP.comp.stderr 2013-08-22 16:11:18.000000000 -0400 @@ -0,0 +1,6 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.7.20130822 for x86_64-apple-darwin): + DsMonad: uninitialised ds_parr_bi + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> jmp_tbl(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c jmp_tbl.hs -O -fasm -fPIC -O >jmp_tbl.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(hpc) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fhpc -hpcdir .hpc.T7574 -no- hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(optasm) 102 of 3736 [0, 33, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -O -fasm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug =====> T7574(normal) 102 of 3736 [0, 2, 0] cd ./codeGen/should_compile && '/Users/carter/Desktop/repoScratcher/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7574.cmm -no-hs-main >T7574.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130822 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8841: PatternSynonyms error gives wrong source locations
by GHC 17 Mar '14

17 Mar '14

#8841: PatternSynonyms error gives wrong source locations -------------------------+------------------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: 7.8.1 Priority: low | Version: 7.8.1-rc2 Component: | Operating System: Linux Compiler | Type of failure: Incorrect warning at Keywords: | compile-time PatternSynonyms | Test Case: Architecture: x86 | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Using an example from the [http://www.haskell.org/ghc/docs/7.8.1-rc1/html/users_guide/syntax- extns.html GHC user's guide] but omitting the argument to `Maybe` {{{ {-# LANGUAGE PatternSynonyms #-} data Type = App String [Type] pattern Maybe = App "Maybe" [t] }}} gives the following error without the correct source locations {{{ ghci> :load /tmp/failure.hs [1 of 1] Compiling Main ( /tmp/failure.hs, interpreted ) /tmp/failure.hs:1:1: Right-hand side of bidirectional pattern synonym cannot be used as an expression App "Maybe" [t] Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8851: Standalone deriving and GND behave differently
by GHC 17 Mar '14

17 Mar '14

#8851: Standalone deriving and GND behave differently ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- Sergey Tromimovich writes: Trying to build random packages with fresh ghc-7.8.1-rc2 I've come up with a strange bit: https://github.com/trofi/Idris- dev/commit/9f93122ba1aa075c2fa1555fea68a6c403697e04 Is it an intended behaviour that standalone deriving (A) {{{ deriving instance Parsing IdrisInnerParser }}} is capable of doing more, than a deriving clause (B) {{{ newtype IdrisInnerParser a = IdrisInnerParser { runInnerParser :: Parser a } deriving (Parsing) }}} where the class is defined thus {{{ class Alternative m => Parsing m where .... notFollowedBy :: (Monad m, Show a) => m a -> m () notFollowedBy p = try ((try p >>= unexpected . show) <|> pure ()) }}} The error message from the (B) is {{{ [50 of 75] Compiling Idris.ParseHelpers ( src/Idris/ParseHelpers.hs, dist/build/Idris/ParseHelpers.o ) src/Idris/ParseHelpers.hs:40:97: Could not coerce from ‘Monad Parser’ to ‘Monad IdrisInnerParser’ because the first type argument of ‘Monad’ has role Nominal, but the arguments ‘Parser’ and ‘IdrisInnerParser’ differ arising from the coercion of the method ‘notFollowedBy’ from type ‘forall a. (Monad Parser, Show a) => Parser a -> Parser ()’ to type ‘forall a. (Monad IdrisInnerParser, Show a) => IdrisInnerParser a -> IdrisInnerParser ()’ Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Parsing IdrisInnerParser) }}} Answer: no they should not behave differently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8858: Wrong maxStkSize calculation
by GHC 17 Mar '14

17 Mar '14

#8858: Wrong maxStkSize calculation ------------------------------------+------------------------------------- Reporter: awson | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When fighting with #8839, I've found what I think is a bug in `maxStkSize` calculation: if `getPhysicalMemorySize` succeeds, we set `maxStkSize` in bytes, not words. It did not manifest itself yet, but I've decided to provide a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8878: Export runTcInteractive from TcRnDriver
by GHC 17 Mar '14

17 Mar '14

#8878: Export runTcInteractive from TcRnDriver -------------------------------------------+------------------------------- Reporter: holzensp | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- For people writing more involved code onto GHC than the normal API (GHC.hs) allows, this is a very useful function. In previous versions of GHC, it has always been unclear to me how I should run the type checker on, for example, a single expression, while keeping the context (i.e. when running the type checker again, the types derived in the former run should still be known in the latter). Simply having runTcInteractive exported does wonders for self-documentation purposes. (patch to follow shortly) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8878> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8888: Document Coercible in user's guide
by GHC 17 Mar '14

17 Mar '14

#8888: Document Coercible in user's guide ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Documentation | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As far as I can tell, there is no discussion of `Coercible` in the User's Guide. Although the interface to `coerce` is essentially a vanilla API, the generation of `Coercible` instances is a language feature, and I believe deserves to be included. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8888> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16