May 2015 - ghc-tickets

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 17 May '15

17 May '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977, #10298 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hsyl20): Fixed with my patch for #10298 (see my comment there). Can you check that you obtain the same result on your system with this code: {{{ $> cat test.c #include <langinfo.h> #include <locale.h> #include <stdio.h> int main() { setlocale(LC_CTYPE, ""); printf("LC_CTYPE: %s\n", nl_langinfo(CODESET)); return 0; } $> gcc -static -L/path/to/static/glibc test.c -o test $> sudo chroot `pwd` /test LC_CTYPE: ANSI_X3.4-1968 }}} I don't know if the default LC_CTYPE is the same everywhere... (You should get the same result if you have compiled the glibc with --disable-shared when you call ./test directly without the chroot) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 15 May '15

15 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I agree that this should not hold up a patch level release that others are waiting for. Better fix this properly, and then, maybe, see if it can be part of a 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:84> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 15 May '15

15 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high Comment: George Colpitts asks: the milestone is 7.12.1, should it be 7.10.2? It would be unusual to delay a patch-level release for a ticket that has been open for five years. Doing so would mean indefinitely delaying 7.10.2. By “indefinite” I don't mean "forever", I just mean “we don’t know how long”: * We don’t have anyone owning the ticket, * we don’t know how difficult it is to fix; and * a full bulletproof fix is probably quite challenging (e.g. forcing the unique-supply generator to give reproducible results even though some (ultimately irrelevant) bits of the environment have changes, would be difficult) At the same time we have some folk urging us to get 7.10.2 out sooner rather than later. So everyone: * If you think we should delay 7.10.2 pending at least some progress on this, please say so on the ticket. * Better still, roll up your sleeves and take a crack at understanding more precisely what is going on, and proposing a fix. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:83> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10293: CallArity taking 20% of compile time
by GHC 14 May '15

14 May '15

