August 2014 - ghc-tickets

[GHC] #9132: takeWhile&C. still not fusible
by GHC 15 Dec '14

15 Dec '14

#9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: fusion | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Moderate (less | performance bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- takeWhile is not still fusible, 2 1/2 years after this report: http://www.haskell.org/pipermail/glasgow-haskell- users/2011-December/021299.html The discussion suggests making takeWhile a good producer/consumer with foldr/build fusion: takeWhile' :: (a -> Bool) -> [a] -> [a] takeWhile' p xs = build $ \c n -> foldr (takeWhileF p c n) n xs {-# INLINE takeWhile' #-} takeWhileF p c n x xs = if p x then x `c` xs else n Furthermore, the discussion suggests having rewrite rules to go to this version and then rewrite back (if fusion fails). The report also mentions concatMap (which is a separate known problem). It also mentions drop and dropWhile, but I don't see when they perform allocations, so I think that's an erroneous request. I experienced the bug on GHC 7.6.3, but it seems still there in base-4.7.0.0, judging from the source: http://hackage.haskell.org/package/base-4.7.0.0/docs/src/GHC- List.html#takeWhile -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar
by GHC 15 Dec '14

15 Dec '14

#9169: Add mkWeakTMVar to Control.Concurrent.STM.TMVar -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.2 Keywords: stm | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I just needed a Weak pointer to a TMVar: {{{ -- | Make a 'Weak' pointer to a 'TMVar', using the second argument as -- a finalizer to run when 'TMVar' is garbage-collected. mkWeakTMVar :: TMVar a -> IO () -> IO (Weak (TMVar a)) mkWeakTMVar tmv@(TMVar (TVar t#)) f = IO $ \s -> case mkWeak# t# tmv f s of (# s1, w #) -> (# s1, Weak w #) }}} It might make sense to add a similar function for TSem as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9169> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9393: execvpe should handle ENOTDIR
by GHC 15 Dec '14

15 Dec '14

#9393: execvpe should handle ENOTDIR -------------------------------------+------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If PATH environment variable contains non directory component, execvpe fails by ENOTDIR. For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo". {{{ module Main where import System.Environment import System.Posix.Process main :: IO () main = do env <- getEnvironment executeFile "echo" True [] (Just env) return () }}} {{{ $ PATH=/tmp/foo:$PATH runghc a.hs a.hs: echo: executeFile: inappropriate type (Not a directory) }}} See for example, https://github.com/haskell/cabal/issues/1723 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8778: Typeable TypeNats
by GHC 15 Dec '14

15 Dec '14

#8778: Typeable TypeNats -------------------------------------------+------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type checker) | Version: 7.8.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 4385 | Test Case: | Blocking: -------------------------------------------+------------------------------- It would be useful (the case I have at hand is for some scenarios involving checking of physical dimensions) to be able to combine the Data.Dynamic story with the GHC.TypeLits story. A Typeable instance for every Nat is the sticking point. (I do not know if this is even theoretically possible.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #9371: Overlapping type families, segafult
by GHC 15 Dec '14

15 Dec '14

#9371: Overlapping type families, segafult ----------------------------------+---------------------------------------- Reporter: pingu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------------- Not entirely sure what's going on here. I don't think this should type check; it appears to segfault whilst calling show on the wrong type. This is probably not the absolute minimum required to reproduce. I have reproduced on 7.8.3 and 7.9.20140727. {{{#!haskell {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE OverlappingInstances #-} import Data.Monoid class C x where data D x :: * makeD :: D x instance Monoid x => C x where data D x = D1 (Either x ()) makeD = D1 (Left mempty) instance (Monoid x, Monoid y) => C (x, y) where data D (x,y) = D2 (x,y) makeD = D2 (mempty, mempty) instance Show x => Show (D x) where show (D1 x) = show x main = print (makeD :: D (String, String)) }}} This does not segfault if you add: {{{#!haskell instance (Show x, Show y) => Show (D (x,y)) where show (D2 x) = show x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9415: Superclass cycle with ambiguous type causes loop
by GHC 15 Dec '14

15 Dec '14

#9415: Superclass cycle with ambiguous type causes loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I say {{{ class D a => C a where meth :: D a => () class C a => D a }}} I get a loop in the typechecker. I know what's going on here: the error for the superclass cycle is added during the validity check, but then we go on to do ambiguity checks. Unfortunately, the ambiguity check never finishes. We just need to bail when there are superclass errors before doing the ambiguity check. Patch on the way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9390: Inlining prevents evaluation of ignored parts of unboxed tuples
by GHC 15 Dec '14

15 Dec '14

#9390: Inlining prevents evaluation of ignored parts of unboxed tuples -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples #-} import GHC.IO (IO (..)) import GHC.Prim writeB :: MutableArray# RealWorld Char -> IO () writeB arr# = IO $ \s0# -> (# writeArray# arr# 0# 'B' s0#, () #) inlineWriteB :: MutableArray# RealWorld Char -> () inlineWriteB arr# = case f realWorld# of (# _, x #) -> x where IO f = writeB arr# test :: IO Char test = IO $ \s0# -> case newArray# 1# 'A' s0# of (# s1#, arr# #) -> case seq# (inlineWriteB arr#) s1# of (# s2#, () #) -> readArray# arr# 0# s2# main :: IO () main = test >>= print }}} I would expect this code to output the letter 'B'. When compiled without optimizations, that's exactly what it does. However, with optimizations turned on, it seems that it decides that, in `inlineWriteB`, the state value does not need to be evaluated, which results in the `writeArray#` call never occurring. This affected me when working with the vector and primitive packages. I believe I have a workaround in place (see https://github.com/haskell/primitive/pull/11) but this should probably be fixed in GHC as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #8988: Documentation build fails if GHCi is unavailable
by GHC 15 Dec '14

