September 2015 - ghc-tickets

[GHC] #10826: [Security] Safe Haskell can be bypassed via annotations
by GHC 23 Sep '15

23 Sep '15

#10826: [Security] Safe Haskell can be bypassed via annotations -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ module Test (hook) where import System.Process import System.IO.Unsafe {-# ANN hook (unsafePerformIO (putStrLn "Woops.")) #-} hook = undefined }}} {{{ ➜ Test ghc -fpackage-trust -XSafe Test_simple.hs [1 of 1] Compiling Test_simple ( Test_simple.hs, Test_simple.o ) [flags changed] Woops. Test_simple.hs:4:1: System.IO.Unsafe: Can't be safely imported! The module itself isn't safe. }}} GHC ultimately rejects the program due to the {{{System.IO.Unsafe}}} import, but this check doesn't occur until GHC has compiled and run the annotation expression, allowing arbitrary IO operations via {{{unsafePerformIO}}}. The solution is probably to move the import check from the end of renaming/typechecking to the start. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #1830: Automatic derivation of Lift
by GHC 23 Sep '15

23 Sep '15

#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"73921df27cac0615d2272b8729381aa0f229a0c8/ghc" 73921df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="73921df27cac0615d2272b8729381aa0f229a0c8" Update Cabal to recognize DeriveLift This should (1) fix the ./validate build, which I accidentally broke in D1168, and (2) update the Cabal submodule so that it recognizes `DeriveLift` as a GHC extension. Reviewed By: adamse, austin Differential Revision: https://phabricator.haskell.org/D1269 GHC Trac Issues: #1830 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10910: Data families seem not to be "surely apart" from anything
by GHC 23 Sep '15

23 Sep '15

#10910: Data families seem not to be "surely apart" from anything -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: data | Operating System: Unknown/Multiple families, closed type families | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following code is not compiling (GHC 7.10.2), it looks as if data families are not considered "surely apart" from any type, despite being injective. {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, GADTs #-} type family Equals x y where Equals x x = True Equals x y = False data Booly b where Truey :: Booly True Falsey :: Booly False data family ID a data instance ID Bool = IB test :: Booly (Equals (ID Bool) Int) test = Falsey }}} (Inspired and simplified from http://stackoverflow.com/questions/32733368 /type-inequalities-in-the-presence-of-data-families#32733368.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10910> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10652: Better cache performance in Array#
by GHC 23 Sep '15

23 Sep '15

#10652: Better cache performance in Array# -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: Compiler | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A common use case for arrays is to loop over them, performing an operation on each element of the array. For `ByteArray#`s, this is guaranteed to have good cache performance: When element `i` is accessed, the CPU's prefetcher will ensure that the element `i+1` is already sitting in cache, so the next loop will not suffer a cache miss. Currently, the `Array#` and `SmallArray#` types do not significantly benefit from the prefetcher. This feature request asks for a few new primops that would improve the situation. My understanding is that the "raw" element in an `Array#` is actually a pointer to the region in memory associated with the "logical" element of the array. When looping, the subsequent pointers are guaranteed to get prefetched, but the subsequent logical element is not guaranteed to be prefetched. In particular, if we'll only get the benefits of prefetching on the logical elements if we're lucky enough that the memory manager happened to allocate these logical elements on the heap next to each other. I don't know enough about GHC internals to check the source code, but my experiments demonstrate that this is not currently happening in my use case, resulting in rather significant performance degradations. (The experiments are rather complicated, so I'm not attaching them.) I propose adding the primops: {{{ packArray# :: Array# a -> b -> b packSmallArray# :: SmallArray# a -> b -> b packMutableArray# :: MutableArray# s a -> State# s -> State# s packSmallMutableArray# :: SmallMutableArray# s a -> State# s -> State# s }}} These operations would have the semantic effect of noops, with the exception that they request that the logical elements in the arrays be arranged adjacently in memory. Thus, future loops over the arrays would benefit from CPU prefetching. There are a number of ways the memory manager could handle these requests, and I don't particular care which is chosen. For example, the memory manager could rearrange the memory immediately or wait until the next garbage collection pass and do it then. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8213: Bad error message when using lazy IO to read from closed handle
by GHC 22 Sep '15

22 Sep '15

#8213: Bad error message when using lazy IO to read from closed handle ------------------------------------+-------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- Today I accidentally wrote this code: {{{ filesEqual :: FilePath -> FilePath -> IO Bool filesEqual f1 f2 = do equal <- withBinaryFile f1 ReadMode $ \f1 -> withBinaryFile f2 ReadMode $ \f2 -> c1 <- BSL.hGetContents h1 c2 <- BSL.hGetContents h2 return (c1 == c2) return $! equal }}} The problem is that I should have done the forcing before the files are closed: {{{ return $! (c1 == c2) }}} I got the incredibly unhelpful error message {{{ myprogram: myfile.txt: illegal operation }}} It took me 2 hours and strace to find out what was going on, especially because around every file open() there are multiple things that map top IllegalOperation (e.g. the ENOTTY from the ioctl that checks whether the device is a TTY). Can we give a better error message here, at least mentioning that the problem has to do with closed (and GC'd) handles? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2595: Implement record update for existential and GADT data types
by GHC 22 Sep '15

22 Sep '15