#10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- The `CallArity` analysis can, apparently, take 20% of compile time. That's a lot for one analysis that is on by default with `-O`. Michael Terepeta writes: Out of curiosity I had a look at compiling haskell-src-exts since that takes quite a while. I've used ghc HEAD and 7.8.4 (both built with BuildFlavour=prof & bootstrapped with a standard ghc 7.8.4) and it's interesting -- the current HEAD takes quite a bit longer and allocates way more than 7.8.4. One of the main things that stand out is the CallArity analysis (which IIRC was not there in 7.8.4). So unless I messed something up with measuring, the analysis seem to be pretty expensive. HEAD {{{ Sun Apr 12 15:52 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] total time = 147.84 secs (147841 ticks @ 1000 us, 1 processor) total alloc = 172,378,600,408 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 32.4 28.8 CallArity SimplCore 18.4 25.6 lintAnnots CoreLint 4.5 4.6 CoreTidy HscMain 4.5 5.1 pprNativeCode AsmCodeGen 3.2 3.4 OccAnal SimplCore 3.2 3.1 occAnalBind.assoc OccurAnal 2.6 2.5 StgCmm HscMain 2.3 1.9 Simplify SimplCore 2.1 0.2 RegAlloc AsmCodeGen 2.1 2.4 FloatOutwards SimplCore 2.0 1.6 regLiveness AsmCodeGen 1.9 1.9 tc_rn_src_decls TcRnDriver 1.8 1.3 sink CmmPipeline 1.7 1.5 NewStranal SimplCore 1.3 1.5 genMachCode AsmCodeGen 1.1 1.0 layoutStack CmmPipeline 1.0 1.0 }}} HEAD with `-fno-call-arity` {{{ Sun Apr 12 18:16 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] -fno-call-arity total time = 113.71 secs (113714 ticks @ 1000 us, 1 processor) total alloc = 121,884,896,720 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 37.2 36.6 CoreTidy HscMain 6.0 7.3 lintAnnots CoreLint 5.8 6.5 pprNativeCode AsmCodeGen 4.1 4.8 OccAnal SimplCore 3.6 3.8 occAnalBind.assoc OccurAnal 2.9 3.2 StgCmm HscMain 2.9 2.6 RegAlloc AsmCodeGen 2.6 3.4 FloatOutwards SimplCore 2.6 2.3 regLiveness AsmCodeGen 2.5 2.8 tc_rn_src_decls TcRnDriver 2.4 1.9 Simplify SimplCore 2.4 0.3 sink CmmPipeline 2.1 2.2 NewStranal SimplCore 1.7 2.1 genMachCode AsmCodeGen 1.4 1.4 layoutStack CmmPipeline 1.4 1.4 NativeCodeGen CodeOutput 1.1 1.2 FloatInwards SimplCore 1.1 1.4 do_block Hoopl.Dataflow 1.0 0.6 Digraph.scc Digraph 0.8 1.3 }}} GHC 7.8.4 {{{ Sun Apr 12 15:41 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] total time = 93.11 secs (93112 ticks @ 1000 us, 1 processor) total alloc = 103,135,975,120 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 38.5 37.4 pprNativeCode AsmCodeGen 6.2 7.2 StgCmm HscMain 3.9 4.2 RegAlloc AsmCodeGen 3.7 5.1 occAnalBind.assoc OccurAnal 3.3 3.6 OccAnal SimplCore 3.3 3.6 regLiveness AsmCodeGen 3.1 3.4 FloatOutwards SimplCore 2.9 2.4 sink CmmPipeline 2.8 2.8 Simplify SimplCore 2.6 0.3 tc_rn_src_decls TcRnDriver 2.4 2.1 genMachCode AsmCodeGen 1.9 2.0 NewStranal SimplCore 1.8 2.1 layoutStack CmmPipeline 1.8 1.8 Core2Core HscMain 1.3 1.2 deSugar HscMain 1.1 1.1 do_block Hoopl.Dataflow 1.1 0.7 CoreTidy HscMain 1.0 1.1 CorePrep HscMain 1.0 1.1 Digraph.scc Digraph 0.9 1.5 versioninfo MkIface 0.9 1.0 zonkEvBndr_zonkTcTypeToType TcHsSyn 0.6 1.4 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 14 May '15

14 May '15

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by duncan): * related: #6082 => #6082, #10418 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10418: Incorrect RULE warning on constructor, and inablilty to {-# INLINE [0] #-} constrcutor
by GHC 14 May '15

14 May '15

#10418: Incorrect RULE warning on constructor, and inablilty to {-# INLINE [0] #-} constrcutor -------------------------------------+------------------------------------- Reporter: duncan | 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 is mentioned in passing in ticket #10417, but pulling it out here to track it. Given a type {{{#!hs data Decoder s s' where Done :: Decoder s s Sequence :: Decoder a b -> Decoder b c -> Decoder a c }}} and rules: {{{#!hs {-# RULES "Sequence/Done" forall sa. Sequence Done sa = sa #-} {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} }}} GHC gives us warnings like: {{{ Rule "Sequence/Done" may never fire because ‘RulesExample.Sequence’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘RulesExample.Sequence’ }}} but it's currently syntactically invalid to write such a pragma: {{{#!hs {-# INLINE [0] Done #-} {-# INLINE [0] Sequence #-} }}} Now there's two problems here: 1. This warning is wrong most of the time 2. The warning is actually right sometimes, but there's nothing you can do about it. For 1, most of the time constructors remain as themselves in core, with no wrappers to get in the way of rule matching. In these cases the warning is just wrong. For 2, for some constructors ghc does rewrite them. In this case the rewrite rule really will fail to match. But we cannot tell GHC to delay the rewriting of them because we cannot write INLINE pragmas for them. So for this case it would be useful to allow us to write INLINE pragmas. In the above example, GHC will rewrite `Done` during optimisation, e.g. an excerpt from ticket #10417: {{{ $WDone = \ @ s_anC -> Done @~ <s_anC>_N working_example2 = \ @ b_aw2 -> AlterStack (working_example3) ($WDone) }}} This can and will interfere with rule matching. In this case it would be desirable to be able to write {{{ {-# INLINE [0] Done #-} }}} Currently that's a syntax error. For the case of nullary constructors, a workaround is to consistently use a smart constructor with an `INLINE [0]` pragma, and do all the rule matching on that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10418> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10415: ForeignPtr touched in FFI wrapper is never discarded
by GHC 14 May '15

