May 2018 - ghc-tickets

[GHC] #15205: Unnecessary equality superclass
by GHC 25 Jun '18

25 Jun '18

#15205: Unnecessary equality superclass -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 {{{ {-# LANGUAGE MultiParamTypeClasses, GADTs, TypeOperators #-} module Foo where class (a ~ b) => C a b where op :: a -> a -> b f :: C a b => a -> b f x = op x x }}} If you compile this you'll end up with {{{ f = \ (@ a_a1dk) (@ b_a1dl) ($dC_a1dn :: C a_a1dk b_a1dl) (eta_B1 :: a_a1dk) -> case GHC.Types.heq_sel @ * @ * @ a_a1dk @ b_a1dl ((Foo.$p1C @ a_a1dk @ b_a1dl $dC_a1dn) `cast` (Data.Type.Equality.N:~[0] <*>_N <a_a1dk>_N <b_a1dl>_N :: (a_a1dk ~ b_a1dl) ~R# (a_a1dk ~~ b_a1dl))) of co_a1dw { __DEFAULT -> op @ a_a1dk @ b_a1dl $dC_a1dn eta_B1 eta_B1 } }}} What is that unused `heq_sel` doing? It happens during solving * We have `[G] a ~ b` * And, by superclasses we have `[G] a ~# b` * We use this to rewrite `a` to `b` in both givens and wanteds which is all fine, but we end up with {{{ f = \ (@ a_a1dk) (@ b_a1dl) ($dC_a1dn :: C a_a1dk b_a1dl) -> case GHC.Types.heq_sel @ * @ * @ a_a1dk @ b_a1dl (Data.Type.Equality.$p1~ @ * @ a_a1dk @ b_a1dl (Foo.$p1C @ a_a1dk @ b_a1dl $dC_a1dn)) of co_a1dw { __DEFAULT -> \ (x_axX :: a_a1dk) -> op @ a_a1dk @ b_a1dl (($dC_a1dn `cast` ((C co_a1dw <b_a1dl>_N)_R :: C a_a1dk b_a1dl ~R# C b_a1dl b_a1dl)) `cast` ((C (Sym co_a1dw) <b_a1dl>_N)_R :: C b_a1dl b_a1dl ~R# C a_a1dk b_a1dl)) x_axX x_axX } }}} Notice that `co_a1dw` is used. But we are just casting and casting back, so it ends up as Refl and `co_a1dw` is unused. Nothing is wrong here, but it seems inelegant * Can we discard that `heq_sel`? Perhaps we can declare that dictionary- valued terms are always treated strictly (#2439), so that `(heq_sel ...)` is guaranteed non-bottom, and we can discard the case. * Or maybe we can expand the given superclasses less aggressively, so that the equality isn't exposed until necessary. But see `Note [Eagerly expand given superclasses]` in `TcCanonical`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14926: failed to build cross-compiler
by GHC 22 Jun '18

22 Jun '18

#14926: failed to build cross-compiler -------------------------------------+------------------------------------- Reporter: rueshyna | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm trying to build cross-compiler(ghc-8.4.1) but got an error. Target platform is 32-bit windows. Here is what I do: 1. pull docker image[1]: `docker pull gregweber/ghc-haskell-dev` 2. install gcc-mingw-w64-i686: `apt-get install gcc-mingw-w64-i686` 3. download ghc source and switch to tag ghc-8.4.1-release 4. run `./boot` 5. `CC=/usr/bin/i686-w64-mingw32-gcc ./configure --target=i686-w64-mingw32 --enable-unregisterised` 6. `cp mk/build.mk.sample mk/build.mk` 7. uncomment the line: `BuildFlavour = quick-cross-ncg` 8. run `make` Error message: {{{ Configuring ghc-pkg-6.9... "inplace/bin/mkdirhier" utils/ghc-pkg/dist/build/tmp//. "/opt/ghc/8.2.1/bin/ghc" -o utils/ghc-pkg/dist/build/tmp/ghc-pkg -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build -iutils/ghc- pkg/dist/build/ghc-pkg/autogen -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen -optP-include -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h -no-user-package-db -rtsopts -odir utils/ghc-pkg/dist/build -hidir utils/ghc-pkg/dist/build -stubdir utils/ghc-pkg/dist/build -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all- packages -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -Iutils/ghc- pkg/dist/build -iutils/ghc-pkg/dist/build/ghc-pkg/autogen -Iutils/ghc- pkg/dist/build/ghc-pkg/autogen -optP-include -optPutils/ghc- pkg/dist/build/ghc-pkg/autogen/cabal_macros.h -no-user-package-db -rtsopts -no-auto-link-packages -no-hs-main ghc: no input files Usage: For basic information, try the `--help' option. utils/ghc-pkg/ghc.mk:70: recipe for target 'utils/ghc-pkg/dist/build/tmp /ghc-pkg' failed make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 }}} If using `BuildFlavour = quick`, it works well. [1]https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#Docker -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12769: ghc: internal error: stg_ap_pp_ret
by GHC 22 Jun '18

