- ghc-tickets - Haskell.org

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 09 Dec '16

09 Dec '16

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: Here is a quick attempt at a patch: https://github.com/bgamari/array/commit/73144bda5cf4f5ba2e73206ea0a53200e30…. The only trouble here is that we now are doing overflow in unsafe indexing operations, which will cost a bit of performance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12941: Extend nofib with benchmarks focused on compiler performance
by GHC 09 Dec '16

09 Dec '16

#12941: Extend nofib with benchmarks focused on compiler performance -------------------------------------+------------------------------------- Reporter: michalt | Owner: michalt Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib | Version: benchmark suite | 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: -------------------------------------+------------------------------------- GHC seems to be missing a set of benchmarks focused on the compiler performance that would contain some realistic examples and make it easy to test even small changes in the compiler (by having a simple "before and after" comparison). The two main use cases would be: - Anyone hacking on GHC could quickly check even for small performance differences (running the benchmark with and without their change). - Tracking performance of GHC over time (potentially as part of perf.haskell.org) We already have two collections of performance tests/benchmarks: - `tests/perf/compiler` which contains actual tests (part of `validate`) and seems to be focused on larger regressions (if the bounds are too tight, it can generate a fair amount of noise). - `nofib` which is mostly focused on benchmarking the code produced by GHC (the vast majority of the modules compile within 400ms). The current idea is to extend `nofib` with some modules that are only checking the performance of GHC (e.g., might be a library module that doesn't contain `main`). Please see: https://mail.haskell.org/pipermail/ghc- devs/2016-December/013323.html for an initial discussion about this. Also related: - Ticket focused on improvements to `tests/perf/compiler` #12758 - Proposal of having a similar tests but hosted in a separate repo on github: https://github.com/ghc-proposals/ghc-proposals/pull/26 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 08 Dec '16

08 Dec '16

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 08 Dec '16

08 Dec '16

#7289: Mingw FPU init not Windows compatible. -----------------------------------+-------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: Sure, I'll whip up a patch in the weekend. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12943: Adjust AST to capture additional parens around a context
by GHC 08 Dec '16

08 Dec '16

#12943: Adjust AST to capture additional parens around a context -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | 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: #3384 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment the parser strips redundant parens around a context when constructing the AST. So the following two definitions would end up with the same AST. {{{#!hs foo :: (Show a) => a -> String foo' :: ((Show a)) => a -> String }}} This causes roundtripping of an AST via `ppr` to fail, and adds complexity to the API Annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10371: GHC fails to inline and specialize a function
by GHC 08 Dec '16

08 Dec '16

#10371: GHC fails to inline and specialize a function -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have an alternative Prelude library called [subhask](https://github.com/mikeizbicki/subhask) that redefines the numeric type class hierarchy. I'm trying to update it to work with GHC 7.10, but there is a major inlining bug that is killing performance. The code below demonstrates the issue. It first defines a distance function over 2 vectors, then measures the performance using criterion. (It requires the subhask to compile.) {{{ {-# LANGUAGE BangPatterns #-} import Control.DeepSeq import Criterion.Main import qualified Data.Vector.Unboxed as VU import qualified Data.Vector.Generic as VG import qualified Prelude import SubHask -- distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float distance_standalone v1 v2 = sqrt $ go 0 0 where go !tot !i = if i>VG.length v1-4 then goEach tot i else go tot' (i+4) where tot' = tot +(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) +(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1)) *(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1)) +(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2)) *(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2)) +(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3)) *(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3)) goEach !tot !i = if i>= VG.length v1 then tot else goEach tot' (i+1) where tot' = tot+(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) main = do let v1 = VU.fromList [1..200] :: VU.Vector Float v2 = VU.fromList [1..200] :: VU.Vector Float deepseq v1 $ deepseq v2 $ return () defaultMain [ bench "distance_standalone" $ nf (distance_standalone v1) v2 ] }}} Here are the results of compiling and running using GHC 7.10 and 7.8: {{{ $ ghc-7.10.1 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl && ./Main [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... benchmarking distance_standalone time 8.135 μs (8.121 μs .. 8.154 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 8.188 μs (8.158 μs .. 8.250 μs) std dev 139.3 ns (66.05 ns .. 250.4 ns) variance introduced by outliers: 15% (moderately inflated) }}} {{{ $ ghc-7.8.2 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl && ./Main [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... benchmarking distance_standalone time 733.2 ns (732.9 ns .. 733.6 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 734.1 ns (733.7 ns .. 734.5 ns) std dev 1.458 ns (1.262 ns .. 1.754 ns) }}} As you can see, GHC 7.10 is 10x slower. Looking through the core output shows that the cause of this is that GHC 7.8 is properly specializing the code whereas GHC 7.10 is not. If you uncomment the type signature before the `distance_standalone` function then both compilers perform at the faster speed. I believe the cause of this may be related to the complicated class numeric class hierarchy in SubHask. If you comment out the lines: {{{ import qualified Prelude import SubHask }}} then GHC uses the Prelude hierarchy instead of SubHask's hierarchy, and both compilers generate the faster program. There's one last wrinkle. If you define the `distance_standalone` function in a different file. Then in GHC 7.10, the `INLINE` and `INLINABLE` pragmas do absolutely nothing. Not only does the resulting code not get inlined, but if I add the specialization: {{{ {-# SPECIALIZE distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float #-} }}} to the Main file, I get an error message saying something like: {{{ bench/Vector.hs:18:1: Warning: You cannot SPECIALISE ‘distance_standalone{v ru1}’ because its definition has no INLINE/INLINABLE pragma (or its defining module ‘subhask-0.1.0.0@subha_LNZiQvSbo8Z0VdLTwuvkrN:SubHask.Algebra’ was compiled without -O) }}} I get this message despite the fact that the defining module was compiled with `-O2` and the function had an `INLINABLE` pragma. If I add the specialization pragma to the defining module, then I don't get the warning, but the code still doesn't specialize properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5835: Make better use of known dictionaries
by GHC 08 Dec '16

