April 2017 - ghc-tickets

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 winter): > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. > Although, thinking about this for a tad longer it's not necessarily clear that this is a direction which we'd want to go. Afterall, it would require the introduction of another closure type since the current representation requires that the bytes directly follow the closure header. I suspect this would introduce quite a bit of complexity in the RTS. Yes, that is a more expensive design IMO. I read about the notes on unpointed heap object(maybe somewhere in `infoTable.h`), it says that they shouldn't be entered. But i fail to understand how can we provide `unsafeMkByteArray#` in an obvious way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:63> 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): > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. Although, thinking about this for a tad longer it's not necessarily clear that this is a direction which we'd want to go. Afterall, it would require the introduction of another closure type since the current representation requires that the bytes directly follow the closure header. I suspect this would introduce quite a bit of complexity in the RTS. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:62> 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): Replying to [comment:60 winter]: > > What is stopping these libraries from providing this mechanism currently using Addr# and primitive strings directly? > > The problem is that there's no way to cast `Addr#` into `ByteArray#` without copy, while unboxed vector(not storable) and text both want `ByteArray#`. > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. > > 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. > > I disagree. If we give string literal a proper compact representation, not only we can save unnecessary copying during runtime, we can save code size in other ways. > > Consider if string literal now are `ByteArray#`s, we can use rules to simplify a UTF8 text type like `forall a. fromString (GHC.unpackCString# a) = UTF8 a`, that means we can directly use constructor here instead of several calls. The same applys for unbox vectors using unboxed string literal and hexdecimal notation. I agree that these are all great simplifications, but I don't see why changing the representation of primitive strings is necessary to get there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build
by GHC 07 Apr '17

07 Apr '17

#13534: ghc-8.2.0.20170404/testsuite/timeout failed to build --------------------------------------+--------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: timeout | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- {{{ Looks like you don't have timeout, building it first... make -C ../timeout all make[2]: Entering directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe python3 calibrate '' > calibrate.out Traceback (most recent call last): File "calibrate", line 20, in <module> compiler_name, 'TimeMe.hs', '-o', 'TimeMe', '-O2') File "/usr/lib64/python3.6/os.py", line 920, in spawnl return spawnv(mode, file, args) File "/usr/lib64/python3.6/os.py", line 871, in spawnv return _spawnvef(mode, file, args, None, execv) File "/usr/lib64/python3.6/os.py", line 838, in _spawnvef raise ValueError('argv first element cannot be empty') ValueError: argv first element cannot be empty make[2]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' make[2]: *** [Makefile:54: calibrate.out] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/tests' make[1]: *** [../mk/test.mk:293: ../timeout/install-inplace/bin/timeout] Error 2 make: *** [Makefile:217: test] Error 2 }}} Full buildlog at https://copr- be.cloud.fedoraproject.org/results/petersen/ghc-8.2.1/fedora-26-x86_64/0053… (for a couple of weeks) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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 winter): > What is stopping these libraries from providing this mechanism currently using Addr# and primitive strings directly? The problem is that there's no way to cast `Addr#` into `ByteArray#` without copy, while unboxed vector(not storable) and text both want `ByteArray#`. > 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. I disagree. If we give string literal a proper compact representation, not only we cab save unnecessary copying during runtime, we can save code size in other ways. Consider if string literal now are `ByteArray#`s, we can use rules to simplify a UTF8 text type like `forall a. fromString (GHC.unpackCString# a) = UTF8 a`, that means we can directly use constructor here instead of several calls. The same applys for unbox vectors using unboxed string literal and hexdecimal notation, which we have to use `fromList` and a real list now(which carrys a much larger overhead). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4862: Enable usage of gold linker with GHC
by GHC 07 Apr '17

07 Apr '17

#4862: Enable usage of gold linker with GHC -------------------------------------+------------------------------------- Reporter: ajd | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 7.4.3 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have opened #13541, which describes a proposal for making it easier to use `gold`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4862#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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 06 Apr '17

06 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 06 Apr '17

06 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 06 Apr '17

06 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