February 2018 - ghc-tickets

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 12 Feb '18

12 Feb '18

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508, DeterministicBuilds | Phab:D4388 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268, Phab:D1360, Phab:D1373, Phab:D1396, Phab:D1457, Phab:D1468, Phab:D1487, Phab:D1504, Phab:D1508 => Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268, Phab:D1360, Phab:D1373, Phab:D1396, Phab:D1457, Phab:D1468, Phab:D1487, Phab:D1504, Phab:D1508, Phab:D4388 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14798: Error message suggests applying (non-existant) function to more arguments
by GHC 12 Feb '18

12 Feb '18

#14798: Error message suggests applying (non-existant) function to more arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Applying a constraint that doesn't hold fails, this is expected {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data Dict c where Dict :: c => Dict c Prelude> data A Prelude> :t Dict @(Eq A) <interactive>:1:1: error: No instance for (Eq A) arising from a use of ‘Dict’ }}} but for `(Eq (Int -> Int))` GHC additionally suggests maybe applying a function (what function?) to more arguments {{{ Prelude> :t Dict @(Eq (Int -> Int)) <interactive>:1:1: error: No instance for (Eq (Int -> Int)) arising from a use of ‘Dict’ (maybe you haven't applied a function to enough arguments?) Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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] #14793: some executables in the binary distribution are not versioned
by GHC 11 Feb '18

11 Feb '18

#14793: some executables in the binary distribution are not versioned -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- GHC is generally quite careful to play nicely when you install multiple versions, in particular by putting a version number somewhere in the filepath for almost every installed file. Then a few top-level non- versioned symlinks are made to (versioned) executables. Consequently, build tools with enough knowledge of the GHC versioning infrastructure can select an older or newer GHC to build things with by ignoring the top- level symlinks and explicitly selecting the versioned executable names. There are a few exceptions where this is not possible: hsc2hs, hp2ps, and hpc. These executables are *overwritten* on each installation, so it is not possible to select "the one that goes with the currently chosen compiler". I'd like to request that these begin being installed with the same scheme as other GHC executables: with an appended dash and version number, together with a non-versioned symlink. I don't know to what extent this matters for hp2ps and hpc; perhaps these change infrequently enough that it doesn't matter too much. But hsc2hs at least bakes some GHC version knowledge in; it has at least a default template that it #include's that defines some C macros, and this template changes occasionally. There is a command-line option to specify a template filepath explicitly, but it would be nice if build tools could reliably choose a version of hsc2hs that has the right defaults, so that using the command-line flag is a special case for special circumstances. (For some context: I have just finished hunting down an issue related to exactly this. I installed an older GHC to test that some code was backwards-compatible. All of a sudden, existing builds, still using the new compiler, started failing, because hsc2hs was now using an outdated template that did not define all the necessary macros.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 11 Feb '18

11 Feb '18

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * priority: high => normal * cc: George (added) Comment: Changing from high to normal priority as it is 5 years olds with no fix in sight and there is a workaround of compiling with GCC which we do for our distributions. If anybody disagrees feel free to put back to high priority. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 11 Feb '18

11 Feb '18

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * os: Linux => Unknown/Multiple * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 11 Feb '18

11 Feb '18

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 11 Feb '18

11 Feb '18

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * failure: Runtime crash => GHC rejects valid program * architecture: x86_64 (amd64) => Unknown/Multiple Comment: {{{ Compiling with -O avoids the bug , probably a good idea to change the current error message to mention that. On my Mac with 8.4.1 alpha 3 ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180204 ghc --make LongList.hs [1 of 1] Compiling Main ( LongList.hs, LongList.o ) ghc: sorry! (unimplemented feature or known bug) (GHC version 8.4.0.20180204 for x86_64-apple-darwin): Trying to allocate more than 129024 bytes. This is currently not possible due to a limitation of GHC's code generator. See http://hackage.haskell.org/trac/ghc/ticket/4505 for details. Suggestion: read data from a file instead of having large static data structures in code. bash-3.2$ ghc -O LongList.hs [1 of 1] Compiling Main ( LongList.hs, LongList.o ) Linking LongList ... bash-3.2$ ./LongList 8595 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7231: GHCi erroneously unloads modules after a failed :reload
by GHC 11 Feb '18

11 Feb '18

#7231: GHCi erroneously unloads modules after a failed :reload -------------------------------------+------------------------------------- Reporter: parcs | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.6.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by nh2): From over at https://ghc.haskell.org/trac/ghc/ticket/12935#comment:14, I found that this change is what makes the `[3 of 4]` order of `ghc --make` dependent on file mtime and thus generates different output depending on whether or not your resume a build. Could somebody shortly explain to me what the use case of the functionality that was broken and fixed in this issue is? Is it important that in ghci you can already use imports from the non- broken module imports while other imports are still broken? I'm asking because I'd imagine you'd first fix all imports anyway before you are doing anything sensible in the module, or am I wrong? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7231#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0