July 2014 - ghc-tickets

[GHC] #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output.
by GHC 11 Nov '14

11 Nov '14

#9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. -------------------------+------------------------------------------------- Reporter: | Owner: Westycoot | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: x86 | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Below is the source code in which the bug occurs. It is easily reproduce- able, by having the type be IO{} instead of IO(). When ran, this code will produce the "panic! The impossible has happened" output. Which told me to report the bug here. By changing IO() to IO{} (which I did by accident), no exception is thrown, it simply tells the user to panic! {{{ main :: IO {} main = do e1 <- getLine e2 <- getLine print ((read e1) + (read e2)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8427: GHC accepts invalid program because of EPS poisoning
by GHC 10 Nov '14

10 Nov '14

#8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Moderate (less | invalid program than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Assume the following setup: - compiling in batch mode (`--make`), - package klassz, module Class contains the class "Class a" and the data "Data", - package klassz, module A contains an (orphan) instance "Class Data", - package main, module AImporter just imports A, - package main, module B imports only Class, but uses the instance (invalidly); then - if package main, module Main imports B, later imports AImporter; then it compiles; - if package main, module Main imports AImporter, later imports B, then it doesn't compile. The attached tgz contains this setup. `diff -u main-docompile main- nocompile` shows that the only difference between the two main directories is the order of import statements. The language definitely doesn't accept compilation success to depend on import ordering, therefore this is a bug. My current understanding is that the issue is that this code should never compile, both mains should be rejected, since module B imports only the class, but not the instance. The issue is that the EPS is only ever increased, never decreased between compilation of different modules in a single batch compilation. This naïve approach causes the instances to be loaded and then never unloaded, so it can be magically found when compiling the invalid B module. The current code can be found in [[GhcFile(compiler/iface/LoadIface.hs)]] line 280. I propose to instead of always loading ifaces into the EPS directly, introduce a proper cache for interfaces, that contains parsed up interface data in a `ModuleEnv`. Then we can start up with an empty EPS at the beginning of the compilation of every unit and quickly merge info from this cache. I guess the majority of time is the file reading IO and the parsing, not the merging of multiple interface files together. I also think that these kind of issues will get more and more prominent as people start to use parallel cabal and ghc, because if compilation of the attached example program is randomly parallelized, then in some cases it will build, some cases it won't. Any opinions, alternative fix ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8672: :browse and roles on typefamilies
by GHC 10 Nov '14

10 Nov '14

#8672: :browse and roles on typefamilies -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- :browse on `ghci tests/ghci.debugger/scripts/T8557.hs` outputs a weird looking line: {{{ type role Sing nominal data family Sing (a :: k) type role T8557.R:Sing[]a nominal <-- data instance Sing a = SNil }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9073: small SPECIALIZE INLINE program taking gigabytes of memory to compile
by GHC 09 Nov '14

09 Nov '14

#9073: small SPECIALIZE INLINE program taking gigabytes of memory to compile -------------------------+------------------------------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I have a small program that is taking 1+ GB of memory to compile. I've distilled the troublesome input down to the following: {{{ {-# LANGUAGE BangPatterns #-} import Data.Vector knot :: Vector Double -> Int -> Double knot vs k = vs ! idx0 where !idx0 = abs k `mod` 16 {-# SPECIALIZE INLINE knot :: Vector Double -> Int -> Double #-} noise :: Vector Double -> Int -> Double noise vs k = knot vs k + knot vs k + knot vs k + knot vs k + knot vs k + knot vs k + knot vs k + knot vs k }}} Compiled with `ghc -fprof-auto -prof -O2 -Wall`. As far as I can tell, prof-auto, prof, and optimizations of at least -O1 are required to trigger it. I'm using ghc-7.8.2 64bit for Windows. vector is version 0.10.9.1 (currently the latest on hackage). Same code worked fine on ghc 7.6.2. Also worth noting: Even though the `SPECIALIZE` isn't needed, if you remove the `SPECIALIZE` or the `INLINE` the problem goes away. If you remove even one of the duplicated calls to `knot vs k` in the body of `noise` then the amount of memory required drops dramatically. Add more to increase the requirements. I've been able to push it up around 10 GB, but I don't have enough memory to test beyond that! Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory]
by GHC 09 Nov '14

