February 2017 - ghc-tickets

[GHC] #13325: Binary distributions produced from cross-compiled stage2 are broken
by GHC 27 Feb '17

27 Feb '17

#13325: Binary distributions produced from cross-compiled stage2 are broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: #8910 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The binary distribution by a cross-compiled build (e.g. configure with `./configure --target=$cross_target`) is broken out of the box. After untarring and configuring the bindist, `make install` fails due to missing files, {{{ # make install make --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES ghc.mk:742: utils/ghctags/ghc.mk: No such file or directory ghc.mk:742: utils/check-api-annotations/ghc.mk: No such file or directory ghc.mk:742: utils/check-ppr/ghc.mk: No such file or directory make[1]: *** No rule to make target 'utils/check-ppr/ghc.mk'. Stop. Makefile:51: recipe for target 'install' failed make: *** [install] Error 2 }}} This can be worked around by, {{{ $ mkdir utils/ghctags utils/check-ppr utils/check-api-annotations $ touch utils/hp2ps/dist/build/tmp/hp2ps \ utils/ghctags/ghc.mk \ utils/check-api-annotations/ghc.mk \ utils/check-ppr/ghc.mk }}} I believe the reason for this is that these are utilities which would typically be built by the stage2 compiler, which we obviously are unable to build. There are a few options for fixing this, * Produce a shell script throwing an error to sit in place of the unbuildable utilities * Fix the build system to include the appropriate `ghc.mk` files in the bindist, despite the utilities they build not being present * Include the sources for the utilities in the bindist and teach `make install` to build them -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10940: Random number chosen by openTempFile is always 1804289383846930886
by GHC 27 Feb '17

27 Feb '17

#10940: Random number chosen by openTempFile is always 1804289383846930886 -------------------------------------+------------------------------------- Reporter: andersk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- {{{#!hs import System.Directory import System.IO main = do (p, _) <- openTempFile "/tmp" "" print p removeFile p }}} {{{#!console $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" }}} This “random” number is the concatenation of the first two numbers 1804289383, 846930886 returned by glibc’s `rand()` when not seeded (or seeded with 1). This is not immediately a library security bug, I think: the file is created with `O_EXCL`, and if it already exists, `openTempFile` will move onto the next value 16816927771714636915, and so on. However, the predictable filenames make a potential application security bug that much more likely. (For your amusement, [https://www.google.com/search?q=1804289383846930886 Google 1804289383846930886].) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13113: Runtime linker errors with CSFML on Windows
by GHC 27 Feb '17

27 Feb '17

#13113: Runtime linker errors with CSFML on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Another day, another runtime linker bug on Windows. This time, it's from the CSFML library (written in C++). I observed this when trying to load the [http://hackage.haskell.org/package/SFML SFML] Haskell library in GHCi. To install CSFML in MSYS2: {{{ pacman -S mingw-w64-x86_64-csfml }}} Here's the Haskell code I'm using: {{{#!hs module Main (main) where import Foreign.Ptr newtype CircleShape = CircleShape (Ptr CircleShape) deriving Show foreign import ccall unsafe "sfCircleShape_create" sfCircleShape_create :: IO CircleShape foreign import ccall unsafe "sfCircleShape_copy" sfCircleShape_copy :: CircleShape -> IO CircleShape main :: IO () main = do putStrLn "----------------------" cs1 <- sfCircleShape_create print cs1 cs2 <- sfCircleShape_copy cs1 print cs2 putStrLn "----------------------" }}} Compiling it with `ghc -lcsfml-graphics SFML.hs` on GHC 8.0.2 and HEAD seems to work fine. But if you run it in GHCi, it breaks. With GHCi 8.0.2: {{{ $ ghci -lcsfml-graphics SFML.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc.exe: addDLL: csfml-graphics-2.dll (Win32 error 127): The specified procedure could not be found. ghc.exe: Could not load `csfml-graphics-2.dll'. Reason: addDLL: could not load DLL Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf [1 of 1] Compiling Main ( SFML.hs, interpreted ) Ok, modules loaded: Main. > main ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: sfCircleShape_create This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} With GHC HEAD: {{{ $ ..\..\..\Software\ghc\inplace\bin\ghci -lcsfml-graphics SFML.hs GHCi, version 8.1.20170108: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: addDLL: csfml-graphics-2.dll (Win32 error 127): The specified procedure could not be found. ghc-stage2.exe: Could not load `csfml-graphics-2.dll'. Reason: addDLL: could not load DLL Loaded GHCi configuration from C:\Users\RyanGlScott\AppData\Roaming\ghc\ghci.conf Ok, modules loaded: Main (SFML.o). > main ghc-stage2.exe: C:\Users\RyanGlScott\Documents\Hacking\Haskell\SFML.o: unknown symbol `sfCircleShape_create' }}} I also get the same error with Phab:D2941 (#13082) applied. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13113> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13189: Implement same specification as GHC spec file for mingw32
by GHC 27 Feb '17