22 Jun '18

#12769: ghc: internal error: stg_ap_pp_ret ----------------------------------------+---------------------------------- Reporter: kinnla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- appeared when building a project on macOS Sierra: https://github.com/Potregon/while/blob See attached log file (told me to report the bug) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12769> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11958: Improved testing of cross-compiler
by GHC 21 Jun '18

21 Jun '18

#11958: Improved testing of cross-compiler -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: task | Status: new Priority: low | Milestone: 8.2.1 Component: Test Suite | Version: 7.10.3 Keywords: cross-compile | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is already possible to build cross compiler eg from x86_64/linux to armhf/linux or arm64/linux, but there is currently no way to run the test suite. However, at least for the host and targets above, it should be possible to run the test executables under the Qemu user space emulation. I know this works, because in my own personal jenkins build instance, I test exactly this by doing (for x86_64/linux to amr64/linux cross): {{{ echo -e 'main :: IO ()\nmain = putStrLn "Hello World"\n' > hello-world.hs inplace/bin/ghc-stage1 hello-world.hs -o hello-world test $(file hello-world | grep -c 'ARM aarch64, version 1') -eq 1 ./hello-world }}} The linux machine I run the above test on is x86_64/linux but has Qemu and `binfmt` stuff set up so that it can run some foreign binaries. For instance, if GHC worked as a Linux to Windows cross-compiler the resulting windows binaries should work under Wine. To get this working, I suspect that just about all the required work is in the build system. Not sure if it might not be better to wait until the Shake based build system is in better shape. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14673: Unary Unboxed Tuple Type Constructor
by GHC 21 Jun '18

21 Jun '18

#14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 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: -------------------------------------+------------------------------------- The type constructor for a unary unboxed tuple cannot be written in GHC haskell. Consider the following value which is wrapped in by a unary unboxed tuple: {{{ >>> :type (# 5# #) (# 5# #) :: (# Int# #) }}} Now consider the type constructor for unboxed 2-tuples: {{{ >>> :set -fprint-explicit-kinds >>> :set -fprint-explicit-foralls >>> :kind! (# , #) (# , #) :: forall (k0 :: RuntimeRep) (k1 :: RuntimeRep). TYPE k0 -> TYPE k1 -> TYPE ('TupleRep ((':) RuntimeRep k0 ((':) RuntimeRep k1 ('[] RuntimeRep)))) = (#,#) }}} Horrid looking, but undoubtedly correct. But how can we do this for a unary unboxed tuple? The naive approach gives us the nullary tuple instead: {{{ >>> :kind! (# #) (# #) :: TYPE ('TupleRep ('[] RuntimeRep)) = (# #) }}} I do actually have a real use-case for this that I can discuss more if needed. For the syntax, I really haven't the faintest idea what I would expect. Maybe something like: `(## ##)` or `(# @1 #)`, but those both seem pretty bad. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #14617: Join point test join001 doesn't seem to be properly automated
by GHC 21 Jun '18

21 Jun '18

#14617: Join point test join001 doesn't seem to be properly automated -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test `join001` was presumably used for manual testing (poring over the Core by hand). Unfortunately, the test suite runs it in an utterly bland fashion that doesn't appear to check whether the join point transformation is working as intended. The other join point tests run in this fashion (`join005` and `join006`) include notes indicating that Core Lint will trip if the desired property doesn't hold; there is no such note here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14617> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14319: Stuck kind families can lead to lousy error messages
by GHC 21 Jun '18

