February 2017 - ghc-tickets

[GHC] #8396: cleanup / refactor native code gens
by GHC 09 May '17

09 May '17

#8396: cleanup / refactor native code gens ----------------------------------------+---------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: #8299 , #8287 ,#8272 | Blocking: ----------------------------------------+---------------------------------- the native code gen could use some cleanup / love. 1. Catchup with feature parity of the llvm a. this includes adding SIMD support on applicable native code gen architectures, starting with x86_64 2. make it easier to extend / modify experiment with the native code gen 3. make it easier to add new primops (maybe even a magic inline asm primop?!) 4. other things i'm overlooking right now this also overlaps with a number of related tickets i've been adding to trac. a more ambitious strategic goal that won't be the initial goal, that simon marlow suggested when i chatted with him at ICFP, is to make the native code gen codebase a sort of "mini-llvm". I think thats a bit ambitious for the near term, but maybe thats the point on the horizon we may want to aim towards. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8396> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8573: "evacuate: strange closure type 0" when creating large array
by GHC 09 May '17

09 May '17

#8573: "evacuate: strange closure type 0" when creating large array ----------------------------+---------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------- Consider the following code: {{{ module Main where import Data.Array xs :: [Int] xs = [0 .. 64988] crash :: Int -> IO () crash m = array (0, m) [ (x, x) | x <- xs ] `seq` return () strangeClosureType = do print (sum xs) crash (maxBound - 1) segFault1 = crash (maxBound - 1) segFault2 = do print (sum xs) crash (maxBound - 2) }}} If I compile the program using `ghc --make Main.hs -O -main-is strangeClosureType`, then I get the following error message: {{{ Main: internal error: evacuate: strange closure type 0 (GHC version 7.6.3 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} If I don't use `-O`, or if I let `segFault1` or `segFault2` be `main`, then I get the following error message instead: {{{ Segmentation fault (core dumped) }}} If the number `30000` is replaced by some other number, then the strange closure error may be replaced by a segfault, or even no error at all. Perhaps this is another instance of bug #7762; I have only tested using GHC 7.6.3. I am using base 4.6.0.1 and array 0.4.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8082: Ordering of assembly blocks affects performance
by GHC 09 May '17

09 May '17

#8082: Ordering of assembly blocks affects performance ----------------------------------+--------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- During my work on #6135 I noticed that performance of reverse-complem benchmark in nofib depends highly on the order in which assembly block are laid out. With my patches I am consistently getting a 18-20% speed-up. In theory my patches should not impact performance of existing programs, but for some reason they affect the ordering of generated assembly blocks. On of the earlier versions of my patch I noticed that kahan benchmark suffered a 16% performance hit and again the only difference I noticed in the generated assembly was ordering of blocks. I did a more in-depth investigation in case of kahan and it turned out that this difference results from the way Core is generated: the difference between HEAD and my patches was that a worker function had its three parameters passed in different order. I did not investigate this for reverse-complem because Core is considerably larger, but I could spend some time on it if it might be relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13150: unknown warning is not reported by GHC
by GHC 09 May '17

09 May '17

