April 2017 - ghc-tickets

[GHC] #10323: Add Android and iOS Operating Systems in Trac
by GHC 10 May '17

10 May '17

#10323: Add Android and iOS Operating Systems in Trac -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: hvr Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Trac & Git | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- These are sufficiently different from Linux/MacOS X to be distinguished from those Operating System values, and sufficiently mainstream to not fall under Other. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9120: Cache intermediate powers
by GHC 10 May '17

10 May '17

#9120: Cache intermediate powers ------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `GHC.Float` caches powers of 2 and 10. The arrays of powers are currently constructed using: {{{ expts :: Array Int Integer expts = array (minExpt,maxExpt) [(n,2^n) | n <- [minExpt .. maxExpt]] }}} Unfortunately, the intermediate powers in the `2^n` computation are not stored back in the array, only the result is. I propose to use the following scheme that does store the intermediate powers: {{{ -- | Exponentiation with a cache for the most common numbers. expt :: Integer -> Int -> Integer expt _ e | e < 0 = error "Negative exponent" expt 2 e | e <= maxExpt2 = expts2 ! e | otherwise = expts2 ! maxExpt2 * 2^(e-maxExpt2) expt 10 e | e <= maxExpt10 = expts10 ! e | otherwise = expts10 ! maxExpt10 * 10^(e-maxExpt10) expt base e = base^e maxExpt2 :: Int maxExpt2 = 1100 maxExpt10 :: Int maxExpt10 = 324 expts2 :: Array Int Integer expts2 = expts 2 maxExpt2 expts2 expts10 :: Array Int Integer expts10 = expts 10 maxExpt10 expts10 expts :: Integer -> Int -> Array Int Integer -> Array Int Integer expts base hi arr = listArray (0, hi) $ 1 : base : go 2 where go :: Int -> [Integer] go !ix = xx : base*xx : go (ix+2) where xx = x * x x = arr ! half half = ix `unsafeShiftR` 1 }}} I will attach a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8875: Track Exceptions
by GHC 10 May '17

10 May '17

#8875: Track Exceptions ----------------------------------------------+---------------------------- Reporter: yokto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Figure out for each function which exceptions can be thrown by it. This could probably be done by tracking calls to {{{ throw }}} and {{{ catch }}} and their types. The info would probably need to be stored in the .hi files, and could then be displayed by haddock. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8875> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

10 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 10 May '17

10 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 10 May '17

10 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 09 May '17

09 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