- ghc-tickets - Haskell.org

Re: [GHC] #7830: Error: operand out of range
by GHC 04 Oct '15

04 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Thanks erikd! Applied to `ghc-7.10` as e22d7dc434b64709a4b19b11f2e0a41676c04035. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10071: Implement warnings for class-method overriding
by GHC 04 Oct '15

04 Oct '15

#10071: Implement warnings for class-method overriding -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: AMP | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #8004, #4384 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This would aid long-term transitions like phasing out `Monad(return)` (in the spirit of #4834): With the AMP, `Monad(return)` being a class method becomes an historic artifact. The ideal long-term situation would rather be to have `return` become a top-level definition (i.e. outside the `Monad`-class), generalised to `Applicative` just aliasing `Applicative(pure)`, i.e. {{{#!hs return :: Applicative f => a -> f a return = pure }}} This may be beneficial for things like ApplicativeDo which otherwise would require a `return` to be handled is if it was `pure` in order to weaken the type-constraint in an `do`-expression like e.g. {{{#!hs do { x <- f; return (fst x) } }}} Right now, we can attach a `DEPRECATE`-pragma to the `return`-class- method. That however would trigger warnings on ''all'' uses of `return`, rather than only when using `return` in a context that requires it to be a class-method (like overriding `return` in instance definitions, or importing/exporting it via the explicit `Monad(return)`-syntax) Instead we need a way to warn about such uses of `return` which assume it to be a class-method, in order to phase out such uses. NB: This will probably require additional discussions, but we shouldn't wait too long, if we want to integrate the AMP into a future Haskell Report (for which we should try to clean up historic warts such as `Monad(return)` if feasable). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #2119: explicitly importing deprecated symbols should elicit the deprecation warning
by GHC 04 Oct '15

04 Oct '15

#2119: explicitly importing deprecated symbols should elicit the deprecation warning -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4879 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): See [[Design/DeprecationMechanisms]] for a summary of this and related deprecation proposals. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2119#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4879: Deprecate exports
by GHC 04 Oct '15

04 Oct '15

#4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: infoneeded Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10071 #2119 | Differential Rev(s): Phab:D638 -------------------------------------+------------------------------------- Comment (by bgamari): See [[Design/DeprecationMechanisms]] for a summary of this and related deprecation proposals. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4879#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10909: Test suite: Support non-utf8 locale
by GHC 04 Oct '15

04 Oct '15

#10909: Test suite: Support non-utf8 locale -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In order to properly test #10907, it should be possible to specify a locale (or at least some representative values like “non-utf8-locale” and “utf8-locale” in the options of a test. Currently, the test suite runs completely in an utf8-locale. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7830: Error: operand out of range
by GHC 04 Oct '15

04 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Comment (by erikd): I've attached a version of @trommler's patch for the 7.10 branch. WIth this patch applied to ghc-7.10.2, that compiler can build git HEAD again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 04 Oct '15

04 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7830: Error: operand out of range
by GHC 04 Oct '15

04 Oct '15

#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by erikd): * Attachment "0001-nativeGen-PPC-fix-16-bit-offsets-in-stack- handling.patch" added. Patch for 7.10 branch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows
by GHC 04 Oct '15

04 Oct '15

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows ----------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- I work on a Haskell library interfacing with foreign C++ library. While trying to use it in GHCi on Windows 8.1 64bit, I encountered an error message that said: {{{ <loading other libraries> Loading package library-0.1.0.0 ... <interactive>: Unknown PEi386 section name ` .text$_ZNSt6vectorIcSaIcEED1Ev' (while processing: c:\path\to\file.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-mingw32): loadObj "C:\\path\\to\\file.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've prepared a minimal example triggering this bug and attached it to this bug report. On Linux (Arch 64bit), after cabal build and cabal repl it behaves as intended: {{{ 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. Loading object (static) dist/build/cbits/ex.o ... done final link ... done [1 of 1] Compiling Example ( Example.hs, interpreted ) Ok, modules loaded: Example. λ: foo Test }}} However, on Windows 8.1 it crashes while loading object file: {{{ 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. Loading object (static) dist\build\cbits\ex.o ... ghc.exe: Unknown PEi386 sectio n name `.text$printf' (while processing: dist\build\cbits\ex.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-mingw32): loadObj "dist\\build\\cbits\\ex.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Crashing in GHCi means that I cannot use it with programs that contain TH splices, what is important for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom
by GHC 04 Oct '15

04 Oct '15

#10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom -----------------------------------------+--------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- {{{ [ 4 of 11] Compiling Reflex.Dom.Internal ( src\Reflex\Dom\Internal.hs, dist\build\Reflex\Dom\Internal.o ) ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 00000000184b3978 (GHC version 7.10.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This happens with unmodified reflex-dom.cabal (which specifies -funbox- strict-fields and -O2) and also with all ghc-options: flags removed and -O or -O0. When compiling with the bundled mingw it also pops up a GUI error window: {{{ ghc.exe - Entry Point Not Found The procedure entry point pthread_cond_timedwait_relative_np could not be located in the dynamic link library libwinpthread-1.dll. }}} I also tried using a fully-updated mingw64 from MSYS2, which has solved -pthread issues for me in the past, but that simply crashes with no additional message. Verbose cabal output attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8