November 2016 - ghc-tickets

[GHC] #12075: Fails to build on powerpcspe because of inline assembly
by GHC 05 Jun '18

05 Jun '18

#12075: Fails to build on powerpcspe because of inline assembly --------------------------------+---------------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Hello! I'm currently bootstrapping GHC on powerpcspe (e500v2) which is a PowerPC architecture without an FPU but with signal processing extensions (hence SPE). When building GHC on this architecture, it detects the host architecture as powerpc-linux-gnuspe or short "powerpc" which works most of the time. However, GHC contains some inline assembly in rts/StgCRunAsm.s which uses FPU instructions not available on e500v2 CPUs resulting in assembler error, here with GHC 7.10.3: {{{ "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing- declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist- derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc- Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc- DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/autogen -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-w -static -H32m -O -lffi -optl-pthread -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgCRun.c -o rts/dist/build/StgCRun.o /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /tmp/ghcf20d_0/ghc_1.s: Assembler messages: /tmp/ghcf20d_0/ghc_1.s:24:0: Error: unrecognized opcode: `stfd' (...) /tmp/ghcf20d_0/ghc_1.s:67:0: Error: unrecognized opcode: `lfd' /tmp/ghcf20d_0/ghc_1.s:68:0: Error: unrecognized opcode: `lfd' /tmp/ghcf20d_0/ghc_1.s:69:0: Error: unrecognized opcode: `lfd' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgCRun.o' failed make[3]: *** [rts/dist/build/StgCRun.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/usr/src/ghc-7.10.3' dh_auto_build: make -j1 returned exit code 2 debian/rules:109: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/usr/src/ghc-7.10.3' debian/rules:47: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2 (sid2-powerpcspe-sbuild)root@atlantis:/usr/src/ghc-7.10.3# }}} This can be verified by commenting out the assembly which will make the above compile command execute without any problems. Trying to continue compiling GHC will still fail with: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) /tmp/ghcca51_0/ghc_3.s: Assembler messages: /tmp/ghcca51_0/ghc_3.s:525:0: Error: unrecognized opcode: `lfs' /tmp/ghcca51_0/ghc_3.s:538:0: Error: unrecognized opcode: `lfd' /tmp/ghcca51_0/ghc_3.s:592:0: Error: unrecognized opcode: `stfs' /tmp/ghcca51_0/ghc_3.s:604:0: Error: unrecognized opcode: `stfd' rts/ghc.mk:236: recipe for target 'rts/dist/build/HeapStackCheck.o' failed make[3]: *** [rts/dist/build/HeapStackCheck.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/usr/src/ghc-7.10.3' dh_auto_build: make -j1 returned exit code 2 debian/rules:109: recipe for target 'override_dh_auto_build' failed make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory '/usr/src/ghc-7.10.3' debian/rules:47: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2 (sid2-powerpcspe-sbuild)root@atlantis:/usr/src/ghc-7.10.3# }}} So, there is obviously more assembly code that needs to be disabled on powerpcspe. For that, I suggest testing whether the compiler sets __NO_FPRS__which is only set on powerpc hosts without FP registers: {{{ root@atlantis:~# echo | gcc -E -dM -|grep -i FP #define __NO_FPRS__ 1 root@atlantis:~# dpkg --print-architecture powerpcspe root@atlantis:~# uname -m ppc root@atlantis:~# }}} For reference, on a real powerpc host, the output is as follows: {{{ (sid_powerpc-dchroot)glaubitz@partch:~$ echo | gcc -E -dM -|grep -i FP #define __FP_FAST_FMAF 1 #define __FP_FAST_FMA 1 (sid_powerpc-dchroot)glaubitz@partch:~$ dpkg --print-architecture powerpc (sid_powerpc-dchroot)glaubitz@partch:~$ uname -m ppc (sid_powerpc-dchroot)glaubitz@partch:~$ }}} If you need any more input, please let me know. Adrian -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics
by GHC 04 Jun '18

04 Jun '18

#8516: Add (->) representation and the Invariant class to GHC.Generics ----------------------------------------------+---------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- We currently disallow any use of the parameter in the domain of (->). {{{ newtype F a = F ((a -> Int) -> Int) deriving Generic1 <interactive>:4:38: Can't make a derived instance of `Generic1 (F g)': Constructor `F' must use the last type parameter only as the last argument of a data type, newtype, or (->) In the data declaration for `F' }}} !DeriveFunctor succeeds for this F. I'd like to add this representation type to GHC.Generics and !DeriveGeneric. {{{ newtype (f :->: g) a = FArrow1 (f a -> g a) }}} We could then represent the first example above. We could also derive the more interesting Generic1 (F g). {{{ newtype F g a = F (g a -> Int) deriving Generic1 type instance Rep1 (F g) = Rec1 g :->: Rec0 Int instance Generic1 (F g) where to x = F $ unRec0 . unArrow1 x . Rec1 from (F x) = FArrow1 $ Rec0 . x . unRec1 }}} Admittedly, there's not many generic definitions impeded by not having (:->:). Contra- and in-variant types are uncommon. I'm suggesting this feature without strong motivating examples because I think this would streamline the implementation of -XDeriveGenerics in some ways while also making it more general — assuming that we added the Invariant class to base or ghc-prim. {{{ class Invariant t where invmap :: (a -> b) -> (b -> a) -> t a -> t b invmap_covariant :: Functor t => (a -> b) -> (b -> a) -> t a -> t b invmap_covariant f _ = fmap f instance (Invariant f,Invariant g) => Invariant (FArrow f g) where invmap co contra (FArrow h) = FArrow $ invmap co contra . h . invmap contra co }}} (Of course, Invariant should be a super class of Functor. :/ ) Now we can handle quite involved examples: {{{ newtype F g h a = F (g (h a)) deriving Generic1 instance Invariant g => Generic1 (F g h) where to x = invmap unRec1 Rec1 $ unComp1 x from (F x) = Comp1 $ invmap Rec1 unRec1 }}} All of that said, I'm mostly opening this ticket so I can get feedback on difficulties I might not be anticipating and have a place to reference from the compiler source code comments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8516> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12152: panic: Loading temp shared object failed
by GHC 03 Jun '18