08 Dec '16

#5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by danharaj): * differential: => Phab:D2714 Comment: My patch for #12791 also resolves this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5835#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 08 Dec '16

08 Dec '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2
by GHC 08 Dec '16

08 Dec '16

#12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Following code if compiled with -O2 (but not -O1) causes assertion failure. Depends only on vector. {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} module A where import GHC.Base import qualified Data.Vector.Unboxed.Base import qualified Data.Vector.Generic.Base import Data.Vector.Generic.Mutable import qualified Data.Vector.Generic.Mutable.Base import Data.Vector.Generic (fromList) data A = A Int Int Int instance Data.Vector.Unboxed.Base.Unbox A newtype instance Data.Vector.Unboxed.Base.MVector s_a4iX A = MV_A (Data.Vector.Unboxed.Base.MVector s_a4iX (Int, Int, Int)) instance MVector Data.Vector.Unboxed.Base.MVector A where basicLength (MV_A v) = basicLength v basicUnsafeSlice idx len (MV_A v) = MV_A (basicUnsafeSlice idx len v) basicUnsafeNew len = (MV_A `liftM` (basicUnsafeNew len)) basicUnsafeWrite (MV_A v) idx val_a4iW = basicUnsafeWrite v idx ( (\ (A a_a4iT b_a4iU c_a4iV) -> (a_a4iT, b_a4iU, c_a4iV)) val_a4iW) newtype instance Data.Vector.Unboxed.Base.Vector A = V_A (Data.Vector.Unboxed.Base.Vector (Int, Int, Int)) instance Data.Vector.Generic.Base.Vector Data.Vector.Unboxed.Base.Vector A where mkA :: Data.Vector.Unboxed.Base.Vector A mkA = fromList [] }}} {{{ ghc: panic! (the 'impossible' happened) [7/1644] (GHC version 8.1.20161202 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {wild_00 eta_X1T $cbasicUnsafeFreeze_a6sr $cbasicUnsafeThaw_a6st $cbasicLength_a6sv $cbasicUnsafeSlice_a6sx $cbasicUnsafeIndexM_a6sz $cbasicUnsafeCopy_a6sF $celemseq_a6t3 $cbasicLength_a6tm $cbasicUnsafeSlice_a6ty $cbasicOverlaps_a6tL $cbasicUnsafeNew_a6tN $cbasicInitialize_a6uj $cbasicUnsafeReplicate_a6up $cbasicUnsafeRead_a6uJ $cbasicUnsafeWrite_a6uL $cbasicClear_a6vg $cbasicSet_a6vE $cbasicUnsafeCopy_a6w2 $cbasicUnsafeMove_a6wr $cbasicUnsafeGrow_a6wQ wild_a7QO dt_a7QQ ds1_a7QR ds2_a7QS ds3_a7QT wild_a80U x_a819 xs1_a81a ds4_a84V z_a84W s7_a84X ds5_a851 wild5_a85V v3_a85X i_a85Y wild7_a866 x_a868 y_a86k wild9_a86m $tcA $trModule $tc'A $fVectorVectorA $fUnboxA $fMVectorMVectorA mkA $cbasicUnsafeSlice_s7QF $trModule_s7Su $trModule_s7Sv $tc'A_s7Sw $s$dmbasicUnsafeGrow_s7Vp $s$dmbasicUnsafeMove_s7Vw $s$dmbasicUnsafeReplicate_s7VB $s$dmbasicSet_s7VG $s$dmbasicUnsafeCopy_s7VN $s$dmbasicUnsafeCopy_s7VW $sunstream_s886 $s$fMVectorMVector(,,)_$cbasicUnsafeNew_s896 $s$fMVectorMVector(,,)_$cbasicUnsafeWrite_s89h $s$fMVectorMVector(,,)_$cbasicUnsafeSlice_s89k $s$fMVectorMVector(,,)_$cbasicLength_s89l $sfromList_s89m $snew_s89n $s$dmelemseq_s89o $s$dmbasicClear_s89p lvl_s89Y $j_sa8p lvl_sbhM lvl_sbhN lvl_sbhO lvl_sbhP lvl_sbhQ lvl_sbhR lvl_sbhT lvl_sbhU lvl_sbhV lvl_sbhW lvl_sbi1 lvl_sbi2 lvl_sbi4 lvl_sbi5 lvl_sbi6 lvl_sbi7 foldlM_loop_sbns foldlM_loop_sbnL lvl_sbo2 $sfoldlM_loop_sbHS $s$j_sbI5 $sfoldlM_loop_sbIa $sfoldlM_loop_sbIx} tenv [] tenvFVs [] cenv [sbHY :-> sg_sbHY] cenvFVs [sbHY :-> sg_sbHY] tys [PrimState (ST RealWorld)] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1163:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2023:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2056:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1457:33 in ghc:Coercion Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1161:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2023:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2056:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1457:33 in ghc:Coercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5835: Make better use of known dictionaries
by GHC 08 Dec '16

08 Dec '16

#5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danharaj): * owner: => danharaj -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5835#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0