November 2018 - ghc-tickets

[GHC] #15702: "-main-is" flag is broken for recent ghc-head
by GHC 17 Nov '18

17 Nov '18

#15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a minimal reproduction: Main.hs: {{{ main :: IO () main = putStrLn "Main" }}} Main2.hs: {{{ module Main2 where import Main main2 :: IO () main2 = do putStrLn "Main2" main }}} Run ghc with something like `/home/terrorjack/.stack/programs/x86_64-linux/ghc-8.7.20181003/bin/ghc -main-is Main2.main2 Main.hs Main2.hs`, and it reports the following error: {{{ [1 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:1:1: error: Not in scope: ‘main2’ Perhaps you meant ‘main’ (line 2) | 1 | main :: IO () | ^ }}} Meanwhile, the exact same flags work for ghc-8.6.1, and also a previous ghc-head build on d90946cea1357d3e99805c27dab1e811785a4088, so some accidental breakage might be in a recent commit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13704: -main-is flag should change exports in default module header
by GHC 17 Nov '18

17 Nov '18

#13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- The -main-is option to GHC should probably change the export list for the default module header. It doesn't. {{{ $ cat Main.hs program = return () $ ghc -main-is Main.program Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:1:1: error: Not in scope: ‘main’ Perhaps you meant ‘min’ (imported from Prelude) Main.hs:1:1: error: The main IO action ‘program’ is not exported by module ‘Main’ }}} I cannot imagine any possible use case for a feature that changes the entry point name to something else, and then deliberately fails to export the symbol by that name. This seems like an obvious thing to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11477: Remove -Wamp
by GHC 17 Nov '18

17 Nov '18

#11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This warning is intended as a temporary measure to aid the Applicative- Monad Proposal transition. It should be eventually removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15879: Make UniqDSet a newtype
by GHC 17 Nov '18

17 Nov '18

#15879: Make UniqDSet a newtype -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13114 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For the same reasons as in #13114 and Phab:D3146 we should make `UniqDSet` a newtype of `UniqDFM`. I wonder if we can also have a prettier `Outputable` instance this way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15124: Improve block layout for the NCG
by GHC 17 Nov '18

17 Nov '18

#15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (NCG) | Keywords: CodeGen | 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 current codegen tries to place two blocks A and B next to each other if they are "close". = Drawbacks of the current algorithm Blocks are only considered close if one jumps to the other via a unconditional jump instructions. This is a fast and reasonable approximation. But we might be able to do better. == Calls are not considered even if they always return to the same block. For example it's clear that if foo == bar we jump to C here: {{{ A: movq $block_C_info,-16(%rbp) cmp foo,bar jne D B: jmp *(%rbx) #Returns to C ... .align 8 .infotable block_C_info: C: doThings }}} == Conditional jumps are never considered. The following block either jumps directly to c3mQ or returns there from a call. Yet that is completely ignored by the current algorithm. {{{ _c3mG: movq $block_c3mQ_info,-8(%rbp) ... jne _c3mQ jmp *(%rbx) #returns to c3mQ }}} == Likelyhood of branches is not considered. We track information about branches which are rarely taken at the cmm level. However this information is currently lost during the Cmm -> Asm transformation which happens before we do code layout. This means for Cmm code where one branch is never executed the branch that's never executed might be the only one considered relevant. This happens for example for this stack check: {{{ if ((Sp + -40) >= SpLim) (likely: True) goto c5PS; else goto c5Q3; }}} = Potential gains If nothing else this would allow some Cmm optimizations which are made useless by the current code layout algorithm. I have hit cases where the block layout algorithm turned optimizations into pessimizations of 2-5% by pulling obvious loops apart. Given that the scenario that leads to loops being pulled apart doesn't seem that unlikely I assume some loops are also pulled apart like this in HEAD. Cleaning this up ideally would also make it possible to move blocks which are not part of loops out of them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15909: prepareAlts does not take into account equalities which are in scope
by GHC 16 Nov '18

