May 2016 - ghc-tickets

[GHC] #12130: ghc: panic! (the 'impossible' happened): find_tycon Block []
by GHC 06 Oct '16

06 Oct '16

#12130: ghc: panic! (the 'impossible' happened): find_tycon Block [] -------------------------------------+------------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just tried building yesod-simple template project with nightly-2016-05-29 snapshot and some extra-deps package, and it seems to fail due to {{{$(widgetFile ...)}}} yesod template haskell clause. It was same on linux and windows, and when I remove handler ghc fails at Application module (and seems also due to template haskell). {{{ ~/yt> stack build ... yt-0.0.0: configure Configuring yt-0.0.0... yt-0.0.0: build Preprocessing library yt-0.0.0... [1 of 9] Compiling Settings ( Settings.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings.o ) [2 of 9] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Settings/StaticFiles.o ) [3 of 9] Compiling Import.NoFoundation ( Import/NoFoundation.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import/NoFoundation.o ) [4 of 9] Compiling Foundation ( Foundation.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Foundation.o ) [5 of 9] Compiling Import ( Import.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Import.o ) [6 of 9] Compiling Handler.Common ( Handler/Common.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Common.o ) [7 of 9] Compiling Handler.Home ( Handler/Home.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Handler/Home.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Block [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 179 action(s). -- While building package yt-0.0.0 using: /home/jeiea/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:yt exe:yt --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10163: Export typeRepKinds in Data.Typeable
by GHC 04 Oct '16

04 Oct '16

#10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc3 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{TypeRep}}} has a {{{[KindRep]}}} field internally, {{{Data.Typeable}}} should export {{{typeRepKinds}}} (alongside {{{typeRepTyCon}}} and {{{typeRepArgs}}}, which are currently exported) to allow users to access it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11054: GHC on Windows could not use more than 64 logical processors
by GHC 04 Oct '16

04 Oct '16

#11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found that GHC runtime does not take advantage of processor groups under Windows. So it cannot use more than 64 logical processors (2x 18 core physical + HT). This is Reddit thread about: https://www.reddit.com/r/haskell/comments/3q1r0o/ghc_on_numa_72_core_2_proc… MSDN link https://msdn.microsoft.com/en- us/library/windows/desktop/dd405503(v=vs.85).aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #11987: Allow record wildcards with pattern synonyms
by GHC 02 Oct '16

02 Oct '16

#11987: Allow record wildcards with pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With pattern synonym `pattern Point {x, y} = (x, y)` we can write {{{ >>> let { x = 1; y = 2 } in Point { x = x, y = y } (1, 2) }}} {{{ >>> let { x = 1; y = 2 } in Point { x, y } (1, 2) }}} but record wildcards ain't workin {{{#!hs >>> let { x = 1; y = 2 } in Point {..} <interactive>:342:25-36: error: Pattern synonym ‘Point’ used as a data constructor }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11792: Optimised unsafe FFI call can get wrong argument
by GHC 02 Oct '16

02 Oct '16

