- ghc-tickets - Haskell.org

[GHC] #12981: SMP never enabled on ARMv7
by GHC 22 Dec '16

22 Dec '16

#12981: SMP never enabled on ARMv7 -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- SMP support should be enabled on ARMv7, however I have been unable to force it so. The problem lies in `mk/config.mk.in`, where double quotes have been erroneously added around the `ArchSupportsSMP` variable. This causes the `GhcWithSMP` variable to always be `NO` when building for ARM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13030: Build error from following default nixos instructions and -Werror
by GHC 22 Dec '16

22 Dec '16

#13030: Build error from following default nixos instructions and -Werror -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- When building the RTS with the nixos instructions from the wiki (https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#NixNixOS) if you enable `Werror` then the build fails with warnings from the rts. For example {{{ rts/Interpreter.c: In function ‘interpretBCO’: rts/Interpreter.c:593:41: error: warning: ‘obj’ may be used uninitialized in this function [-Wmaybe- uninitialized] debugBelch("Returning: "); printObj(obj); }}} Is this something I should worry about? Are there additional flags that I should pass to gcc in order to turn these warnings off? The workaround is compile without `-Werror` and then turn it on once the `rts` has been compiled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13017: GHC panics during build of etkmett/free
by GHC 22 Dec '16

22 Dec '16

#13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- While using stack, I get the following error: {{{ -- While building package free-4.12.4 using: /home/user/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.0.0_ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/user/dev/haskellito/.stack- work/logs/free-4.12.4.log Configuring free-4.12.4... Building free-4.12.4... Preprocessing library free-4.12.4... [ 1 of 16] Compiling Control.Monad.Free.TH ( src/Control/Monad/Free/TH.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Free/TH.o ) [ 2 of 16] Compiling Control.Monad.Free.Class ( src/Control/Monad/Free/Class.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Free/Class.o ) [ 3 of 16] Compiling Control.Monad.Trans.Iter ( src/Control/Monad/Trans/Iter.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Trans/Iter.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Ix{Int}.index: Index (16777216) out of range ((0,392)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13028: Compile-time validation of literals in IsString instances
by GHC 22 Dec '16

22 Dec '16

#13028: Compile-time validation of literals in IsString instances -------------------------------------+------------------------------------- Reporter: jml | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- I would like to be able to make `IsString` instances using the `OverloadedStrings` extension such that my instance rejects some literals as being invalid and such that that rejection happens at compile time, so that programming mistakes don't make it into the code I give to my users. I have a couple of use cases where I have a `Name` type that only admits certain strings. e.g. {{{#!hs module Name (Name(getName), makeName) where import Data.Text (Text) import qualified Data.Text as Text -- | A guaranteed non-empty name. newtype Name = Name { getName :: Text } deriving (Eq, Show, Ord) makeName :: Text -> Maybe Name makeName name | Text.null name = Nothing | otherwise = Just name }}} In a real use case, I'd check for valid characters, not starting with a digit, that sort of thing. The idea is that we don't export the `Name` constructor, which means anyone using a `Name` value can trust that it has certain properties (in this case, non-empty). My problem is that I'd like to use literal names in many places. e.g. {{{#!hs programName :: Name programName = fromJust $ makeName "the-great-and-powerful-turtle" }}} Because I do this a lot, I've defined an `unsafeMakeName` helper that does pretty much the same thing: {{{#!hs unsafeMakeName :: Text -> Name unsafeMakeName name = fromMaybe (error $ "Invalid name: " <> Text.unpack name) (makeName name) }}} The problem with this approach is that even though the cause of the mistake is a programming error, I don't find out about it until run time. What I'd like to do is write an `IsString` instance for `Name` which does that validation, e.g. {{{#!hs instance IsString Name where fromString = unsafeMakeName . Text.pack }}} ... but to get the error about invalid names in literals at compile-time. This doesn't seem logically impossible to me, since the compiler could know the values of literals with certainty. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8107: need types to express constant argument for primop correctness
by GHC 22 Dec '16

22 Dec '16

#8107: need types to express constant argument for primop correctness ------------------------------------+------------------------------------- Reporter: carter | 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: | ------------------------------------+------------------------------------- (not sure if this is a bug or a feature request, or a task, or a dialogue, filing as a bug for now) a number of compiler intrinsics that GHC has started to support (prefetch) and will come to support (concurrent memory operations a la http://ghc.haskell.org/trac/ghc/ticket/7883) require certain arguments to be statically fixed at compile time {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# -> Int# -> Addr# with llvm_only = True }}} consider the specification on the llvm side for prefetch http://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic {{{ Syntax:¶ declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>, i32 <cache type>) Overview: The ‘llvm.prefetch‘ intrinsic is a hint to the code generator to insert a prefetch instruction if supported; otherwise, it is a noop. Prefetches have no effect on the behavior of the program but can change its performance characteristics. Arguments: address is the address to be prefetched, rw is the specifier determining if the fetch should be for a read (0) or write (1), and locality is a temporal locality specifier ranging from (0) - no locality, to (3) - extremely local keep in cache. The cache type specifies whether the prefetch is performed on the data (1) or instruction (0) cache. The rw, locality and cache type arguments must be constant integers. }}} the punch line is that we're starting add primops that REALLY require certain arguments to be compile time constants to work correctly, otherwise there will by definition be compiler errors after the c-- phase when operations are passed along to the llvm backend and friends. (for the atomicity ops, i'll be looking into adding them to the native code gen, but the point being it will likely trigger an error at code gen time). a strawman approach would look like adding a type {{{ ReallyActuallyConstant :: * or unliftedtype -> * unliftedtype}}} roughly, then prefetch could have the type {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# ->ReallyActuallyConstant Int# -> Addr# with llvm_only = True }}} a way of emulating something like this functionality now, would be some template haskell that lets you lift a compile time constant of type t into the type ReallyActuallyConstant t, and is the only way to build a value of that type "ReallyActuallyConstant t". That said, that approach seems like a bad way of providing type safetype for making sure primops actually compile! Point being, some sort of way of nicely enforcing that a value needs to be available at compile time, that doesn't require doing abusing template haskell, is the idea i'm pointing at. Might also be useful for other things, but for now, i'm merely remarking on an invariant these primops have -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker
by GHC 21 Dec '16

