January 2017 - 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] #12850: Panic with unboxed integers and ghci
by GHC 11 May '17

11 May '17

#12850: Panic with unboxed integers and ghci -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attempting to load the following file in ghci causes a panic in getIdFromTrivialExpr. Tested in GHC 8.0.1 and HEAD. {{{ {-# LANGUAGE ExplicitForAll, MagicHash, KindSignatures #-} import GHC.Types (RuntimeRep(..), TYPE) f :: forall (x :: TYPE 'IntRep). x -> x f x = x g = () where h = f 0# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12850> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10584: Installation of SFML failed
by GHC 09 May '17

09 May '17

#10584: Installation of SFML failed -------------------------------------+------------------------------------- Reporter: SoleSoul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This report is bad because I have no idea what I'm reporting but the compiler asked me to so there you go: % cabal install sfml :( Resolving dependencies... Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Failed to install SFML-0.2.0.0 Build log ( /home/user/.cabal/logs/SFML-0.2.0.0.log ): Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Preprocessing library SFML-0.2.0.0... [ 1 of 71] Compiling SFML.Window.WindowHandle ( src/SFML/Window/WindowHandle.hs, dist/build/SFML/Window/WindowHandle.o ) [ 2 of 71] Compiling SFML.SFDisplayable ( src/SFML/SFDisplayable.hs, dist/build/SFML/SFDisplayable.o ) [ 3 of 71] Compiling SFML.SFCopyable ( src/SFML/SFCopyable.hs, dist/build/SFML/SFCopyable.o ) [ 4 of 71] Compiling SFML.System.InputStream ( dist/build/SFML/System/InputStream.hs, dist/build/SFML/System/InputStream.o ) [ 5 of 71] Compiling SFML.SFResource ( src/SFML/SFResource.hs, dist/build/SFML/SFResource.o ) [ 6 of 71] Compiling SFML.Utils ( src/SFML/Utils.hs, dist/build/SFML/Utils.o ) [ 7 of 71] Compiling SFML.Window.VideoMode ( dist/build/SFML/Window/VideoMode.hs, dist/build/SFML/Window/VideoMode.o ) [ 8 of 71] Compiling SFML.Window.Types ( src/SFML/Window/Types.hs, dist/build/SFML/Window/Types.o ) [ 9 of 71] Compiling SFML.Window.Keyboard ( dist/build/SFML/Window/Keyboard.hs, dist/build/SFML/Window/Keyboard.o ) [10 of 71] Compiling SFML.Window.Joystick ( dist/build/SFML/Window/Joystick.hs, dist/build/SFML/Window/Joystick.o ) [11 of 71] Compiling SFML.Window.ContextSettings ( dist/build/SFML/Window/ContextSettings.hs, dist/build/SFML/Window/ContextSettings.o ) [12 of 71] Compiling SFML.Window.Context ( dist/build/SFML/Window/Context.hs, dist/build/SFML/Window/Context.o ) [13 of 71] Compiling SFML.System.Vector3 ( dist/build/SFML/System/Vector3.hs, dist/build/SFML/System/Vector3.o ) [14 of 71] Compiling SFML.System.Vector2 ( dist/build/SFML/System/Vector2.hs, dist/build/SFML/System/Vector2.o ) [15 of 71] Compiling SFML.Window.Mouse ( dist/build/SFML/Window/Mouse.hs, dist/build/SFML/Window/Mouse.o ) [16 of 71] Compiling SFML.Window.Event ( dist/build/SFML/Window/Event.hs, dist/build/SFML/Window/Event.o ) [17 of 71] Compiling SFML.Window.SFWindow ( src/SFML/Window/SFWindow.hs, dist/build/SFML/Window/SFWindow.o ) [18 of 71] Compiling SFML.Window.Window ( dist/build/SFML/Window/Window.hs, dist/build/SFML/Window/Window.o ) [19 of 71] Compiling SFML.System.Time ( dist/build/SFML/System/Time.hs, dist/build/SFML/System/Time.o ) [20 of 71] Compiling SFML.Audio.SFSoundBuffer ( src/SFML/Audio/SFSoundBuffer.hs, dist/build/SFML/Audio/SFSoundBuffer.o ) [21 of 71] Compiling SFML.System.Sleep ( dist/build/SFML/System/Sleep.hs, dist/build/SFML/System/Sleep.o ) [22 of 71] Compiling SFML.System.Clock ( src/SFML/System/Clock.hs, dist/build/SFML/System/Clock.o ) [23 of 71] Compiling SFML.System ( src/SFML/System.hs, dist/build/SFML/System.o ) [24 of 71] Compiling SFML.Window ( src/SFML/Window.hs, dist/build/SFML/Window.o ) [25 of 71] Compiling SFML.Graphics.Types ( src/SFML/Graphics/Types.hs, dist/build/SFML/Graphics/Types.o ) [26 of 71] Compiling SFML.Graphics.SFSmoothTexture ( src/SFML/Graphics/SFSmoothTexture.hs, dist/build/SFML/Graphics/SFSmoothTexture.o ) [27 of 71] Compiling SFML.Graphics.SFShapeResizable ( src/SFML/Graphics/SFShapeResizable.hs, dist/build/SFML/Graphics/SFShapeResizable.o ) [28 of 71] Compiling SFML.Graphics.SFCoordSpace ( src/SFML/Graphics/SFCoordSpace.hs, dist/build/SFML/Graphics/SFCoordSpace.o ) [29 of 71] Compiling SFML.Graphics.SFBindable ( src/SFML/Graphics/SFBindable.hs, dist/build/SFML/Graphics/SFBindable.o ) [30 of 71] Compiling SFML.Graphics.Rect ( dist/build/SFML/Graphics/Rect.hs, dist/build/SFML/Graphics/Rect.o ) [31 of 71] Compiling SFML.Graphics.SFBounded ( src/SFML/Graphics/SFBounded.hs, dist/build/SFML/Graphics/SFBounded.o ) [32 of 71] Compiling SFML.Graphics.SFViewable ( src/SFML/Graphics/SFViewable.hs, dist/build/SFML/Graphics/SFViewable.o ) [33 of 71] Compiling SFML.Graphics.Texture ( src/SFML/Graphics/Texture.hs, dist/build/SFML/Graphics/Texture.o ) [34 of 71] Compiling SFML.Graphics.Transform ( dist/build/SFML/Graphics/Transform.hs, dist/build/SFML/Graphics/Transform.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $j_sJFj To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 190129 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: SFML-0.2.0.0 failed during the building phase. The exception was: ExitFailure 1 cabal install sfml 7.18s user 0.76s system 93% cpu 8.460 total -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

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

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

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

09 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 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