09 Nov '14

#9053: make sdist fails with repeated /bin/sh[1]: lndir: not found [No such file or directory] -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: smartos illumos | Operating System: Solaris lndir sdist | Type of failure: Building GHC Architecture: Unknown/Multiple | failed Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- It appears that source for lndir was intentionally included in utils and customized to handle .git directories: http://git.haskell.org/ghc.git/blobdiff/c629bd1539b1865cc28ce053234595e7aeb… This ignoring of .git directories has been in the upstream lndir.c since 2009: http://cgit.freedesktop.org/xorg/util/lndir/tree/lndir.c However, lndir is not installed by default (on Ubuntu or SmartOS) and is not listed in the tools required to build: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools It does not appear to be built during the sync, boot, or make steps of a GHC build. Here is an excerpt: {{{ /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] /bin/sh[1]: lndir: not found [No such file or directory] ghc.mk:1117: recipe for target 'sdist-ghc-prep' failed gmake[1]: *** [sdist-ghc-prep] Error 127 Makefile:64: recipe for target 'sdist' failed gmake: *** [sdist] Error 2 }}} Here is a detailed log: http://haskell.inf.elte.hu/builders/smartos-x86_64-head/19/16.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8699: Multiple test faliures on 32-bit Linux systems.
by GHC 07 Nov '14

07 Nov '14

#8699: Multiple test faliures on 32-bit Linux systems. ----------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- I ran validate with HEAD (e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19) on 3 different 32-bit Linux boxes and I'm seeing different failures on each one. I was advised on IRC to create a ticket with all the failures. The first and third box are using the binary of 7.6.3 provided on the GHC site. I had to link libgmp.so.3 to libgmp.so.10 on both of these in order to get it to install properly. Please ask about any info that I have not provided below! First box: {{{Linux misaki 3.12.3-gentoo #2 SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.0 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.0, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 16 Oct 14 04:24 /usr/lib/libgmp.so.10 -> libgmp.so.10.1.3 lrwxrwxrwx 1 root root 12 May 31 2013 /usr/lib/libgmp.so.3 -> libgmp.so.10 }}} The full log is at [1]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.Cabal haddock.base" OVERALL SUMMARY for test run started at Sun Jan 26 03:26:36 2014 GMT 0:19:58 spent to go through 3883 total tests, which gave rise to 15172 test cases, of which 11625 were skipped 28 had missing libraries 3458 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) }}} As discussed on the mailing list, the Haddock numbers still need tweaking even after Austin updated them the other day. T1969 failure seems to come and go. ---- Second box: {{{Linux yuuki 3.11.4-gentoo #1 SMP Tue Oct 8 00:19:37 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} I installed the bootstrapping compiler on this box from Gentoo's package manager so I'm not sure how gmp is linked here. I can retry by boostrapping from binary and linking libgmp.3 to libgmp.10 (like the other boxes did) for consistency. The version of this complier is 7.6.3-r1. The full log is at [2]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="T1969 haddock.compiler T7859" OVERALL SUMMARY for test run started at Sun Jan 26 03:34:47 2014 GMT 0:12:04 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3453 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) runghc T7859 [bad stderr] (normal) }}} A different Haddock perf failure, T1969 seems to have failed again and a totally new failure, T7859. ---- Third box: {{{Linux lenalee 3.11.4-gentoo #1 SMP Mon Oct 7 19:19:00 BST 2013 i686 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux}}} {{{Happy Version 1.19.3 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow}}} {{{Alex version 3.1.3, (c) 2003 Chris Dornan and Simon Marlow}}} {{{ lrwxrwxrwx 1 root root 9 Jan 26 02:42 /usr/lib/libgmp.so.3 -> libgmp.so lrwxrwxrwx 1 root root 16 Nov 20 11:54 /usr/lib/libgmp.so -> libgmp.so.10.1.3 }}} The full log is at [3]. Inlining the end of the log with the failures: {{{ Unexpected results from: TEST="hsc2hs004 T3837 haddock.compiler haddock.base T3307 environment001 T1969 gadt23 Capi_Ctype_001 Capi_Ctype_002" OVERALL SUMMARY for test run started at Sun Jan 26 03:28:47 2014 GMT 0:10:37 spent to go through 3883 total tests, which gave rise to 12748 test cases, of which 9209 were skipped 26 had missing libraries 3446 expected passes 57 expected failures 3 caused framework failures 0 unexpected passes 10 unexpected failures Unexpected failures: ../../libraries/base/tests/IO T3307 [bad stderr] (normal) ../../libraries/base/tests/IO environment001 [bad stderr] (normal) ffi/should_run Capi_Ctype_001 [bad stderr] (normal) ffi/should_run Capi_Ctype_002 [bad stderr] (normal) gadt gadt23 [bad stderr] (normal) hsc2hs T3837 [bad stderr] (normal) hsc2hs hsc2hs004 [bad stderr] (normal) perf/compiler T1969 [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) }}} Whole plethora of failures! Haddock numbers again and a bunch of other stuff. Considering how close 7.8 is, I think these should be looked at (especially that last set doesn't look too good). I notice that over 2000 more tests were skipped on the first box (this is my day-to-day use computer). How are the tests to be skipped determined? [1]: http://fuuzetsu.co.uk/misc/validate-misaki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [2]: http://fuuzetsu.co.uk/misc/validate-yuuki- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 [3]: http://fuuzetsu.co.uk/misc/validate-lenalee- e01367ff8c3165b0dd1fb78bcb3a3ced1e4a5f19 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8828: allow fully applied type families in instance heads
by GHC 07 Nov '14