15 Dec '14

#8988: Documentation build fails if GHCi is unavailable -------------------------------------+------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Operating System: Linux Keywords: | Type of failure: Building GHC Architecture: arm | failed Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Joachim Breitner [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024730.html reported] that the documentation fails to build on Debian armhf: {{{ 0% ( 0 / 5) in 'WwLib' 0% ( 0 / 2) in 'DmdAnal' 0% ( 0 / 2) in 'WorkWrap' compiler/typecheck/TcSplice.lhs-boot:29:1: TcSplice.tcTopSpliceExpr is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:37:1: TcSplice.runMetaE is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:38:1: TcSplice.runMetaP is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:39:1: TcSplice.runMetaT is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:40:1: TcSplice.runMetaD is exported by the hs-boot file, but not exported by the module 67% ( 2 / 3) in 'CmmPipeline' 0% ( 0 / 3) in 'StgCmmHpc' 0% ( 0 / 13) in 'PrelInfo' 0% ( 0 / 4) in 'StgCmmCon' 0% ( 0 / 2) in 'StgCmmExpr' 0% ( 0 / 6) in 'StgCmmBind' 0% ( 0 / 2) in 'CmmParse' 0% ( 0 / 2) in 'StgCmm' 5% ( 9 /175) in 'TcRnMonad' make[2]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 }}} The attached patch fixes this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters
by GHC 15 Dec '14

15 Dec '14

#9336: binutils gold linker detection does not work when called via gcc and selected by commandline parameters -------------------------------------+------------------------------------- Reporter: slomo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The binutils gold detection does not work if it is called via gcc and only selected via commandline parameters (i.e. -fuse-ld=gold). Reason is that the "linker" (actually compiler) is called without its commandline parameters. Attached patch fixes that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock
by GHC 15 Dec '14

15 Dec '14

#8951: genSym uses atomic_inc but doesn't link arm_atomic_spin_lock --------------------------------+---------------------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------+---------------------------------------- On Debian armel, a snapshot of GHC 7.8 from 20140228 fails to build as follows: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20140… {{{ "inplace/bin/ghc-stage2" -o utils/haddock/dist/build/tmp/haddock -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -optc-mlong-calls -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package deepseq-1.3.0.2 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.0.20140228 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build utils/haddock/dist/build/Main.o utils/haddock/dist/build/Documentation/Haddock.o utils/haddock/dist/build/Data/Attoparsec.o utils/haddock/dist/build/Data/Attoparsec/ByteString.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.o utils/haddock/dist/build/Data/Attoparsec/Combinator.o utils/haddock/dist/build/Data/Attoparsec/Number.o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.o utils/haddock/dist/build/Haddock.o utils/haddock/dist/build/Haddock/Interface.o utils/haddock/dist/build/Haddock/Interface/Rename.o utils/haddock/dist/build/Haddock/Interface/Create.o utils/haddock/dist/build/Haddock/Interface/AttachInstances.o utils/haddock/dist/build/Haddock/Interface/LexParseRn.o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.o utils/haddock/dist/build/Haddock/Parser.o utils/haddock/dist/build/Haddock/Parser/Util.o utils/haddock/dist/build/Haddock/Utf8.o utils/haddock/dist/build/Haddock/Utils.o utils/haddock/dist/build/Haddock/Backends/Xhtml.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.o utils/haddock/dist/build/Haddock/Backends/LaTeX.o utils/haddock/dist/build/Haddock/Backends/HaddockDB.o utils/haddock/dist/build/Haddock/Backends/Hoogle.o utils/haddock/dist/build/Haddock/ModuleTree.o utils/haddock/dist/build/Haddock/Types.o utils/haddock/dist/build/Haddock/Doc.o utils/haddock/dist/build/Haddock/Version.o utils/haddock/dist/build/Haddock/InterfaceFile.o utils/haddock/dist/build/Haddock/Options.o utils/haddock/dist/build/Haddock/GhcUtils.o utils/haddock/dist/build/Haddock/Convert.o utils/haddock/dist/build/Paths_haddock.o /«PKGBUILDDIR»/compiler/stage2/build/libHSghc-7.8.0.20140228.a(genSym.o): In function `genSym': genSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock' genSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock' collect2: error: ld returned 1 exit status make[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1 }}} Our armel architecture satisfies "arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6)", so cas() in includes/stg/SMP.h will (uniquely among architectures) not be entirely inline: it calls arm_atomic_spin_lock and arm_atomic_spin_unlock, which are in libHSrts. 7.8 introduces compiler/cbits/genSym.c which uses atomic_inc. How should the linkage requirements be satisfied here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8