September 2015 - ghc-tickets

Re: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
by GHC 27 Sep '15

27 Sep '15

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1282 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1282 Comment: I have Phab:D1282 up on Phabricator covering this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7883#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9079: Foreign.C.Types in haskell2010
by GHC 27 Sep '15

27 Sep '15

#9079: Foreign.C.Types in haskell2010 -----------------------------------------+--------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- According to Haskell 2010, a marshallable foreign type has to be a `newtype` of a basic type with exposed constructor. Why constructors are not exposed in the module `Foreign.C.Types` from `haskell2010`? When I replace `base` with `haskell2010` in {{{ module Test where import Foreign.C foreign import ccall unsafe "sys/mount.h umount" umount :: CString -> IO CInt }}} I get {{{ Unacceptable result type in foreign declaration: IO CInt When checking declaration: foreign import ccall unsafe "static sys/mount.h umount" umount :: CString -> IO CInt }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1883: GHC can't find library using "short" name
by GHC 27 Sep '15

27 Sep '15

#1883: GHC can't find library using "short" name -------------------------------------+------------------------------------- Reporter: m4dc4p | Owner: Phyx- Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: link library | windows Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #2283 #3242 | Differential Rev(s): #1883 #7097 | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: Assigning this to myself as this will be fixed once the fix for the test in #9907 or Phab:D1244 is pushed. The reason this still doesn't work is that the code that Simon added won't be called in a few cases. This code was added in `Linker.c` which is called from `Linker.hs`. `Linker.hs` itself tries to find the library by just appending ".dll" to the name. Eventually none of the methods will be able to find the DLL and we then the code assumes the `Linker.c` can find it, so it passes the short name to the `addDLL` function. Eventually `addDLL` tries `lib%s.DLL` but this will most of the time fail since `LoadLibrary` won't be able to find it because the `extra-lib-dirs` paths are never used by it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1883#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10907: GHC fails to read file with byte-order mark when LANG=C
by GHC 25 Sep '15

25 Sep '15

#10907: GHC fails to read file with byte-order mark when LANG=C -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: #6016, #6037 Differential Revisions: | -------------------------------------+------------------------------------- I've attached a minimal example that causes the problem. Compiling `ByteOrderMark.hs` like so fails: {{{ $ LANG=C ghc ByteOrderMark.hs ByteOrderMark.hs: hLookAhead: invalid argument (invalid byte sequence) }}} I can reproduce this on x86_64 Linux using GHC 7.10.2 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10907> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10867: Primop types should not mention ()
by GHC 25 Sep '15

25 Sep '15

#10867: Primop types should not mention () -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I've just noticed that two primpops have types that mention tuples (see `compiler/prelude/primops.txt.pp`): {{{ primop FinalizeWeakOp "finalizeWeak#" GenPrimOp Weak# a -> State# RealWorld -> (# State# RealWorld, Int#, (State# RealWorld -> (# State# RealWorld, () #)) #) primop Check "check#" GenPrimOp (State# RealWorld -> (# State# RealWorld, a #) ) -> (State# RealWorld -> (# State# RealWorld, () #) ) }}} But they really really shouldn't. The unit tuple is a type defined in Haskell, and it makes an awkward cycle if the supposedly-truly-primitive primpops refer to it. (Discovered during the saga of [Phab:D757].) Most primpops do not do this; eg {{{ primop WriteMutVarOp "writeMutVar#" GenPrimOp MutVar# s a -> a -> State# s -> State# s }}} Now `check#` and `finalizeWeak#` are pretty obscure primops and I don't think anyone will mind if I fix their type signatures. But in addition to doing that, I'll have to look at their implementations. '''But where ''are'' those implementations??''' I can't find anything in the RTS. While thinking about it * Both come with literally zero Haddock documentation which is terrible. The type of both is pretty obscure. * `check#` is a very short name for very specialised STM operation. Surely we should call it `addSTMInvariant` or something like that? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10674: Expose OSThreadID and assorted functions from Haskell
by GHC 24 Sep '15

24 Sep '15

