July 2014 - ghc-tickets

[GHC] #8664: libffi does not recognize AArch64 (ARM64)
by GHC 17 Nov '14

17 Nov '14

#8664: libffi does not recognize AArch64 (ARM64) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, bundled libffi-3.0.11's configure does not recognize aarch64/arm64 platform. This is easily solvable by replacing it with newer release. I tested 3.0.13 and it went well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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] #8730: Invalid Unicode Codepoints in Char
by GHC 16 Nov '14

16 Nov '14

#8730: Invalid Unicode Codepoints in Char ------------------------------------+------------------------------------- Reporter: mdmenzel | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: unicode | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The surrogate range in Unicode is supposed to (as of Unicode 2.0, 1996) be a range of invalid code points yet, Data.Char allows the use of values in this range (in fact, it even gives them their own GeneralCategory). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8756: Test case concurrent/should_run/T5611 fails on Mac
by GHC 16 Nov '14

16 Nov '14

#8756: Test case concurrent/should_run/T5611 fails on Mac ------------------------------------+------------------------------------- Reporter: goldfire | 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: | ------------------------------------+------------------------------------- On a fresh check out, test case concurrent/should_run/T5611 fails: {{{ Actual stderr output differs from expected: --- ./T5611.stderr 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stderr 2014-02-08 22:00:06.000000000 -0500 @@ -1 +0,0 @@ -T5611: user error (Exception delivered successfully) Actual stdout output differs from expected: --- ./T5611.stdout 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stdout 2014-02-08 22:00:06.000000000 -0500 @@ -1,2 +1,3 @@ child: Sleeping +child: Done waiting parent: Done throwing exception *** unexpected failure for T5611(normal) }}} I'm on Mac OS 10.8.5 with Xcode 4.6.1 (4H512). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8798: Missing symbols with -fprof-auto-calls
by GHC 16 Nov '14

16 Nov '14

#8798: Missing symbols with -fprof-auto-calls ------------------------------------+------------------------------------- Reporter: edsko | 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: | ------------------------------------+------------------------------------- To reproduce: in an empty environment (no packages installed), run {{{ cabal install --only-dependencies --enable-library-profiling --ghc-option =-fprof-auto-calls }}} for the attached test case. This will seem to work okay (no errors), but if you then do {{{ cabal configure --enable-executable-profiling --enable-library-profiling --ghc-option=-fprof-auto-calls }}} then {{{ cabal build }}} will fail with {{{ Building autocallsbug-0.1.0.0... Preprocessing executable 'autocallsbug' for autocallsbug-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/autocallsbug /autocallsbug-tmp/Main.p_o ) Linking dist/build/autocallsbug/autocallsbug ... Undefined symbols for architecture x86_64: "_attoparseczm0zi11zi1zi0_DataziAttoparsecziInternalziTypes_manyzimanyzuv_Cb_cc", referenced from: _sR1Q_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) _sR5p_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} (Haven't yet confirmed with 7.8RC1 because that failed to build on my system; reported separately.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC
by GHC 15 Nov '14

15 Nov '14

#9302: relocation R_X86_64_PC32 against undefined symbol (from Data.Array.Parallel) while building GHC ----------------------------------+---------------------------------------- Reporter: ulysses4ever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I followed “First steps” section in [https://ghc.haskell.org/trac/ghc/wiki/Newcomers Newcomers guide] to build GHC from sources (got via git-clone) on Ubuntu 14.04 (amd64). During the last step (make) it comes to the error: {{{ /usr/bin/ld: libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/Prelude/Bool.dyn_o: relocation R_X86_64_PC32 against undefined symbol `dphzmliftedzmcopyzm0zi8zi0zi1_DataziArrayziParallelziPreludeziBool_andPzuv_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9192: Add sameByteArray#
by GHC 15 Nov '14

15 Nov '14

#9192: Add sameByteArray# ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- We have `sameMutableByteArray#` so we ought to have `sameByteArray#` as well, allowing for cheap equality checks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1