#2595: Implement record update for existential and GADT data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: tc244 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jkarni): * cc: jkarni@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2595#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 22 Sep '15

22 Sep '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268 -------------------------------------+------------------------------------- Changes (by niteria): * differential: Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192 => Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9927: Should simplifier try more iterations?
by GHC 22 Sep '15

22 Sep '15

#9927: Should simplifier try more iterations? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling with the `devel1` build, we get debugging output while building libraries. I see a lot of warnings like this: {{{ WARNING: file compiler/simplCore/SimplCore.hs, line 592 Simplifier bailing out after 4 iterations [5024, 247, 22, 1] Size = {terms: 3,735, types: 3,028, coercions: 216} }}} It looks to me like the simplifier is doing quite a nice job and shouldn't give up so soon. Concretely, I propose: increase the cutoff and see what the effect is on timing of running the entire GHC build, at whatever settings a performance guru thinks appropriate (almost certainly ''not'' `devel1`!). Ideally, the testing would take place on ghcspeed, so that it's a controlled environment and can be compared nicely with historical performance. I have not carried out this proposal myself because I'm not sure if there are other issues at work here (I don't know the simplifier much at all), and I don't know if there is even a way to get ghcspeed to do this for us. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10906: `SPECIALIZE instance` could be better
by GHC 22 Sep '15

22 Sep '15

#10906: `SPECIALIZE instance` could be better -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | 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: | -------------------------------------+------------------------------------- END GOAL: Use dependent types (or their approximation) to make code run faster. ----------------------------- Suppose we have a heterogeneous list type that can only hold a nice, limited set of things, as defined by this universe: {{{ data U = INT | BOOL | LIST U -- interpret the universe into Haskell types type family El u where El 'INT = Int El 'BOOL = Bool El ('LIST u) = [El u] }}} Here's our list type: {{{ data HList :: [U] -> * where Nil :: HList '[] (:>) :: El u -> HList us -> HList (u ': us) infixr 5 :> }}} Now, suppose I want to write a `Show` instance for `HList us`. This should certainly be possible -- we can see that such a list can contain only things that have instances for `Show`. But I don't really expect GHC to do the nested induction to figure that out. Through moderate pyrotechnics, I can get something like this to type- check, where I'm eliding the pyrotechnics: {{{ -- space separated (terminated, actually), just for ease instance {- don't look here -} => Show (HList us) where show Nil = "" show (x :> xs) = {- convince GHC that we can `show x` -} $ show x ++ " " ++ show xs }}} (The full file is attached. But it's nothing extraordinary.) Now, suppose in client code, I know I'm often dealing with `HList '[INT, BOOL, LIST INT]`. Let's call that type `MyList`. When printing a `MyList`, the `Show` instance above has to do a runtime lookup to figure how to print the elements of `MyList`. It must do this //every time//. This is very silly. The whole point of putting the element types in the index to `HList` is so that GHC can know, statically, what types the elements are. We shouldn't have to check! The next step in my thought process was to use `{-# SPECIALIZE instance ... #-}` to specialize the `Show` instance. But then I ran into two problems: 1. `{-# SPECIALIZE instance ... #-}` is allowed only in the context of the instance declaration. You can't do it in an importing module, even if the exporting module is kind enough to say `INLINABLE` in the right spots. 2. `{-# SPECIALIZE instance ... #-}` doesn't allow one specialization to use another. 3. (For more complicated scenarios) `{-# SPECIALIZE instance ... #-}` doesn't allow type families in the `...`. About point (1): Is there a good reason for this restriction? Of course, the concrete implementations of the methods of the instance to be specialized must be available, but the exporting module should be able to arrange that with the right pragmas. To illustrate (2), I said `{-# SPECIALIZE instance Show (HList '[ 'INT, 'BOOL, 'LIST 'INT ]) #-}` and GHC specialized only the first layer. OK. Reasonable enough. But then I tried {{{ {-# SPECIALIZE instance Show (HList '[ 'LIST 'INT ]) #-} {-# SPECIALIZE instance Show (HList '[ 'BOOL, 'LIST 'INT ]) #-} {-# SPECIALIZE instance Show (HList '[ 'INT, 'BOOL, 'LIST 'INT]) #-} }}} and it still only went one layer deep. One specialization didn't call another. (Examined with `-ddump-simpl` on `-O2`.) That's frustrating. About point (3): While it would be a bad idea to allow type families in normal instance heads, it seems sensible to allow them in `SPECIALIZE instance`. This is rather like allowing expressions (instead of, say, bare variables) on the LHS of rules. ------------------- This ticket posting may be a little overly broad, but I'd love to know what others think about all of this. As we pick off the pieces that we decide are actually feasible, they should probably become separate tickets. But I think these are all of a piece and might benefit from some general thought about the whole `SPECIALIZE instance` pragma and how improvements here can make a big difference when we have dependent types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1012: ghc panic with mutually recursive modules and template haskell
by GHC 22 Sep '15

22 Sep '15

#1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | TH_import_loop Blocked By: | Blocking: Related Tickets: #9032 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:34 jstolarek]: > #9032 looks related (not sure if it's a duplicate or not). It's not a duplicate. #9032 is fixed, but `make test TEST=TH_import_loop` (this ticket) is still failing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1012#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0