21 Dec '16

#13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: SpecConstr | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- !SpecConstr creates the following rules, with the right cajoling. (I've used unboxed integers merely to avoid w/w, which only adds noise in this example.) {{{#!hs data VL :: [k] -> * where VLZ :: VL '[] VLS :: VL as -> VL (a ': as) lengthVL :: GHC.Types.SPEC -> VL as -> Int# {-# INLINABLE lengthVL #-} lengthVL !sPEC VLZ = 0# lengthVL !sPEC (VLS vl) = 1# +# lengthVL sPEC vl ==================== Tidy Core rules ==================== "SC:lengthVL0" [ALWAYS] forall (@ a) (@ (as :: [*])) (sc :: VL as). lengthVL @ (a : as) SPEC (VLS @ * @ (a : as) @ as @ a @~ (<a : as>_N :: (a : as) ~ (a : as)) sc) = lengthVL_$slengthVL1 @ a @ as sc "SC:lengthVL1" [ALWAYS] forall (sc :: VL '[]). lengthVL @ '[] SPEC sc = lengthVL_$slengthVL sc }}} But the cons-case specialization, `lengthVL_$slengthVL1`, is marked as a loopbreaker. Consider the following idiomatic usage to see why that is problematic. {{{#!hs class KnownSpine (as :: [k]) where sing :: VL as instance KnownSpine '[] where -- ' {-# INLINE sing #-} sing = VLZ instance KnownSpine as => KnownSpine (a ': as) where -- ' {-# INLINE sing #-} sing = VLS sing example :: Int example = I# $ lengthVL SPEC (sing :: VL '[Int,Char,Bool]) }}} The right-hand side of `example` would ideally be simplified to `3`. It's not, ultimately because the specialization is marked as a loopbreaker. I switched on `-dverbose-core2core` to track the simplification of the right-hand side of `example`. 1) The `sing` dictionary is unfolded to constructor applications. 2) Those are floated out but then pre-inlined- unconditionally right back in before CSE gets a chance to spoil it. 3) Thus the VLS rule fires. But it only fires once, because of the loopbreaker designation! I have not yet investigated why the specialization in the cons-case is marked a loopbreaker. (Even if the specialization wasn't being considered a loopbreaker --- which immediately makes this approach to optimization a dead-end --- I don't know with any certainty how to force the specialization to be inlined in those cases where its right-hand side was relatively large.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13024: T12877 intermittently fails
by GHC 21 Dec '16

21 Dec '16

#13024: T12877 intermittently fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: 8.1 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: -------------------------------------+------------------------------------- I recently ran a validate where this failed: {{{ bytes allocated value is too high: Expected T12877(normal) bytes allocated: 135979000 +/-5% Lower bound T12877(normal) bytes allocated: 129180050· Upper bound T12877(normal) bytes allocated: 142777950· Actual T12877(normal) bytes allocated: 143317872· Deviation T12877(normal) bytes allocated: 5.4 % *** unexpected stat test failure for T12877(normal) }}} When I reran the test by itself, it passed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12485: -package-db flags now need to be sorted by dependency order
by GHC 21 Dec '16

21 Dec '16

#12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | 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: -------------------------------------+------------------------------------- After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error: {{{ <command line>: cannot satisfy -package-id b-1-XXX: b-1-XXX is unusable due to missing or recursive dependencies: a-1-XXX (use -v for more information) }}} See attached file for a repro. It's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #13023: strange behaviour of GHCi when int value exceed int range
by GHC 21 Dec '16

21 Dec '16

#13023: strange behaviour of GHCi when int value exceed int range -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- import Data.Char type Bit = Int int2bin :: Int -> [Bit] int2bin 0 = [] int2bin n = reverse (n `mod`2 : (reverse (int2bin (n `div`2)))) When n = 4200000000, GHCi crash with "out of memory" but if n = 4300000000 GHCi send a result as [1,0,0,1,1,0,0,1,1,0,0,1,0,1,1,0,0,0,0,0,0,0,0] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12969: Rebindable enumFrom etc. syntax
by GHC 21 Dec '16

21 Dec '16

#12969: Rebindable enumFrom etc. syntax -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple RebindableSyntax | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Constructs like `[x..]` or `[x..y]` etc. seem to use wired-in `enumFrom`, `enumFromTo`, etc. names even when `RebindableSyntax` is turned on. I think we should allow these to be shadowed by the user the same way they can shadow other syntax desugarings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3