16 Nov '18

#15909: prepareAlts does not take into account equalities which are in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- If we consider this program submitted for our consideration by Andres we see some surprising behaviour. https://gist.github.com/kosmikus/237946a2335600690208a4a36efef988 {{{ {-# LANGUAGE TypeOperators, GADTs, FlexibleContexts, DataKinds, RankNTypes, PolyKinds, TypeFamilies, MultiParamTypeClasses, UndecidableInstances, UndecidableSuperClasses, FlexibleInstances, ConstraintKinds, TypeApplications, EmptyCase, ScopedTypeVariables, PartialTypeSignatures, TemplateHaskell #-} module Partition where import Data.Coerce import Data.Kind import Data.Proxy data NP (f :: k -> Type) (xs :: [k]) where Nil :: NP f '[] (:*) :: f x -> NP f xs -> NP f (x : xs) infixr 5 :* strictToPair :: forall f a b . NP f '[a, b] -> (f a, f b) strictToPair np = case np of (fx :* fxs) -> case (fxs {- :: NP f '[b] -}) of (fy :* fys) -> (fx, fy) }}} Both pattern matches are exhaustive so we don't need to generate any failure cases when pattern matching. Notice in the generated core that we have a match on `Partition.Nil` even though the match will never be reached. {{{ Partition.strictToPair :: forall k (f :: k -> *) (a :: k) (b :: k). Partition.NP f '[a, b] -> (f a, f b) [GblId, Arity=1, Str=<S,1*U>m, Unf=OtherCon []] Partition.strictToPair = \ (@ k_a1gV) (@ (f_a1gW :: k_a1gV -> *)) (@ (a_a1gX :: k_a1gV)) (@ (b_a1gY :: k_a1gV)) (np_s1yz [Occ=Once!] :: Partition.NP f_a1gW '[a_a1gX, b_a1gY]) -> case np_s1yz of { Partition.:* @ x_a1h2 @ xs_a1h3 co_a1h4 fx_s1yB [Occ=Once] fxs_s1yC [Occ=Once!] -> case fxs_s1yC of { Partition.Nil _ [Occ=Dead, Dmd=<B,A>] -> Partition.strictToPair1 @ k_a1gV @ a_a1gX @ f_a1gW @ b_a1gY; Partition.:* @ x1_a1h7 @ xs1_a1h8 co1_a1h9 fy_s1yE [Occ=Once] _ [Occ=Dead] -> (fx_s1yB `cast` (<f_a1gW>_R (Nth:1 (Sym co_a1h4)) :: (f_a1gW x_a1h2 :: *) ~R# (f_a1gW a_a1gX :: *)), fy_s1yE `cast` (<f_a1gW>_R (Nth:1 (Sym co1_a1h9 ; Nth:2 (Sym co_a1h4))) :: (f_a1gW x1_a1h7 :: *) ~R# (f_a1gW b_a1gY :: *))) } } }}} This is because in `prepareAlts` are try to inspect the type of `fxs` which looks like a type variable, however it has since been refined by the pattern match on `np` above. Adding the explicit type signature to `fxs` makes `prepareAlts` treat it correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15900: Can't boot with GHC 8.6.2
by GHC 16 Nov '18

16 Nov '18