21 Jun '18

#14319: Stuck kind families can lead to lousy error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeFamilies, TypeInType, ScopedTypeVariables #-} module ArityError where import Data.Kind import GHC.TypeLits import Data.Proxy type family F (s :: Symbol) :: Type type family G (s :: Symbol) :: F s type instance G "Hi" = Maybe }}} This produces the error message {{{#!hs ArityError.hs:10:24: error: • Expecting one more argument to ‘Maybe’ Expected kind ‘F "Hi"’, but ‘Maybe’ has kind ‘* -> *’ • In the type ‘Maybe’ In the type instance declaration for ‘G’ | 10 | type instance G "Hi" = Maybe | ^^^^^ }}} This looks utterly bogus: `F "Hi"` is stuck, so we have no idea what arity it indicates. What I ''think'' is a term level version of this, {{{#!hs f :: forall (s :: Symbol). Proxy s -> F s f _ = Just }}} gives a much less confusing message: {{{ ArityError.hs:14:7: error: • Couldn't match expected type ‘F s’ with actual type ‘a0 -> Maybe a0’ The type variable ‘a0’ is ambiguous • In the expression: Just In an equation for ‘f’: f _ = Just • Relevant bindings include f :: Proxy s -> F s (bound at ArityError.hs:14:1) | 14 | f _ = Just | ^^^^ }}} The fix (I think) is to refrain from reporting arity errors when we don't know enough about the relevant arities. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13724: Clamping of llvm llc to -O1 and -O2
by GHC 21 Jun '18

21 Jun '18

#13724: Clamping of llvm llc to -O1 and -O2 -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (LLVM) | 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: -------------------------------------+------------------------------------- We currently clamp the optimization level of llvm llc (3.9 and 4.0) within `[1,2]`. The reason is that with `-O0`, the naive register allocator can topple over with {{{ Error while trying to spill R1 from class GPR: Cannot scavenge register without an emergency spill slot! }}} and with `-O3` the `llvm::SelectionDAGISel::LowerArguments` may break, when compiling `rts/HeapStackCheck.cmm` with the stage1 ghc. {{{ 0 llc 0x0000000102ae63e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 llc 0x0000000102ae69a6 SignalHandler(int) + 358 2 libsystem_platform.dylib 0x00007fffc23f4b3a _sigtramp + 26 3 libsystem_c.dylib 0x00007fffc226498b __vfprintf + 17876 4 llc 0x00000001029d5123 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) + 5699 5 llc 0x0000000102a21a35 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3381 6 llc 0x0000000102a202b1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1457 7 llc 0x0000000101bdc474 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20 8 llc 0x00000001025573a6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134 9 llc 0x000000010274fb12 llvm::FPPassManager::runOnFunction(llvm::Function&) + 498 10 llc 0x000000010274fd23 llvm::FPPassManager::runOnModule(llvm::Module&) + 67 11 llc 0x00000001027501b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 920 12 llc 0x000000010195f075 compileModule(char**, llvm::LLVMContext&) + 12133 13 llc 0x000000010195bf0b main + 491 14 libdyld.dylib 0x00007fffc21e5235 start + 1 Stack dump: 0. Program arguments: llc -O3 -mtriple=arm-unknown-linux-gnueabihf -enable-tbaa /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module '/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"' }}} `opt` and `llc` should respect `-opt_lo` and `-opt_lc`, such that `-opt_lc=-O3` can be used to validate the behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14413: Profiling breaks determinism
by GHC 21 Jun '18

21 Jun '18

#14413: Profiling breaks determinism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: determinism | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking at #5889 I noticed that `CostCentre` currently includes a `Unique` (although it's represented as an `Int` for reasons that aren't relevant here; I change this in Phab:D4148). This unique identifies the cost centre and appears to be derived from the unique of a binder. This presumably breaks determinism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13240: Make it easier to find builds we may want to cancel
by GHC 21 Jun '18

21 Jun '18

#13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Trac & Git | Version: 8.0.1 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: -------------------------------------+------------------------------------- I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples: 1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest. 2. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific. 3. Only documentation files have changed. Building these on one platform should be sufficient. 4. A differential was closed by a commit. Only the most recent build will be useful, if that. It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6