October 2014 - ghc-tickets

[GHC] #9450: GHC instantiates Data instances before checking hs-boot files
by GHC 11 May '17

11 May '17

#9450: GHC instantiates Data instances before checking hs-boot files -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: boot,deriving | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When compiling a file with deriving instances in it and making use of boot files, it appears that the derivation is attempted before the boot files are checked for consistency. This can lead to GHC panics, as when compiling GHC after this commit https://github.com/alanz/ghc/commit/c73182ca7345f0debba47d0b17a907bcac27c41f In the attached files, if you try to load HsLit.lhs into ghci it will complain about the missing Data instance, not about the boot file inconsistency. If you remove the Data from the deriving clause of HsOverLit, it complains about the boot file inconsistency. I have not managed to reproduce the original panic in this stripped down environment, but if it is needed to more fully understand the problem I can try again to do that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[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] #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] #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] #9557: Deriving instances is slow
by GHC 06 May '17

06 May '17

#9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Let's take [https://raw.githubusercontent.com/haskell-suite/haskell-src- exts/8e0153d33b66add96fd5606614ce7938d2029510/src/Language/Haskell/Exts/Annotated/Syntax.hs this file] (from haskell-src-exts) and build it with -O0. On my machine it takes 55s. If we remove deriving of all classes except Functor (which is the only one used by the module itself), the time will drop down to 4s. Different classes vary in their compile-time cost, but there's no single culprit. Among the costly ones are Generic, Data, Show, Ord. haskell-src-exts users are very annoyed by its long compile time, about 10 minutes, especially because we don't compile with -O0 by default. It would be nice to get this fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #8443: cannot find normal object file when compiling TH code
by GHC 01 May '17

01 May '17

#8443: cannot find normal object file when compiling TH code ----------------------------+---------------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects valid program (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Unfortunately, I haven't been able to whittle this down to a smaller test case. In order to reproduce, just run `cabal install yesod-core-1.2.4.5 --enable-tests`. The result is: {{{ test/YesodCoreTest/NoOverloadedStrings.hs:16:26: cannot find normal object file ‛dist/build/tests/tests- tmp/YesodCoreTest/NoOverloadedStringsSub.dyn_o’ while linking an interpreted expression }}} Tested using: The Glorious Glasgow Haskell Compilation System, version 7.7.20131012 cabal-install version 1.18.0.2 using version 1.18.0 of the Cabal library I'm on Ubuntu 12.04 64-bit. Compiling with GHC 7.6.3 and 7.4.2 works correctly. Let me know if there's any other information I can provide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5