07 Nov '14

#8828: allow fully applied type families in instance heads ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, it would be nice if the following example were acceptable: {{{ {-# LANGUAGE FlexibleInstances, TypeFamilies, TypeSynonymInstances #-} data X a = X a type family TX a type instance TX a = X a instance Show (TX Int) }}} But ghc complains that it cannot substitute the instance of TX: {{{ ts.hs:6:10: Illegal type synonym family application in instance: TX Int In the instance declaration for ‛Show (TX Int)’ }}} A more practical (but not self-contained) example involving extensible records looks http://lpaste.net/100436 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9295: Deadlock in forkProcess
by GHC 07 Nov '14

07 Nov '14

#9295: Deadlock in forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As part of `forkProcess` we discard all tasks except the one task that remains. As part of this we call `freeTask`, and `freeTask` in turn calls `closeCondition` and `closeMutex`, which are very thin wrappers around `pthread_cond_destroy` and `phread_mutex_destroy`. However, the behaviour of these functions is undefined when there are currently threads blocked on these condition variables/mutexes. In reality, this undefined behaviour often (though not always) results in a deadlock. Unfortunately, I don't have a minimal test case to demonstrate this, but in the large system on which I am testing this I am seeing these deadlocks rather frequently. For the global mutex we don't attempt to call `pthread_cond_destroy` or `pthread_mutex_destroy`, but instead re-initialize them. The patch https://phabricator.haskell.org/D59 does precisely that for the condition variables and mutexes associated with tasks. This is ''somewhat'' or a long way around, because we will then subsequently still call `pthread_..._destroy`, but it means that we don't have to mess with `freeTask`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9296: Acquire all_tasks_mutex in forkProcess
by GHC 07 Nov '14

07 Nov '14

#9296: Acquire all_tasks_mutex in forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `forkProcess` we acquire a bunch of mutexes so make sure that when we fork the child doesn't see an inconsistent state of any global data structures. However, we do not acquire the `all_tasks_mutex`, which means that the child might have an inconsistent view of the `all_tasks` list. https://phabricator.haskell.org/D60 Sadly, I do not have a test case illustrating that this is in fact a problem. Found this while working tracking down a deadlock in forkProcess (https://ghc.haskell.org/trac/ghc/ticket/9295) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9296> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8812: Make *_stub.c files available again
by GHC 07 Nov '14

07 Nov '14

#8812: Make *_stub.c files available again ------------------------------------+------------------------------------- Reporter: ralphb | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In our project we would like to link Haskell functions into C++ code. In principle this works fine using FFI. An additional constraint, however, is that we need to generate and link the object files ourselves. Alas, ghc no longer keeps the *_stub.c files around. (And fishing for files in /tmp is not a viable solution.) I would like to propose an additional command line switch to keep *_stub.c files, as previous compiler versions did by default. (Note that there is an older, similar request #7463, but our use case is much broader than that and not limited to unregistered compilation.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1