27 Feb '17

#13189: Implement same specification as GHC spec file for mingw32 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 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: #13093 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the `GCC` driver envokes the pipeline a `SPEC` is used to determine how to configure the compiler and which libraries to pass along. For Windows/mingw, this specfile is https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/mingw32.h This has a lot of interesting things that we need to emulate in order to be able to link as many things out of the box as GCC. In particular this is why you never need to specify `-lgcc_s` when compiling, but you do when using `GHCi`. Or specifying what `-mwindows` links in, that when `-lstdc++` is used what else to link in. Which base DLLs GCC will always link with when building an exe. And how to link `libgcc`, either static or dynamically. Currently we only support static linking of `libgcc` (which maybe we should change? or at least make user changeable). The current partial implementation works by adding hooks into the RTS. A better implementation is adding it all outside the RTS in the `DriverPipeline` tied directly to the commandline options. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] Batch modify: #12776, #12944, #12425, #11525, #11731, #12234, ...
by GHC 26 Feb '17

26 Feb '17

Batch modification to #12776, #12944, #12425, #11525, #11731, #12234, #12846, #12885, #12921, #12985, #13025, #13035, #13043, #13050, #13056, #13083, #13135, #13285, #12055 by bgamari: Action: merged -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=12776%2C12944%2C12425%2C11525%2C11…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13218: <$ is bad in derived functor instances
by GHC 26 Feb '17

26 Feb '17

#13218: <$ is bad in derived functor instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- `Functor` deriving derives the definition of `fmap`, leaving the definition of `<$` to the default. This is quite bad for recursive types: {{{#!hs data Tree a = Bin !(Tree a) a !(Tree a) | Tip deriving Functor }}} produces {{{ Replace.$fFunctorTree_$c<$ = \ (@ a_aGl) (@ b_aGm) (eta_aGn :: a_aGl) (eta1_B1 :: Tree b_aGm) -> Replace.$fFunctorTree_$cfmap @ b_aGm @ a_aGl (\ _ [Occ=Dead] -> eta_aGn) eta1_B1 }}} Why is this bad? It fills the tree with thunks keeping the original values (which we never use again) alive. What we want to generate is {{{#!hs x <$ Bin l _ r = Bin (x <$ l) x (x <$ r) }}} When there are other functor types in the constructor, like {{{#!hs | Whatever (Tree (Tree a)) }}} we will need to insert `fmap (x <$) t`. The overall shape should be basically the same as `fmap` deriving. Note: there are some types for which we will not realistically be able to derive optimal definitions. In particular, fixed-shape, undecorated types that appear in nested types allow special treatment: {{{#!hs data Pair a = Pair a a deriving Functor data Tree2 a = Z a | S (Tree2 (Pair a)) deriving Functor }}} The ideal definition for this type is {{{#!hs x <$ Z _ = Z x x <$ S t = S (Pair x x <$ t) }}} but that requires cleverness. We should probably settle for {{{#!hs x <$ Z _ = Z x x <$ S t = S (fmap (x <$) t) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12885: "too many iterations" causes constraint solving issue.
by GHC 26 Feb '17

26 Feb '17

