- ghc-tickets - Haskell.org

[GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD
by GHC 07 Apr '17

07 Apr '17

#13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm trying to implement `Float` <-> `Word32` bit casts (`Double` <-> `Word64` works fine) in CMM using: {{{ stg_word32ToFloatzh(I32 w) { F_ f; P_ ptr; STK_CHK_GEN_N (FLOAT_STACK_WDS); reserve FLOAT_STACK_WDS = ptr { I32[ptr] = w; f = F_[ptr]; } return (f); } stg_floatToWord32zh(F_ f) { I32 w; P_ ptr; STK_CHK_GEN_N (FLOAT_STACK_WDS); reserve FLOAT_STACK_WDS = ptr { I32[ptr] = f; w = I32[ptr]; } return (w); } }}} This compiles correctly and passes all tests with ghc 8.0.2, but compiling the above CMM with git HEAD (currently 1e58efb16f7) results in: {{{ Cmm lint error: in basic block cq in assignment: _cj::I32 = R1; Reg ty: I32 Rhs ty: I64 Program was: {offset cq: // global _cj::I32 = R1; //tick src<rts/CastFloatWord.cmm:(49,1)-(61,1)> goto cm; cm: // global if ((old + 0) - 8 / 8 < SpLim) (likely: False) goto co; else goto cp; co: // global I64[(young<cn> + 8)] = cn; call stg_gc_noregs() returns to cn, args: 8, res: 8, upd: 8; cn: // global goto cm; cp: // global _cl::P64 = (old + 16); //tick src<rts/CastFloatWord.cmm:(55,29)-(58,5)> I32[_cl::P64] = _cj::I32; _ck::F32 = F32[_cl::P64]; F1 = _ck::F32; call (P64[(old + 8)])(F1) args: 8, res: 0, upd: 8; } }}} ghc 8.0.2 is accepts this code and gives the correct results, so I can only assume that git HEAD is incorrect. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE
by GHC 07 Apr '17

07 Apr '17

#13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE FlexibleContexts, FlexibleInstances, FunctionalDependencies, MultiParamTypeClasses, UndecidableInstances #-} module Test where import Foreign.Ptr class DescendentOf a b where upCast :: Ptr b -> Ptr a upCast = castPtr class ChildOf b c | c -> b instance {-# OVERLAPPING #-} DescendentOf a a where upCast = id instance (DescendentOf a b, ChildOf b c) => DescendentOf a c data Value operateOnValue :: Ptr Value -> IO () operateOnValue _ = pure () typeOf :: DescendentOf Value v => Ptr v -> IO () typeOf = operateOnValue . upCast }}} The above code results in the following warning with GHC 8.2rc1 {{{ Test.hs:21:11: warning: [-Wsimplifiable-class-constraints] The constraint ‘DescendentOf Value v’ matches an instance declaration instance (DescendentOf a b, ChildOf b c) => DescendentOf a c -- Defined at Test.hs:14:10 This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance | 21 | typeOf :: DescendentOf Value v => Ptr v -> IO () }}} However, if I add `OVERLAPPABLE` to the second instance, the warning disappears because such instances are explicitly excluded in the check for this warning. I think it would make sense to silence this warning also if there is any `OVERLAPPING` instance that matches. The current warning is confusing since in this case the constraint actually can’t be simplified without changing the meaning of the code (the first instance would no longer match). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13526> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13135: Typechecker: the 'impossible' happened
by GHC 07 Apr '17

07 Apr '17

#13135: Typechecker: the 'impossible' happened -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | 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: -------------------------------------+------------------------------------- May be something to do with type family dependencies? Unclear - but I've attached a reduced source. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible
by GHC 07 Apr '17

07 Apr '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Duog, I've posted the relevant pieces of your branch to Phabricator as Phab:D3427. Feel free to "commandeer" this Differential using the Actions menu at the bottom on the page. Once you have done so you can update the Diff using `arc diff --update D3427`. Do let me know if I can be of assistance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4960: Better inlining test in CoreUnfold
by GHC 07 Apr '17

07 Apr '17

#4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | Inlining 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: | -------------------------------------+------------------------------------- Changes (by bredelings): * cc: bredelings (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4960#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 07 Apr '17

07 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > If i remember correctly, a `ByteArray#` would have an extra header and a length field, which in turn bring a 2 words overhead, one word more compareing to the `(# int#, addr# #)` solution. Right, this would incur another word of overhead. However, on the majority of machines this is 8-bytes which is quite significant. Looking at GHC itself, just over a third of all string literals are 8 characters or less (6000 our of 17500). For these literals adding another word would increase the fractional overhead from >50% to >67%. I have spoken with GHC users targeting mobile platforms who already suffer from our code size; it's hard to justify such an increase without a very good reason. > But i would argue this overhead can bring a nice solution to ghc's long lasting literal problem, for example, vector package and text package can provide some TH to directly save some byteArray# literal using hexadecimal notation, this save many extra copying during runtime. What is stopping these libraries from providing this mechanism currently using `Addr#` and primitive strings directly? In general primitive strings are, as the name would suggest, primitive. I'm not sure forcing a heap object representation here is necessary nor prudent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:59> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13539: Options -pgmlclang and -pgmlc overlap
by GHC 07 Apr '17

07 Apr '17

#13539: Options -pgmlclang and -pgmlc overlap -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to tell GHC to use `clang` with `-pgmlclang`, and only after some time found out that it won't work, because GHC interprets that as `-pgmlc` `lang` (surprise, `-pgmlc` is also an option). The user manual suggests that `pgmc<value>` (without space) is the recommended syntax. If spaces are in fact allowed, we should change the manual. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13505: Write the name of the people of the Haskell Committee into the GHC compiler
by GHC 06 Apr '17

06 Apr '17

#13505: Write the name of the people of the Haskell Committee into the GHC compiler -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- Hi,\\ Write the name of the people in the Haskell report file is good.\\ I propose to write also the names in the compiler.\\\\ The names would be accessible, for instance, by the following commands:\\ with GHC in a command line: {{{ghc -- Committee}}}\\ with GHCi: {{{: Committee}}}\\\\ For instance, in the Haskell 2010 Language Report, the Haskell Committee is not up-to-date. In the last release of GHC, 8.0.2, it would have been the current Committee with the former.\\ What do you all think?\\ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10053: problem in ghci calling main after loading compiled code
by GHC 06 Apr '17

06 Apr '17

#10053: problem in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :load rsa Ok, modules loaded: Main. Prelude Main> :show modules Main ( rsa.hs, rsa.o ) Prelude Main> main Too late for parseStaticFlags: call it before runGhc or runGhcT *** Exception: ExitFailure 1 Prelude Main> note, there is no failure if I load interpreted code -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 06 Apr '17

06 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): If i remember correctly, a `ByteArray#` would have an extra header and a length field, which in turn bring a 2 words overhead, one word more compareing to the `(# int#, addr# #)` solution. But i would argue this overhead can bring a nice solution to ghc's long lasting literal problem, for example, `vector` package and `text` package can provide some TH to directly save some `byteArray#` literal using hexadecimal notation, this save many extra copying during runtime. Finally, by nature of binary loading, this `ByteArray#` is pinned, so we can still get its address without trouble. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0