#15900: Can't boot with GHC 8.6.2 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 just installed GHC 8.6.2 on a fresh Ubuntu 18.04 and cloned the repo. This is what I get when I do `make` without a `build.mk`: {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id Cabal-2.4.0.1 -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.1 -package-id filepath-1.4.2.1 -package-id ghc-8.7 -package-id ghc-boot-8.7 -package-id parsec-3.1.13.0 -package-id text-1.2.3.1 -package-id transformers-0.5.5.0 -package-id xhtml-3000.2.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no- user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-api/src/Haddock/Types.hs -o utils/haddock/dist/build/Haddock/Types.dyn_o utils/haddock/haddock-api/src/Haddock/Types.hs:385:37: error: • Data constructor not in scope: NotPromoted :: BasicTypes.PromotionFlag • Perhaps you want to add ‘NotPromoted’ to the import list in the import of ‘BasicTypes’ (utils/haddock/haddock-api/src/Haddock/Types.hs:37:1-30). | 385 | tvar = L loc (HsTyVar NoExt NotPromoted (L loc name)) | ^^^^^^^^^^^ utils/haddock/haddock-api/src/Haddock/Types.hs:386:47: error: • Data constructor not in scope: NotPromoted :: BasicTypes.PromotionFlag • Perhaps you want to add ‘NotPromoted’ to the import list in the import of ‘BasicTypes’ (utils/haddock/haddock-api/src/Haddock/Types.hs:37:1-30). | 386 | mkType (UserTyVar _ name) = HsTyVar NoExt NotPromoted name | ^^^^^^^^^^^ utils/haddock/ghc.mk:20: recipe for target 'utils/haddock/dist/build/Haddock/Types.dyn_o' failed make[1]: *** [utils/haddock/dist/build/Haddock/Types.dyn_o] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15907: memo001 causes compile time panic with fails with -O -dannot-lint
by GHC 16 Nov '18

16 Nov '18

#15907: memo001 causes compile time panic with fails with -O -dannot-lint -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- {{{ $ cd libraries/base/tests; ghc-stage2 memo001.hs -O -dannot-lint [1 of 2] Compiling Memo1 ( Memo1.lhs, Memo1.o ) [Optimisation flags changed] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181116 for x86_64-unknown-linux): idInfo val_a3pf Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:567:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15898: Promoted type constructors don't print right in HsType
by GHC 16 Nov '18

16 Nov '18

#15898: Promoted type constructors don't print right in HsType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 {{{ ghci> import Data.Proxy ghci> undefined :: '() -> Int <interactive>:11:14: error: • Expected a type, but ‘ '()’ has kind ‘()’ • In an expression type signature: '() -> Int }}} What is that strange space doing before the `'()`? Similarly {{{ undefined :: Proxy '() Int <interactive>:12:14: error: • Expected kind ‘* -> *’, but ‘Proxy '()’ has kind ‘*’ • In an expression type signature: Proxy '() Int }}} Again, the strange space. It comes from the `HsType` pretty printer, which is worried about printing the type {{{ '['K] }}} That is, a promoted list with one element `K`. The trouble is that looks like a character literal `'['`. So we add an extra space, thus `'[ 'K]`. ''But we add it before every promoded data constructor!" Hence the spurious spaces. In `IfaceType` exactly the same thing happens, but we are more clever, and only print the leading space if the promoted data con immediately follows `'[` or `'(`. We should do the same thing for `HsType`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15903: Assertion failure in LDV profiler
by GHC 16 Nov '18

16 Nov '18

#15903: Assertion failure in LDV profiler -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.7 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: -------------------------------------+------------------------------------- `T11627a` and `T11627b` fail the same way when run with debug runtime: {{{ $ make EXTRA_HC_OPTS=-debug TEST=T11627b WAY=prof_hb ... =====> T11627b(prof_hb) 1 of 1 [0, 0, 0] cd "profiling/should_run/T11627b.run" && "/home/omer/haskell/ghc_4/inplace/test spaces/ghc-stage2" -o T11627b T11627b.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -debug -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto cd "profiling/should_run/T11627b.run" && ./T11627b +RTS -hb -RTS +RTS -i0 -RTS Wrong exit code for T11627b(prof_hb)(expected 0 , actual 134 ) Stderr ( T11627b ): T11627b: internal error: ASSERTION FAILED: file rts/ProfHeap.c, line 200 (GHC version 8.7.20181115 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for T11627b(prof_hb) Unexpected results from: TEST="T11627b" }}} Only tried with GHC HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0