February 2016 - ghc-tickets

[GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch
by GHC 12 Feb '16

12 Feb '16

#9022: TH pretty printer and GHC parser semicolon placement mismatch ----------------------------+---------------------------------------------- Reporter: roldugin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- In GHC 7.8 TemplateHaskell pretty printer started inserting explicit braces and semicolons. It puts semicolons at the end of the line as opposed to the beginning of the next line. This causes GHC to fail parsing if we try to compile the pretty printed code. {{{ $ cat Foo.hs module Main where import Language.Haskell.TH main = putStrLn $ pprint foo foo :: Dec foo = barD where barD = FunD ( mkName "bar" ) [ Clause manyArgs (NormalB barBody) [] ] barBody = DoE [letxStmt, retxStmt] letxStmt = LetS [ ValD (VarP xName) (NormalB $ LitE $ IntegerL 5) [] ] retxStmt = NoBindS $ AppE returnVarE xVarE xName = mkName "x" returnVarE = VarE $ mkName "return" xVarE = VarE xName manyArgs = map argP [0..9] argP n = VarP $ mkName $ "arg" ++ show n $ ghc-7.8.2 Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo ... $ ./Foo | tee Bar.hs bar arg0 arg1 arg2 arg3 arg4 arg5 arg6 arg7 arg8 arg9 = do {let x = 5; return x} $ ghc Bar.hs [1 of 1] Compiling Main ( Bar.hs, Bar.o ) Bar.hs:2:61: parse error on input `return' }}} I don't know if this is a problem with TH pretty printer or if GHC is supposed to parse semicolons wherever they are.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11533: Stack check not optimized out even if it could be
by GHC 12 Feb '16

12 Feb '16

#11533: Stack check not optimized out even if it could be -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- CmmLayoutStack tries to remove a stack check if a function uses no stack space. It knows that Sp < SpLim is always false, but not that Sp >= SpLim is always true. However, the latter can arise when GHC flips the comparison (which it does sometimes). An example would be the worker function generated for {{{go}}}: {{{ countDown :: Int -> Int countDown = go 0 where go acc n | n > 0 = go (acc + 1) (n - 1) | otherwise = acc + n }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11559: Building a cross-compiler for MIPS target on Mac OS X host fails
by GHC 12 Feb '16

12 Feb '16

#11559: Building a cross-compiler for MIPS target on Mac OS X host fails -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was able to build a cross-compiling GHC on a Ubuntu 16.04 host with just a few changes to the source code (see this article I wrote about it, the necessary source code changes are in the GHC/Haskell section: https://medium.com/@wereHamster/cross-compiling-for-the-onion-omega- 1cf8ee80df02) Replicating the necessary steps on my Mac OS X laptop didn't work. The build system doesn't clearly distinguish between CPP/C/LD flags required by the host and target compilers (which in my case are quite different, clang for the host and gcc for the target). The C/LD flags determined by `--with-curses-includes/libraries` are passed to both the host and target compiler. The host has ncurses installed in a standard search path (/usr), I used this option to let the build system know where a version of ncurses for the target is installed (required for the stage2 compiler I believe). The problem here is that the host compiler fails to build stage1 libraries/terminfo because it first finds the cross- compiled ncurses library in its search path and stops because it is incompatible. Maybe it's a peculiarity of clang that it doesn't keep on searching when it comes across the first library it can find, even though later in the search path there is one which is compatible. I was able to get past that by changing some makefile rules and pass the necessary options only when building the stage2 terminfo. Similar issue is when wrong CPP options are passed to the pre-processor during building of stage2. The configure script adds `-m64` to CPP options (because the build host is x86_64 darwin). However, these options are then passed to the target compiler which doesn't understand `-m64`. I tried to track down where exactly that happens but I was not able to find where (`rules/build-dependencies.mk` -> `addCFileDeps` is who calls `$(CPP)` with the wrong flags). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9386: GHCi cannot load .so in same ./
by GHC 12 Feb '16

12 Feb '16

#9386: GHCi cannot load .so in same ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In my directory ./ I have an empty file Foo.hs and a shared object file mylib.so. From that directory in the shell, $ ghci Foo *.so GHCi, version 7.8.2: 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 (dynamic) mylib.so ... failed. <command line>: user specified .o/.so/.DLL could not be loaded (mylib.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) mylib.so Additional directories searched: (none) It's interesting that GHCi searches ./ and identifies the correct object file, but then fails to load it. I have also tried the path ./*.so for the GHCi option. However, if I move mylib.so to a directory ./Temp, $ ghci Foo Temp/*.so loads without issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11520: GHC falls into a hole
by GHC 11 Feb '16

11 Feb '16

#11520: GHC falls into a hole -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RankNTypes, PolyKinds, TypeInType, GADTs, UndecidableSuperClasses #-} module Play where import GHC.Types hiding (TyCon) data TyCon (a :: k) = TyCon data TypeRep (a :: k) where TypeCon :: forall (a :: k). TyCon a -> TypeRep k -> TypeRep a TypeApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep a -> TypeRep b -> TypeRep (a b) class Typeable k => Typeable (a :: k) where typeRep :: TypeRep a data Compose (f :: k1 -> *) (g :: k2 -> k1) (a :: k2) = Compose (f (g a)) composeTyCon :: TyCon Compose composeTyCon = TyCon Fingerprint "Compose" instance (Typeable f, Typeable (g :: k), Typeable k) => Typeable (Compose f g) where typeRep = TypeApp (TypeApp (TypeCon composeTyCon typeRep) typeRep) typeRep instance (Typeable f, Typeable g, Typeable a) => Typeable (Compose f g a) where typeRep = TypeApp (TypeApp (TypeApp (TypeCon composeTyCon typeRep) typeRep) typeRep) typeRep }}} fails with {{{ λ> :load Bug.hs [1 of 1] Compiling Play ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160122 for x86_64-unknown-linux): fvProv falls into a hole {abet} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic
by GHC 11 Feb '16

11 Feb '16

#11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE FlexibleInstances, TypeInType #-} module FvProvFallsIntoAHole where import Data.Kind newtype UhOh (k :: * -> *) (a :: k *) = UhOh (k *) instance Functor k => Functor (UhOh k) where }}} produces this GHC panic: {{{ $ /opt/ghc/head/bin/ghc FvProvFallsIntoAHole.hs [1 of 1] Compiling FvProvFallsIntoAHole ( FvProvFallsIntoAHole.hs, FvProvFallsIntoAHole.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160108 for x86_64-unknown-linux): fvProv falls into a hole {aq6} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11530: Make fails on systems with GREP_OPTIONS
by GHC 11 Feb '16

11 Feb '16

#11530: Make fails on systems with GREP_OPTIONS ----------------------------------------+--------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In rules/manual-package-config.mk the following use of grep will cause later errors if -n (prepending line numbers) is set in GREP_OPTIONS. {{{ grep -v '^#pragma GCC' $$@.raw | \ sed -e 's/""//g' -e 's/:[ ]*,/: /g' >$$@ }}} It causes parsing issues later, with errors like: {{{ : Warning: Unrecognized field 420 on line 420 : Warning: Unrecognized field 419 on line 419 ... : Warning: Unrecognized field 1 on line 1 : missing id field : invalid package identifier: : invalid package key: }}} It may be worth adding an `export GREP_OPTIONS=` somewhere in the make file as it's reasonably difficult to figure out the actual problem from the error message. I would do this and submit a patch but I'm not sure if it is desired since GREP_OPTIONS is now deprecated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False
by GHC 11 Feb '16

11 Feb '16

#11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Tried to debug unrelated build failure of constraints-0.4.1.3 and found this in today's ghc-HEAD: {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -c C.hs -O0 WARNING: file compiler/stgSyn/CoreToStg.hs, line 250 $fCategoryConstraint:- True False }}} {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE Rank2Types #-} {-# LANGUAGE GADTs #-} module C () where import Control.Category import GHC.Types (Constraint) data Dict :: Constraint -> * where Dict :: a => Dict a infixr 9 :- newtype a :- b = Sub (a => Dict b) instance Category (:-) where id = refl (.) = trans infixl 1 \\ (\\) :: a => (b => r) -> (a :- b) -> r r \\ Sub Dict = r trans :: (b :- c) -> (a :- b) -> a :- c trans f g = Sub (Dict \\ f \\ g) refl :: a :- a refl = Sub Dict {- $ inplace/bin/ghc-stage2 -fforce-recomp -c C.hs -O0 WARNING: file compiler/stgSyn/CoreToStg.hs, line 250 $fCategoryConstraint:- True False -} }}} Original file it was factored out is: https://github.com/ekmett/constraints/blob/c550b7653e88d58882873d11f05538d7… Might be a result of Phab:D1889 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10734: pprint of ‘let’ inside ‘do’ prints invalid Haskell
by GHC 10 Feb '16

10 Feb '16

#10734: pprint of ‘let’ inside ‘do’ prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On GHC 7.10.1 {{{#!hs Prelude Language.Haskell.TH Language.Haskell.TH.Ppr> pprint <$> runQ [| do { let { x = 5 }; return x; } |] "do {let x_0 = 5; GHC.Base.return x_0}" }}} The let binding inside the resulting {{{do}}} should be inside curly braces too -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11561: Have static ghci link against its own copy of its libraries
by GHC 09 Feb '16

09 Feb '16

#11561: Have static ghci link against its own copy of its libraries -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When ghci is built dynamically, there is just one copy of each of the libraries that make up ghci (the ghc library, and base and ghc-prim and all the other dependencies of ghc or ghci) loaded, which is used both by ghc(i) itself directly, and also by the code run inside ghci. Could we do the same for statically-built ghci? Here is a possibility. * Ensure through suitable linker flags that ''all'' objects in the archives for the libraries that make up ghci are linked into the ghci executable. (Or link the .o files that we also produce (except for ghc itself), instead.) * Through more linker flags, add ''dynamic symbol table'' entries for all the symbols in the ghci executable that might be referenced from code run inside ghci; say all the symbols that the runtime linker would add to its internal symbol table. This is a bit weird, because the ghci executable is not relocatable. But I can't see any specific reason why it is wrong to do. * In the runtime linker, don't load any library that was linked into ghci. Instead, trust that `dlsym()` (or the OS-specific equivalent) will find symbols from those libraries. Pros: * ghci startup time (and time to load other libraries linked into ghc) should be reduced since the runtime linker doesn't need to process a bunch of relocations. ghci startup time is particularly noticeable on, say, ARM. (On my tablet it takes about a second.) Not sure whether the dynamic loader has to process the executable's dynamic symbol table at startup time, but I assume that even if it does, that process is much faster. * We can eliminate the .o file for each library linked into ghci from the binary distribution, at the cost of having to link that entire .o file into ghci. The net savings would be whatever part of that object file would have been linked into ghci anyways. (Note that we do not currently distribute a .o file for the ghc library anyways. My estimate for the total savings is on the order of 20MB.) Unknown * The total process size of ghci might go up or down. For each library that is eventually loaded into ghci anyways, we save space equal to the amount of code that would have been linked into ghci from that library. For each library that is not eventually loaded into ghci, we use additional space equal to the amount of code in that library that would not have been linked into ghci. We could exclude some libraries from this treatment if they make for particularly bad tradeoffs here and are not depended on by other libraries that we want to include. We might exclude the ghc package just because it is rarely loaded into ghci, even though most or all of it will be linked into ghci anyways, to leave more flexibility for its dependencies. Cons: * ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5