03 Jun '18

#12152: panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Linking) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've attached a no-Haskell-code project that fails when I run `cabal repl` with the following: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc60744_0/libghc_1.so: undefined symbol: _ZN2Zq1qE }}} Building the project works fine, so the problem seems to be (only) with dynamic linking. The issue can be resolved by swapping the order of the .cpp files in the cabal file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9247: Document -XDatatypeContexts in flag reference
by GHC 03 Jun '18

03 Jun '18

#9247: Document -XDatatypeContexts in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Documentation | 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: | ------------------------------------+------------------------------------- It may be a deprecated feature, but it still exists and should be listed. I can do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness?
by GHC 03 Jun '18

03 Jun '18

#11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10.2 reports inaccessible branches as a type error, and I think this is really a bug. First, the implicit thinking seems to be "why would a user want to write inaccessible cases, they'd be crazy!". But that only applies to human-written code. Program generators can have a great deal of trouble avoiding this error, unless they replicate the GHC type checker to predict the problem and prune branches. (That's why we are hitting this error and are stuck.) Second, it seems like this is a problem for type soundness. See the attached program where "step1" typechecks but "step2" does not. And yet, the operational semantics should allow step1 to reduce to step2. Indeed, in the "GADTs meet their match" paper it seems like the intent was to warn for these inaccessible cases, not error. For example, the paper contains the language: "If we warn that a right-hand side of a non-redundant clause is inaccessible," -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #9724: reexport IsList class from a trustworthy module
by GHC 01 Jun '18

01 Jun '18

#9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ==== Motivation GHC's Safe Haskell extension relies to a large extent on inferring safety of modules automatically. As a concrete example, [[http://hackage.haskell.org/package/data-default|data-default]] used to be inferred safe. This is no longer the case, because [[http://hackage.haskell.org/package/dlist-0.7.1|dlist-0.7.1]] added an {{{IsList}}} instance for difference lists. The only way to do that currently is to import the relevant parts of {{{GHC.Exts}}}, and that module is not safe. Of course the resulting non-safety of the {{{Data.DList}}} module can be fixed by adding a {{{TrustWorthy}}} pragma to the module and trusting the {{{dlist}}} package. But that is unsatisfactory, because there is nothing unsafe about providing an instance for the {{{IsList}}} class. This issue is bound to pop up in other packages as well. ==== Proposed Solution (this is one of many possibilities) Add a {{{GHC.Exts.Safe}}} module that is marked {{{TrustWorthy}}} and reexports the {{{IsList}}} class, and possibly other things from {{{GHC.Exts}}} that are safe to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9479: Report required constraints when reporting the type of a hole
by GHC 31 May '18

31 May '18

#9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: dominiquedevriese | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: holes | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For the following code {{{ module Test where test :: String test = show _h }}} GHC currently reports: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Applicable constraints: Show a0 Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS
by GHC 30 May '18

30 May '18

#12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this bare-bones module {{{#!hs {-# OPTIONS -fplugin GHC.TypeLits.Normalise #-} module A where }}} compiling it will always say {{{ $ ghc --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) [GHC.TypeLits.Normalise changed] }}} even when the module was compiled before. {{{ $ ghc A.hs -c -ddump-if-trace -ddump-hi-diffs }}} will give the reason: {{{ imported module ‘GHC.TypeLits.Normalise’ is from package ‘ghc-typelits- natnormalise-0.5’, which is not among previous dependencies }}} Which is the probable cause: when writing the `.hi` file, the used plugins' package dependencies should be also written out. AFAICS they are extracted fron the `DynFlags` but for this comparison in {{{ checkDependencies :: HscEnv -> ModSummary -> ModIface -> IfG RecompileRequired }}} but not found in the `ModSummary` that was originally written to disk. This is pretty nasty for `clash` compilations and the suspected bug is documented here: https://github.com/clash-lang/ghc-typelits- natnormalise/issues/2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9438: panic: loading archives not supported
by GHC 29 May '18

29 May '18

#9438: panic: loading archives not supported ----------------------------------+---------------------------------- Reporter: egl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------- Running {{{ ghci -L/opt/local/lib -latlas }}} eventually leads to {{{ Loading object (static archive) /opt/local/lib/libatlas.a ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading archives not supported Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This looks similar to 8164 and 4828, which are marked closed. Mac OSX 10.9.4 Xcode 5.1.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10843: Allow do blocks without dollar signs as arguments
by GHC 29 May '18

29 May '18

#10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would like the following to be valid Haskell code: {{{#!hs main = when True do putStrLn "Hello!" }}} Instead of requiring a dollar sign before the "do". This would parse as {{{#!hs main = when True (do putStrLn "Hello!") }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48