#10674: Expose OSThreadID and assorted functions from Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently given two {{{ThreadId}}}s, there is no way to tell without FFI if they are running on the same OS thread. There is not even a way to ask what OS thread we are currently on: something like {{{myThreadId}}} except {{{myOsThreadId}}}. Currently to remedy this, the user has to effectively copy and paste parts of the internal rts files and use something like {{{.hsc}}} with CPP to get at this information. This is not really portable on the user side and requires nasty gutting. In the RTS the function we are interested in is at least {{{osThreadId}}}: at least with this function we can inspect current {{{OSThreadId}}} and communicate it out through an {{{MVar}}} or otherwise. So this is a feature request for an abstract type {{{OSThreadId}}} with instances of at least {{{Eq, Show}}} and a function {{{myOsThreadId :: IO OSThreadId}}}. Nice to have would be {{{osThreadId :: ThreadID -> IO OSThreadId}}} but not critical. If there is room for optimisation in GHC, functions like {{{sameOsThread :: ThreadId -> ThreadId -> IO Bool}}} would also be nice but again not critical. Not sure what to set in ticket meta-data so please change as appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10692: Replace (SourceText, FastString) with WithSourceText data type
by GHC 24 Sep '15

24 Sep '15

#10692: Replace (SourceText,FastString) with WithSourceText data type -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Phab:D907 introduced `SourceText` for a number of data types, by replacing `FastString` with `(SourceText,FastString)`. Since this has an `Outputable` instance, no warnings are generated when `ppr` is called on it, but unexpected output is generated. See Phab:D1096 for an example of this. Replace the `(SourceText,FastString)` tuples with a new data type {{{#!hs data WithSourceText = WithSourceText SourceText FastString }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10767: SPECIALIZE generates warning but works fine
by GHC 24 Sep '15

24 Sep '15

#10767: SPECIALIZE generates warning but works fine -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I have this code: {{{#!hs {-# LANGUAGE ScopedTypeVariables, TypeFamilies #-} module Main where import Data.Proxy class SpecList a where type List a :: * slCase :: List a -> b -> (a -> List a -> b) -> b data IntList = ILNil | ILCons {-# UNPACK #-} !Int IntList deriving (Show) instance SpecList Int where type List Int = IntList slCase ILNil n _ = n slCase (ILCons i t) _ c = c i t fromList :: [Int] -> IntList fromList [] = ILNil fromList (h : t) = ILCons h (fromList t) lst1 :: IntList lst1 = fromList [1..10] {-# SPECIALIZE genLength :: Proxy Int -> List Int -> Int #-} genLength :: forall a . SpecList a => Proxy a -> List a -> Int genLength p lst = slCase lst 0 (\(_ :: a) tail -> 1 + genLength p tail) main :: IO () main = print (genLength (Proxy :: Proxy Int) lst1) }}} When I compile it(no matter which optimization level is used), it prints this warning: {{{ Main.hs:30:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case cobox_a17r of _ [Occ=Dead] { GHC.Types.Eq# cobox -> genLength @ Int $dSpecList_a17q } Orig lhs: case cobox_a17r of cobox_a17r { GHC.Types.Eq# cobox -> genLength @ Int $dSpecList_a17q } }}} (I presume this is related with the rewrite rule generated to be able to replace calls to generic version to calls to specialized versions when possible.) But this program compiles fine with -O2, i.e. `genLength lst1` is replaced with specialized definition of `genLength`, without any dictionary passing. So the warning is confusing for two reasons: - It's not related with the code, it seems like it's a problem with GHC- generated rewrite rule. - It still works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10738: Make Exception datatypes into newtypes
by GHC 24 Sep '15

24 Sep '15

#10738: Make Exception datatypes into newtypes -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4961 Differential Revisions: | -------------------------------------+------------------------------------- Certain instances of `Exception` in `base` are datatypes with only one argument: {{{#!hs data RecUpdError = RecUpdError String data RecConError = RecConError String data RecSelError = RecSelError String data PatternMatchFail = PatternMatchFail String data NoMethodError = NoMethodError String data AssertionFailed = AssertionFailed String }}} Why not make these into `newtype`s? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10555: RULE left-hand side too complicated to desugar
by GHC 24 Sep '15

24 Sep '15

#10555: RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: yes | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHC version 7.10.1.20150612 breaks the `fast-math` package, which compiled fine on GHC 7.10.1. To reproduce, run `cabal install fast-math`. {{{ Numeric/FastMath/Approximation.hs:60:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> +## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> +## wild_00 }) wild_00 } Numeric/FastMath/Approximation.hs:63:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> -## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> -## wild_00 }) wild_00 } Numeric/FastMath/Approximation.hs:103:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_X2 { __DEFAULT -> minusFloat# wild_X2 }) wild_00 } Orig lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_00 { __DEFAULT -> minusFloat# wild_00 }) wild_00 } ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired float commute left * To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 4004 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8