#11792: Optimised unsafe FFI call can get wrong argument -------------------------------------+------------------------------------- Reporter: Szunti | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attached a simple test case. It should print 7457, but the C function is called with 0 as the third argument. If I compile with -O0 or omit the unsafe keyword in the FFI import it works as it should. In gdb disassembly looks to me as edx (the place for third argument on 64-bit) is set to 7457, then the opaquify is inlined, but it doesn't preserve edx and then third_arg is called with the zeroed edx. ---------------- Specs ------------- 64-bit Archlinux with arch-haskell repo gcc -v: {{{ Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto- wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-5-20160209/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with- bugurl=https://bugs.archlinux.org/ --enable- languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable- threads=posix --enable-libmpx --with-system-zlib --with-isl --enable- __cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install- libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 5.3.0 (GCC) }}} ghc compile output: {{{ Glasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.10.3 Using binary package database: /usr/lib/ghc-7.10.3/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181 wired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d wired-in package base mapped to base-4.8.2.0-0d6d1084fbc041e1cded9228e80e264d wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-3c4cb52230f347282af9b2817f013181 wired-in package ghc mapped to ghc-7.10.3-3a39f8f970ff545623196002970730d1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Main.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2016-04-05 14:24:20.801997492 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude, import Data.Word] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Main.hs Created temporary directory: /tmp/ghc1541_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( Main.hs, Main.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 317, types: 387, coercions: 3} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 261, types: 290, coercions: 14} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 216, types: 262, coercions: 18} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 274, types: 305, coercions: 18} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 407, types: 388, coercions: 70} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 463, types: 375, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 430, types: 362, coercions: 25} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 426, types: 363, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 426, types: 363, coercions: 25} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 310, types: 291, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 248, types: 217, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: *** Float inwards: Result size of Float inwards = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Float inwards: *** Called arity analysis: Result size of Called arity analysis = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Called arity analysis: *** Simplifier: Result size of Simplifier = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 336, types: 242, coercions: 25} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 369, types: 283, coercions: 25} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 354, types: 266, coercions: 25} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 354, types: 266, coercions: 25} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 356, types: 267, coercions: 25} *** Core Linted result of Tidy Core: writeBinIface: 18 Names writeBinIface: 81 dict entries *** CorePrep: Result size of CorePrep = {terms: 654, types: 379, coercions: 25} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeGen: *** Assembler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -x assembler -c /tmp/ghc1541_0/ghc_2.s -o Main.o Upsweep completely successful. *** Deleting temp files: Deleting: /tmp/ghc1541_0/ghc_3.c /tmp/ghc1541_0/ghc_2.s /tmp/ghc1541_0/ghc_1.s Warning: deleting non-existent /tmp/ghc1541_0/ghc_3.c Warning: deleting non-existent /tmp/ghc1541_0/ghc_1.s link: linkables are ... LinkableM (2016-04-05 15:42:11.288210053 UTC) Main [DotO Main.o] Linking Main ... *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_4.c -o /tmp/ghc1541_0/ghc_5.o -I/usr/lib/ghc-7.10.3/include *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc1541_0/ghc_7.s -o /tmp/ghc1541_0/ghc_8.o -I/usr/lib/ghc-7.10.3/include *** Linker: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash- size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -o Main Main.o Test.o -L/usr/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM -L/usr/lib/ghc-7.10.3/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/usr/lib/ghc-7.10.3/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/lib/ghc-7.10.3/rts /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_8.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM -lHSinteger- gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -lgmp -lm -lrt -ldl link: done *** Deleting temp files: Deleting: /tmp/ghc1541_0/ghc_10.rsp /tmp/ghc1541_0/ghc_9.rsp /tmp/ghc1541_0/ghc_8.o /tmp/ghc1541_0/ghc_7.s /tmp/ghc1541_0/ghc_6.rsp /tmp/ghc1541_0/ghc_5.o /tmp/ghc1541_0/ghc_4.c *** Deleting temp dirs: Deleting: /tmp/ghc1541_0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11792> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits
by GHC 02 Oct '16

02 Oct '16

#8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ----------------------------+--------------------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Windows shows a window that says "GHC has stopped working" when compiling a simple hello world. Steps to reproduce 1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386 -unknown-mingw32.tar.bz2) 2) Extract the contents of the tar to folder $GHC$ 3) Add $GHC$\bin and $GHC$\mingw\bin folder to the PATH, add env var "LANG=C". 4) Create file test.hs with contents: main = putStrLn "Hello, World!" 5) run "ghc test.hs". Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully. GHCi appears to work normally (when doing simple tests). More details: http://stackoverflow.com/questions/22291739/cant-install-packages-with- cabal-using-ghc-7-8rc2-and-windows-7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #12019: Profiling option -hb is not thread safe
by GHC 02 Oct '16

02 Oct '16

