- ghc-tickets - Haskell.org

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

[GHC] #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack
by GHC 24 Sep '15

24 Sep '15

#10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack -------------------------------------+------------------------------------- Reporter: | Owner: robstewartuk | Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 7.10.2 Documentation | Keywords: user | Operating System: Unknown/Multiple guide, profiling | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The documentation for compiling with cost centre profiling support is here: https://github.com/ghc/ghc/blob/master/docs/users_guide/profiling.xml#L79 It says: {{{ Compile and run this program as follows: $ ghc -prof -fprof-auto -rtsopts Main.hs $ ./Main +RTS -p 121393 $ }}} This is not the case when cabal or stack are used, as `-prof` should be omitted, i.e. {{{ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-fprof-auto -rtsopts" }}} If the user does not know this and includes `-prof` in the --ghc-options string, they are likely to see compiler error messages relating to `p_dyn`, e.g. {{{ Failed to load interface for ‘GHC.Integer.Type’ Perhaps you haven't installed the "p_dyn" libraries for package ‘integer- gmp-1.0.0.0’? Use -v to see a list of the files searched for. }}} Given that other parts of the `profiling.xml` file does refer to cabal, do people agree that it might be helpful to make it explicit in Section "5.1. Cost centres and cost-centre stacks", that using ghc directly `-prof` should be used (no change to the XML file): {{{ $ ghc -prof -fprof-auto -rtsopts Main.hs }}} Though if cabal/stack is being used, the `-prof` should be omitted (an addition to the XML file): {{{ $ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-fprof-auto -rtsopts" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 `
by GHC 24 Sep '15

24 Sep '15

#8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` ------------------------------+-------------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- While implementing `zeroBits` (see [83bd2f5fc7e/base]) I noticed that constant folding of the expression `clearBit (bit 0) 0` regressed (and improved at the same time) from GHC 7.6.3 to GHC 7.8.1, specifically, the following module {{{#!haskell {-# LANGUAGE CPP #-} module M where import Data.Bits import Data.Int import Data.Word #define T(s,T) \ s :: T ; \ s = clearBit (bit 0) 0 ; \ T(i,Int) T(i8,Int8) T(i16,Int16) T(i32,Int32) T(i64,Int64) T(w,Word) T(w8,Word8) T(w16,Word16) T(w32,Word32) T(w64,Word64) T(z,Integer) }}} compiled with GHC 7.8.1RC2 results in the following Core output: {{{#!haskell -- GHC 7.8.1RC2 i = I# (andI# 1 (notI# 1)) i8 = I8# 0 i16 = I16# 0 i32 = I32# 0 i64 = I64# 0 w = W# (__word 0) w8 = W8# (__word 0) w16 = W16# (__word 0) w32 = W32# (__word 0) w64 = W64# (__word 0) z2 = $w$cbit 0 z1 = complementInteger z2 z = andInteger z2 z1 }}} Thus, `i` and `z` are not properly constant-folded in GHC 7.8.1RC2. With GHC 7.6.3, however, `i` and `z` were properly folded to `0`: {{{#!haskell -- GHC 7.6.3 i = I# 0 i8 = case $fBitsInt8_$cbit i of _ { I8# x#_aDf -> case $fBitsInt8_$cbit i of _ { I8# x#1_aDr -> I8# (word2Int# (and# (int2Word# x#_aDf) (xor# (int2Word# x#1_aDr) (__word 18446744073709551615)))) } } i16,i32,i64 -- equivalent to i8 w = W# (__word 0) w8 = case $fBitsWord8_$cbit i of _ { W8# x#_aEV -> case $fBitsWord8_$cbit i of _ { W8# x#1_aF5 -> W8# (and# x#_aEV (xor# x#1_aF5 (__word 255))) } } w16,w32,w64 -- equivalent to w8 z = __integer 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32