January 2014 - ghc-tickets

[GHC] #8671: Rebindable syntax creates bogus warning
by GHC 17 Nov '14

17 Nov '14

#8671: Rebindable syntax creates bogus warning -------------------------+------------------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Windows Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- {{{ {-# LANGUAGE RebindableSyntax #-} import Data.Void import Prelude ((.), ($), Int, id, Num(..)) (>>) :: (b -> c) -> (a -> b) -> (a -> c) (>>) = (.) return :: Void -> Void return = absurd run :: a -> (a -> b) -> b run x f = f x result :: Int result = run 8 $ do \n -> n * n id (+ 7) (* 2) }}} Compile with -Wall issues incorrect warnings. In fact the suggested fixes cause compile errors if implemented. {{{ Test.hs:22:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- \ n -> (*) n n", or by using the flag -fno-warn-unused-do-bind Test.hs:23:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- id", or by using the flag -fno-warn-unused-do-bind Test.hs:24:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- (( \ x_ -> (+) x_ 7))", or by using the flag -fno-warn-unused-do-bind }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction
by GHC 17 Nov '14

17 Nov '14

#8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction ------------------------------+-------------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I'm sorry if this is expected behavior; I'm still trying to wrap my head around this. I was surprised to learn that the right branch of an `orElse` can be invalidated by changes to the world only visible by the left branch. This might lead to starvation or performance issues for the use- case I was envisioning it for (e.g. several threads trying to take from one of a large set of TMVars in a randomized round-robin fashion). Here is a really bad example demonstrating current behavior: {{{ import Control.Concurrent import Control.Concurrent.STM import Control.Concurrent.STM.TSem import Control.Monad import System.IO import Debug.Trace main = do hSetBuffering stdout NoBuffering noMansLand <- replicateM 998 $ newTVarIO 0 t0 <- newTVarIO (1::Int) t999 <- newTVarIO (-1) let ts = t0:noMansLand++[t999] done <- atomically $ newTSem 0 forkIO $ atomically $ nestedOrElseMap done ts -- need enough time here for nestedOrElseMap thread above to move past t0 -- in this version, the modifications to t0 force nestedOrElseMap to be restarted forkIO (trace "starting vexing!" $ forever $ atomically $ (modifyTVar' t0 (+1) >> trace "vex" (return ()))) -- in this version nestedOrElseMap causes this transaction to be restarted and never makes progress: --forkIO (atomically (trace "starting vexing!" $ forever $ (modifyTVar' t0 (+1) >> trace "vex" (return ())))) atomically $ waitTSem done putStrLn "No livelock! Did the t0 counter get incremented?: " atomically (readTVar t0) >>= print -- another thread begins modifying head ts after we've moved to the right branch nestedOrElseMap :: TSem -> [TVar Int] -> STM () nestedOrElseMap done ts = trace "nestedOrElseMap starting" $ foldl1 orElse $ map transaction $ zip [(1::Int)..] ts where transaction (cnt,v) = do n <- traceShow cnt $ readTVar v if n < 0 then trace "@" (modifyTVar' v (subtract 1)) >> signalTSem done else retry }}} I can see it possibly being useful that both branches of an `orElse` see the same view of the variables they ''share'', but current behavior seems overzealous in restarting the whole transaction. Maybe this is an artifact of changes related to #7493? Or maybe it's obvious why this behavior has to be the way it is and its just not clicking for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8688: internal error: stg_ap_p_ret
by GHC 17 Nov '14

17 Nov '14

#8688: internal error: stg_ap_p_ret ------------------------------------+------------------------------------- Reporter: massysett | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When in GHCi I get: <interactive>: internal error: stg_ap_p_ret (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug There is probably something wrong with the FFI binding I am testing; under other circumstances I get a segfault. But since I was asked to report this, here I am. Let me know if I can provide anything else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8716: improve AMP join warning
by GHC 17 Nov '14

17 Nov '14

#8716: improve AMP join warning ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Any module that defines a top-level join gets this error: {{{ Local definition of ‛join’ clashes with a future Prelude name - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. }}} This file triggers the warning, but it will keep on working when Prelude exports join: {{{ module M1 (M.join) where join x = x }}} This file will break when Prelude exports join, but there is no warning currently given. {{{ module M2 where import M1 (join) f x = join }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8701: Update libffi-tarballs to latest libffi
by GHC 14 Nov '14

14 Nov '14

#8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- libffi 3.0.14 contains fixes necessary for successful iOS (and probably ARM in general) cross-compilation. I've created a new archive that can be dropped in to replace the current libffi-tarballs archive here: https://github.com/ghc-ios/libffi- tarballs/blob/master/libffi-3.0.14.tar.gz?raw=true -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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

11 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] #8699: Multiple test faliures on 32-bit Linux systems.
by GHC 08 Nov '14

08 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] #8623: Strange slowness when using async library with FFI callbacks
by GHC 07 Nov '14

07 Nov '14

#8623: Strange slowness when using async library with FFI callbacks ------------------------------+-------------------------------------------- Reporter: | Owner: simonmar JohnWiegley | Status: new Type: bug | Milestone: 7.8.1 Priority: normal | Version: 7.6.3 Component: Runtime | Operating System: MacOS X System | Type of failure: Runtime performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I've attached a Haskell and a C file, when compiled as such: ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs SpeedTestC.c You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building with SPEED_BUG=0 produces an executable that takes more than a second to run, while building with SPEED_BUG=1 runs very quickly. I've also attached the Core for both scenarios. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8626: Bad magic. Expected: feedfacf, got: feedface
by GHC 07 Nov '14

07 Nov '14

#8626: Bad magic. Expected: feedfacf, got: feedface ----------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- Loading package base-unicode-symbols-0.2.2.4 ... <interactive>: /Users/paulo/Library/Haskell/ghc-7.6.3/lib/base-unicode- symbols-0.2.2.4/lib/HSbase-unicode-symbols-0.2.2.4.o: Bad magic. Expected: feedfacf, got: feedface. ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): loadObj "/Users/paulo/Library/Haskell/ghc-7.6.3/lib/base-unicode- symbols-0.2.2.4/lib/HSbase-unicode-symbols-0.2.2.4.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3