14 May '15

#10415: ForeignPtr touched in FFI wrapper is never discarded -------------------------------------+------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If a `ForeignPtr` is touched in an FFI wrapper (`foreign import ccall "wrapper"`), it appears to never be discarded. For example, the program below demonstrates a space leak due to multiple `mallocForeignPtrBytes` results hanging around forever. {{{#!hs import Control.Concurrent (threadDelay) import Foreign.ForeignPtr import Foreign.Marshal.Utils (fillBytes) import Foreign.Ptr (FunPtr) foreign import ccall "wrapper" wrap :: IO () -> IO (FunPtr (IO ())) main :: IO () main = flip mapM_ [0..50] $ \_ -> do let len = 30 * 2^20 fp <- mallocForeignPtrBytes len withForeignPtr fp $ \p -> fillBytes p 0 len _ <- wrap $ touchForeignPtr fp threadDelay 100000 }}} Each of the 50 iterations allocates 30 megabytes of memory via `mallocForeignPtrBytes`. None of those allocations is ever freed, resulting in around 1.5 gigabytes of memory use by the time the program terminates. (Neither `fillBytes` nor `threadDelay` are required to reproduce the issue: they are there to respectively touch the memory so that it's fully allocated by the OS and to slow the program down so that one can view the memory usage gradually increasing e.g. with `top`.) Example run, with almost 1.6 gigabytes of memory usage reported by GNU time (the "maxresident" bit): {{{ $ ghc --make asdf.hs [1 of 1] Compiling Main ( asdf.hs, asdf.o ) Linking asdf ... $ /usr/bin/time ./asdf 0.12user 0.54system 0:05.77elapsed 11%CPU (0avgtext+0avgdata 1587300maxresident)k 0inputs+0outputs (0major+138078minor)pagefaults 0swaps }}} People bitten by this can probably work around it without too much trouble by either: 1. Simply avoiding the trigger, i.e. `touchForeignPtr` in a wrapper. In my case, that amounts to changing some functions to take `Ptr a` instead of `ForeignPtr a` and moving some `withForeignPtr` calls around, possibly adding manual `touchForeignPtr` calls somewhere. 2. Switching to manual memory management with functions like `mallocBytes` and `free`. But the issue seems rather nasty regardless. (At least it took me a while to pin down.) Hopefully it can be fixed without too much trouble. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP'
by GHC 13 May '15

13 May '15

#8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Looks like WITHSMP is not generated anywere, thus don't know how it worked before. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10177: Typeable solver regression
by GHC 13 May '15

13 May '15

#10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This bug is known and fixed in master. Simon and Austin and Iavor are all aware of it. This ticket exists to ensure that the fix doesn't get lost. This code breaks under the Typeable solver in 7.10.1-rc3 and is fixed in master. The relevant commit in master is 3a0019e3672097761e7ce09c811018f774febfd2 : Improve `Typeable` solver. {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE FlexibleContexts #-} module Bug where import Data.Typeable newtype V n a = V [a] class Typeable a => C a instance (Typeable (V n), Typeable a) => C (V n a) -- Bug.hs:13:10: -- Could not deduce (Typeable (V n a)) -- arising from the superclasses of an instance declaration -- from the context (Typeable (V n), Typeable a) -- bound by the instance declaration at Bug.hs:13:10-50 -- In the instance declaration for ‘C (V n a)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 12 May '15

12 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by literon): Just +1-ing to express my support for full binary determinism. Reproducible builds are important for efficiency and verification purposes in the distributed and containerized world. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:82> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0