January 2018 - ghc-tickets

[GHC] #14619: Output value of program changes upon compiling with -O optimizations
by GHC 12 Feb '18

12 Feb '18

#14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The optimisation pass seems to affect the behaviour of the attached program (a basic ray-sphere intersection test, 40 lines long, no dependencies). Specifically, compiling the attached source file with -O or -O2, and considering the definition of main: {{{#!hs result = sphereIntersection testRay testSphere main :: IO() main = do print $ result print $ sphereIntersection testRay testSphere }}} I get the troubling output: {{{ > bug.exe Just ((0.0,0.0,0.0),0.0) Just ((0.0,0.0,100.0),1.0) }}} This is especially troubling because the second component of the output should always be 1.0: {{{#!hs testRay = ((0, 0, 0),(0, 0, 1)) sphereIntersection (orig, dir@(_, _, dirz)) (c,r) | disc < 0 = Nothing | t1 > 0 = Just (t1 *> dir <+> orig, dirz) | t2 > 0 = Just (t2 *> dir <+> orig, dirz) | otherwise = Nothing where ... }}} as we are returning the "dirz" component of the input ray straight back out. On the other hand, when the program is run without optimisations, I get the expected output: {{{ > bug.exe Just ((0.0,0.0,100.0),1.0) Just ((0.0,0.0,100.0),1.0) }}} This behaviour was present on all versions of GHC that I tested (7.10.1, 8.0.1, 8.2.1, 8.2.2). I initially ran into this issue when I noticed that the profiling builds of my program produced different results, which was boiled down to this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow
by GHC 11 Feb '18

11 Feb '18

#14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Keywords: panic! stack | Operating System: MacOS X depth overflow | Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I created a neural network library within haskell. I was able to create, test, and train the net (using data from the mNist dataset). I could only test manually (try one input at a time and compare the two outputs), so i made a function which allowed me to test many test inputs on the net at once. Recreating bug: first, load main.hs in ghci (duh) then, run the entirety of trainedNetwork.txt as a command to initialise the network (i.e. copy paste the file into the ghci command line) then run the entirety of test.txt as a command. Here you will get the error. To test with different input values for the function "test" (the function whose being run caused the crash), you can open the jupyter notebook and run the function mnistTest with higher or lower values (higher using more test cases, lower using less) and run the output of that function as a command in haskell. (i know from testing that 30 inputs does not cause a crash, but 50 does). What i know is not the problem/probably causes: I know that y was initiliased correctly. The function being run here is : {{{#!hs --takes in a network and an array of test inputs and their corresponding outputs and returns the accuracy of the network --only works for classification networks testClassification :: [Layer] -> [[Double]] -> [[Double]] -> Double testClassification net inputs outputs = testClassificationHelper net inputs outputs 0 0 testClassificationHelper :: [Layer] -> [[Double]] -> [[Double]] -> Double -> Double -> Double testClassificationHelper _ [] _ correct incorrect = (correct/(correct+incorrect)) testClassificationHelper net (input:inputs) (output:outputs) correct incorrect | netMax == outMax = next (correct+1) incorrect | otherwise = next correct (incorrect+1) where next = testClassificationHelper net inputs outputs netMax = greatestIndex (getOutput net input) outMax = greatestIndex output }}} I know that getOutput and greatestIndex work\\ I know that it works with a small amount of inputs (test3.txt is essentially the same command except instead of using the first 100 test examples of the mnist data set, it uses the first 3)\\ I know that it works when using the first 30 data points, but not with the first 50.\\ I know that doing it for the first 30 inputs only takes 2 seconds and 270 MB, while training the network took 40 minutes and 820GB, take from that what you will\\ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14535> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14654: Nofib: Strip called without .exe extension resulting in errors.
by GHC 08 Feb '18

08 Feb '18

#14654: Nofib: Strip called without .exe extension resulting in errors. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: 8.2.2 benchmark suite | Keywords: nofib, | Operating System: Windows windows | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ ... ==nofib== bernouilli: size of Main.o follows... text data bss dec hex filename 8080 1632 0 9712 25f0 Main.o ==nofib== bernouilli: time to link bernouilli follows... <<ghc: 27269080 bytes, 11 GCs, 471856/801256 avg/max bytes residency (2 samples), 32M in use, 0.000 INIT (0.000 elapsed), 0.016 MUT (1.134 elapsed), 0.016 GC (0.015 elapsed) :ghc>> C:\ghc\msys64\mingw64\bin\strip.exe: 'bernouilli': No such file make[2]: *** [../../mk/target.mk:96: size] Error 1 make[2]: Target 'all' not remade because of errors. Finished making all in bernouilli: 0 ... }}} I assume strip looks for a file, not an executable. And as such requires the full name "foo.exe" instead of just "foo". Make sees this error and stops before the actual benchmark is run. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12262: Binary output is not deterministic
by GHC 07 Feb '18

07 Feb '18

#12262: Binary output is not deterministic -------------------------------------+------------------------------------- Reporter: niteria | 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 goal of DeterministicBuilds (#4012) was to get ABI-compatible binaries given the same sources, flags and the environment. There's a stronger goal of getting bit-for-bit identical binaries and this ticket will track that. Known causes of binary nondeterminism: * Unique comparison * Uniques converted to strings for symbol names * everything else from #4012 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12685: getNumProcessors semantics dont match documentation
by GHC 06 Feb '18