#13150: unknown warning is not reported by GHC -------------------------------------+------------------------------------- Reporter: jonaprieto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documented and official flag for the warning when a module, function or type with a WARNING or DEPRECATED pragma is used is `-fwarn-warnings- deprecations`. (See for instance https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/options- sanity.html). If the goal is turn off the warning I use `-fno-warn- warnings-deprecations` flag. By default `-fwarn-warnings-deprecations` on. In the next example shows a warning by using the flag mention above. {{{ $ cat Foo.hs {-# OPTIONS_GHC -fwarn-warnings-deprecations #-} import Data.Version (Version(Version, versionBranch, versionTags)) main :: IO () main = do let v = Version { versionBranch = [1,0,0] , versionTags = ["beta"] } return () }}} and GHC outputs: {{{ $ ghc Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Foo.hs:9:11: warning: [-Wdeprecations] In the use of ‘versionTags’ (imported from Data.Version): Deprecated: "See GHC ticket #2496" Linking Foo ... }}} The first unexcepted behavior is the warning message showed above. Following the convention the warning message should be: {{{ Foo.hs:9:11: warning: [-Wwarnings-deprecations] }}} The second unexcepted behavior happened when I used a pragma to silenced the warning `warnings-deprecations`, I committed the mistake to misspelled it, but surprisingly GHC didn't complaint about the unknown pragma, it seems treated again like a synonymous of `-fno-warn-warnings- deprecations` in this case. {{{ {-# OPTIONS_GHC -fno-warn-deprecations #-} import Data.Version (Version(Version, versionBranch, versionTags)) main :: IO () main = do let v = Version { versionBranch = [1,0,0] , versionTags = ["beta"] } return () }}} Searching a little, I found it is not documented the flag -Wdeprecations in recent versions of GHC ( I tested with 7.8.2 too) but it does for instance available in GHC 6.3.0 (See https://manned.org/ghc-cvs/42a4c961) but it actually continues appearing in the source code of the recent GHC. See https://github.com/mlen/ghc/search?utf8=%E2%9C%93&q=deprecations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13239: Phabricator upgrade broke the ticket custom field
by GHC 09 May '17

09 May '17

#13239: Phabricator upgrade broke the ticket custom field -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- We have one custom field which should also appear in commit messages when running "arc diff". Since the upgrade on 07/02/2017, the field no longer appears when running "arc diff". The upgrade path is detailed in this upstream task. https://secure.phabricator.com/T12085 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8332: hp2ps does not escape parentheses
by GHC 09 May '17

09 May '17

#8332: hp2ps does not escape parentheses ------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If some symbol name in the key includes a (, but is cut off before the ), hp2ps generates an invalid postscript file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13211: NegativeLiterals -0.0 :: Double
by GHC 08 May '17

08 May '17

#13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compare {{{ rwbarton@morphism:~$ ghc-8.0.1 -e '-0.0' -0.0 rwbarton@morphism:~$ ghc-8.0.1 -XNegativeLiterals -e '-0.0' 0.0 }}} This behavior is logical, but unexpected. The logic is that with `NegativeLiterals` the literal `-0.0` means `fromRational ((-0)%0)`, which equals `fromRational 0`, which for `Double` is positive zero, not negative zero. But this seems unfortunate. Perhaps it would be best if `-0.0` (or `-` applied to any other literal mathematically equal to zero) was desugared as `negate 0.0` even under `NegativeLiterals`, since there doesn't seem to be any other reason to write `-0.0`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code
by GHC 07 May '17

07 May '17

#8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code -------------------------+------------------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- {{{ {-# OPTIONS_GHC -Wall #-} module A where data ABC = A | B | C abc :: ABC -> Int abc x = case x of A -> 1 }}} {{{ $ ghc -fno-code -fforce-recomp /tmp/A.hs [1 of 1] Compiling A ( /tmp/A.hs, nothing ) }}} {{{ $ ghc -fobject-code -fforce-recomp /tmp/A.hs [1 of 1] Compiling A ( /tmp/A.hs, /tmp/A.o ) /tmp/A.hs:7:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: B C }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10431: EqualityConstraints extension?
by GHC 06 May '17

06 May '17

#10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, writing an equality constraint in a type requires at least one of the `GADTs` or `TypeFamilies` extensions. However, each of these has other effects. Could we have an `EqualityConstraints` extension to permit equality constraints in types, but neither GADTs nor type families? Presumably this extension should imply `MonoLocalBinds`. The `GADTs` extension could then become precisely the conjunction of `GADTSyntax`, `EqualityConstraints` and `ExistentialQuantification`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12947: Core lint error
by GHC 06 May '17

06 May '17

#12947: Core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{#!hs import qualified Control.Monad.Fail as Fail newtype P m a = P { unP :: (a -> IO (m ())) -> IO (m ()) } instance Functor (P m) where instance Applicative (P m) where instance Monad (P m) where instance (Fail.MonadFail m) => Fail.MonadFail (P m) where fail msg = ContT $ \ _ -> Fail.fail msg }}} fails when run with `$ ghci -ignore-dot-ghci -fdefer-typed-holes -dcore- lint /tmp/tQZR.hs`, log is attached -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6