November 2014 - ghc-tickets

[GHC] #9796: Implement amap/coerce rule for `Array`
by GHC 16 Nov '14

16 Nov '14

#9796: Implement amap/coerce rule for `Array` -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We have `map/coerce`; there's no reason not to have `amap/coerce` as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8798: Missing symbols with -fprof-auto-calls
by GHC 16 Nov '14

16 Nov '14

#8798: Missing symbols with -fprof-auto-calls ------------------------------------+------------------------------------- Reporter: edsko | 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: | ------------------------------------+------------------------------------- To reproduce: in an empty environment (no packages installed), run {{{ cabal install --only-dependencies --enable-library-profiling --ghc-option =-fprof-auto-calls }}} for the attached test case. This will seem to work okay (no errors), but if you then do {{{ cabal configure --enable-executable-profiling --enable-library-profiling --ghc-option=-fprof-auto-calls }}} then {{{ cabal build }}} will fail with {{{ Building autocallsbug-0.1.0.0... Preprocessing executable 'autocallsbug' for autocallsbug-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/autocallsbug /autocallsbug-tmp/Main.p_o ) Linking dist/build/autocallsbug/autocallsbug ... Undefined symbols for architecture x86_64: "_attoparseczm0zi11zi1zi0_DataziAttoparsecziInternalziTypes_manyzimanyzuv_Cb_cc", referenced from: _sR1Q_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) _sR5p_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} (Haven't yet confirmed with 7.8RC1 because that failed to build on my system; reported separately.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC
by GHC 16 Nov '14

16 Nov '14

#9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC ----------------------------------+---------------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I followed “First steps” section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9800: Panic when building HEAD with BuildFlavour=quickest: "Can't use Integer in integer-*"
by GHC 16 Nov '14

16 Nov '14

#9800: Panic when building HEAD with BuildFlavour=quickest: "Can't use Integer in integer-*" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ $ uname -op x86_64 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ git log --oneline | head -1 fa75309 Update .mailmap $ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -this-package-key integ_2MbWUstH60IEgCAexOk3v3 -hide-all-packages -i -ilibraries/integer-gmp2/src/ -ilibraries/integer-gmp2/dist- install/build -ilibraries/integer-gmp2/dist-install/build/autogen -Ilibraries/integer-gmp2/dist-install/build -Ilibraries/integer-gmp2/dist- install/build/autogen -Ilibraries/integer-gmp2/include -optP-include -optPlibraries/integer-gmp2/dist-install/build/autogen/cabal_macros.h -package-key ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -this-package-key integer-gmp -Wall -XHaskell2010 -O0 -fasm -no-user-package-db -rtsopts -odir libraries/integer-gmp2/dist-install/build -hidir libraries/integer-gmp2 /dist-install/build -stubdir libraries/integer-gmp2/dist-install/build -dynamic-too -c libraries/integer-gmp2/src//GHC/Integer/Type.hs -o libraries/integer-gmp2/dist-install/build/GHC/Integer/Type.o -dyno libraries/integer-gmp2/dist-install/build/GHC/Integer/Type.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20141114 for x86_64-unknown-linux): Can't use Integer in integer-* Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/integer-gmp2/dist- install/build/GHC/Integer/Type.o] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9192: Add sameByteArray#
by GHC 15 Nov '14

15 Nov '14

#9192: Add sameByteArray# ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We have `sameMutableByteArray#` so we ought to have `sameByteArray#` as well, allowing for cheap equality checks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9197: FFI types should be usable in foreign import decls without revealing representations
by GHC 15 Nov '14

15 Nov '14

#9197: FFI types should be usable in foreign import decls without revealing representations ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This is another go at #5529 but with, we hope, clearer and better arguments. The original FFI spec defined a whole bunch of FFI types that are acceptable in foreign import/export declarations, including lots of things defined in Foreign.C.*. The original spec defined these as abstract types. The original FFI spec also allowed for automatic newtype unwrapping in foreign declarations. In 2009 Simon PJ [pointed out http://www.haskell.org/pipermail/haskell-prime/2009-February/002726.html] that automatic newtype unwrapping breaks abstraction for user-defined types. In that same thread [I suggested http://www.haskell.org/pipermail /haskell-prime/2009-February/002727.html] that the breaking of abstraction for user types should be fixed, but that the intent of the FFI spec to have the FFI types as abstract should be kept. Manuel [argued http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html] that the C FFI types should actually not be abstract, and thus no special case for them was needed. On the basis of that thread the decision in #5529 was to only allow FFI decls to look through newtypes when the constructor is available, plus for a few types GHC uses to represent the C FFI types, like Int32 etc. Johan and I want to argue that it still makes sense as a user to not be forced into knowing the representation of the C FFI types to be able to use them. This is similar to but slightly weaker than the rationale of the FFI spec originally making those types abstract. Manuels argument is essentially that sometimes you need to know concrete types when those can change, e.g. CInt might be Int32 or Int64 and you should be free to depend on that difference. Manuel's argument is fine when the "concrete" representation exists as yet another portable type, as is the case for Int32. Of course we don't insist that the representation for Int or Int32 be exposed, in large part because they cannot have a Haskell implementation independent representation. The important point is Johan and I are defining/writing a portable low level ByteArray library that could be considered alongside the FFI's definition of some of the Foreign.* libraries: it defines and API for some low level types and functions but different Haskell implementations will implement them differently. For GHC we implement `data ByteArray = BA ByteArray#`. We want to make this an FFI type, in the same sense as the FFI spec defines the C types to be FFI types. (You could consider our library as a Haskell extension and implementations following this extension will support this type for FFI in a similar way to the FFI spec). Of course for this implementation of `ByteArray` the representation crosses the boundary into implementation dependent, unlike the case for `newtype CInt = CInt Int32` where both are still portable types. So, we think the right thing to do is to again be able to declare certain types (those defined in the FFI spec and its extensions) as being valid types to use in FFI decls, without their constructors being available. Thus users could choose to import `CInt` only (i.e. without its constructor) and use it. We are not arguing against Manuel's point that it's sometimes useful to not hide representations where that is possible (like for CInt being an Int32 or 64). So we are not asking that the C FFI types be made abstract again, just that it be possible to use them (and our new type) as FFI types without user access to the constrctor. For GHC, my suggestion for a reasonable way to do this is with a pragma. The pragma would say that this single-constrcutor single-field newtype or data is an FFI type, and that GHC may perform the usual newtype unwrapping even when the constructor is not in scope at the FFI decl site. We would then use this pragma on Int, Int32 and other core GHC (and FFI) types, and also on the various C FFI types. And finally, we would also do this on our ByteArray type. Note that it would have to cover data as well as newtype to be able to work for Int and other boxed wrappers of unboxed types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9802: A ghci bug
by GHC 15 Nov '14

15 Nov '14

#9802: A ghci bug -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: :force :type | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Prelude> let a = [1,2,3] (0.00 secs, 0 bytes) Prelude> :t a a :: Num t => [t] Prelude> :force a a = _ Prelude> a [1,2,3] (0.02 secs, 3580816 bytes) Prelude> :print a a = (_t1::Num t => [t]) Prelude> :t _t1 ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): tcTyVarDetails t{tv auB} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 15 Nov '14

15 Nov '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 15 Nov '14

15 Nov '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D476 Comment: It's up for review at Phab:D476! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 14 Nov '14

14 Nov '14

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac | Owner: Dupree | Status: new Type: feature | Milestone: ⊥ request | Version: 6.10.2 Priority: normal | Keywords: backpack Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9256 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9256 Comment: See #9256 for a recent proposal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0