- ghc-tickets - Haskell.org

Re: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
by GHC 15 Sep '15

15 Sep '15

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+-------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Revisions: ---------------------------------+-------------------------------- Changes (by WrenThornton): * priority: normal => high * cc: wrengr (added) Comment: @oerjan Yes, I've long known about and documented this problem in the INSTALL/README file for the logfloat package. It's always been there in the repo and tarball, but hopefully is more visible now that Hackage has links to readme files. There used to be another ticket for this problem, though I lost the ticket number over the years so the readme only gives a short description of the problem (i'll add this ticket number to the readme once I get home). The long description of the situation so far as I'm aware/concerned is: For *compiled* code, everything works perfectly fine— without the need for Cygwin or Mingw/Msys or any of that. The problem is specifically with GHCi. The C functions that logfloat needs live in what posix calls "libm", thus we have "Extra-Libraries: m" in the cabal file. However, as nus mentions, MinGW's so-called "libm" file (which ships with GHC) is just a dummy header with no actual content; therefore the cabal file is useless here. The actual symbols/C-code lives in the libmingwex.a library (which also ships with GHC). When compiling, libmingwex.a is picked up automagically and so everything works; whereas when using the interpreter, libmingwex.a is ignored and the loading error is generated. This bug has been a thorn in my side for years. I don't use Windows, but I have many users who do and who have to work around the problem on a daily basis. The only feasible workaround at present is to compile logfloat without FFI support (thereby eliminating most of the precision which is the entire point of the library) in order to do any sort of interactive debugging or development, and then hopefully remembering to recompile logfloat and everything that depends on it (to get precision) before shipping. I really wish we could just get this fixed already so I don't have to explain the sorry state of things to yet another machine learning / natural language processing person just trying out Haskell. This really makes a terrible impression on folks :( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #229: Integer overflow in array allocation
by GHC 15 Sep '15

15 Sep '15

#229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by WrenThornton): * priority: normal => high * cc: wrengr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/229#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7175: Panic when wrongly using a type family as return types for GADTs
by GHC 14 Sep '15

14 Sep '15

#7175: Panic when wrongly using a type family as return types for GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.6.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T7175 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): We try to please :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7175#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7175: Panic when wrongly using a type family as return types for GADTs
by GHC 14 Sep '15

14 Sep '15

#7175: Panic when wrongly using a type family as return types for GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.6.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T7175 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Hooray! Hooray! Hooray! This fix is quite straightforward, of course, but somehow this dark corner has lurked a long time. Thanks. I no longer don armor and surround myself in a cloud of fear and loathing every time I need to think about editing `rejigConRes`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7175#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10880: The 'impossible' happend
by GHC 14 Sep '15

14 Sep '15

#10880: The 'impossible' happend -----------------------------------+--------------------------------------- Reporter: drever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: ia64 | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+--------------------------------------- The compiler told me to file this report. I hope this helps! {{{ drever$ cabal build Building xxx-0.0... Preprocessing library xxx-0.0... In-place registering xxx-0.0... Preprocessing executable 'xxx' for xxx-0.0... [21 of 21] Compiling Main ( src/main.hs, dist/build/xxx/xxx- tmp/Main.o ) src/main.hs:107:19: Couldn't match kind `* -> *' with `*' Expected type: FileName -> ReaderT XXXEnvironment IO t0 Actual type: FileName -> ReaderT XXXEnvironment IO t0 Kind incompatibility when matching types: FileName :: * -> * FileName :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs generatecode :: (Entity -> [EntitySample]) -> ReaderT MyEnvironment IO () generatecode sample = do domain_xsd <- lift xsdEntities "test" return () }}} {{{#!hs xsdEntities :: String -> IO [Entity] xsdEntities f = do maybeEntities <- runX ((XS.gettypes f) BaseWrite) return $ catMaybes $ concat maybeEntities }}} {{{#!hs gettypes :: String -> MyType -> IOSLA (XIOState s) a [Maybe S.Entity] gettypes f t = (cris f) >>> (arr $ filterExtends BaseWrite) >>> (arr getComplexTypes) >>> (arr (map complexTypeToEntity)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10880> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7830: Error: operand out of range
by GHC 14 Sep '15

14 Sep '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:29 erikd]: > I noticed that since the above numbers are using the bootstrap compiler with `-O0`. > > As a test, on PowerPC, changed `-O0` to `-O2` which cause the generated assembly file to grow to 302144 lines of code. > > At @rwbarton's suggestion added `NOINLINE` pragmas to `above_` and `beside_` functions in `compiler/utils/Pretty.hs` and now the assembler file for `compiler/cmm/PprC.hs` is 158390 lines. #8901 is a case where adding `NOINLINE` pragmas to the `time` library caused shrinkage in generated `.o` files by a factor ~5. Originally it also busted the 16-bit offsets on PPC32. Not sure whether the `time` maintainer followed my suggestions to add the pragmas or if everybody is just waiting for saner GHC inlining... :-( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7253: Top-level bindings in ghci
by GHC 14 Sep '15

14 Sep '15

#7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Reddit user "roshats" is also working on a patch for this: https://www.reddit.com/r/haskell/comments/3ks5mi/function_definition_in_ghc… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7253#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 14 Sep '15

14 Sep '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:29 erikd]: > At @rwbarton's suggestion added `NOINLINE` pragmas to `above_` and `beside_` functions in `compiler/utils/Pretty.hs` and now the assembler file for `compiler/cmm/PprC.hs` is 158390 lines. That worked when building the stage1 compiler using the bootstrap compiler, but it fails again when build the stage2 compiler with the stage1 compiler. The assembler file for `compiler/cmm/PprC.hs` compiled with the stage1 compiler is 220293 lines. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7253: Top-level bindings in ghci
by GHC 14 Sep '15

14 Sep '15

#7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > My first instinct was to treat declarations like "a = 1" in GHCI as equivalent to "let a = 1"; this would be a straightforward matter of parsing. On the other hand, as thoughtpolice comments, let-bound variables are treated subtly differently than top-level bindings, so the proper solution may be more involved. Would you like to elaborate on the "subtle difference"? Is it just `MonoLocalBinds`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7253#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10863: "hello world" produces illegal instruction error
by GHC 14 Sep '15

14 Sep '15

#10863: "hello world" produces illegal instruction error -----------------------------------+---------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+---------------------------------- I saw there was a new debian experimental package for 7.10.2, so I installed it on my raspberry pi 2, an arm v7 computer running debian jessie. Someone on twitter had some success with the package, but it didn't work for me. https://packages.debian.org/experimental/armhf/ghc/download See the attached file for versions of things, and test results. This is similar to another attempt where I installed the 7.10.2 binary available from the ghc website. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10863> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33