#12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11978, #12009 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is a continuation of #11978 and #12009. After fixing a couple of issues in those two tickets I found that the profiling run time is not thread safe. Have a trivial test program (written as one of the tests for #11978): {{{ import Control.Concurrent import Control.Concurrent.MVar import Control.Exception import Control.Monad main :: IO () main = do putStrLn "Start ..." mvar <- newMVar (0 :: Int) let count = 50 forM_ [ 1 .. count ] $ const $ forkIO $ do threadDelay 100 i <- takeMVar mvar putMVar mvar $! i + 1 threadDelay 1000000 end <- takeMVar mvar putStrLn $ "Final result " ++ show end assert (end == count) $ return () }}} Compiling that with a compiler that has bug fixes arising from #11978 and #12009 as: {{{ inplace/bin/ghc-stage2 testsuite/tests/profiling/should_run/T11978b.hs \ -fforce-recomp -rtsopts -fno-warn-tabs -O -prof -static -auto-all \ -threaded -debug -o T11978b }}} and run as: {{{ ./T11978b +RTS -p -hb -N10 }}} crashes in a number of different ways. I've seen at least 3 different assertion failures and numerous segfaults (in different `stg_ap_*` functions). Replace `-hb` with other profiling options like `-hr` etc do not seem to crash. Looking at code, one example of lack of thread safetly is the function `LDV_recordDead` which mutates global variable `censuses` which does not have any locking around it. Only figured this out because the following assert (in `LDV_recordDead`) was being triggered occasionally. {{{ ASSERT(censuses[t].void_total < censuses[t].not_used); }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10740: Ensure that ticky, profiler, and GC allocation numbers agree
by GHC 30 Sep '16

30 Sep '16

#10740: Ensure that ticky, profiler, and GC allocation numbers agree -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently we have several subsystems independently tracking allocations. It is very likely there are discrepancies between them. Ensuring that they agree would be a great way to test each of them (especially ticky, which is almost certainly bitrotted, see #10739). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9520: Running an action twice uses much more memory than running it once
by GHC 29 Sep '16

29 Sep '16

#9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a [http://www.haskell.org/pipermail/haskell- cafe/2014-August/115751.html Haskell cafe discussion] about conduit. This may be related to #7206, but I can't be certain. It's possible that GHC is not doing anything wrong here, but I can't see a way that the code in question is misbehaving to trigger this memory usage. Consider the following code, which depends on conduit-1.1.7 and conduit- extra: {{{#!hs import Data.Conduit ( Sink, (=$), ($$), await ) import qualified Data.Conduit.Binary as CB import System.IO (withBinaryFile, IOMode (ReadMode)) main :: IO () main = do action "random.gz" --action "random.gz" action :: FilePath -> IO () action filePath = withBinaryFile filePath ReadMode $ \h -> do _ <- CB.sourceHandle h $$ CB.lines =$ sink2 1 return () sink2 :: (Monad m) => Int -> Sink a m Int sink2 state = do maybeToken <- await case maybeToken of Nothing -> return state Just _ -> sink2 $! state + 1 }}} The code should open up the file "random.gz" (I simply `gzip`ed about 10MB of data from /dev/urandom), break it into chunks at each newline character, and then count the number of lines. When I run it as-is, it uses 53KB of memory, which seems reasonable. However, if I uncomment the second call to `action` in `main`, maximum residency shoots up to 45MB (this seems to be linear in the size of the input file. I additionally tried copying `random.gz` into two files, `random1.gz` and `random2.gz`, and changed the two calls to `action` to use different file names. It still resulted in large memory usage. I'm going to continue working to make this a smaller reproducing test case, but I wanted to start with what I had so far. I'll also attach the core generated by both the low-memory and high-memory versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9349: excessive inlining with -fpre-inlining
by GHC 29 Sep '16

29 Sep '16

#9349: excessive inlining with -fpre-inlining --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ The program at https://gist.github.com/jorendorff/a3005968adc8f054baf7 runs very slowly when compiled with `-O` or higher. It seems that `arr` and/or `rangeMap` is being inlined into the do block on lines 89-91 and recomputed for each iteration of the loop. The program runs nearly instantly when compiled with `-O0` or with `-O -fno-pre-inlining`. (Of course, this does not mean `-fpre-inlining` is necessary the culprit; it could be enabling some subsequent misoptimization.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10