06 Feb '18

#12685: getNumProcessors semantics dont match documentation ----------------------------------------+--------------------------------- Reporter: Llgn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hi, The documentation of getNumProcessors says : "Returns the number of CPUs that the machine has", but it is true only for program compiled with -threaded option. https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-Conc- Sync.html#v:getNumProcessors I guess the documentation is just misleading. Or is it a bug ? Regards -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14717: Hidden package hints no longer display
by GHC 06 Feb '18

06 Feb '18

#14717: Hidden package hints no longer display -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This started as a mailing list thread: https://mail.haskell.org/pipermail /haskell-cafe/2018-January/128485.html. Dan Burton demonstrated a reproduction without any build tool. With GHC 8.0.2, when you try to use a module from a hidden package, you get an error message with a helpful hint to add the package to the build- depends. With GHC 8.2.2 (and I believe 8.2.1), it appears that this hint is no longer displayed. To demonstrate, I'll copy Dan's repro: {{{ $ cat Main.hs module Main where import Data.Map main = putStrLn "It compiles" $ ghc-pkg list containers /usr/local/Cellar/ghc/8.2.2/lib/ghc-8.2.2/package.conf.d containers-0.5.10.2 $ ghc --make -hide-all-packages -package base Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:2:1: error: Could not find module ‘Data.Map’ Use -v to see a list of the files searched for. | 2 | import Data.Map | ^^^^^^^^^^^^^^^ $ ghc --make -hide-all-packages -package base -package containers Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14693: Computing imp_finst can take up significant amount of time
by GHC 06 Feb '18

06 Feb '18

#14693: Computing imp_finst can take up significant amount of time -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I profiled a build of a production code base with thousands of modules and merging `imp_finsts` [1] from different imports came up on top taking up 9% of total compile time. I made a synthetic test case to reproduce the issue (see attached `generateModules`). The test case is basically multiple layers of modules where each module defines a type family instance through deriving Generic. The problem is quite obvious, `unionLists` is quadratic and `imp_finsts` just keeps growing with the size of the code base. [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/typech… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14637: Simplifier Ticks Exhausted when compiling with profiling
by GHC 06 Feb '18

06 Feb '18

#14637: Simplifier Ticks Exhausted when compiling with profiling -------------------------------------+------------------------------------- Reporter: cfhammill | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi GHC devs, I've run into a problem with the Frames library, I can compile a simple example using stack without executable profiling enabled, but when I enable profiling I get the simplifier ticks exhausted error. I've tried using -fsimpl-tick-factor=1000 to no avail. I've attached the stack config, cabal file, haskell code, two csv files, and the simplifier dump. Any help would be appreciated. Chris -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #14683: Hole-y partial type signatures lead to slow compile times
by GHC 06 Feb '18

06 Feb '18

#14683: Hole-y partial type signatures lead to slow compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This came up while investigating the compile times of Happy grammars: https://github.com/simonmar/happy/issues/109. GHC 8 and later take a lot longer to compile grammars with types that rely on `PartialTypeSignatures` and have lots of wildcards. Example: {{{#!hs happyReduce_6 :: () => Happy_GHC_Exts.Int# -> L Token -> Happy_GHC_Exts.Int# -> Happy_IntList -> HappyStk (HappyAbsSyn _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) -> ParserMonad (HappyAbsSyn _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _) }}} There is an example repo (https://github.com/wiz/too-happy) in that thread containing a grammar whose generated code has lots of wildcards. On my laptop, the project takes about 25 seconds to compile on 7.10.3. With 8.0.2, 8.2.2, and HEAD it takes on the order of 4 minutes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #14396: Hs-boot woes during family instance consistency checks
by GHC 05 Feb '18

05 Feb '18

#14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider this set of modules (related to #13981 but not the same) {{{ {-# LANGUAGE TypeFamilies #-} module Fam where type family XListPat a {-# LANGUAGE TypeFamilies #-} module T1 where import Fam import {-# SOURCE #-} T( SyntaxExpr ) type instance XListPat Int = SyntaxExpr {-# LANGUAGE TypeFamilies #-} module T2 where import Fam type instance XListPat Bool = Int -- T.hs-boot module T where data SyntaxExpr = S -- T.hs module T where import T1 import T2 data SyntaxExpr = S }}} Compiled with GHC 8.0, 8.2, and HEAD we get {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing SyntaxExpr which was lazily initialized by initIfaceTcRn, I tried to tie the knot, but I couldn't find SyntaxExpr in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] }}} Reason: * After renaming, but before type checking, we try to do family-instance consistency checking in `FamInst.checkFamInstConsistency` * To do so we have to pull in the axioms from `T1` and `T2`. * Then we poke on those axioms, to check consistency, we pull in both LHS and RHS of the type instances. * Alas that pulls on `SyntaxExpr`, which we have not yet typechecked. I don't think it's enough to make lazier the loading of the RHS of the axiom, because I think `checkFamInstConsistency` ends up looking at the RHS too. See the call to `compatibleBranches` in `lookupFamInstEnvConflicts`. This setup is actually used in Alan's `wip/ttg-2017-10-13` branch for Trees That Grow. Here module `T` is `HsExpr`, `T1` is `HsPat`. And indeed GHC 8.0 crashes when compiling this branch. SO it's becoming a real problem. Generally I'm concerned that #13981 may also become more pressing; and #14080 is still open -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14396> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14