#12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 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: -------------------------------------+------------------------------------- The following file compiled fine with ghc-7.10, but fails in ghc-8.0.2-rc1 (as well as ghc-8.0.1). This is a simplified version of a compilation issue with ghc-8 and https://github.com/tensorflow/haskell. It seems similar to #12175, but even though that was fixed in ghc-8.0.2-rc1, the below code still doesn't compile. {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module ConstraintTest where import Data.Int import Data.Word import GHC.Exts (Constraint) import Lens.Family2 ((.~), (&), Lens') import Lens.Family2.Unchecked (lens) class MyType a where instance MyType Int8 instance MyType Int16 instance MyType Int32 instance MyType Int64 instance MyType Word8 instance MyType Word16 instance MyType Word32 -- Require every element in the list to be an instance of 'MyType'. type family MyTypes (as :: [*]) :: Constraint where MyTypes '[] = () MyTypes (a ': as) = (MyType a, MyTypes as) data Foo = Foo { fooInt :: Int } class Attr a where attr :: Lens' Foo a instance Attr Int where attr = lens fooInt (\f n -> f { fooInt = n }) test :: MyTypes '[Int8,Int16,Int32,Int64,Word8,Word16,Word32] => Foo test = attr .~ (3 :: Int) $ Foo 0 }}} Compilation error: {{{ tensorflow/tests/ConstraintTest.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [W] hole{a282} :: b_a25A ~ Int (CNonCanonical)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit }}} Some ways to change the test to make the compilation succeed: - Pass "-fconstraint-solver-iterations=0" to ghc. - Shorten the type-level list in the constraint of `test`. - Replace `Lens.Family2` with `Lens.Micro` from the `microlens` package. I think this is because `Lens.Family2`'s version of (.~) is higher-order than `Lens.Micro`: https://hackage.haskell.org/package/lens-family-1.2.1/docs/Lens- Family2.html#v:.-126- https://hackage.haskell.org/package/microlens-0.4.7.0/docs/Lens- Micro.html#v:.-126- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS
by GHC 26 Feb '17

26 Feb '17

#12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an annoyance I discovered when working with the [https://github.com/rrnewton/haskell- lockfree/tree/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops atomic-primops] package on Windows. Here is a simplified test case: {{{#!hs module Main (main) where foreign import ccall unsafe "store_load_barrier" storeLoadBarrier :: IO () main :: IO () main = do putStrLn "1" storeLoadBarrier putStrLn "2" }}} Compiling and running this program works without issue. But when run as GHCi bytecode, it fails. I've reproduced this with GHC 8.0.1 and HEAD (but based on [https://github.com/rrnewton/haskell-lockfree/pull/38 this], the issue is likely much older than 8.0.1). {{{ $ runghc Bug.hs Bug.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: store_load_barrier This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} To work around this issue, `atomic-primops` currently links against [https://github.com/rrnewton/haskell- lockfree/blob/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic- primops/cbits/RtsDup.c#L52-L69 a separate C file] that contains an exact duplicate of the `store_load_barrier` function from GHC's RTS when build on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM
by GHC 26 Feb '17

26 Feb '17

#12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new 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 example is slimmed down unit test of Annotations-0.2.1 hackage package. If we try to compile Bug.hs with -O0 it compiles quickly. Trying it with -O1 makes GHC-8.0.1 takes a minute to finish. {{{#!hs -- Bug1.hs: {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} {- # OPTIONS_GHC -O1 #-} module Bug () where import Prelude (Eq) data ExprF rT = ExprF rT rT deriving Eq newtype Expr = Expr (Fix ExprF) deriving Eq newtype Fix fT = In (fT (Fix fT)) deriving instance Eq (f (Fix f)) => Eq (Fix f) }}} {{{ $ time ghc-8.0.1 -c -O0 Bug1.hs -fforce-recomp real 0m0.611s user 0m0.549s sys 0m0.053s $ time ghc-8.0.1 -c -O1 Bug1.hs -fforce-recomp real 1m2.199s user 1m1.676s sys 0m0.465s }}} 7.10.2 for comparison is very quick in both O0/O1: {{{ $ time ghc-7.10.2 -c -O0 Bug1.hs -fforce-recomp real 0m0.220s user 0m0.183s sys 0m0.036s $ time ghc-7.10.2 -c -O1 Bug1.hs -fforce-recomp real 0m0.237s user 0m0.213s sys 0m0.023s }}} The real ExprF datatype uses more constructors and instances: {{{ data ExprF rT = Add rT rT | Sub rT rT | Mul rT rT | Div rT rT | Num Int deriving (Eq, Show) }}} That requires a lot of time and space to finish (Bug2.hs in attach). I've stopped it after 5 minutes (took ~8GB RAM). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #11731: Demand analysis: Thunk wrongly determined single-entry
by GHC 26 Feb '17

26 Feb '17

#11731: Demand analysis: Thunk wrongly determined single-entry -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- While working on #10613, I looked a bit more closely at the ticky numbers of single-entry thunks. In all of nofib, I found exactly one fishy result: A thunk, marked as single entry, but entered multiple times, in gameteb. I’ll write a preliminary analysis in the comments and either found a bug or a misunderstanding on my side. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 53