ticket length cc summary component version milestone owner status priority _changetime _description _reporter
5972 24 adam.gundry@… option to suppress (Monomorphic) record selector functions Compiler 7.12.1 adamgundry new normal 2014-12-23T13:34:10Z "This proposal is a modest step towards freeing up the record fieldname namespace, without in any way pre-judging how the 'narrow namespace issue' might get addressed.
There is to be a compiler flag (suggestion) -XNoMonoRecordFields. (Default value ‑XMonoRecordFields, to give H98 behaviour.)
-XNoMonoRecordFields suppresses creating the field selector function from the field name in a record-style data declaration.
Suppressing the function frees up the namespace, to be able to experiment with various record/field approaches -- including the 'cottage industry' of Template Haskell solutions.
In particular, this means we can declare more than one record type within a module using the same field name.
For background, details, use cases, see: http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/NoMonoRecordFields
(Contrast ticket #3356 {-# LANGUAGE NoTraditionalRecordSyntax #-}, which suppresses far too much (IMHO).)" AntC
1168 37 adam@…, klao@… Optimisation sometimes decreases sharing in IO code Compiler 6.6 ⊥ new normal 2015-02-21T11:30:27Z The simplifier is losing sharing in spectral/calendar, probably because we're being a bit fast-and-loose with eta-expanding State# lambdas. A quick look at the Core shows that `calFor year` is not shared across multiple executions. simonmar
9636 10 adamgundry Function with type error accepted Compiler 7.8.3 new normal 2015-04-17T15:01:35Z "The following program is accepted by ghc even though it is clearly wrong.
The type family T is closed so T Bool cannot ever be reduced, so it must be a type error.
{{{#!hs
{-# LANGUAGE TypeFamilies #-}
module Err62 where
type family T a where
T Int = ()
x :: T Bool
x = undefined
f :: T Bool -> Bool
f _ = True
y :: Bool
y = f x
}}}
" augustss
10077 10 adamgundry Providing type checker plugin on command line results in false cyclic import error Compiler (Type checker) 7.11 new normal 2015-04-24T09:13:33Z "I am playing around with the new type checker plugins using the current development branch of GHC. When I supply the plugin module to GHC through the command line I get a cyclic import error message, which I think is false. If I supply the same plugin module using a pragma I do not get an error message.
=== Minimal Example (Command Line)
`MyPlugin.hs`:
{{{#!hs
module MyPlugin ( plugin ) where
import Plugins ( Plugin, defaultPlugin )
plugin :: Plugin
plugin = defaultPlugin
}}}
`Test.hs`:
{{{#!hs
module Test where
main :: IO ()
main = return ()
}}}
Command line call of GHC:
{{{
~/ghc/inplace/bin/ghc-stage2 \
--make
-package ghc-7.11.20150209 \
-fplugin=MyPlugin \
Test.hs
}}}
Results in the following error
{{{
Module imports form a cycle:
module ‘MyPlugin’ (./MyPlugin.hs) imports itself
}}}
which does not seem reasonable to me understand.
=== Minimal example (pragma)
On the other hand, if I change `Test.hs` to the following
{{{#!hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Test where
main :: IO ()
main = return ()
}}}
and calling GHC like this
{{{
~/ghc/inplace/bin/ghc-stage2 \
--make \
-package ghc-7.11.20150209 \
-dynamic \
Test.hs
}}}
it works.
I did not change `MyPlugin.hs`.
=== Note
1. Using `-fplugin=MyPlugin` vs. `-fplugin MyPlugin` does not make a difference.
1. The command line example behaves the same independent of whether I supply the `-dynamic` flag or not.
1. I had to add the `-dynamic` flag, because otherwise GHC will complain that:
{{{
:
cannot find normal object file ‘./MyPlugin.dyn_o’
while linking an interpreted expression
}}}
This might be a long shot, but maybe using the `-fplugin` option should imply the `-dynamic` flag?
" jbracker
9637 10 adamgundry Type level programming needs an error function Compiler 7.8.3 new normal 2015-04-16T14:34:05Z "When doing type level programming you often need a way to report errors.
I suggest a closed type family called Error with special semantics.
It is kinded like this Error :: Symbol -> k1 -> k2
If this function has to be reduced during constraint solving it will simply generate a type error with the given string and printing the type as extra information (this kind can be generalized a lot if we want to).
I've found that having this function gives more accurate and earlier error messages." augustss
10592 10 adamgundry Allow cycles in class declarations Compiler (Type checker) 7.10.1 new normal 2015-07-10T23:35:34Z "In particular, I would like to have a class hierarchy that looks like:
{{{
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE FlexibleContexts #-}
type family Scalar x
class Field (Scalar x) => Vector x
class Vector x => Field x
}}}
It is the case that every field is a vector, and the scalar associated with every vector is a field. But we can't currently enforce that." MikeIzbicki
10344 10 adamgundry Make BranchList simpler Compiler 7.11 goldfire new normal 2015-04-24T14:10:13Z "As Adam Gundry suggested, `BranchList` could be made much simpler by actually storing a list in the `Branched` case.
Though, as I'm thinking about it, what's better about a real list over a `BranchList`? We're more familiar with it... but perhaps adding a `Foldable` instance for `BranchList` would solve the problem.
In any case, this ticket is to record the desire for improvement. If Adam is up to it, he may fix this with Phab:D841. Otherwise, I'll get to it." goldfire
10301 10 adamgundry Plugins/dynamic loading subtly broken (it seems) Compiler 7.8.2 7.10.3 new normal 2015-07-15T11:30:25Z "Imported from #8276, which was originally about a Haddock bug (that was different in nature but appeared similarly):
> I still experience this panic on GHC 7.8.2 with Windows x86_64:
>
> {{{
> $ ghci
> GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> λ> import StaticFlags
> λ> import Data.IORef
> λ> readIORef v_opt_C_ready
> Loading package array-0.5.0.0 ... linking ... done.
> Loading package deepseq-1.3.0.2 ... linking ... done.
> Loading package bytestring-0.10.4.0 ... linking ... done.
> Loading package containers-0.5.5.1 ... linking ... done.
> Loading package Win32-2.3.0.2 ... linking ... done.
> Loading package filepath-1.3.0.2 ... linking ... done.
> Loading package old-locale-1.0.0.6 ... linking ... done.
> Loading package time-1.4.2 ... linking ... done.
> Loading package directory-1.2.1.0 ... linking ... done.
> Loading package pretty-1.1.1.1 ... linking ... done.
> Loading package process-1.2.0.0 ... linking ... done.
> Loading package Cabal-1.18.1.3 ... linking ... done.
> Loading package binary-0.7.1.0 ... linking ... done.
> Loading package bin-package-db-0.0.0.0 ... linking ... done.
> Loading package hoopl-3.10.0.1 ... linking ... done.
> Loading package hpc-0.6.0.1 ... linking ... done.
> Loading package template-haskell ... linking ... done.
> Loading package transformers-0.3.0.0 ... linking ... done.
> Loading package ghc-7.8.2 ... linking ... done.
> False
> λ> staticFlags
> ghc.exe: panic! (the 'impossible' happened)
> (GHC version 7.8.2 for x86_64-unknown-mingw32):
> Static flags have not been initialised!
> Please call GHC.parseStaticFlags early enough.
>
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> }}}
>
> But not with GHC 7.8.2 on Linux x86_64:
>
> {{{
> $ ghci
> GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> λ> import StaticFlags
> λ> import Data.IORef
> λ> readIORef v_opt_C_ready
> Loading package array-0.5.0.0 ... linking ... done.
> Loading package deepseq-1.3.0.2 ... linking ... done.
> Loading package bytestring-0.10.4.0 ... linking ... done.
> Loading package containers-0.5.5.1 ... linking ... done.
> Loading package filepath-1.3.0.2 ... linking ... done.
> Loading package old-locale-1.0.0.6 ... linking ... done.
> Loading package time-1.4.2 ... linking ... done.
> Loading package directory-1.2.1.0 ... linking ... done.
> Loading package pretty-1.1.1.1 ... linking ... done.
> Loading package process-1.2.0.0 ... linking ... done.
> Loading package Cabal-1.18.1.3 ... linking ... done.
> Loading package binary-0.7.1.0 ... linking ... done.
> Loading package bin-package-db-0.0.0.0 ... linking ... done.
> Loading package hoopl-3.10.0.1 ... linking ... done.
> Loading package hpc-0.6.0.1 ... linking ... done.
> Loading package template-haskell ... linking ... done.
> Loading package transformers-0.3.0.0 ... linking ... done.
> Loading package ghc-7.8.2 ... linking ... done.
> True
> λ> staticFlags
> []
> }}}
>
> This has caused problems for me when running programs such as [https://github.com/ku-fpg/hermit/ HERMIT] on Windows, since at some point, {{{parseStaticFlagsFull}}} seems to be called during program execution. A workaround is to call {{{initStaticOpts}}} manually somewhere in the program, but I feel like that shouldn't be necessary.
The one above was on Windows. Also reported:
> Hello,
>
> A similar panic also happens when running Liquid Haskell [http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/] on a file that uses the Units of Measure plugin [https://github.com/adamgundry/uom-plugin]
>
>
> {{{
> liquid: liquid: panic! (the 'impossible' happened)
> (GHC version 7.10.1 for x86_64-unknown-linux):
> Static flags have not been initialised!
> Please call GHC.parseStaticFlags early enough.
> }}}
" thoughtpolice
5941 10 adamgundry Add compilation stage plugins Compiler 7.4.1 7.12.1 infoneeded normal 2015-07-04T16:19:25Z "There are several different tools that could be written using one of GHC's intermediate ASTs, like the post type-checking `HsSyn Id`. These can today be written as separate programs, using the GHC API. An example of such a program would be a CTAGS-on-steroids tool that would let you, as part of compilation, output a file containing all the names in the program, together with their source locations and types. This file could then be used to implement a type and qualified names aware grep.
However, compiling every file twice, once normally and once using this hypothetical tool, just to get that additional output file, is wasteful. It would be better if we could specify a plugin that would run at one of a few well defined places in the pipeline e.g. after renaming or type checking. Those plugins could be passed the data structures (e.g. `HsSyn Id`) created by GHC and then perform some arbitrary action (e.g. write to a file or modify the AST.)" tibbe
10284 48 adamgundry, core-libraries-committee@… Create a dedicated `TypeError` exception type Core Libraries 7.10.1 kanetw patch normal 2015-07-07T17:17:24Z "Ticket #10283 discusses using `-fdefer-type-errors` to test that certain programs do not type check.
In practice, this involves evaluating certain expressions to WHNF at run-time can checking whether they trigger an exception. Currently, it seems the exception to catch is an `ErrorCall` exception. It would be nice if we could very specifically catch type errors though. It's entirely possible that a critical test case that I want to be a type error mistakenly type-checks and then calls `error`. In such a situation, it's hard to distinguish such a true run-time error from a deferred type error. It would be much nicer if something like `TypeError` would be thrown instead of `ErrorCall`.
Yes, it's currently possible to look at the text of the `ErrorCall` and check for certain text fragments in there, but that sounds extremely fragile to me." kosmikus
10716 30 adamgundry, kosmikus, goldfire Metadata in GHC.Generic should give access to strictness annotation Compiler 7.10.2 new normal 2015-07-31T08:55:32Z "Currently, the metadata in the GHC.Generics module do not give access to the strictness annotations attached to a field of a datatype. It would be great if this piece of information could be added.
Background: we are using a class FullyStrict for ensuring that a datatype is fully strict (in the sense that all fields have bang patterns and the types of all fields are also fully strict). Currently we are using TemplateHaskell to derive the instances automatically. The TemplateHaskell function also checks that all fields have bang patterns.
To improve compilation speed, I would like to derive the instances with DeriveGeneric. But this is not possible because then I cannot implement the check whether all fields have bang patterns.
" StefanWehr
10227 19 adamgundry, nfrisby Type checker cannot deduce type Compiler 7.10.1 new normal 2015-07-28T15:44:29Z "When using closed type families the type checker does not use all the information that the closedness condition implies.
In the following module the type checker fails to deduce the type for `f`.
But lets start with `descrIn` since it has the same problem. The deduced type is `(D d Bool ~ Bool, D d Double ~ Bool, D d (Maybe String) ~ Bool) => Descr d`. But it is (to quote Simon PJ) plain as a pikestaff that `D d Double ~ Bool` can only hold if `d ~ In`, since there are only two equations and it cannot be the second.
Similar reasoning can be used to deduce all the commented out type signatures.
{{{#!hs
{-# LANGUAGE RecordWildCards, TypeFamilies, DataKinds, NoMonomorphismRestriction, FlexibleContexts #-}
module Main(main) where
import Data.Maybe
data InOut = In | Out
type family D (d :: InOut) a where
D 'In a = Bool
D 'Out a = a
data Descr d = Descr {
abc :: D d Bool,
def :: D d Double,
ghi :: D d (Maybe String)
}
--descrIn :: Descr 'In
descrIn = Descr { abc = False, def = True, ghi = True }
--f :: Descr 'Out -> Double
f Descr{..} = def + read (fromMaybe ""0"" ghi)
--g :: Descr 'In -> Descr 'Out
g d = Descr { abc = if abc d then True else False,
def = if def d then 1234 else 0,
ghi = if ghi d then Just ""3008"" else Nothing }
main :: IO ()
main = do
print $ f $ g descrIn
}}}
" augustss
1487 56 adrien@…, core-libraries-committee@… unix package: test needed for getLoginName Core Libraries ekmett new lowest 2015-03-01T06:08:12Z I disabled the test for `getLoginName` in unix/tests/user001 because `getLoginName` cannot be called unless stdin is a terminal, which it isn't during an unattended build. Perhaps we can test this by setting up a pseudoterminal first, but that requires the pty patches which aren't in yet. simonmar
10558 10 agibiansky Alter type of parseDeclaration and parseTypeSignature entry points Compiler 7.10.1 patch normal 2015-06-22T07:27:35Z "Currently the type of the two mentioned entry points is
{{{#!hs
parseDeclaration :: P (OrdList (LHsDecl RdrName))
}}}
and
{{{#!hs
parseTypeSignature :: P (Located (OrdList (LHsDecl RdrName)))
}}}
It turns out that in both cases, OrdList is always a singleton so the additional wrapping is redundant. I propose that the parser is modified in order to reflect this so that this is clearer to end users. The end result being that both entry points have type `P (LHsDecl RdrName)`
" mpickering
10242 83 alanz, dominique.devriese@…, Thomas, Winant, Multiple constraint wildcards allowed with PartialTypeSignatures Compiler 7.10.1 thomasw new normal 2015-04-07T09:59:02Z "The [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures wiki] states that
> As a single extra-constraints wildcard is enough to infer any number of constraints, only one is allowed in a type signature and it should come last in the list of constraints.
However the following program compiles with GHC 7.10.1
{{{#!hs
{-# LANGUAGE PartialTypeSignatures #-}
f :: (Eq a, _, _) => a -> a -> Bool
f x y = x == y
}}}
" mpickering
3384 17 alanz, mpickering Add HsSyn prettyprinter tests Test Suite ⊥ new normal 2015-06-11T23:18:34Z "Add HsSyn prettyprinter tests. See #1966 for some discussion.
" igloo
8206 109 alex.sayers@…, hvr, silvio.frischi@…, ydewit@…, snoyberg, tomberek@…, jakzale Add support for Portable Native Client Compiler Alex Sayers new normal 2015-07-05T11:36:12Z "== Motivation ==
[http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client Portable Native Client] (PNaCl) is a feature in Google Chrome which (roughly) allows it to use LLVM bitcode like browsers use javascript today. The bitcode is downloaded, validated, compiled, and (safely) executed, with access to an API for manipulating the DOM of the page which loaded it. The dream: Haskell executed in the browser at near-native speed. Unfortunately, while GHC has an LLVM backend, the bitcode it generates doesn't satisfy the PNaCl validator.
== Portable Native Client ==
The user visits a page with an tag pointing to a ""pexe"" - a PNaCl bitcode file. The bitcode is downloaded and streamed first into a code validator, and then into a compiler. The resulting machine code is then executed as a memory-protected process. The [https://developers.google.com/native-client/pepperc/ Pepper API], a library Google provides, provides access to the browser for things like connecting to websockets, playing audio, and communicating with javascript running on the page.
PNaCl is present in Chrome 29 (go to chrome://flags to enable it), and will be enabled for arbitrary sources (the ""open web"") in Chrome 30. Mozilla have announced that they don't intend to support Native Client.
== The Easily-Fixed ==
The pexe bitcode format is a frozen subset of LLVM bitcode. The PNaCl toolchain provides `pnacl-finalize`, which translates LLVM bitcode into pexe bitcode.
PNaCl [http://www.chromium.org/nativeclient/pnacl/bitcode-abi##callingconventions only allows] the standard ""ccc"" calling convention, whereas GHC likes to use its own ""cc 10"" calling convention. You can make GHC use ccc by using an unregisterised build, for a slow-down factor of about 2.
It seems likely that code-next-to-tables will upset the validator. If so, this can be turned off for a small performance hit.
== The Not-So-Easily-Fixed ==
The validator requires that requests for IO are sent to Pepper. PNaCl also requires that you use newlib instead of glibc. Spawning new processes is forbidden (although creating pthreads is fine). It also seems likely that the validator with take umbrage at calls to `mmap`, which the GHC runtime uses to request memory allocation.
It seems, therefore, that significant chunks of the RTS will have to be ported." guest
4101 116 alexey.skladnoy@…, bjornbm, anton.nik@…, carter.schonwald@…, jan.stolarek@…, schyler Primitive constant unfolding Compiler 6.12.2 7.12.1 schyler new low 2014-12-23T13:33:45Z "Examining the core generated by ghc with -O2 on a numerical code, I saw things like :
{{{
case GHC.Prim. Lift a"" (requires allowing undecidable and overlapping instances) in template-haskell. Since Data can be derived automatically by GHC, such an instance would imply automatic derivation of Lift as well.
[1] http://www.haskell.org/pipermail/template-haskell/2007-October/000635.html
[2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/th-lift-0.2" guest
9509 19 alpmestan@… No automatic specialization of inlinable imports in 7.8 Compiler 7.8.3 new normal 2014-08-24T17:24:41Z "According to the GHC manual, any uses of an imported definition that is overloaded and INLINABLE will automatically cause a SPECIALIZE to be generated for those uses, if appropriate. However, this no longer appears to be the case in 7.8(.3). Here is a simple test case:
{{{#!hs
module A (foo) where
import Data.IORef
foo :: Ord a => a -> IO a
foo x = newIORef x >>= readIORef >>= \y -> case compare x y of LT -> return x ; _ -> return y
{-# INLINABLE foo #-}
}}}
{{{#!hs
module Main (main) where
import A
main = foo (5 :: Int) >>= print
}}}
`foo` is constructed to be long enough that GHC 7.8.3 will elect to not inline it.
When compiling with 7.6.3, the core contains the following:
{{{
Main.$sfoo1
:: GHC.Types.Int
-> GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #)
[GblId,
Arity=2,
Caf=NoCafRefs,
Str=DmdType LL,
Unf=Unf{Src=, TopLvl=True, Arity=2, Value=True,
ConLike=True, WorkFree=True, Expandable=True,
Guidance=IF_ARGS [20 0] 55 30}]
Main.$sfoo1 =
\ (x_XkE :: GHC.Types.Int)
(eta_B1 :: GHC.Prim.State# GHC.Prim.RealWorld) ->
case GHC.Prim.newMutVar#
@ GHC.Types.Int @ GHC.Prim.RealWorld x_XkE eta_B1
of _ { (# ipv_amT, ipv1_amU #) ->
case GHC.Prim.readMutVar#
@ GHC.Prim.RealWorld @ GHC.Types.Int ipv1_amU ipv_amT
of ds1_amJ { (# ipv2_Xn8, ipv3_Xna #) ->
case x_XkE of wild_axu { GHC.Types.I# x#_axw ->
case ipv3_Xna of _ { GHC.Types.I# y#_axA ->
case GHC.Prim. ds1_amJ;
GHC.Types.True -> (# ipv2_Xn8, wild_axu #)
}
}
}
}
}
Main.$sfoo :: GHC.Types.Int -> GHC.Types.IO GHC.Types.Int
[GblId,
Arity=2,
Caf=NoCafRefs,
Str=DmdType LL,
Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True,
ConLike=True, WorkFree=True, Expandable=True,
Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}]
Main.$sfoo =
Main.$sfoo1
`cast` (
-> Sym )>
:: (GHC.Types.Int
-> GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #))
~#
(GHC.Types.Int -> GHC.Types.IO GHC.Types.Int))
...
------ Local rules for imported ids --------
""SPEC A.foo [GHC.Types.Int]"" [ALWAYS]
forall ($dOrd_sxj :: GHC.Classes.Ord GHC.Types.Int).
A.foo @ GHC.Types.Int $dOrd_sxj
= Main.$sfoo
}}}
However, in 7.8.3 and newer (I'm actually using 7.9.20140725 for this particular output, but 7.8.3 is similar), we see the following:
{{{
Main.main1
:: GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld, () #)
[GblId,
Arity=1,
Str=DmdType ,
Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True,
ConLike=True, WorkFree=True, Expandable=True,
Guidance=IF_ARGS [0] 100 0}]
Main.main1 =
\ (s_aIb :: GHC.Prim.State# GHC.Prim.RealWorld) ->
case ((A.foo @ GHC.Types.Int GHC.Classes.$fOrdInt Main.main2)
`cast` (GHC.Types.NTCo:IO[0] _R
:: GHC.Types.IO GHC.Types.Int
~R# (GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #))))
s_aIb
of _ [Occ=Dead] { (# ipv_aIe, ipv1_aIf #) ->
GHC.IO.Handle.Text.hPutStr2
GHC.IO.Handle.FD.stdout
(GHC.Show.$fShowInt_$cshow ipv1_aIf)
GHC.Types.True
ipv_aIe
}
}}}
There is no local rules section in 7.8.3. Putting a manual SPECIALIZE pragma in the main module generates comparable code to 7.6.3, so it does not appear to be a failure at that level. Rather, GHC seems to just not be generating the SPECIALIZE equivalent.
Presumably this is a regression, but even if not, the manual should be revised." dolio
8045 25 andreas.voellmy@… Move I/O manager benchmarks into the GHC tree NoFib benchmark suite 7.6.3 new normal 2013-07-10T11:23:29Z "When we developed the scalable I/O manager (i.e. the first version that used epoll) we wrote a bunch of benchmarks that were never moved to the GHC tree or integrated into the make system:
https://github.com/tibbe/event/tree/master/benchmarks
It would be nice to move this into the GHC tree to catch future regressions and use them when trying to make improvements." tibbe
8046 25 andreas.voellmy@… Make the timer management scale better across multicore Compiler 7.6.3 new normal 2014-11-22T02:30:43Z "Commit 2d5eccdf1cfb389074cc2e5b52ae40b535c3b235
{{{
Author: Ian Lynagh
Date: Sat Jun 8 20:19:59 2013 +0100
IO manager: Edit the timeout queue directly, rather than using an edit list
Fixes #7653.
}}}
undid an optimization to the management of timeouts (to fix a bug, which is good). We should check how much this hurt performance, but it might be better to rewrite the timeout management altogether. The current scheme scales poorly to several cores. We should probably have one priority queue per core and use an efficient mutable data structure." tibbe
9285 24 AndreasVoellmy, simonmar IO manager startup procedure somewhat odd Runtime System 7.8.2 simonmar patch low 2015-03-19T15:14:07Z "Currently the RTS startup procedure for the threaded runtime with a single capability looks something like this:
'''1. Capability gets initialized'''
{{{
hs_main
real_main
hs_init_ghc
initScheduler
initCapabilities
}}}
'''2. IO Manager is started'''
{{{
hs_main
real_main
hs_init_ghc
ioManagerStart
}}}
'''3. ensureIOManagerIsRunning'''
The IO manager of course is mostly written in Haskell, so `ioManagerStart` does
{{{
cap = rts_lock();
rts_evalIO(&cap,&base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL);
rts_unlock(cap);
}}}
'''4. Bound task is created and we start running Haskell code'''
Since this is the first call to `rts_lock`, it creates a bound task to correspond to the current OS thread.
'''5. Haskell code does a safe FFI call: create worker task 1'''
The first safe FFI call that the IO manager makes (ignoring `labelThread`) is to `c_setIOManagerControlFd`. At this point, the bound task gets suspended and we create a worker task.
'''6. Worker task 1 starts executing `GHC.Event.Manager.loop`'''
The worker tasks gets suspended due to an explicit call to `yield` in `GHC.Event.Manager.step`, at which point the bound task continues execution. It continues and finishes (`ensureIOManagerRunning` completes). The worker task takes over.
'''7. Worker task 1 does a safe FFI call to `I.poll`, create new worker task 2'''
(This safe call is from `GHC.Event.Manager.step`)
'''8. Worker task 2 executes `GHC.Event.TimerManager.loop`, and does safe FFI call to `I.poll`; create worker task 3'''
This worker task will remain spare for now.
'''9. Start executing the actual main function'''
The IO manager calls `rts_unlock`, which verifies if there are any spare workers available; it finds that there are and doesn't start a new one.
Then when we start `main` itself of course we go through this `rts_lock, rts_evalIO, rts_unlock` sequence ''again''. This is somewhat confusing, and makes tracing the startup of the code more difficult to interpret. It seems that this could be simpler: only a single `rts_lock` should be necessary, in which we first call `ensureIOManagerIsRunning` and then `main`, followed by a single `rts_unlock`. A similar simplification should be possible in `forkProcess`. " edsko
2075 25 andy.adamsmoran@… hpc should render information about the run in its html markup Code Coverage 6.8.2 7.12.1 andy@… new lowest 2014-12-23T13:33:22Z To check if a generated coverage test is up to date, it would be useful to have hpc annotate its generated output with the date of the run, the compiler version, and OS info. Perhaps also information about which packages were included in the build. dons
4144 79 AntoineLatter, joeyadams3.14159@…, core-libraries-committee@… Exception: ToDo: hGetBuf - when using custom handle infrastructure Core Libraries 7.6.1 7.12.1 new high 2015-02-22T12:06:00Z "When trying to use the custom handle infrastructure, hGetContents fails like so:
*** Exception: ToDo: hGetBuf
This exception occurs twice in GHC.IO.Handle.Text
The handle implementation I'm using is attached.
It would be neat if I could pass along some witness that my device implements RawDevice, then we could just run the same code that we use for file-descriptors. But I'd be happy enough with a general solution, as I just plan to use this for testing." AntoineLatter
5556 71 AntoineLatter, v.dijk.bas@…, as@…, jystic@… Support pin-changing on ByteArray#s Compiler 7.2.1 7.12.1 new normal 2014-12-23T13:34:10Z "I'm mostly posting this here as a chance for discussion for this feature, as I've wanted it a few times before and because Roman Leshchinskiy mentioned it on reddit and reminded me.
IIRC, the basic idea was to have an operation like:
{{{
pin# :: ByteArray# -> ByteArray#
}}}
Then you could say:
{{{
let y = pin# x
}}}
and y would have the same contents as x but be pinned. Whether it is the same memory block as x would be implementation-dependent but with GHC, it would be. When GHC would garbage collect y, it would unpin x (if x is still alive). You would also have unpin# so if you said:
{{{
let z = unpin# y
}}}
then z will become unpinned when y is garbage collected.
I mostly care because it's unfortunate to have to decide up front whether you want to suffer from memory fragmentation or to support foreign bindings. This could for example let us break the distinction between Data.Vector.Unboxed and Data.Vector.Storable. From a higher level, you might have a `withPinned` function that would temporarily pin (without copying) an array while you make foreign calls with it (even across multiple foreign calls), and then would unpin it when you're done.
I'm not sure what this would entail on the actual GC/runtime side of things, but I figured it'd be worth discussing." pumpkin
3872 19 anton.nik@… New way to make the simplifier diverge Compiler 6.12.1 ⊥ new normal 2011-08-10T15:32:06Z "GHC's simplifier can go into a loop if you use fixpoints in a funny way, as documented here http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc (12.2.1, third bullet). But GADTs provide new opportunities. This ticket records one, thanks to Ryan Ingram and Matthieu Sozeau:
{{{
{-# LANGUAGE GADTs #-}
module Contr where
newtype I f = I (f ())
data R o a where R :: (a (I a) -> o) -> R o (I a)
run :: R o (I (R o)) -> R o (I (R o)) -> o
run x (R f) = f x
rir :: (R o) (I (R o))
rir = R (\x -> run x x)
absurd :: a
absurd = run rir rir
}}}
Now the simplifier can loop. Look:
{{{
run rir rir
= {inline run}
case rir of R f -> f rir
= {case of known constructor}
let { f = \x -> run x x } in f rir
= {inline f}
run rir rir
}}}
" simonpj
5355 15 as@… Link plugins against existing libHSghc Compiler 7.0.3 new normal 2015-07-31T17:55:44Z "This ticket split out from #3843 since it was getting too crowded
Once we can safely export all symbols from libHSghc through the executable, we want to link plugins against the loaded GHC library rather than a new copy. This has two benefits:
1. Linking plugins will be faster
2. We can make reinitializeGlobals into a no-op
This is currently blocked by #5292 because libHSghc exports more symbols than we can reexport on Windows. There is one suggestions in #3843 to reexport less: exclude more of GHC's dependencies from being reexported, using this snippet to get the package list:
{{{
$(foreach p,$(PACKAGES),$p-$(libraries/$p_dist-install_VERSION))
}}}
Once we have cut the number of exported symbols down enough, the patches in #3843's attachment 3843-v2.zip can be applied to fix this ticket. (There was a reported validate failure with this patch in annrun01 on x64 linux which should also be checked)" batterseapower
9445 6 aseipp GHC Panic: Tick Exhausted with high factor Compiler 7.8.3 new normal 2014-10-20T10:06:00Z "Hello guys,
this is an old bug which has been reported so many times that I'm not sure this will be noise or something useful.
In a nutshell I have been hit by this bug installing the library ""SFML"", which relies heavily on FFI.
The only interesting thing of this report is that it was necessary an very high simpl-factor to make the installation go through!
Pre-bump:
{{{
Resolving dependencies...
In order, the following will be installed:
SFML-0.2.0.0 (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Configuring SFML-0.2.0.0...
Building SFML-0.2.0.0...
Preprocessing library SFML-0.2.0.0...
[...]
[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.8.3 for x86_64-apple-darwin):
Simplifier ticks exhausted
When trying UnfoldingDone $j_sZQW{v} [lid]
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: 2655928
}}}
And this was the magic line:
{{{
cabal install SFML --ghc-option=-fsimpl-tick-factor=1630
}}}
HTH, it turns out it's quite an annoying one! And yes, ""1630"" was the smaller factor which made the installation possible.
Alfredo" adinapoli
10367 22 asgerdrewsen@… """ghc: panic! (the 'impossible' happened)""" Code Coverage 7.10.1 new normal 2015-06-17T00:13:24Z "When running tasty-hunit tests through `cabal repl`, I get the following error:
{{{
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib, 9): Symbol not found: __hpc_tickboxes_horsezmcontrolzm0zi1zi0zi0_HorseziCommands_hpc
Referenced from: /var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib
Expected in: flat namespace
in /var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
I have a hunch that it's because I enabled the following flags in my .cabal file, since I didn't get the exception before adding them:
{{{
Test-Suite test-horse
...
GHC-Options: -fhpc -hpcdir dist/hpc/horse-control-1.0
}}}
When I run the tests via `cabal test`, I don't get the exception.
I've created a branch that showcases the crash: https://github.com/bgwines/horse-control/tree/ghc-panic
Repro steps:
* clone repo
* cd to repo
* run `cabal repl`
* run `:l Tests/test-horse.hs`
* run `main`
Reproducability: 100%
Please feel free to contact me if there's information lacking, here! :)" bgwines
2625 18 aslatter@… Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields Compiler 6.8.3 ⊥ new low 2014-12-04T20:39:52Z "In the following example, with either -O or -O2
In the derived Eq instance for A, in '==' nothing ever gets re-packed into a B constructor.
However in the derived Ord instance, in the 'compile' function the code from -ddump-simpl shows that the RHS of 'compare' is unpacked from the 'A' constructor only to be repacked in 'B' constructor and then passed on to a different function.
Is there any way we can do for 'compare' what was done for '==' ?
Thanks
{{{
module Bug where
data A = A {-# UNPACK #-} !B
deriving (Eq, Ord)
data B = B {-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
deriving (Eq, Ord)
}}}" aslatter
10513 3 asr ghc 7.6.3 Compiler panic with Generics Compiler 7.6.3 new normal 2015-07-09T12:47:56Z "Currently, Agda only compiles with ghc 7.4, 7.8, and 7.10, see
https://code.google.com/p/agda/issues/detail?id=1558
Here is a the relevant commit:
https://github.com/agda/agda/commit/f7b47de0cb167514f6db859b204abd638887b76f
Generics do not seem to work properly in ghc 7.6
{{{
[ 92 of 312] Compiling Agda.Syntax.Abstract.Name ( src/full/Agda/Syntax/Abstract/Name.hs, dist/build/Agda/Syntax/Abstract/Name.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-unknown-linux):
tcIfaceGlobal (local): not found:
Agda-2.4.3:Agda.Syntax.Fixity.D1PrecedenceLevel{tc a4mIV}
[(rc0D,
Type constructor `Agda-2.4.3:Agda.Syntax.Fixity.Fixity'{tc rc0D}'),
(r4mFT,
Type constructor `Agda-2.4.3:Agda.Syntax.Fixity.Precedence{tc r4mFT}'),
[…]
(r4mKa,
Identifier `Agda-2.4.3:Agda.Syntax.Fixity.$fTypeable1ThingWithFixity{v r4mKa}'),
(r4mKb,
Identifier `Agda-2.4.3:Agda.Syntax.Fixity.$fGenericThingWithFixity{v r4mKb}'),
(r4mKc,ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-unknown-linux):
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-unknown-linux):
tcIfaceGlobal (local): not found:
<>
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
I don't know whether you are maintaining old ghcs, but it seems we have to drop Generics until we drop support for ghc 7.6" andreas.abel
10470 48 austin@…, slyfox@…, simonmar Allocating StablePtrs leads to GC slowdown even after they're freed Runtime System 7.10.1 simonmar new normal 2015-06-01T19:14:49Z "If we allocate and then free a lot of StablePtrs the GC performance will be degrated for the rest of the execution.
I have attached a program that performs a GC-heavy task (foldr'ing a long list of Ints) before and after allocating and then freeing a million StablePtrs. After the StablePtrs are freed the task takes more than twice as long.
The reason for this is that `stable_ptr_table` in `Stable.c` is never resized, and is looped over for every GC pause." bitonic
1894 29 b.hilken@…, sorear Add a total order on type constructors Compiler (Type checker) 6.8.1 7.12.1 new lowest 2014-12-23T13:33:22Z "Several proposals for ExtensibleRecords can be implemented as libraries if type constructors can be ordered globally.
This proposal is to add built-in types:
{{{
data LabelLT
data LabelEQ
data LabelGT
type family LabelCMP
}}}
such that, for any two datatypes
{{{
data N = N
data M = M
}}}
the instance {{{LabelCMP N M}}} takes one of the values {{{LabelLT, LabelEQ, LabelGT}}} depending on the lexicographic ordering on the fully-qualified names of {{{N}}} and {{{M}}}.
" guest
9494 23 basvandijk, duncan, hvr Probable data corruption with GHCi 7.8.* and Zlib GHCi 7.8.3 infoneeded normal 2015-06-24T12:33:10Z "The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`.
{{{
module Main where
import qualified Codec.Compression.Zlib as Zlib
import qualified Data.ByteString.Lazy as BL
import qualified Data.ByteString.Internal as BI
import Control.Exception (bracket)
import Control.Concurrent
import Control.Monad
import Control.Exception ( evaluate)
import Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package
import Control.Concurrent.Async ( mapConcurrently)
import System.Mem ( performGC )
import Debug.Trace
test :: Int -> IO String
test _ = do
tid trace (show tid ++ "":"" ++ showBS x) x) [1..]
$ BL.toChunks bs
showBS (BI.PS ptr off len) = show ptr
main = do
r > threadDelay 1000)
killThread
(const io)
}}}
The output should be something like:
{{{
...
ThreadId 51:0x00000001091ee010
ThreadId 49:0x00000001091a7010
...
ThreadId 49:0x000000010986f010
zlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check)
}}}
You'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different.
So far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It '''was''' reproducable with HEAD from Jan 30 (I had that lying around somewhere).
" nominolo
2988 13 baterseapower Improve float-in Compiler 6.10.1 7.12.1 new lowest 2014-12-23T13:33:22Z "At the moment we can get a cascade of simplifier iterations like this:
{{{
let x1 = blah
x2 = x1 : []
x3 = 1 : x2
x4 = 2 : x3
in case blah of
True -> f x4
False -> g x4
}}}
Then `x4` satisfies the conditions for `postInlineUnconditionally` (not top-level, used once in each case branch, not inside lambda). So it's inlined. In the next iteration of the simplifier, `x3` satisfies the conditions, and so on.
It might be better for `postUnconditionally` to require an interesting context. But then this case doesn't work so well:
{{{
let x = blah in case foo of { A -> ..x..; B -> ..x..; C -> ..no x.. }
}}}
If C is the hot branch, it's a good idea to push `x` into the A,B branches.
But perhaps this question is one that `FloatIn` should deal with, not `postInlineUnconditionally`. Indeed `FloatIn` has the following comment:
{{{
-- For case expressions we duplicate the binding if it is
-- reasonably small, and if it is not used in all the RHSs
-- This is good for situations like
-- let x = I# y in
-- case e of
-- C -> error x
-- D -> error x
-- E -> ...not mentioning x...
}}}
So this ticket is just to record the idea:
* Make `postInlineUnconditionally` check for interesting context
...and check on performance changes, and whether `FloatIn` is doing the Right Thing.
Simon
" simonpj
8730 52 batterseapower, core-libraries-committee@… Invalid Unicode Codepoints in Char Core Libraries 7.6.3 ekmett new low 2014-11-16T21:38:44Z The surrogate range in Unicode is supposed to (as of Unicode 2.0, 1996) be a range of invalid code points yet, Data.Char allows the use of values in this range (in fact, it even gives them their own GeneralCategory). mdmenzel
3123 26 batterseapower@… make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) Compiler 6.11 7.12.1 new lowest 2014-12-23T13:33:22Z "Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner.
Unfolding Recursions
Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand-unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents.
More details, examples, and an informal spec: wiki:Inlining" claus
3571 53 batterseapower@…, michal.terepeta@… Bizzarely bloated binaries Compiler 6.10.4 7.12.1 new lowest 2014-12-23T13:33:22Z "Compiling a trivial test program:
{{{
module Main where
main = print ""Hello World""
}}}
Using GHC 6.10.4 produces a VERY suspicious PE file. (NB: this applies to DLL as well as EXE output).
The two problems that I have observed are:
1) The PE always contains a .stab and .stabstr section totalling 0x2A00 of debug data. Looking at the contents of stabstr, this appears to originate from a libffi object file. Perhaps we could disable stabs when building libffi to remove this bloat from output binaries.
2) The PE contains *A LOT* of trailing junk. My hello world program is 691K, and the PE contains 0x4FAFC = 318K of data which doesn't live in any section! Trimming this data appears to have no effect on the correctness of the program! The amount of junk grows proportionally to the amount of real code and data - I have observed e.g. 18Mb DLLs of which 9Mb are trailing junk.
To repeat: we could potentially *halve* GHC binary sizes by fixing this linker behaviour.
I'm not sure where exactly the fault lies - whether it is a GHC problem or some bug in Ld.
To test trimming your executables and DLLs, you can use this utility I whipped up. Usage is ""trimpe ... "". It will trim useless data from the end of the files in place:
{{{
{-# LANGUAGE ScopedTypeVariables #-}
module Main (main) where
import Control.Monad
import Data.Binary
import Data.Binary.Get
import qualified Data.ByteString.Lazy as ByteString
import Data.Word
import System.Environment
import Debug.Trace
assertM :: Monad m => Bool -> m ()
assertM True = return ()
assertM False = fail ""assertM""
newtype PEImageLength = PEImageLength Word32
-- http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
instance Binary PEImageLength where
get = do
-- Skip the MS DOS stub
skip 0x3c
pe_sig_offset IO ()
trimPEToImageSize file = do
putStrLn $ file
pe_contents fromIntegral image_size) $ do
putStrLn $ ""* Trimming to image size ("" ++ show image_size ++ "")""
let pe_contents' = ByteString.take (fromIntegral image_size) pe_contents
ByteString.writeFile file pe_contents'
}}}" guest
8023 4 benl dph-examples binaries don't use all CPUs Data Parallel Haskell 7.6.3 new normal 2014-11-22T03:43:16Z "Hi,
I've run dph-spectral-quicksort 3000000 +RTS -N6 of dph-examples-0.7.0.5 but it doesn't seem to use all the 6 hyperthreads. You can see the system monitor attached.
Same goes for the other quickhull-vector example.
ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
llvm-config-3.0 --version
3.0
What am I possibly doing wrong?" Lethalman
4081 137 benl@…, nightski@…, bjornbm, chr.andreetta@…, choener@…, batterseapower, rl, bgamari@… Strict constructor fields inspected in loop Compiler 6.13 7.12.1 benl new low 2014-12-23T13:33:45Z "Here is a small example to illustrate the problem:
{{{
module T where
data S a b = S !a !b
class C a where
make :: a -> S a a
instance C Int where
{-# NOINLINE make #-}
make n = S n n
foo :: (C a, Num a) => a -> Int -> a
{-# INLINE foo #-}
foo x k = k `seq` m `seq` go k 0
where
S m n = make x
go 0 i = i
go k i = go (k-1) (i + m)
}}}
{{{
module U where
import T
bar :: Int -> Int -> Int
bar s k = foo s k + 1
}}}
Relying on !LiberateCase seems to be the only way to unbox `m` outside of the loop in `bar`. The seq in `foo` doesn't help because it gets eliminated immediately.
GHC does have enough information to do this:
{{{
U.bar =
\ (s_aaw [Dmd=Just S(A)] :: GHC.Types.Int)
(k_aax [Dmd=Just U(L)] :: GHC.Types.Int) ->
case k_aax
of k1_ajh [Dmd=Just U(L)] { GHC.Types.I# ipv_ajj [Dmd=Just A] ->
case T.$fCInt_$cmake s_aaw of _ { T.S m_ajy [Dmd=Just U(T)] _ ->
...
}}}
Note the demand on `m`. If it was an argument instead of a local binding, it would be unboxed by w/w.
Also, the seq does help if we use lazy pairs instead of strict ones.
" rl
10595 7 bgamari BuiltinRules override other rules in some cases. Compiler 7.11 new high 2015-07-29T15:21:16Z "It seems that the Class op * rules will override a user defined rule for class functions.
This seems to be a long outstanding issue: http://stackoverflow.com/questions/9811294/rewrite-rules-not-firing-for-rules-matching-multiple-instance-methods
I also just ran into someone else on the haskell IRC channel who had an even simpler example then the one on that page:
{{{#!hs
{-# NOINLINE d #-}
{-# RULES ""d exp"" d exp = exp #-}
d :: (Double -> Double) -> (Double -> Double)
d f = f . (+20.0)
g :: Double -> Double
g = (+5.0)
main = do
print $ d exp 1.0 -- FAIL should print 2.718281828459045 >> printed exp 21.0 instead
print $ d g 3.0 -- PASS should print 28.0
-- Compiled with:
-- ghc -fenable-rewrite-rules -O rules.hs
}}}" gjsimms
10007 7 bgamari Fix misattribution of Cost Centre profiles to lintAnnots Profiling 7.10.1-rc1 7.10.3 scpmw new high 2015-07-27T17:26:35Z Split off from #9961 - the profiling results while debugging erroneously reported that most cost centre profiles were a result of `lintAnnots`, as opposed to `CSE`. This is a bug. thoughtpolice
10376 7 bgamari arm/linux linking failure Compiler 7.11 7.12.1 new normal 2015-05-04T01:13:24Z "Tests `sigcabal01` and `sigcabal02` both fail with an error like:
{{{
/usr/bin/ld.gold: warning: cannot scan executable section 1 of \
/home/erikd/ghc-upstream/testsuite/tests/cabal/sigcabal01/inst-p/lib/\
arm-linux-ghc-7.11.20150501/p_F3lh2Js8iHV9qItpHBsq0d/\
libHSp-1.0-F3lh2Js8iHV9qItpHBsq0d.a(P.o)
for Cortex-A8 erratum because it has no mapping symbols.
}}}
" erikd
10394 7 bgamari LLVM mangler doesn't mangle AVX instructions Compiler (LLVM) 7.11 7.12.1 patch normal 2015-07-03T11:22:10Z "The LLVM mangler does not currently transform AVX instructions on x86-64 platforms, due to a missing #include. Also, it is significantly more complicated than necessary, due to the file into sections (not needed anymore), and is sensitive to the details of the whitespace in the assembly.
I have attached a modified mangler that I believe to be simpler and more robust. I have not tested it, though, as I do not have a recent enough version of LLVM on my machine.
I am marking this as `Runtime crash' because that is what would happen if the unchanged AVX instructions made their way into the executable." dobenour
4960 7 bgamari Better inlining test in CoreUnfold Compiler 7.0.1 7.12.1 new low 2015-02-26T22:44:54Z "Consider this
{{{
f x = let
$j y = case x of { True -> e1; False -> e2 }
in
case x of
True -> ...$j y1...
False -> ...$j y2...
}}}
If a function that scrutinises its argument is applied to a constructor, it becomes much keener to inline. But in this example the function scrutinises a ''free variable'' that is evaluated to a known constructor at the call site. At the moment this is ignored, and `$j` may well not be inlined in situations where it would be jolly good to do so.
This shows up in test `perf/should_run/MethSharing` where the join points created early only inline because `exprIsDupable` is ''just'' generous enough to do so. If you reduce `CoreUtils.dupAppSize` by 1, the join point doesn't inline any more. But it should.
The solution is fairly easy: compute discounts on free varaibles as well as arguments. I'm making a ticket because I don't want to execute on this today." simonpj
8809 19 bgamari, adamgundry Prettier error messages? Compiler 7.9 new normal 2015-07-03T11:42:42Z "`clang` has very nice-looking error messages.
{{{
#!html

}}}
In my opinion, there are three independent improvements that could be made to GHC error messages and warnings: color, context and whitespace. Currently they're blobs of text.
Consider all three applied to error messages:
{{{
#!html

}}}
In my opinion, context and whitespace are more important that color. Even without color, compare this error message to the one shown above:
{{{
ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int'
main = print $ f ""Hello, world!""
^~~~~~~~~~~~~~~
ugly.hs:3:1: note: type of 'f' is given here:
f :: () -> IO ()
^~
}}}
In my opinion this is much easier to visually process than GHC's current messages." joelteon
7316 28 bgamari, cjwatson@… GHC segfaults on ARM Compiler 7.4.2 7.12.1 bgamari new normal 2014-12-23T13:34:10Z "Sorry for the lack of detail. I thought I'd file this upstream. We've been seeing this in Ubuntu with 7.4.2. Some cabal packages, like chell, fail to build with a segfault in ghc.
{{{
[3 of 4] Compiling Test.Chell.Main ( lib/Test/Chell/Main.hs, dist-ghc/build/Test/Chell/Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package time-1.4 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package patience-0.1.1 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package monads-tf-0.1.0.0 ... linking ... done.
Loading package text-0.11.2.0 ... linking ... done.
Loading package system-filepath-0.4.6 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package options-0.1.1 ... linking ... done.
make: *** [build-ghc-stamp] Error 11
}}}
Full build log attached. I'll try to reduce the example and/or reproduce with 7.6 soon. (I can also provide you with SSH access to hardware if you need it)." laney
10375 12 bgamari, hvr arm: ghci hits an illegal instruction GHCi 7.10.1 7.10.3 new high 2015-06-27T06:24:51Z "Some GHCi tests on arm/linux ie:
{{{
(cd testsuite ; make TEST=""print018 print020 print021 print022 print025"")
}}}
fail, all with the same error:
{{{
Stderr:
Illegal instruction
}}}
" erikd
9043 58 bgamari, hvr, ekmett, core-libraries-committee@… Add missing type class instances for data types in GHC.Generics Core Libraries 7.8.2 7.12.1 dreixel infoneeded normal 2014-12-23T13:34:10Z GHC.Generics offers a bunch of data types which have valid instances of various type classes in base, such as Functor. There's no good reason not to have these instances, so they should be added. ocharles
8326 17 bgamari, rwbarton Place heap checks common in case alternatives before the case Compiler 7.7 new normal 2015-07-26T03:53:24Z "We would like to have functions that check whether an `Int#` is a valid tag to represent `Bool` (see Note [Optimizing isTrue#] in ghc-prim):
{{{
isTrue# :: Int# -> Bool
isTrue# 1# = True
isTrue# _ = False
isFalse# :: Int# -> Bool
isFalse# 0# = True
isFalse# _ = False
}}}
We could use them with comparison primops like this:
{{{
f :: Int# -> Int
f x | isTrue# (x ># 0#) = I# x
| otherwise = -(I# x)
}}}
`isTrue#` is optimized away at the Core level:
{{{
A.f =
\ (x_aqM :: GHC.Prim.Int#) ->
case GHC.Prim.># x_aqM 0 of _ {
__DEFAULT -> GHC.Types.I# (GHC.Prim.negateInt# x_aqM);
1 -> GHC.Types.I# x_aqM
}
}}}
but the code genrator produces very bad Cmm code, because it pushes heap checks into case alternatives:
{{{
{offset
cFd: // stack check
if ((Sp + -16) < SpLim) goto cFr; else goto cFs;
cFr: // not enough place on the stack, call GC
R2 = R2;
R1 = A.f_closure;
call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8;
cFs: // scrutinize (x ># 0#)
_sEU::I64 = R2;
_sEV::I64 = %MO_S_Gt_W64(R2, 0);
if (_sEV::I64 != 1) goto cFg; else goto cFo;
cFg: // False branch
Hp = Hp + 16;
if (Hp > HpLim) goto cFy; else goto cFx;
cFy: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFf;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8;
cFf: // re-do the False branch
_sEU::I64 = I64[Sp + 8];
Sp = Sp + 16;
_sEV::I64 = R1;
goto cFg;
cFx: // RHS of False branch
I64[Hp - 8] = GHC.Types.I#_con_info;
I64[Hp] = -_sEU::I64;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
cFo: // True branch
Hp = Hp + 16;
if (Hp > HpLim) goto cFv; else goto cFu;
cFv: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFn;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8;
cFn: // re-do the True branch
_sEU::I64 = I64[Sp + 8];
Sp = Sp + 16;
_sEV::I64 = R1;
goto cFo;
cFu: // RHS of True branch
I64[Hp - 8] = GHC.Types.I#_con_info;
I64[Hp] = _sEU::I64;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}
}}}
This results in average 2.5% increase in binary size. By contrast, if we use `tagToEnum#` instead of `isTrue#` heap check will be placed before `case` expression and the code will be significantly shorter (this is done by a special case-on-bool optimization in the code generator - see #8317). What we would like to do here is:
1. compile case alternatives without placing heap checks inside them
2. each compiled alternative should return amount of heap it needs to allocate
3. code generator inspects amounts of heap needed by each alternative and either adds heap checks in alternatives or puts a single check before the case expression.
Getting this right might be a bit tricky.
1. if all branches allocate some heap then we can just put a common heap check before the case. Note that we must allocate the higgest amount required by any of the alternatives and then alternatives that use less heap must retract the heap pointer accordingly.
2. if we have two alternatives, one of which allocates heap and the other does not, we should place the heap check only in the alternative that allocates the stack. This will solve #1498.
3. it is not clear to me what to do if we have combination of the above (more than one branch that allocates heap and at least one branch that does not). If we place heap check before the `case` expression we lose optimization of recursive functions and face the problem described in #1498. If we push heap checks into branches that allocate heap then we get code duplication, i.e. the problem that we're addressing in this ticket. I guess the only way to make correct decission here is to try different aproaches and measure their performance.
This ticket is mentioned [http://ghc.haskell.org/trac/ghc/wiki/PrimBool#Implementationdetails on this wiki page] and in the source code in Note [Optimizing isTrue#] in ghc-prim. Once this ticket is resolved we need to update these places accordingly." jstolarek
6124 17 bgamari@… Spurious non-exhaustive warning with GADT and newtypes Compiler (Type checker) 7.4.1 7.12.1 new normal 2014-12-23T13:34:10Z "This may be related to #3927 or similar, but here's another case where the compiler produces a ""Pattern match(es) are non-exhaustive"" warning for patterns on a GADT that are impossible to implement:
{{{
newtype A = MkA Int
newtype B = MkB Char
data T a where
A :: T A
B :: T B
f :: T A -> A
f A = undefined
}}}
This produces the following warning:
{{{
Warning: Pattern match(es) are non-exhaustive
In an equation for `f': Patterns not matched: B
}}}
It is impossible to write a pattern for {{{B}}} because {{{B :: T B}}} does not match {{{T A}}}.
If I replace {{{newtype}}} with {{{data}}} for both {{{A}}} and {{{B}}}, the warning goes away. If I replace only one instance of either {{{newtype}}}, it will still produce the warning." joeyadams
2895 17 bgamari@… "Implement the ""Class System Extension"" proposal" Compiler 6.10.1 ⊥ new normal 2012-02-29T04:30:57Z "See: http://haskell.org/haskellwiki/Class_system_extension_proposal
Executive summary:
1. Class and instance declarations would allow method implementations to be given for any methods in the class or any ancestor class.
2. Whenever an instance declaration is visible there would always be a full set of instance declarations for all ancestor classes, by supplementing the set of explicitly given instance declarations that are visible in a module by automatically generated implicit instance declarations.
3. The most specific method implementation would always be chosen (ie prefer an explicit instance method over a class method and prefer a subclass method to a superclass method)
4. Modules would only export explicit instance declarations " porges
4213 17 bgamari@… LLVM: Add support for TNTC to LLVM compiler suite Compiler (LLVM) 6.13 7.12.1 dterei new low 2014-12-23T13:33:45Z "At the moment we handle TNTC in the LLVM backend in two different ways:
Linux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments. (Asm injection)
Mac: Mac assembler doesn't support the GNU As subsections feature, so we post-process the assembly code produced by llc.
Both these methods (especially Mac) are hacks. It would be better to extend LLVM to support the TNTC feature." dterei
7398 44 bgamari@…, ghc.haskell.org@… RULES don't apply to a newtype constructor Compiler 7.6.1 7.12.1 new normal 2015-05-14T17:51:21Z "For some reason, RULES that involve a newtype constructor never seem to fire. The following program demonstrates the problem:
{{{
module Main where
newtype Foo a = Foo { unFoo :: a }
deriving Show
foo :: a -> Foo a
foo = Foo
{-# RULES ""rule Foo"" forall v. Foo v = error ""Foo"" #-}
{-# RULES ""rule foo"" forall v. foo v = error ""foo"" #-}
main :: IO ()
main = do
print (Foo ())
print (foo ())
}}}
""rule foo"" fires, but ""rule Foo"" doesn't. The program prints
{{{
Foo {unFoo = ()}
D: foo
}}}
Note that this doesn't seem to affect selectors, only constructors." shachaf
8279 75 bgamari@…, schyler, hvr, george.colpitts@…, archblob, gidyn bad alignment in code gen yields substantial perf issue Compiler 7.7 7.12.1 new normal 2015-05-04T07:38:41Z "independently, a number of folks have noticed that in various ways, GHC currently has quite a few different memory alignment related performance problems that can have >= 10% perf impact!
Nicolas Frisby notes
{{{
On my laptop, a program showed a consistent slowdown with -fdicts-strict
I didn't find any obvious causes in the Core differences, so I turned to Intel's
Performance Counter Monitor for measurements. After trying a few counters, I eventually
saw that there are about an order of magnitude more misaligned memory loads with
-fdicts-strict than without, so I think that may be a significant part of the slowdown.
I'm not sure if these are code or data reads.
Can anyone suggest how to validate this hypothesis about misaligned reads?
A subsequent commit has changed the behavior I was seeing, so I'm not interested
in alternatives means to determine if -fdicts-strict is somehow at fault — I'm just
asking specifically about data/code memory alignment in GHC and how to
diagnose/experiment with it.
}}}
Reid Barton has independently noted
{{{
so I did a nofib run with llvm libraries, ghc quickbuild
so there's this really simple benchmark tak,
https://github.com/ghc/nofib/blob/master/imaginary/tak/Main.hs
it doesn't use any libraries at all in the main loop because the Ints all get unboxed
but it's still 8% slower with quick-llvm (vs -fasm)
weird right?
[14:36:30] could you post the asm it generates for that function?
[14:36:49] well it's identical between the two versions
but they get linked at different offsets because some llvm sections are different sizes
if I add a 128-byte symbol to the .text section to move it to the same address... then the llvm libs version is just as fast
well, apparently 404000 is good and 403f70 is bad
I guess I can test other alignments easily enough
I imagine it wants to start on a cache line
but I don't know if it's just a coincidence that it worked with the ncg libraries
that it got a good location
for this program every 32-byte aligned address is 10+% faster than any merely 16-byte aligned address
and by alignment I mean alignment of the start of the Haskell code section
haswell, sandybridge, ivy bridge, other?
dunno
I have similar results on Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
and on Quad-Core AMD Opteron(tm) Processor 2374 HE
ok
trying a patch now that aligns all *_entry symbols to 32 bytes
}}}
the key point in there is that on the tak benchmark, better alignment for the code made a 10% perf differnce on TAk on Core2 and opteron cpus!
benjamin scarlet and Luite are speculating that this may be further induced by Tables next to code (TNC) accidentally creating bad alignment so theres cache line pollution / conflicts between the L1 Instruction-cache and data-caches.
So one experiment would be to have the TNC transform pad after the table so the function entry point starts on the next cacheline?
" carter
8406 27 bgamari@…, simonmar Invalid object in isRetainer() or Segfault Runtime System 7.8.3 7.12.1 infoneeded normal 2015-05-11T10:52:25Z "When compiling with
-rtsopts -threaded -prof -fprof-auto -caf-all
and running with
-N4 -hr
I get a ""Segmentation fault"" every time.
If I run with -N4 -qg1 -hr, I either get a segfault or
internal error: Invalid object in isRetainer(): 40
When the segfault happens, it happens quickly. If the segfault doesn't happen, the program runs for about 5 seconds and I get ""invalid object"" error (always 40).
Without -hr, I have never gotten a segfault.
Edit (1/2015): This is still occurring under multiple threads in ghc 7.8.3.
GHC options: -Wall -prof -fprof-auto -threaded -rtsopts
Runtime Options: -N4 -hr -L1000
" crockeea
5987 81 bill@…, george.colpitts@…, tkn.akio@…, shelarcy@… Too many symbols in ghc package DLL Compiler 7.5 7.12.1 thoughtpolice new high 2015-07-04T15:23:36Z "In HEAD, the libHSghc DLL currently contains about 75000 symbols, but DLLs can only have about 65000 symbols. This means that when you try to run anything that uses the libHSghc DLL, references get resolved incorrectly and the GCer segfaults.
Max ran into this before, and temporarily fixed it with:
{{{
commit dd391759500ab2b6abd23d502ade7ff8946c780f
Author: Max Bolingbroke
Date: Wed Jul 6 18:01:02 2011 +0100
Don't export the _info symbol for the data constructor worker bindings
}}}
but the number of symbols has since crept up.
Three possible solutions:
* Split the ghc package up into `ghc-base`, `ghc-codegen`, `ghc-nativegen`, etc.
* Export fewer things. We'd first have to do this at the Haskell level (i.e. stop exposing some modules in the .cabal file; this may upset GHC API users), and then thread this info through so that we can tell the linker which symbols we do/don't want it to expose. Unfortunately, re-exports at the Haskell level mean that it isn't as simple as just not exporting anything from modules that aren't exposed.
* Automatically split the package into 2 DLLs. The tricky bit here is that we'd need dependencies to go only in one direction, i.e. if libHSghc1.dll uses symbols from libHSghc2.dll, then libHSghc2.dll doesn't use any symbols from libHSghc1.dll. Ideally Cabal would have a way to do this automatically, and the GHC build system would use the split that it calculates. However, i don't think Cabal has enough info to do this currently.
It would also be good if we can detect that building a DLL has gone wrong, and give an error.
" igloo
5620 34 bill@…, idhameed@… Dynamic linking and threading does not work on Windows Runtime System 7.2.1 7.12.1 new normal 2014-12-23T13:34:10Z "On Windows, compile this module:
{{{
main = print 42
}}}
With this command:
{{{
ghc --make -threaded -dynamic Main.hs
}}}
Run, and watch it segfault.
" Lennart
2408 76 blackbox.dev.ml@…, hvr, ekmett, core-libraries-committee@… threadWaitRead on mingw32 threaded causes internal error Core Libraries 7.6.1 7.12.1 new normal 2015-02-22T12:08:07Z "threadWaitRead (used in 6.8.x to avoid the non-interruptable getChar) causes internal error on GHC 6.8.2 and 6.8.3:
{{{
prompt: test: internal error: waitRead# on threaded RTS
(GHC version 6.8.2 for i386_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
}}}
This is because in GHC.Conc:
{{{
threadWaitRead :: Fd -> IO ()
threadWaitRead fd
#ifndef mingw32_HOST_OS
| threaded = waitForReadEvent fd
#endif
| otherwise = IO $ \s ->
case fromIntegral fd of { I# fd# ->
case waitRead# fd# s of { s -> (# s, () #)
}}
}}}
So the threaded case is ignored on mingw32, and waitRead# crashes on threaded RTS.
It should be at least written on the threadWaitRead documentation, and a workaround provided.
I've attached a little program to show the issue (if compiled with -threaded on windows)." kirby
8793 16 bos, hvr, ekmett Improve GHC.Event.IntTable performance Core Libraries 7.6.3 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "The performance of `GHC.Event.IntTable` can be improved. I've managed to get some nice increases across the board. Benchmarking using `criterion` shows:
function, % faster than current impl.
`insert`: 4%
`lookup`: 26%
`update`: 11%
`delete`: 5%
There is one strange thing I noted. In `updateWith`, there is an inner loop that looks like this:
{{{
data Bucket a = Empty | Bucket Int a (Bucket a)
go _ Empty = (False, Nothing, Empty)
go cont (Bucket key val next)
| key == k = case f val of
Nothing -> (True, Just val, cont next)
Just v -> (False, Just val, cont (Bucket key v next))
| otherwise = go (\x -> cont (Bucket key val x)) next
}}}
which returns a tuple that is immediately consumed like so:
{{{
(delete_occurred, old_val, new_bkt)
when delete_occurred
return old_val
}}}
I expected that inlining the `` and `` code blocks directly into `go` would result in better code than creating a tuple and then pattern matching on it afterwards. ie.
{{{
go _ Empty = return Nothing
go cont (Bucket key val next)
| key == k = do
case f val of
Nothing -> (cont next) >>
Just v -> (cont (Bucket key v next)
return (Just val)
| otherwise = go (\x -> cont (Bucket key val x)) next
}}}
which has the exact same semantics. To my suprise, this code is almost 2x slower! The core generated in both cases is exactly what I'd expect; if anything, the second version seems tighter. I'm not sure why the first version is faster, but perhaps the original author, Bryan O'Sullivan, can shed some light as he used the tupled method in the first version.
I'll attach my patch, `criterion`'s html output for the benchmarks as well as the benchmarking code, and the core for the oddity I discussed above.
" cdk
5273 18 bos@… error and undefined should print a location Compiler 7.1 7.12.1 new low 2014-12-23T13:33:45Z "The Control.Exception.assert function has a very nice hack so it prints a location together with the message. Could we please have that feature for 'error' and 'undefined' as well?
I just had the case where in one of 83 installed packages some idiot has an error message that just says 'dataTypeConstrs', which makes it very tedious to figure out what to fix. Yes, I can recompile everything for profiling, but that takes another two hours, which is why I'd prefer location information. (BTW, hbc had location info for those.)" augustss
5444 26 bos@…, dterei Slow 64-bit primops on 32 bit system Compiler 7.2.1 7.12.1 new normal 2014-12-23T13:34:10Z "GHC primops for 64-bit arithmetic are implemented as FFI calls. It leads to serious performance penalty for 32 bit code which heavily uses 64-bit arithmetics.
I found this while investigating poor performance of mwc-random on 32-bit systems. 32-bit build runs 3-4 times slower than 64-bit build on the same hardware. It's difficult to estimate how faster would run optimal implementation since it doesn't exist. But it's probably at least 2x slowdown.
Here is simple program to demonstrate issue
{{{
sqr64 :: Int32 -> Int64
sqr64 x = y * y where y = fromIntegral x
}}}
Here is optimized core
{{{
$wsqr64 :: Int# -> Int64
$wsqr64 =
\ (ww_sGO :: Int#) ->
case {__pkg_ccall ghc-prim hs_intToInt64 Int#
-> State# RealWorld -> (# State# RealWorld, Int64# #)}_aFY
ww_sGO realWorld#
of _ { (# _, ds2_aG2 #) ->
case {__pkg_ccall ghc-prim hs_timesInt64 Int64#
-> Int64# -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aGc
ds2_aG2 ds2_aG2 realWorld#
of _ { (# _, ds4_aGi #) ->
I64# ds4_aGi
}
}
sqr64 :: Int32 -> Int64
sqr64 = \ (w_sGM :: Int32) ->
case w_sGM of _ { I32# ww_sGO -> $wsqr64 ww_sGO }
}}}" Khudyakov
8814 62 bos@…, johan.tibell@…, idhameed@… 7.8 optimizes attoparsec improperly Compiler 7.8.1-rc1 new normal 2014-11-07T16:15:47Z "{{{
#!haskell
{-# LANGUAGE OverloadedStrings #-}
import Control.Applicative
import qualified Data.Attoparsec.Text as A
import Data.Text (Text)
import qualified Data.Text as T
testParser :: Text -> Either String Int
testParser f = fmap length
. A.parseOnly (many (A.char 'b' A.anyChar))
$ f
main :: IO ()
main = print . testParser $ T.replicate 50000 ""a""
}}}
On GHC 7.6.3 with `-O2`:
{{{
real 0m0.062s
user 0m0.022s
sys 0m0.007s
}}}
On GHC 7.8 tip with `-O2`:
{{{
real 0m12.700s
user 0m12.504s
sys 0m0.165s
}}}
On GHC 7.6.3 with `-O0`:
{{{
real 0m0.077s
user 0m0.025s
sys 0m0.007s
}}}
On GHC 7.8 tip with `-O0`:
{{{
real 0m0.055s
user 0m0.026s
sys 0m0.007s
}}}
This seems to be related to the use of ``; if I change the program so that the second branch (`A.anyChar`) is never taken, 7.8 behavior is roughly the same as 7.6 under any optimization level." joelteon
4288 59 bos@…, mmitar@…, p.giarrusso@… Poor -fspec-constr-count=n warning messages Compiler 6.13 7.12.1 new low 2014-12-23T13:33:45Z "The attached file, compiled with
{{{
ghc -O2 -fspec-constr-count=5 -ddpr-debug -c q.hs
}}}
gives a number of messages like
{{{
SpecConstr
Function `$j_X1BO{v} [lid]'
has one call pattern, but the limit is 0
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
SpecConstr
Function `$j_X1BR{v} [lid]'
has two call patterns, but the limit is 1
Use -fspec-constr-count=n to set the bound
Use -dppr-debug to see specialisations
}}}
Note that the limit doesn't match the `spec-constr-count` we set.
The ""limit"" given is `sc_count`, but `decreaseSpecCount` changes `sc_count` from its default of `specConstrCount dflags`. However, if this was fixed then we would get even stranger messages like
{{{
has two call patterns, but the limit is 5
}}}
" igloo
5954 40 buecking@…, conrad@… Performance regression 7.0 -> 7.2 (still in 7.4) Compiler 7.4.1 7.12.1 simonpj infoneeded normal 2015-07-01T18:57:10Z "The program in `nofib/parallel/blackscholes` regressed quite badly in performance between 7.0.x and 7.2.1. This is just sequential performance, no parallelism.
With 7.0:
{{{
3,084,786,008 bytes allocated in the heap
5,150,592 bytes copied during GC
33,741,048 bytes maximum residency (7 sample(s))
1,541,904 bytes maximum slop
64 MB total memory in use (2 MB lost due to fragmentation)
Generation 0: 5760 collections, 0 parallel, 0.08s, 0.08s elapsed
Generation 1: 7 collections, 0 parallel, 0.01s, 0.01s elapsed
INIT time 0.00s ( 0.00s elapsed)
MUT time 17.43s ( 17.47s elapsed)
GC time 0.09s ( 0.09s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 17.53s ( 17.56s elapsed)
}}}
With 7.2.2:
{{{
3,062,127,752 bytes allocated in the heap
4,714,784 bytes copied during GC
34,370,232 bytes maximum residency (7 sample(s))
1,553,968 bytes maximum slop
64 MB total memory in use (2 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 5781 colls, 0 par 0.08s 0.08s 0.0000s 0.0006s
Gen 1 7 colls, 0 par 0.01s 0.01s 0.0014s 0.0017s
INIT time 0.00s ( 0.00s elapsed)
MUT time 23.93s ( 23.93s elapsed)
GC time 0.09s ( 0.09s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 24.02s ( 24.03s elapsed)
}}}
and with 7.4.1:
{{{
3,061,924,144 bytes allocated in the heap
4,733,760 bytes copied during GC
34,210,896 bytes maximum residency (7 sample(s))
1,552,640 bytes maximum slop
64 MB total memory in use (2 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 5781 colls, 0 par 0.08s 0.08s 0.0000s 0.0007s
Gen 1 7 colls, 0 par 0.01s 0.01s 0.0015s 0.0017s
INIT time 0.00s ( 0.00s elapsed)
MUT time 23.90s ( 23.91s elapsed)
GC time 0.09s ( 0.09s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 24.00s ( 24.00s elapsed)
}}}
" simonmar
1273 25 Bulat.Ziganshin@… would like to print partial application values when at a breakpoint GHCi 6.7 ⊥ new normal 2008-09-30T15:51:16Z I'd like to be able to examine partial application values when at a breakpoint. guest
1216 94 Bulat.Ziganshin@…, claus.reinke@…, daniel.is.fischer@…, sveina@… Missed opportunity for let-no-esape Compiler 6.6 7.12.1 simonpj new normal 2014-12-23T13:34:10Z "readArray/writeArray call GHC.Arr.index, which seems inexplicably slow
for 2d arrays. inexplicably, because simply copying the default implementation
of index from GHC.Arr into the local module can speed things up considerably.
originally raised in this thread:
http://www.haskell.org/pipermail/haskell-cafe/2007-March/023394.html
shortened example or matrix/vector-multiplication attached. comment out
the first line of myindex to use the local copy. this results in a speedup
from 20s to 13s (time ./Index 100000) on my system, not to mention the
difference in space usage (a factor of 1000 in allocation, according to
+RTS -sstderr..)." claus
806 106 Bulat.Ziganshin@…, Deewiant, ryani, Olathe, dagitj@…, core-libraries-committee@… hGetBufNonBlocking doesn't work on Windows Core Libraries 6.4.2 ⊥ new normal 2015-02-22T12:01:43Z "All HAppS (http://happs.org/HAppS/README.html) applications fail with an internal error: asyncRead# when compiled with the -threaded option.
To reproduce the error:
- compile any of the apps in the example subdirectory with -threaded and access it over the net (http://localhost:8000).
For example:
ghc --make -v -fallow-overlapping-instances -fglasgow-exts -threaded httpd.hs -o httpd
The same programs compiled without -threaded work fine.
Tested on Windows XP with latest SP/patches and gcc 6.4.2.
Let me know if you would like more info or the full compilation trace." titto@…
605 132 Bulat.Ziganshin@…, id@…, pho@…, hackage.haskell.org@…, tibbe, dterei, bgamari Optimisation: strict enumerations Compiler None ⊥ new normal 2015-03-02T14:15:09Z Strict enumeration types should be implemented by `Int#`, both in the strictness analyser and for constructor fields annotated with `{-# UNPACK #-}`. simonmar
888 162 Bulat.Ziganshin@…, johan.tibell@…, hackage.haskell.org@…, reiner.pope@…, Jake.McArthur@…, choener@…, dterei Implement the static argument transformation Compiler 6.4.2 7.12.1 new normal 2014-12-23T13:34:10Z "The Static Argument transformation optimises
{{{
f x y = ....f x' y...
}}}
into
{{{
f x y = let g x = ....g x'...
in g x
}}}
Instead of passing {{{y}}} along unchanged, we make it into a free variable of a local function definition {{{g}}}.
Unfortunately, it's not always a win. Andre Santos gives a discussion, and quite a few numbers in [http://research.microsoft.com/%7Esimonpj/Papers/santos-thesis.ps.gz his thesis].
But sometimes it is a pretty big win. Here's the example that recently motivated me, which Roman Leshchinskiy showed me. You need the attached file Stream.hs, and then try compiling
{{{
import Stream
foo :: (a -> b) -> [a] -> [c]
foo f = mapL f
}}}
Thus inspired, I think I have a set of criteria that would make the static arg transformation into a guaranteed win:
* there is only one (external) call to the function
* OR its RHS is small enough to inline
* OR it is marked INLINE (?)
So I'd like to try this idea out." simonpj
701 45 Bulat.Ziganshin@…, pho@… Better CSE optimisation Compiler 6.4.1 ⊥ michalt new normal 2013-01-21T05:43:22Z "GHC's CSE optimisation is pretty weedy. It looks for expressions like this:
{{{
let x = e1 in e2
}}}
and replaces all occurrences of e1 in e2 with x. This doesn't do full CSE, but it does catch some cases. There have been case where full CSE would be significantly beneficial, though.
One possible way forward is to have a separate CSE pass that transformed expressions containing common subexpressions into the let-form above, and let the existing CSE pass do the final replacement.
We must be cautious, though: increasing sharing can introduce space leaks. Sometimes we can prove that this cannot happen, for example when the shared object is primitive, or has a bounded size." simonmar
728 72 Bulat.Ziganshin@…, SamB, pho@…, anton.nik@… switch to compacting collection when swapping occurs Runtime System 6.4.1 ⊥ new normal 2013-06-12T07:18:03Z "One avenue for tuning the GC to work better in low memory conditions is for it to auto-switch to compacting collection when swapping is happening. We can detect swapping using {{{getrusage()}}} on Unix systems. See:
[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009863.html]" simonmar
3373 50 byorgey@…, fryguybob@…, me@… GHC API is not thread safe GHC API 7.12.1 new low 2014-12-23T13:33:45Z There are some items of global state (the {{{NameCache}}} and the {{{PackageInterfaceTable}}}) that should be protected. One can workaround this by using a mutex and only invoking GHC API operations in one thread at a time. jcpetruzza
7336 6 cactus Defined but not used is not detected for data types with instances Compiler 7.6.1 new normal 2015-02-23T14:38:24Z "{{{
module Unused () where
data U = U deriving Show
}}}
does _not_ report
{{{
Unused.hs:3:6: Warning:
Defined but not used: type constructor or class `U'
Unused.hs:3:10: Warning: Defined but not used: data constructor `U'
}}}
This message is only displayed without ""deriving"".
I know, instances are always exported, but these instances cannot be used.
Considering that all types may get Typeable instances, no unused warning would ever be issued for data types.
" maeder
9803 6 cactus Poor error message for unbound variable in pattern synonym Compiler (Type checker) 7.9 new normal 2015-04-01T19:12:16Z "When I say
{{{
pattern OneElt = [x]
}}}
I get
{{{
Right-hand side of bidirectional pattern synonym cannot be used as an expression
[x]
}}}
I have two complaints with this error message:
1. It's very unclear what's actually wrong with the pattern -- `[x]` looks like a perfectly fine expression, until I realize that `x` is unbound.
2. The herald of the error is more than 80 characters (if you count the indentation) and wraps on my 80-character terminal. GHC tends to avoid this elsewhere, and so the wrapping is suboptimal.
I would easily say that issue (1) is more important than issue (2).
Perhaps this would be better:
{{{
Variable `x' is unbound in the bidirectional pattern synonym `OneElt':
[x]
}}}" goldfire
8583 6 cactus Associated pattern synonyms Compiler new normal 2015-07-17T18:02:40Z "The PatternSynonyms wiki page has a section on (typeclass-)associated pattern synonyms:
{{{#!hs
class ListLike l where
pattern Nil :: l a
pattern Cons :: a -> l a -> a
isNil :: l a -> Bool
isNil Nil = True
isNil (Cons _ _) = False
append :: l a -> l a -> l a
instance ListLike [] where
pattern Nil = []
pattern Cons x xs = x:xs
append = (++)
headOf :: (ListLike l) => l a -> Maybe a
headOf Nil = Nothing
headOf (Cons x _) = Just x
}}}" cactus
9671 6 cactus Allow expressions in patterns Compiler 7.12.1 new normal 2014-12-23T13:34:10Z "I've outlined a proposal for extending pattern synonyms to depend on terms (PatternFamilies), the name is less than ideal but I'll keep the page under that name for now. The proposal's introduction has been rewritten.
The simplest use case are patterns that matches only when a set contains an element (`IsMember`) or when a set does not contain an element (`NotMember`):
[[Image(wiki:PatternFamilies:member.png)]]
{{{#!hs
hasKeys :: Set Item -> IO ()
hasKeys (IsMember ""keys"") = leaveHouse
hasKeys (NotMember ""keys"") = findKeys >> leaveHouse
}}}
or a pattern that matches a map if the key exists:
[[Image(wiki:PatternFamilies:lookup.png)]]
used like this:
{{{#!hs
age :: Map Person Age -> String
age (Lookup ""Alice"" 60) = ""Alice is 60 years old!""
age (Lookup ""Alice"" age) = ""Alice is "" ++ show age ++ "".""
age (Lookup ""Bob"" _) = ""No info on Alice but we know how old Bob is.""
age _ = ""...""
}}}
Further details and examples can be found here: PatternFamilies, I discussed it with several people ICFP 2014. This would not require a new extension but would extend PatternSynonyms. This feature can be quite useful, especially when working with deeply nested structures (ASTs, JSON, XML, ...).
If people are fine with it I will implement it." Iceland_jack
2189 174 camio, igloo, Deewiant, ryani, sof, ddiaz, Artyom.Kazak@…, malaquias@…, dagitj@…, ryan.gl.scott@…, core-libraries-committee@…, Jedai hSetBuffering stdin NoBuffering doesn't work on Windows Core Libraries 6.8.2 7.12.1 new normal 2015-04-12T19:17:29Z "The following program repeats inputted characters until the escape key is pressed.
{{{
import IO
import Monad
import Char
main :: IO ()
main = do hSetBuffering stdin NoBuffering
inputLoop
inputLoop :: IO ()
inputLoop = do i case x <= b of
True -> e1
False -> e2
False -> e2
}}}
or
{{{#!hs
case x <= b of
True -> a <= x
False -> False
}}}
I don't know if we'll always be so lucky, but I think it may make sense to at least try to recognize these and similar forms." dfeuer
7309 26 carter.schonwald@… The Ix instance for (,) leaks space in range Core Libraries 7.6.1 ⊥ ekmett new normal 2014-10-07T05:47:37Z "(at least if you take leak to mean unexpected space behaviour).
This was brought to my attention via http://stackoverflow.com/questions/12780497/puzzling-memory-behavior-in-haskell where someone created a `6×10^6`-array and was surprised that showing the array caused an additional `(3+2)*8*10^6` bytes to be used. The reason (as far as I could tell) was this code:
{{{
instance (Ix a, Ix b) => Ix (a, b) where
range ((l1,l2),(u1,u2)) = [ (i1,i2) | i1 Boo Int#}}}
doesn't work.
I tried {{{newtype ( FastBool :: # ) = ...}}} , and {{{data Boo ( a :: # ) where...}}} , which just confused GHC.
Is there a reason that coercions of unlifted types shouldn't work, or is it just unimplemented? (inspired by looking at GHC's
compiler/utils/FastTypes.lhs and thinking that using newtypes instead of type synonyms in places like that would improve type-safety)" Isaac Dupree
2439 34 carter.schonwald@…, ekmett Missed optimisation with dictionaries and loops Compiler 6.9 7.12.1 simonpj new lowest 2015-07-09T11:23:59Z "{{{
{-# LANGUAGE BangPatterns #-}
module Foo (sum') where
foldl' :: (a -> b -> a) -> a -> [b] -> a
{-# INLINE foldl' #-}
foldl' f !z xs = loop z xs
where
loop !z [] = z
loop !z (x:xs) = loop (f z x) xs
sum' :: Num a => [a] -> a
sum' xs = foldl' (+) 0 xs
}}}
This is the code before !LiberateCase:
{{{
Foo.sum' =
\ (@ a_a9T) ($dNum_aa1 [ALWAYS Just L] :: GHC.Num.Num a_a9T) ->
let {
lit_scm [ALWAYS Just L] :: a_a9T
[Str: DmdType]
lit_scm =
case $dNum_aa1
of tpl_B1 [ALWAYS Just A]
{ GHC.Num.:DNum tpl_B2 [ALWAYS Just A]
tpl_B3 [ALWAYS Just A]
tpl_B4 [ALWAYS Just A]
tpl_B5 [ALWAYS Just A]
tpl_B6 [ALWAYS Just A]
tpl_B7 [ALWAYS Just A]
tpl_B8 [ALWAYS Just A]
tpl_B9 [ALWAYS Just A]
tpl_Ba [ALWAYS Just C(S)] ->
tpl_Ba lvl_sbH
} } in
letrec {
loop_sck [ALWAYS LoopBreaker Nothing] :: a_a9T -> [a_a9T] -> a_a9T
[Arity 2
Str: DmdType SS]
loop_sck =
\ (z_a6Y :: a_a9T) (ds_db7 :: [a_a9T]) ->
case z_a6Y of z_X7h [ALWAYS Just L] { __DEFAULT ->
case ds_db7 of wild_B1 [ALWAYS Just A] {
[] -> z_a6Y;
: x_a72 [ALWAYS Just L] xs_a74 [ALWAYS Just S] ->
case $dNum_aa1
of tpl_Xl [ALWAYS Just A]
{ GHC.Num.:DNum tpl_B2 [ALWAYS Just A]
tpl_B3 [ALWAYS Just A]
tpl_B4 [ALWAYS Just C(C(S))]
tpl_B5 [ALWAYS Just A]
tpl_B6 [ALWAYS Just A]
tpl_B7 [ALWAYS Just A]
tpl_B8 [ALWAYS Just A]
tpl_B9 [ALWAYS Just A]
tpl_Ba [ALWAYS Just A] ->
loop_sck (tpl_B4 z_a6Y x_a72) xs_a74
}
}
}; } in
\ (xs_a76 :: [a_a9T]) -> loop_sck lit_scm xs_a76
}}}
Note that the Num dictionary is scrutinised in the loop even though sum' is actually strict in the dictionary (by virtue of being strict in lit_scm) and it would make sense to take it apart before entering the loop. !LiberateCase does nail this but only if the loop is small enough and at the expense of code size.
" rl
9041 49 carter.schonwald@…, mail@…, simonmar NCG generates slow loop code Compiler (NCG) 7.6.3 new normal 2015-03-24T23:46:24Z "In http://stackoverflow.com/a/23322255/263061 we compile the code
{{{
main :: IO ()
main = do
loop (maxBound :: Word32) $ \i -> do
when (i `rem` 100000000 == 0) $
putStrLn ""foo""
}}}
and compare the assembly generated by the NCG and `-fllvm`.
The LLVM code is 10 times faster.
While the LLVM code looks great, NCG one generated looks quite unfortunate and messy, with a lot of unnecessary `mov`ing around.
I am by no means an expert in this, but some of it looks like low hanging potential improvements.
This is the '''LLVM code''':
{{{
Main_zdwa_info:
.LBB1_1:
movl $4294967295, %esi /* load the loop bound */
movabsq $-6067343680855748867, %rdi /* load a magic number for the modulus */
jmp .LBB1_2
.LBB1_4:
incl %ecx /* loop core start */
.LBB1_2:
cmpq %rsi, %rcx
je .LBB1_6 /* check loop bound */
/* do the modulus with two multiplications, a shift and a magic number */
/* note : gcc does the same reduction */
movq %rcx, %rax
mulq %rdi
shrq $26, %rdx
imulq $100000000, %rdx, %rax
cmpq %rax, %rcx
jne .LBB1_4 /* loop core end */
/* Code omitted: print, then return to loop beginning */
.LBB1_6:
}}}
So the core of the loop is a nice and short:
{{{
incl
cmpq
je
movq [division replaced by magic multiplication]
mulq
shrq
imulq
cmpq
jne
}}}
Now what '''NCG''' produces:
{{{
Main_zdwa_info: /* loop core start */
.Lc3JD:
leaq -16(%rbp),%rax /* stack check */
cmpq %r15,%rax
jb .Lc3JO /* jump not taken in the normal case */
.Lc3JP:
movl $4294967295,%eax /* issue: loading the bound on every iteration */
cmpq %rax,%r14
jne .Lc3JB
.Lc3JC:
/* Return from main. Code omitted */
.Lc3JB: /* test the index for modulus */
movl $100000000,%eax /* issue: unnecessary moves */
movq %rax,%rbx /* and loading the modulo arg on every iteration */
movq %r14,%rax
xorq %rdx,%rdx /* shorter alternative to mov $0,%rdx */
divq %rbx /* issue: doing the division (llvm and gcc avoid this) */
testq %rdx,%rdx
jne .Lc3JU /* This jump is usually taken. */
.Lc3JV:
/* do the printing. Code omitted. Not relevant */
.Lc3JN:
/* increment index and (I guess) restore registers messed up by the printing */
movq 8(%rbp),%rax /* This code is not very relevant because we don't almost never */
incq %rax
movl %eax,%r14d
addq $16,%rbp
jmp Main_zdwa_info
.Lc3JU:
leaq 1(%r14),%rax /*issue: why not just increment r14? */
movl %eax,%r14d
jmp Main_zdwa_info
}}}
So the core of this loop is
{{{
movl [stack check]
cmpq
jne
movl
movq
movq
xorq
divq
testq
jne
leaq
movl
jmp
}}}
Some issues here:
* the stack check is inside the loop
* the loop limit is loaded every time inside the loop
* the modulo arg is loaded every time inside the loop
* we are shuffling around registers
* no strength reduction (div is not replaced by cheaper magic number imul)
* weird increment using leaq
It would be great if somebody with codegen insight could comment on whether these are easy targets for improvement!" nh2
7883 114 carter.schonwald@…, pho@…, johan.tibell@…, idhameed@…, brooks.brian@… enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? Compiler 7.9 7.12.1 carter new normal 2014-12-23T13:34:10Z "LLVM provides a number of atomicity / memory ordering primitives.
currently the CAS primops exposed at the CMM level are ffi'd inline assembly fun calls. this means that for certain concurrency primops, we've got fun calls within funcalls that could be easily inlined if we did it in a more llvm direct way. A notable example of this is the implementation of {{{ stg_atomicModifyMutVarzh }}}
relevant basic llmv docs are the following
[http://llvm.org/docs/LangRef.html#cmpxchg-instruction Atomic llvm ops]
[http://llvm.org/docs/Atomics.html semantics of the various ordering levels]
relevant locations in the ghc source
[https://github.com/ghc/ghc/blob/master/includes/stg/SMP.h#L170 CAS inline assembly]
[https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L282 defn of atomicModifyMutVar cmm code]
Based upon my reading of the relevant GHC cmm code, and reading the semantics of the LLVM operations, the right level of atomic ordering in the generated bit code would be ""SequentiallyConsistent"".
a first step would be to modify the CMM -> LLVM pass to substitute the cas funcall with the right llvm operation. This ''' SEEMS ''' like it'd be very very easy to do and low hanging fruit.
Theres a few upsides that ''' might ''' come out of this.
1. would be easy to augment to also provide a doubleCAS primitive, which would be useful in writing various lock free data structures.
2. would increase the portability / ease of retargeting new platforms / hardware via LLVM. (not needing to worry about the target's memory consistency model / write new cases of inline assembly)
3. (this would need benchmarks) could potentially improve the performance of certain heavy concurrency operations by eliminating a funcall in an otherwise tight loop.
4. Theres probably other interesting possible upside, such as perhaps having more of the rts be nicely writeable in CMM? (esp since theres now native funcall support)
5. Also would make the CMM memory model a bit more explicit perhaps?
This seems like a *relatively* managable patch to write. I'm up for spending time on this if, should it work, it'd be likely to be merged in.
it'd also be a good warm up for a number of other things I want to do, including http://hackage.haskell.org/trac/ghc/ticket/5567#comment:10
" carter
5916 54 carter.schonwald@…, wren@… runST isn't free Compiler 7.4.1 7.12.1 new normal 2015-07-26T03:50:33Z "While optimizing some code I discovered that `runST` isn't free. I had a function on the form:
{{{
f ... = ...let x = runST in (f x)...
}}}
Manually transforming it into
{{{
f ... = runST (g ...)
where g ... = do
...
x in ViewPatterns binds more weakly than infix data constructors. Compiler (Parser) 6.10.1 ⊥ new normal 2014-12-04T18:49:00Z "The following code, essentially taken from the ViewPatterns page on the wiki doesn't seem to parse correctly.
{{{
mymap f [] = []
mymap f (x : mymap f -> xs) = f x : xs
}}}
However, this does:
{{{
mymap f [] = []
mymap f (x : (mymap f -> xs)) = f x : xs
}}}
(though it triggers bug #2395 about overlapping patterns)
It would seem nicer to make the view pattern arrow bind ''tighter'' than any infix data constructors." guest
7521 31 chak, george.colpitts@… Accelerate examples does not compile with default value of -fsimpl-tick-factor Compiler 7.6.1 7.12.1 new normal 2015-08-02T12:36:59Z "When doing $ `cabal build` for: http://github.com/AccelerateHS/accelerate-examples (commit def2495a1e7bd88e444540c3494b8674da99e201):
{{{
[31 of 36] Compiling SMVM.Matrix ( examples/tests/simple/SMVM/Matrix.hs, dist_accelerate/build/accelerate-examples/accelerate-examples-tmp/SMVM/Matrix.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.1 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying UnfoldingDone base:GHC.Base.returnIO1{v r5g} [gid]
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: 27960
}}}
" eamsden
5224 20 chak@… Improve consistency checking for family instances Compiler 7.0.3 7.12.1 simonpj new low 2014-12-23T13:33:45Z "Several compiler-performance tests got worse when I added the new generic default methods (with Pedro):
* `T3064`: peak_megabytes_allocated 24 is more than maximum allowed 16
* `IndTypesPerf`: needs more than the 20M heap it is given
* `T4801`: max_bytes_used 31.4M is more than maximum allowed 30M
For the first two of these we know exactly why: the (necessarily) eager overlap check is reading interface files that are otherwise not read, becuase of the new `Rep` type family instances in `Data.Maybe` and so on. Both these tests use type families.
For T4801 it's more mysterious. The test does not use type families, and no new interface files are read, but residency increases. So the cause may be different.
I'm pretty sure we can improve matters by propagating a bit more info; specifically, rather than a module simply saying ""I have some type familily instances"" it can say ""I have type family instances for F, G, H"".
I have marked the three tests as expect-broken for now, with the ticket to remind me to get back to it.
" simonpj
9365 12 cheater, hvr Make command key in GHCi configurable GHCi 7.8.3 new normal 2014-07-25T11:25:07Z "Hi,
GHCi rightly uses the Vim-style mode of entering commands, where prefixing the prompt with a special character makes it into an entry on a meta-level (i.e. a command to the interpreter shell, not to the interpreter itself). Unfortunately, that character is fixed to be ':'.
Many Vim power users hate having to press Shift several times a second and so make ';' that character in Vim. It's a popular tip on the Vim Tips site:
http://vim.wikia.com/wiki/Map_semicolon_to_colon
and tells you to perform the following settings:
nnoremap ; :
nnoremap : ;
vnoremap ; :
vnoremap : ;
Having used Vim like this for much over ten years now, it's not even a habit or reflex any more to type the semicolon, therefore (for me at least) it's cumbersome and error prone to type the colon in GHCi.
I ask that a new GHCi setting be added, with the following UI:
:set command-chars ""string""
where each character of ""string"" will start command mode. Multiple (at least two) characters should be available for people switching from their old setting to their new setting.
When command mode is started, even if you had done :set command-chars "";"" and then have typed ';', the prompt should still start with ':', just like in Vim. This is to signify that you're in the command ""mode"".
Thank you!" cheater
4470 81 choener@…, pumpkingod@…, michal.terepeta@…, dterei Loop optimization: identical counters Compiler 7.12.1 new normal 2014-12-23T13:34:10Z "Consider the small program below, where 'f' has to counters 'i' and 'j'. Both are completely identical; the only difference is that 'i' is used to change 's', while 'j' changes 'm'. It would be beneficial to have GHC transform 'f' into something like 'ff' so that one register less is required.
Neither GHC nor LLVM perform this optimization.
Code of this kind occurs when one uses the ""vector library"". See this discussion: [http://www.haskell.org/pipermail/glasgow-haskell-users/2010-November/019446.html]
{{{
{-# LANGUAGE BangPatterns #-}
module Main where
import Criterion.Main
f :: Int -> Int -> Int -> Int -> Int
f !i !j !s !m
| i == 0 = s+m
| otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)
g :: Int -> Int
g !k = f k k 0 0
ff :: Int -> Int -> Int -> Int
ff !i !s !m
| i == 0 = s+m
| otherwise = ff (i-1) (s + i+1) (m + i*5)
gg :: Int -> Int
gg !k = ff k 0 0
{-
main = do
print $ g 20
print $ gg 20
-}
main = defaultMain
[ bench "" g"" $ whnf g 20 -- 67.9ns
, bench ""gg"" $ whnf gg 20 -- 64.5ns
]
}}}
Function 'f' produces this core:
{{{
$wf =
\ (ww_s1uU :: Int#)
(ww1_s1uY :: Int#)
(ww2_s1v2 :: Int#)
(ww3_s1v6 :: Int#) ->
case ww_s1uU of wild_B1 {
__DEFAULT ->
$wf
(-# wild_B1 1)
(-# ww1_s1uY 1)
(+# (+# ww2_s1v2 wild_B1) 1)
(+# ww3_s1v6 (*# ww1_s1uY 5));
0 -> +# ww2_s1v2 ww3_s1v6
}
}}}
'wild_B1' and 'ww1_s1uY' should be merged in this case.
The attached source is above program." choenerzs
9074 42 choener@…, tulcod, crockeea GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files Compiler 7.8.2 new normal 2014-07-23T17:13:38Z "I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6.
In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running ""cabal repl"" I get
Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened)
(GHC version 7.8.2 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
When using the same code and cabal file with GHC 7.6, ""cabal repl"" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully.
Haskell Cafe discussion here:
http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html" massysett
4162 20 chowells79@… GHC API messes up signal handlers GHC API 6.12.3 7.12.1 new low 2014-12-23T13:33:45Z "A side-effect of using the {{{runGhc}}} function is that some signal handlers are modified and not restored afterwards (see function {{{initGhcMonad}}}). In particular, the handler for {{{SIGINT}}} installed by ghc throws an exception to a thread stored in a global variable, which initially corresponds to the thread from which {{{runGhc}}} was run.
This is a particularly problematic for programs that wish to run ghc ""in the background"" on its own thread. For example, consider this code:
{{{
import qualified GHC
import qualified MonadUtils as GHC
import qualified GHC.Paths as GHC
import Control.Concurrent ( forkIO, threadDelay )
main = do
putStrLn ""waiting for 5 seconds...""
threadDelay $ 5 * 1000 * 1000
putStrLn ""starting...""
forkIO $ GHC.runGhc (Just GHC.libdir) (GHC.liftIO $ putStrLn ""hello"")
putStrLn ""waiting for 10 seconds""
threadDelay $ 10 * 1000 * 1000
putStrLn ""exiting after final wait""
}}}
One can interrupt this program with Ctrl-C during the first five seconds of execution only.
It is not clear to me how one can safely workaround this problem. For instance, one could manually restore the program's original handlers at the beginning of execution, that is, transform:
{{{
runGhc action
}}}
into something like this:
{{{
runGhc $ (liftIO restoreProgramHandlers >> action)
}}}
but I don't know if this is safe (i.e., what happens if ghc is run without its own handlers installed).
" jcpetruzza
1853 17 chris@… hpc mix files for Main modules overwrite each other Code Coverage 6.8.1 7.12.1 AndyGill new lowest 2015-03-05T00:32:53Z "I have several programs, and hence several files that define Main modules, in the same directory. I build each one with a ghc --make -o Progname. When The hpc mix files describing the compiled modules are dumped in .hpc, the current Main.mix overwrites any previous Main.mix. As a result, I can only get an hpc report from Progname.tix if Progname was the most recent binary to be compiled.
" guest
5813 48 Christian.Maeder@…, merijn@… Offer a compiler warning for failable pattern matches Compiler 7.2.2 7.12.1 new normal 2014-12-23T13:34:10Z "This started off with a mailing list discussion: [http://www.mail-archive.com/haskell-cafe@haskell.org/msg96517.html]. The problem is that the following code produces no compile-time warning and results in a runtime error:
{{{
data MyType = Foo | Bar
deriving Show
test :: Monad m => m MyType -> m ()
test myType = do
Foo m MyType -> m ()
test myType = do
x return ()
main :: IO ()
main = test $ return Bar
}}}
I understand that this style of code may be very useful in some circumstances when paired with a Monad providing a sensible fail implementation, and is especially used in list comprehensions. However, this is allowing an easily catchable static error to slip through our fingers.
I recommend we add a new compiler warning to catch incomplete patterns in do-notation binding. I believe this warning should not apply to list comprehensions. Ideally, this warning would be turned on by -Wall." snoyberg
1928 5 claus Confusing type error message Compiler (Type checker) 6.8.1 ⊥ new low 2008-09-30T15:52:09Z "The following code (which is part of a bigger module) needs scoped type variables to compile.
{{{
run_state :: forall a s. State s a -> s -> (a,s)
run_state m s = observe_monad unit_op bind_op m where
unit_op v = (v,s)
bind_op :: BindOp (StateE s) a (a,s)
bind_op Get k = run_state (k s) s
bind_op (Put s1) k = run_state (k ()) s1
}}}
However, forgetting to turn on scoped type variables will give a very confusing error message:
{{{
Unimo.hs:56:36:
Couldn't match expected type `s1' against inferred type `s'
`s1' is a rigid type variable bound by
the type signature for `bind_op' at Unimo.hs:55:28
`s' is a rigid type variable bound by
the type signature for `run_state' at Unimo.hs:52:22
In the first argument of `k', namely `s'
In the first argument of `run_state', namely `(k s)'
In the expression: run_state (k s) s
}}}
Line 52 is the type signature of run_state and line 55 is the type signature of bind_op. The error message talks about a type variable `s1' which isn't mentioned anywhere. I guess the reason for this is that we have name collision and this is ghc's way of trying to tell the two variables apart. I don't think it works that well though. But I'm afraid I don't have any suggestion on how to make it better." josef
2365 5 claus Warn about usage of `OPTIONS_GHC -XLanguageExtension` Compiler 6.8.2 7.12.1 new lowest 2014-12-23T13:33:22Z We should warn if suspicious flags are given in `OPTIONS_GHC` pragmas; in particular, if any `-XLanguage` flag is used. igloo
1880 5 claus Unify flag descriptions to generate both docs and code Compiler 6.8.1 7.12.1 new lowest 2014-12-23T13:33:22Z "We want to specify all of GHC's flags in one place, and from there
* Generate the flag reference section of the documentation
* Generate the code to parse the command-line
* Allow flags to be deprecated, generating a warning
* Have an option to list all the flags that GHC supports (see #1226)
for use in command-line completion
* Generate the man page
* Completion in GHCi
This ticket replaces part of #1226." simonmar
2168 40 claus, pho@…, hvr, Fuuzetsu ghci should show haddock comments for identifier GHCi 6.8.2 7.12.1 new normal 2015-03-29T14:47:10Z "This came up in comp.lang.haskell recently:
http://groups.google.com/group/comp.lang.haskell/msg/ae69f720377e7a3f
I like the idea.
Immediate thoughts:
* if ghci reads the source file, it can read haddock annotations
* if ghci reads the interface file only (for library modules),
it needs to find the installed documentation
On the other hand the requested feature is a typical IDE functionality
(cf. Eclipse/show source/show javadoc) and it's perhaps a bit much
to require that from ghci.
" j.waldmann
1693 23 claus.reinke@… Make distclean (still) doesn't Build System 6.6.1 7.12.1 new lowest 2014-12-23T13:33:22Z "There are various ways in which `make distclean` does not remove all the files it should. Please keep adding to this bug description as you find more.
The following things are not currently distcleaned and should be, and hence are ending up in the source distribution:
{{{
libraries/haddock.css
libraries/haddock-util.js
}}}" simonpj
1399 49 claus.reinke@… better support for developing threaded applications in ghci GHCi 6.6.1 ⊥ new normal 2009-04-11T21:23:24Z "The haskell threads model has the appealingly simple property that the main thread determines the lifetime of your program. Once the main thread completes, all other threads are killed.
However this doesn't apply when iteratively developing at the ghci command-line. If, for example, you run `main` from the ghci prompt, you regain control of the prompt when your main thread terminates, but any threads spawned by it will keep running. This is particularly irksome if some of them hold onto OS resources (e.g. listening TCP sockets) as you find you can't run your code more than once due to resource issues.
It is possible to solve this problem explicitly by killing all the threads yourself at the end of `main`, but that amounts to adding a special `ghci` workaround to your code, because you wouldn't need that to compile as a standalone application.
I don't have a specific proposal on the best solution. One would be to alter `ghci`'s semantics so that after the completion of every interactively entered `IO a` action you reap all new threads that have been created. The disadvantage of this would be that it inhibits some interesting kinds of debugging exploring where you deliberately fork some threads from ghci and then communicate with them.
A more general solution would be some kind of `:command` to run either with-or-without the reaper-like function as preferred." guest
1572 44 claus.reinke@…, alpmestan@… Make it easy to find documentation for GHC and installed packages Compiler 6.6.1 7.12.1 new lowest 2014-12-23T13:33:22Z "`ghc-pkg` builds a package database that helps GHC find all installed packages. But it'd be a great improment if the same step also helped the '''user''' find the Haddock documentation for all installed packages.
Corresponding to GHC's package database would be an HTML page that is a single point of entry for the user to find documentation about installed packages. Preferably together with a consolidated index. (And maybe `ghc --help` should give the local URL of this documentation root.)" simonpj
7259 112 Conor.McBride@…, nfrisby, eir@…, adamgundry, sweirich@…, ekmett@… Eta expansion of products in System FC Compiler 7.6.1 7.12.1 simonpj new normal 2015-02-28T12:15:37Z "This ticket is to capture the ideas in these GHC-users threads: [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-August/022790.html PolyKinds Aug 2012] and [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-September/thread.html PolyKinds Sept 2012]
* We want to add eta-rules to FC. Sticking to pairs for now, that would amount to adding two new type functions (Fst, Snd), and three new, built-in axioms
{{{
axPair k1 k2 (a:'(k1,k2)) : a ~ '(Fst a, Snd a)
axFst k1 k2 (a:k1) (b:k2) : Fst '(a,b) ~ a
axSnd k1 k2 (a:k1) (b:k2) : Snd '(a,b) ~ a
}}}
Generalising to arbitrary products looks feasible.
* Adding these axioms would make FC inconsistent, because
{{{
axPair * * (Any '(*,*) ) : Any '(*,*) ~ (Fst .., Snd ..)
}}}
and that has two different type constructors on each side. However, I think is readily solved: see below under ""Fixing Any""
* Even in the absence of Any, it's not 100% obvious that adding the above eta axioms retains consistency of FC. I believe that Richard is volunteering to check this out. Right, Richard?
== Type inference ==
I'm a little unclear about the implications for inference. One route might be this. Suppose we are trying to solve a constraint
{{{
[W] (a:'(k1,ks)) ~ '( t1, t2 )
}}}
where a is an untouchable type variable. (if it was touchable we'd simply unify it.) Then we can replace it with a constraint
{{{
[W] '(Fst a, Snd a) ~ '( t1, t2)
}}}
Is that it? Or do we need more? I'm a bit concerned about constraints like
{{{
F a ~ e
}}}
where `a:'(k1,k2)`, and we have a type instance like `F '(a,b) = ...`
Anything else?
I don't really want to eagerly eta-expand every type variable, because (a) we'll bloat the constraints and (b) we might get silly error messages. For (b) consider the insoluble constraint
{{{
[W] a~b
}}}
where `a` and `b` are both skolems of kind `'(k1,k2)`. If we eta-expand both we'll get two insoluble constraints `(Fst a ~ Fst b)` and `(Snd a ~ Snd b)`, and we DEFINITELY don't want to report that as a type error!
Someone pointed out that Agda grapples with this problem and we should talk to them.
== Fixing Any ==
* I think we can fix the Any problem readily by making Any into a type family, that has no instances. We certainly allow equalities with a type '''family''' application on the left and a type constructor on the right.
I have implemented this change already... it seems like a good plan.
* Several people have asked why we need Any at all. Consider this source program
{{{
reverse []
}}}
At what type should we instantiate `reverse` and the empty list `[]`? Any type will do, but we must choose one; FC doesn't have unbound type variables. So I instantiate it at `(Any *)`:
{{{
reverse (Any *) ([] (Any *))
}}}
Why is Any poly-kinded? Because the above ambiguity situation sometimes arises at other kinds.
* I'm betting that making Any into a family will mess up Richard's (entirely separate) use of `(Any k)` as a proxy for a kind argument `k`; because now `(Any k1 ~ Any k2)` does not entail `(k1~k2)`. See also the module `GHC.TypeLits` in `base`.
We can't solve this by making `Any` to be an ''injective'' type family, because the use in `TypeLits` uses it in a type-class instance, and you can't match on type families!
" simonpj
7414 20 conrad@… plugins always trigger recompilation Compiler 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "When compiling code with a ghc plugin, e.g. '''ghc -O -fplugin SomePlugin Main.hs''', recompilation is triggered for every module. This can make plugins difficult to use in environments with many modules shared between executables.
Since a plugin is a GHC library, I would like to propose that plugin arguments and interface hashes be included in the dependencies for compiled modules, in a similar way to how compiler flags are already included. This would enable ghc to avoid recompilation of modules when using plugins, provided that the plugin and plugin options haven't changed." jwlato
8043 81 conrad@…, mle+hs@…, idhameed@…, pwberry@… Feature Request : Qualified module exports Compiler 7.7 new normal 2015-03-14T18:04:33Z "I quite like the practice of using `-XNoImplicitPrelude` and then defining my own (often per-project) Prelude doing things like:
{{{
module MyProject.Prelude
( module P
)
import Data.Text as P (Text)
import Prelude as P hiding (head, init, tail, last)
}}}
As an extension to the above idea, I would like to add qualified module exports defined so that I can do this:
{{{
module MyProject.Prelude
( module P
, qualified module T
)
import Data.Text as P (Text)
import Prelude as P hiding (head, init, tail, last)
import qualified Data.Text as T
}}}
so that any file which imports `MyProject.Prelude` will then have all the identifiers that they would normally get if they did:
{{{
import qualified Data.Text as T
}}}
Is this something that would have to go through the Haskell Next procedure? If so, how does one get that kicked off?
" erikd
8627 36 core-libraries-committee@… mallocForeignPtrBytes documentation unobvious regarding memory alignment Core Libraries 7.6.3 ekmett new normal 2014-11-17T18:56:23Z "According to the current documentation:
mallocForeignPtr - is equivalent to do { p do
sec IO CInt
}}}
I get
{{{
Unacceptable result type in foreign declaration: IO CInt
When checking declaration:
foreign import ccall unsafe ""static sys/mount.h umount"" umount
:: CString -> IO CInt
}}}
" tensor5
9135 36 core-libraries-committee@… readProcessWithExitCode leaks when the program does not exist Core Libraries 7.8.2 snoyberg new normal 2015-02-17T14:18:53Z "{{{#!haskell
import Control.Monad
import System.Process
import qualified Control.Exception as C
try' :: IO a -> IO (Either C.SomeException a)
try' = C.try
main = replicateM_ 1000 $ do
try' (readProcessWithExitCode ""doesnotexist"" [] """")
print =<< try' (readProcessWithExitCode ""/bin/echo"" [""it works""] """")
}}}
This eventually runs out of file descriptors and fails to start the existing process.
Tested with process 1.2.0.0 and GHC 7.8.2 on OS X
" luite
9539 36 core-libraries-committee@… TQueue can lead to thread starvation Core Libraries 7.8.2 ekmett new normal 2015-04-23T21:12:26Z "For background, please see [http://stackoverflow.com/questions/25536604/huge-memory-consumption-for-simple-multithreaded-haskell/25560047#25560047 this SO question]
When using TQueue, a sufficiently fast/persistent writer can result in the reader never getting scheduled, causing the queue to continually grow and lost concurrency.
I believe the issue is caused by the definition of readTQueue:
{{{
readTQueue :: TQueue a -> STM a
readTQueue (TQueue read write) = do
xs do writeTVar read xs'
return x
[] -> do ys retry
_ -> case reverse ys of
[] -> error ""readTQueue""
(z:zs) -> do writeTVar write []
writeTVar read zs
return z
}}}
Note that the last `case` needs to traverse the write-end of the queue within the STM transaction. If the list is sufficiently large, a writer can commit a new transaction much more quickly, invalidating the read transaction. If threads continue to write to the queue, the reader will never get an opportunity to commit (and the list will grow, exacerbating the problem).
This alternative definition seems to fix the problem, but I don't know if there are other drawbacks to using it.
{{{
readTQueue' :: TQueue a -> STM a
readTQueue' (TQueue read write) = do
xs do writeTVar read xs'
return x
[] -> do ys retry
_ -> do writeTVar write []
let (z:zs) = reverse ys
writeTVar read zs
return z
}}}" jwlato
10065 36 core-libraries-committee@… Definition of fix lacks commentary Core Libraries 7.11 dfeuer new normal 2015-02-04T17:14:03Z "In `Data.Function`,
{{{#!hs
fix :: (a -> a) -> a
fix f = let x = f x in x
}}}
It is not immediately obvious why it is defined like this, rather than the more natural
{{{#!hs
fix f = f (fix f)
}}}
There are very good reasons for this; notably, it allows for the definition of circular data structures. But there should be a comment explaining this, preferably in the Haddocks." dfeuer
10328 36 core-libraries-committee@… Control.Monad exports lead to weird Haddocks Core Libraries 7.10.1 ekmett new normal 2015-04-20T14:51:55Z `Control.Monad` exports, and therefore documents, the `Functor` class (but only the `fmap` member) and the `Monad` class. It does not export, and therefore does not document, the `Applicative` class. This is all pretty weird. Since `Functor` is in the prelude (and probably most/all alternate preludes), is there actually a reason to export it from `Control.Monad`? dfeuer
8844 36 core-libraries-committee@… Pseudo terminal and process-1.2.0.0 Core Libraries 7.6.3 snoyberg new normal 2015-02-17T14:18:42Z "Hello,
I'm writing simple app which execute process and communicate with it
via pseudo terminal. Here is some sample code:
{{{#!haskell
import System.Posix.Terminal
import System.Process
main = do
(master, slave) 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." basvandijk
10014 36 core-libraries-committee@… Data.Array.Base.elems needlessly calls bounds. Core Libraries 7.8.4 ekmett new normal 2015-01-22T22:21:34Z "{{{
elems arr = case bounds arr of
(_l, _u) -> [unsafeAt arr i | i Array Int a -> Array Int Int
failureFunc string = result where
result = listArray (bounds string) (-1 : 0 : getMatch 2 0)
getMatch :: Int -> Int -> [Int]
getMatch p matchPos
| matchPos < 0 = 0 : getMatch (p+1) 0
| string ! (p - 1) == string ! matchPos = matchPos + 1 : getMatch (p+1) (matchPos+1)
| otherwise = getMatch p (result ! matchPos) -- use result!
}}}
This seems reasonable, we just use the result of elements < i to construct element i. However, it does not work:
{{{#!hs
Main> elems $ failureFunc (listArray (0,23) ""participate in parachute"")
*** Exception: <>
}}}
The problem is that listArray is equivalent to:
{{{#!hs
listArray b l = array b (zip (range b) l)
}}}
(Recall that array is strict in the structure of the given list, and in the first elements of the tuples in this list, but not in the second elements of the tuples.)
The structure of the list l=(-1 : 0 : getMatch 2 0) depends on the observing elements of the array (result ! matchPos). The structure of (zip (range b) l) is strict in the structure of l, and hence failure loops.
Proposed solution: redefine listArray as equivalent to:
{{{#!hs
listArray b l = array b (zipLazyRight (range b) l)
zipLazyRight :: [a] -> [b] -> [(a,b)]
zipLazyRight [] _ = []
zipLazyRight (h:t) l = (h,head l): zipLazyRight t (tail l)
}}}
The difference is that listArray is now non-strict in the structure of the argument list, because zipLazyRight is non-strict in the right argument. Using this definition, failureFunc does not fail:
{{{#!hs
Main> elems $ failureFuncArr (toArr ""participate in parachute"")
[-1,0,0,0,0,0,0,0,1,2,0,0,0,0,0,0,1,2,3,0,0,0,0,0]
}}}
This does not change the semantics uses of listArray which were already defined: it just makes more uses of listArray defined.
" atze
10514 36 core-libraries-committee@… Generic for existential types Core Libraries 7.10.1 ekmett new normal 2015-06-12T09:00:58Z "I have some use for Generic for an existential type which is constraint to be Generic.
{{{#!hs
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE StandaloneDeriving #-}
import GHC.Generics
data U = forall a. (Generic a) => U a
deriving (Generic) -- TRY 1
-- Can't make a derived instance of ‘Generic U’:
-- Constructor ‘U’ has existentials or constraints in its type
-- Possible fix: use a standalone deriving declaration instead
deriving instance Generic U -- TRY 2
-- Can't make a derived instance of ‘Generic U’:
-- U must be a vanilla data constructor
-- In the stand-alone deriving instance for ‘Generic U’
data D1Ser
data C1_0Ser
instance Generic U where -- TRY 3
type Rep U = D D1Ser (C1 C1_0Ser (S1 NoSelector (Rep a)))
-- Not in scope: type variable ‘a’
-- How to bring the existential type `a' into scope?
}}}" andreas.abel
9943 36 core-libraries-committee@… "Replace ""error"" with ""errorWithStackTrace"" from GHC.Stack in base libs" Core Libraries new normal 2014-12-31T18:34:41Z It is basically the same as the standard error function but outputs a stack trace if one is available. spacekitteh
7161 36 core-libraries-committee@… hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles Core Libraries 7.6.1-rc1 7.12.1 ekmett infoneeded normal 2014-12-23T13:34:10Z "The `hSetNewlineMode` and `hSetEncoding` functions from `GHC/IO/Handle.hs` do not check that the Handle is in an open mode. It is possible to use them on closed handles. hSetEncoding on a closed Handle triggers a segfault. Similarly, the operations are also both possible on semi-closed handles, and given the way hGetContents is implemented, this will affect the result of hGetContents which is clearly against the intention of the hGetContents/semi-closed stuff.
Both functions use the `withAllHandles__` helper. Unlike similar helpers like `wantReadableHandle_` this one doesn't do any handle mode checking.
Additionally, `hSetBuffering` and `hSetBinary` mode also use the `withAllHandles__` pattern and don't obviously check for an open handle but I've not verified this." duncan
9792 36 core-libraries-committee@… map/coerce rule does not fire until the coercion is known Core Libraries 7.9 7.12.1 ekmett new normal 2014-12-23T13:34:10Z "If I write a nice, simple use, like:
{{{#!hs
myPotato = map coerce
}}}
or even
{{{#!hs
myPotato = Data.OldList.map coerce
}}}
the ""`map/coerce`"" rule does not fire.
It looks like there are two things getting in the way:
1. The `map` rule fires first, turning `map` into a `build/foldr` form, which `map/coerce` does not recognize.
2. Even if `map` gets written back, `coerce` has been expanded into something the rule doesn't recognize.
So we end up with something that looks like
{{{#!hs
myPotato =
\ (@ a_are)
(@ b_arf)
($dCoercible_arz :: Coercible a_are b_arf)
(lst_aqx :: [a_are]) ->
map
@ a_are
@ b_arf
(\ (tpl_B2 [OS=ProbOneShot] :: a_are) ->
case $dCoercible_arz
of _ [Occ=Dead] { GHC.Types.MkCoercible tpl1_B3 ->
tpl_B2 `cast` (tpl1_B3 :: a_are ~R# b_arf)
})
lst_aqx
}}}" dfeuer
9806 36 core-libraries-committee@… malloc and mallocArray ignore Storable alignment requirements Core Libraries 7.8.3 7.12.1 new normal 2015-02-08T17:11:40Z "Not sure if this is a bug or a feature request:
`allocaBytesAligned` exists and allocates a new pinned byte array with a given alignment. It is used for both `alloca` and `allocaArray`.
However, we don't currently have such a facility with `malloc`.
`malloc` and `mallocArray` currently just invoke `mallocBytes`, and `mallocBytes` requests memory without alignment guarantees, so the resulting memory might well violate required `Storable` `alignment` for the result.
We don't currently pad things out or get properly aligned memory.
It strikes me that we should in theory add `mallocBytesAligned`, and switch `malloc` and `mallocArray` to invoke it instead of `mallocBytes`.
`Foreign.Marshal.Alloc.mallocBytes` just invokes system `malloc`, so it seems that `memalign` or `posix_memalign` would be suitable.
In theory `_malloc` on the system is probably aligning to a pretty common unit size, but if you start doing SIMD stuff you'll start seeing 16 byte alignment requirements, folks who care about cache architecture for example can have 128 byte alignments to pad things to separate cache lines.
We probably haven't noticed since you likely get back bytes with slot-sized alignment just by construction, so if your alignment requirements stay in the <= 8 range you'll be okay, but for larger alignments it appears you'd just get wrong answers.
If something more subtle is going on here (e.g. an `alignment` bigger than some threshold wont be respected or that users should explicitly expect `mallocArray` to silently allocate an array with the wrong alignment) that I missed then we definitely need better documentation to address the issue." ekmett
10034 36 core-libraries-committee@… Regression in mapM_ performance Core Libraries 7.10.1-rc2 7.12.1 ekmett new normal 2015-03-03T15:36:01Z The current `mapM_` is sometimes worse than the version in 7.8.3. This can be fixed easily by eta-expansion, matching `mapM`. dfeuer
10216 36 core-libraries-committee@… Allow arr ∧ (first ∨ (***)) as minimal definition of Arrow instance Core Libraries 7.10.1 7.12.1 ekmett infoneeded normal 2015-08-02T18:31:34Z "Add default definitions of `first`, `second` in terms of `(***)` to let one define an `Arrow` instance in terms of `(***)` rather than `first`, which is sometimes more elegant or convenient.
" strake888
9865 36 core-libraries-committee@… Comonads in base library Core Libraries 7.12.1 ekmett new normal 2014-12-19T06:44:38Z "Comonads are useful as heck, and should be in the base library. This could allow codo notation (e.g. https://www.cl.cam.ac.uk/~dao29/publ/codo-notation-orchard-ifl12.pdf ) in the future.
It shouldn't be hard at all to do - just basically copy Edward's comonad package :)" spacekitteh
9908 36 core-libraries-committee@… Improve enumFromX support for OverloadedLists Core Libraries 7.9 7.12.1 ekmett new normal 2014-12-19T20:47:14Z "At present, `OverloadedLists` desugars `[m..n]` as `fromList (enumFromTo m n)`. This is sometimes okay, but terrible for `Data.Sequence`. In particular, I want, for example,
{{{#!hs
[m..n] :: Seq Int
}}}
to end up as `fromFunction (n-m+1) (+m)`, which performs much better. There are a few approaches that look reasonable:
1. Try to catch `fromList (enumFromTo m n)` before `enumFromTo` becomes `eftInt`. This does not, unfortunately, seem to work.
2. Grab `eftInt` after it gets written back from `eftIntFB`. This would probably work, but it's currently impossible because `eftInt` is not exported from `GHC.Exts` or even `GHC.Enum`.
3. Add `enumFromTo`, etc., to the `IsList` class. Default to the current behavior, but if possible use `fromListN` for well-known `Enum` types." dfeuer
9674 36 core-libraries-committee@… Foldable doesn't have any laws Core Libraries 7.8.3 7.12.1 ekmett new normal 2015-02-12T19:52:51Z The documentation for `Foldable` doesn't list any laws. I don't know exactly what its laws may be, but there are, at least, several implicit in the default method definitions. dfeuer
9716 36 core-libraries-committee@… The list modules need a bit of post-BBP shaking Core Libraries 7.9 7.12.1 ekmett new normal 2014-12-23T13:34:10Z "We currently have an unfortunately named `Data.List.OldList`, and no terribly clear story to explain it. One concept, due in part to me and in part to Carter:
1. Move all the basics needed to implement `instance Foldable []` from `Data.OldList` to `Data.List.Base` (or some similar name).
2. Move all the ""extras"" like `inits`, `tails`, and `sort` from `Data.OldList` into `Data.List`.
3. Delete `Data.OldList`." dfeuer
9797 36 core-libraries-committee@… Investigate rewriting `>>=` to `*>` or `>>` for appropriate types Core Libraries 7.9 7.12.1 dfeuer new normal 2014-12-23T13:34:10Z "When we see `m >>= (\_ -> n)` with a type that admits an optimized `>>` or ` *`. If `k` was instantiated to anything other than `*`, you wouldn't be able to make an instance for `Par1`, but then I don't think it would ever come up so that would be exactly the right behavior. This allows, in particular, `DataKinds` to be used as a parameter to instances of `Generic1`.
I don't know if this would affect deriving, but I wouldn't really expect it to." DerekElkins
5376 36 core-libraries-committee@… Quotation in System.Process.system for Windows Core Libraries 7.0.4 7.12.1 snoyberg new low 2015-03-19T21:55:55Z "Wagnerdm writes: I had a bit of fun recently tracking down quoting issues with the ""`system`"" command in Windows. For the examples below, I'll consistently use ""`Windows> `"" as the beginning of some text sent to the Windows command prompt cmd.exe, and use ""`GHC> `"" as the beginning of some text sent to a ghci session running in cmd.exe with `System.Cmd` imported.
The situation is this: I want to hand off a command line which has both a possibly-quoted command name and a (definitely) quoted argument. For concreteness, let's use ""more"" as the command and ""foo.txt"" as the argument, so that you can follow along at home on your favorite Windows system.
{{{
Windows> echo foo > foo.txt
Windows> ""more"" ""foo.txt""
foo
}}}
All good so far. But:
{{{
GHC> system ""\""more\"" \""foo.txt\""""
'more"" ""foo.txt' is not recognized as an internal or external command, operable program or batch file.
ExitFailure 1
}}}
After some digging, I discovered that system is shipping out to cmd /c, and indeed:
{{{
Windows> cmd /c ""more"" ""foo.txt""
'more"" ""foo.txt' is not recognized as an internal or external command, operable program or batch file.
}}}
I don't know what the *right* fix is. However, after a bit of playing around, I discovered the following:
{{{
Windows> cmd /c """"more"" ""foo.txt""""
foo
GHC> system ""\""\""more\"" \""foo.txt\""\""""
foo
ExitSuccess
}}}
Wrapping commands with an extra pair of double-quotes this way seemed to give behavior matching the bare cmd.exe for all the examples I could think of, even ones I thought it would break. For example:
{{{
GHC> system ""\""more foo.txt\""""
foo
ExitSuccess
}}}
If this turns out to be the right thing to do, it's pretty easy to implement. In the `commandToProcess` function, at `libraries/process/System/Process/Internals.hs:455`, the change is just
{{{
- return (cmd, translate cmd ++ ""/c "" ++ string)
+ return (cmd, translate cmd ++ ""/c \"""" ++ string ++ ""\"""")
}}}
(And in any case, the examples above should answer this amusing comment, immediately following those lines:
{{{
-- We don't want to put the cmd into a single
-- argument, because cmd.exe will not try to split it up. Instead,
-- we just tack the command on the end of the cmd.exe command line,
-- which partly works. There seem to be some quoting issues, but
-- I don't have the energy to find+fix them right now (ToDo). --SDM
-- (later) Now I don't know what the above comment means. sigh.
}}}
Later, Brandon comments: What that comment means is that how CMD.EXE handles spaces is Windows-version-dependent. On the other hand, I ''think'' it's mostly consistent between XP and Windows 7 --- and I feel sorry for anyone forced to use an older version.
" simonpj
10063 36 core-libraries-committee@… State a law for foldMap Core Libraries 7.10.1-rc1 7.12.1 ekmett new low 2015-02-03T20:59:56Z "After being prodded by /u/random_crank on reddit, I realized there is a law we can state for `foldMap`:
A monoid homomorphism `g` is a function such that
{{{#!hs
g mempty = mempty
g (mappend a b) = mappend (g a) (g b)
}}}
holds.
For any monoid homomorphism `g`:
{{{#!hs
foldMap (g . f) = g . foldMap f
}}}
This isn't strictly a free theorem as it relies on the `Monoid` laws, but it is true and has the same general flavor as the equally complicated free theorem for `foldr`.
This law is a bit technical, but is a nice tool for equational reasoning, and gives rise to a much nicer `foldMap`-based version of the ""banana split"" theorem for `foldr`.
{{{#!hs
foldMap f &&& foldMap g = foldMap (f &&& g)
}}}" ekmett
9724 63 core-libraries-committee@…, eir@…, oerjan reexport IsList class from a trustworthy module Core Libraries 7.8.3 ekmett new normal 2015-04-01T12:38:35Z "==== Motivation
GHC's Safe Haskell extension relies to a large extent on inferring safety of modules automatically. As a concrete example, [[http://hackage.haskell.org/package/data-default|data-default]] used to be inferred safe.
This is no longer the case, because [[http://hackage.haskell.org/package/dlist-0.7.1|dlist-0.7.1]] added an {{{IsList}}} instance for difference lists. The only way to do that currently is to import the relevant parts of {{{GHC.Exts}}}, and that module is not safe.
Of course the resulting non-safety of the {{{Data.DList}}} module can be fixed by adding a {{{TrustWorthy}}} pragma to the module and trusting the {{{dlist}}} package. But that is unsatisfactory, because there is nothing unsafe about providing an instance for the {{{IsList}}} class. This issue is bound to pop up in other packages as well.
==== Proposed Solution
(this is one of many possibilities)
Add a {{{GHC.Exts.Safe}}} module that is marked {{{TrustWorthy}}} and reexports the {{{IsList}}} class, and possibly other things from {{{GHC.Exts}}} that are safe to use." int-e
229 46 core-libraries-committee@…, gershomb Integer overflow in array allocation Core Libraries 7.9 7.12.1 rwbarton new normal 2015-06-23T17:37:05Z "When asked to create a sufficiently large array ghci
coredumps.
{{{
\begin{code}
import Data.Array.ST
import Control.Monad.ST
import GHC.Base
example = runST (do arr ST s Bool
go arr = readArray arr 3
\end{code}
}}}
Load this into ghci and type 'example'." josefs
10168 56 core-libraries-committee@…, gidyn, RyanGlScott generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ Core Libraries 7.10.1-rc1 ekmett patch normal 2015-07-08T00:05:51Z "These need only an Applicative constaint.
" strake888
10444 60 core-libraries-committee@…, mfdyck@…, hvr Tex.Read.Lex.lex broken Core Libraries 7.10.1 7.12.1 ekmett patch normal 2015-06-02T20:13:03Z "{{{
Prelude> lex ""&) = mempty""
[(""&"","") = mempty"")]
Prelude> lex ""∘) = mempty""
[]
}}}
I traced this problem to Text.Read.Lex.lex
" strake888
10448 62 core-libraries-committee@…, RyanGlScott, hvr, ekmett "Implement rest of ""Add bifunctor related classes to base""-Proposal" libraries/base 7.12.1 ekmett new normal 2015-05-27T02:10:47Z "Cloned from #9682:
----
See [http://www.haskell.org/pipermail/libraries/2014-April/022844.html original libraries@ proposal] for more details" hvr
10512 47 core-libraries-committee@…, vagarenko Generic instances missing for Int32, Word64 etc. Core Libraries 7.10.1 ekmett new normal 2015-07-22T15:51:54Z "Some base types have Generic instances, like Integer, the machine-specific ones like Int32 have none. But these would be most useful when using generic Binary serialization.
I think it makes sense to add Generic instances for *all* primitive types in base.
I can define the instance myself, see
https://github.com/agda/agda/commit/1d3710189989aced61be79c8e52945651fc94c0e
{{{#!hs
import GHC.Generics (Generic(..))
import qualified GHC.Generics as Gen
data D_Int32
data C_Int32
instance Gen.Datatype D_Int32 where
datatypeName _ = ""Int32""
moduleName _ = ""GHC.Int32""
-- packageName _ = ""base""
instance Gen.Constructor C_Int32 where
conName _ = """" -- JPM: I'm not sure this is the right implementation...
instance Generic Int32 where
type Rep Int32 = Gen.D1 D_Int32 (Gen.C1 C_Int32 (Gen.S1 Gen.NoSelector (Gen.Rec0 Int32)))
from x = Gen.M1 (Gen.M1 (Gen.M1 (Gen.K1 x)))
to (Gen.M1 (Gen.M1 (Gen.M1 (Gen.K1 x)))) = x
}}}
However, as GHC.Generics is a moving target, and changes over the compiler versions, I'd rather not have to." andreas.abel
5071 40 dagitj@…, daniel@… GHCi crashes on large alloca/allocaBytes requests Compiler 7.0.3 ⊥ new normal 2015-07-01T17:40:23Z "GHCi, and ghc, seems to exit (crash?) on certain types of memory allocation exceptions.
The FFI addendum says that the allocation functions should be able to return null:
http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-230005
Section 5.8 says this:
> If any of the allocation functions fails, a value of Ptr.nullPtr is produced. If free or reallocBytes is applied to a memory area that has been allocated with alloca or allocaBytes, the behaviour is undefined. Any further access to memory areas allocated with alloca or allocaBytes, after the computation that was passed to the allocation function has terminated, leads to undefined behaviour. Any further access to the memory area referenced by a pointer passed to realloc, reallocBytes, or free entails undefined behaviour.
In practice, code examples and documentation appear to rely on `alloca` '''NOT''' returning a `nullPtr`:
* http://en.wikibooks.org/wiki/Haskell/FFI
* http://www.haskell.org/haskellwiki/HSFFIG/Examples
* http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html
I reported this on the libraries list, and offered a documentation tweak, and I was asked to create a ticket:
http://www.haskell.org/pipermail/libraries/2011-March/016117.html
That email has details about the testing I did at the time to see the crashing behavior in ghci. I was using ghc 7.0.2 on 64bit windows, but this also appears to affect 7.0.3 on linux. It's likely that other versions of ghc are affected.
My recommendation would be to make the exception thrown by `alloca` catchable. Possibly offering an alternative to `alloca`, say `alloca'`, that can produce a `nullPtr` instead of using exceptions. I would advice against changing the existing `alloca` function to produce `nullPtr` as that could make a lot of existing code unsafe.
For example, it would be nice if the following printed ""exception"", instead of exiting:
{{{
$ ulimit -d 100000 -m 1000000 -v 100000
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
$ ./Alloca
Alloca: out of memory (requested 2148532224 bytes)
$ cat Alloca.hs
import Foreign
import Foreign.Marshal
import Foreign.Marshal.Alloc
import GHC.Exception
import System.IO.Error
main :: IO ()
main = do
(allocaBytes maxBound compare)
`catch` (\_ -> print ""exception"")
where
compare p = print ((nullPtr :: Ptr Int) == p)
}}}" guest
4836 84 dagitj@…, jmg@…, trevor@…, bjp@… literate markdown not handled correctly by unlit Compiler 7.0.1 7.12.1 new low 2014-12-23T13:33:45Z "This simple program in literate haskell, using markdown in the comments gives unlit problems:
{{{
### Ok so lets try this again.
### A page that loads and compiles:
> myfact 0 = 1
> myfact n = n * n-1
Lets see if it works!
}}}
If I run unlit and collect the output I can see where it went wrong:
{{{
$ ~/lib/ghc-7.0.1/unlit Main.lhs Main.lpp
$ cat Main.lpp
### Ok so lets try this again.
### A page that loads and compiles:
myfact 0 = 1
myfact n = n * n-1
}}}
When I look through the source code of unlit.c I think the place to check for this would be here:
{{{
if ( c == '#' ) {
if ( ignore_shebang ) {
c1 = egetc(istream);
if ( c1 == '!' ) {
while (c=egetc(istream), !isLineTerm(c)) ;
return SHEBANG;
}
myputc(c, ostream);
c=c1;
}
if ( leavecpp ) {
myputc(c, ostream);
while (c=egetc(istream), !isLineTerm(c))
myputc(c,ostream);
myputc('\n',ostream);
return HASH;
}
}
}}}
It seems that cabal has a similar unlit function:
http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.10.0.0/src/Distribution-Simple-PreProcess-Unlit.html#unlit
I haven't tested it but, I think the cabal version would handle this case correctly (or be easier to fix than a C program from 1990). Would it be possible/wise/feasible to extract the cabal version and make it a permanent replacement for the current unlit.c code?" guest
3676 82 daniel.is.fischer@…, me@…, core-libraries-committee@… realToFrac doesn't sanely convert between floating types Core Libraries 6.12.1 ⊥ ekmett new normal 2015-02-22T12:10:51Z "As far as I can tell, the only way to convert between floating types in Haskell is to use realToFrac. Unfortunately, this function does some insane mangling of values when converting. Some examples:
{{{
realToFrac (0/0 :: Double) :: Double
--> -Infinity
realToFrac (-1/0 :: Float) :: Double
--> -3.402823669209385e38
realToFrac (-0 :: Double) :: CDouble
--> 0.0
}}}
The last item illustrates an important point: it is impossible to convert a value from Double to CDouble without potentially changing it. This makes it difficult or impossible to use the FFI to call any functions with floating point parameters/return values.
Using a combination of unsafeCoerce (to shoehorn Double values in/out of CDoubles) and some functions written in C (to perform float<=>double), I was able to work around these problems, but that hardly seems like a nice solution." draconx
2269 32 daniel.is.fischer@…, dterei Word type to Double or Float conversions are slower than Int conversions Compiler 6.8.2 7.12.1 dons@… new lowest 2014-12-23T13:33:22Z "We have int2Double# and int2Float# primitives, but not equivalent ones for Word
types. We may need word2Double# too, for Words* to be fully first-class performance-wise.
This means we have to do extra tests in the Num instances for Word types
to implement 'fromIntegral':
{{{
toInteger (W# x#)
| i# >=# 0# = smallInteger i#
| otherwise = wordToInteger x#
where i# = word2Int# x#
}}}
Now, for some types, we work around this:
{{{
""fromIntegral/Int->Word"" fromIntegral = \(I# x#) -> W# (int2Word# x#)
""fromIntegral/Word->Int"" fromIntegral = \(W# x#) -> I# (word2Int# x#)
""fromIntegral/Word->Word"" fromIntegral = id :: Word -> Word
}}}
and so on for other Word/Int types. And all is fine.
The problem comes up for Float and Double. For Int, we can write:
{{{
""fromIntegral/Int->Float"" fromIntegral = int2Float
""fromIntegral/Int->Double"" fromIntegral = int2Double
int2Float :: Int -> Float
int2Float (I# x) = F# (int2Float# x)
int2Double :: Int -> Double
int2Double (I# x) = D# (int2Double# x)
}}}
But we can't write these rules for Word types.
The result is a slow down on Word conversions, consider this
program:
{{{
main = print . sumU
. mapU (fromIntegral::Int->Double)
$ enumFromToU 0 100000000
}}}
When in lhs is Int, we get this nice code:
{{{
$wfold :: Double# -> Int# -> Double#
$wfold =
\ (ww_s18k :: Double#) (ww1_s18o :: Int#) ->
case ># ww1_s18o 100000000 of wild_a14T {
False ->
$wfold
(+## ww_s18k (int2Double# ww1_s18o)) (+# ww1_s18o 1);
True -> ww_s18k
}}}
But for Word types, we get:
{{{
$wfold :: Double# -> Word# -> Double#
$wfold =
\ (ww_s1gN :: Double#) (ww1_s1gR :: Word#) ->
case gtWord# ww1_s1gR __word 100000000 of wild_a1do {
False ->
case case >=# (word2Int# ww1_s1gR) 0 of wild1_a1cS {
False ->
case word2Integer# ww1_s1gR of wild11_a1d9 { (# s_a1db, d_a1dc #) ->
case {__ccall __encodeDouble Int#
-> ByteArray#
-> Int#
-> State# RealWorld
-> (# State# RealWorld, Double# #)}_a1bT
s_a1db d_a1dc 0 realWorld#
of wild12_a1bX { (# ds1_a1bZ, ds2_a1c0 #) ->
ds2_a1c0
}
};
True -> int2Double# (word2Int# ww1_s1gR)
}
of wild1_a1bM { __DEFAULT ->
$wfold
(+## ww_s1gN wild1_a1bM) (plusWord# ww1_s1gR __word 1)
};
True -> ww_s1gN
}
}}}
Which is to be expected, and the running time goes from:
{{{
$ time ./henning
5.00000000067109e17
./henning 1.53s user 0.00s system 99% cpu 1.534 total
}}}
To:
{{{
$ time ./henning
5.00000000067109e17
./henning 4.57s user 0.00s system 99% cpu 4.571 total
}}}
So not too bad, but still, principle of least surprise says Word and Int
should behave the same.
Should we have a word2Double# primop?" dons
3744 61 daniel.is.fischer@…, michal.terepeta@…, rwbarton Comparisons against minBound/maxBound not optimised for (Int|Word)(8|16|32) Compiler 6.13 7.12.1 new low 2015-07-20T04:22:44Z "{{{
foo :: Int -> Bool
foo n = n < minBound || n > maxBound
}}}
GHC retains both comparisons even though they are guaranteed to be False. This also happens for other integral types. The optimisation is fairly easy to implement for `Int` and `Word` (only requires some plumbing in !PrelRules) but it's not clear what to do about smaller integral types. For `Int64` and `Word64`, GHC doesn't even inline `minBound` and `maxBound`:
{{{
T.$wfoo :: GHC.Prim.Int64# -> GHC.Bool.Bool
T.$wfoo =
\ (ww_ss5 :: GHC.Prim.Int64#) ->
case GHC.Int.$fBoundedInt64_$cminBound
of _ { GHC.Int.I64# y#_are ->
case {__ccall hs_ltInt64 GHC.Prim.Int64#
-> GHC.Prim.Int64#
-> GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_arD
ww_ss5 y#_are GHC.Prim.realWorld#
of _ { (# _, ds3_arH #) ->
case ds3_arH of _ {
__DEFAULT -> GHC.Bool.True;
0 ->
case GHC.Int.$fBoundedInt64_$cmaxBound
of _ { GHC.Int.I64# y#1_ar4 ->
GHC.IntWord64.gtInt64# ww_ss5 y#1_ar4
}
}
}
}
T.foo :: GHC.Int.Int64 -> GHC.Bool.Bool
T.foo =
\ (w_ss3 :: GHC.Int.Int64) ->
case w_ss3 of _ { GHC.Int.I64# ww_ss5 -> T.$wfoo ww_ss5 }
}}}
" rl
4092 161 daniel.is.fischer@…, midfield@…, dterei, iridcode@…, johan.tibell@…, acfoltzer@…, me@…, mail@…, jystic@… Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# Compiler 6.12.2 7.12.1 bgamari new normal 2015-07-03T18:08:36Z "There are currently two ways to compute the ulp of double numbers with GHC :
* Calling a C function, which requires to allocate a pointer. This is way too expensive when using interval arithmetic (for instance), that compute two ULPs at each arithmetic operations.
* Programming it by hand in haskell with GHC primitive operations, which requires using unsafeCoerce# : this does not work in GHC 6.12.2.
unsafeCoerce# should work, and there should be a primitive ulp# function in GHC, operating on Doubles at least.
By the way, here is my haskell code using C for computing it :
{{{
foreign import ccall unsafe ""math.h frexp"" c_frexp::CDouble->(Ptr CInt)->IO ()
foreign import ccall unsafe ""math.h ldexp"" c_ldexp::CDouble->CInt->IO CDouble
ulp::Double->Double
ulp x=unsafePerformIO $ do
expondo
c_frexp (realToFrac x) e
peek e)
(c_ldexp 0.5 $ expon-52) >>= return.realToFrac
}}}" malosh
3713 24 dankna@…, dterei Track -dynamic/-fPIC to avoid obscure linker errors Compiler 6.10.4 7.12.1 new low 2014-12-23T13:33:45Z "Using the wrong combination of `-dynamic` and/or `-fPIC` can lead to obscure linker errors, see e.g. #3705. We should track whether an object file was compiled with `-dynamic` and `-fPIC` so that we can give better error messages before running the linker.
'''See also'''
[[TicketQuery(id=3712|)]]" simonmar
10134 7 darchon Pattern Matching Causes Infinite Type Error Compiler 7.8.4 new normal 2015-08-02T09:57:33Z "Howsagoin,
This is a report about ghci (7.8.4) with CLaSH 0.4.1
I have a collection of modules that show an odd error. I don't want to send them to the list but I can send them to the developers if they think the described behaviour is definitely an error, which I suspect it is.
When I write:
> (a,b) = expression
I get a type error about an occurs check: cannot construct infinite type: t0 ~ (t0 + 1) -1. The error message doesn't mention t0.
However, when I leave out the pattern matching on the tuple and write
> var = expression
> a = fst var
> b = snd var
where var is a fresh variable, everything is fine. This is odd, because all I did was stripping off the pattern matching.
To make sure, I also tried
> var = expression
> (a,b) = var
This also gave the same type checking error.
If there's anybody willing to have a look at this, please feel free to contact me by email. If you think I should produce a small example, also please let me know, but please note that it already took me several hours before I found that leaving out the pattern matching solved the problem:-(
TIA for your time.
Marc van Dongen
dongen@cs.ucc.ie" dongen
8354 44 dfeuer, core-libraries-committee@… Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim Core Libraries 7.6.3 ekmett new normal 2014-11-19T21:12:17Z Self-explanatory. Eq already has INLINE on (==) and (/=), and it'd be nice to have it on Ord so that SPECIALIZE pragmas on its methods in user code can fire. guest
9505 44 dfeuer, core-libraries-committee@… Bounded instance for Word (and possibly others) uses explicitly unboxed literals Core Libraries 7.8.2 ⊥ ekmett new lowest 2015-07-01T18:22:01Z There's a comment above saying GHC won't optimise. I think since 7.8 they are unboxed by default, so that comment and the explicit constructors can be removed. schyler
4301 30 dfeuer, michal.palka@… Optimisations give bad core for foldl' (flip seq) () Compiler 6.12.3 7.12.1 new low 2014-12-23T13:33:45Z "I'm not sure whether it's one freak case or a symptom of a problem that occurs more often. Compiled with optimisations, the code
{{{
foo :: [a] -> ()
foo = foldl' (flip seq) ()
}}}
produces the core
{{{
Rec {
FSeq.foo1 :: forall a_af0. [a_af0] -> (##)
GblId
[Arity 1
NoCafRefs
Str: DmdType S]
FSeq.foo1 =
\ (@ a_af0) (w_sg9 :: [a_af0]) ->
case case w_sg9 of _ {
[] -> GHC.Unit.();
: x_afz xs_afA ->
case x_afz of _ { __DEFAULT ->
case FSeq.foo1 @ a_af0 xs_afA of _ { (# #) -> GHC.Unit.() }
}
}
of _ { () ->
GHC.Prim.(##)
}
end Rec }
}}}
for the worker (ghc-6.12.3, similar core from HEAD). Due to the boxing and unboxing between (##) and (), there's a case on the recursive call, hence it produces a stack overflow on long enough lists.
The problem was reported in http://www.haskell.org/pipermail/beginners/2010-September/005287.html, my attempt at understanding it here: http://www.haskell.org/pipermail/beginners/2010-September/005293.html.
So far, I've only managed to produce it for the very special combination of foldl' (flip seq) and a single (non-bottom) value datatype; any other function to be folded or a multiple value type produce a tail-recursive two-argument worker.
Nevertheless, on the off chance that it's a symptom of a real problem, I'm reporting it." daniel.is.fischer
9388 15 dfeuer, nomeata "Narrow the scope of the notorious ""state hack""" Compiler 7.8.2 new normal 2015-02-22T13:01:51Z "The ""state hack"" has caused any number of bug reports (just search for that string), the most recent of which is #9349.
Here's an idea to make it less pervasive: (roughly) use the state hack only for top-level functions definitions.
The idea is that for nested lambdas the context should give the one-shot-ness, now that we are equipped with cardinality analysis. For example, consider the call
{{{
replicatM_ 1000 (\(s :: RealWorld#) -> blah)
}}}
The lambda is 1000-shot, not one-shot, notwithstanding the type of the binder. Moreover `replicateM_`'s strictness/cardinality signature will say just that, and GHC already knows how to propagate that information onto the `\s`.
But for top level functions like
{{{
pr :: String -> IO ()
pr x = putStrLn (reverse x)
}}}
we get Core
{{{
pr = \x. let y = reverse x in
\ (s :: State# RealWorld). putStrLn y s
}}}
and, since we can't see all the callers of `pr`, we don't know if work is lost by pushing the `reverse` call inside, to get
{{{
pr = \x. (s :: State# RealWorld). putStrLn (reverse x) s
}}}
which is much more efficient. Indeed, this might not be so good if the calls looked like
{{{
... replicateM_ 1000 (pr ""foo"")...
}}}
because then ""foo"" will be reversed 1000 times. But arguably that's what the programmer expects anyway, looking at the code; and the efficiency hit from not eta-expanding all functions like `pr` (which are very very common) is significant.
The point is the that the only ones that need hacking are the top-level guys, and maybe even the top-level ''exported'' guys.
I have not fully thought this through, let alone tried it out, but I wanted to capture the thought. It would need some careful performance testing.
Simon" simonpj
8422 8 diatchki type nats solver is too weak! Compiler (Type checker) 7.7 7.12.1 new normal 2014-12-23T13:34:10Z "I just built ghc HEAD today, and the type nat solver can't handle the attached program, which *should* be simple to check! (and while I could use unsafeCoerce to ""prove"" it correct, that defeats the purpose of having the type nat solver!)
" carter
8447 8 diatchki A combination of type-level comparison and subtraction does not work for 0 Compiler (Type checker) 7.6.3 infoneeded low 2014-11-18T21:19:12Z "The following function on type level naturals
{{{
Diff x y = If (x <=? y) (y-x) (x-y)
}}}
does not work when either x or y is 0.
https://github.com/nushio3/practice/blob/ea8a1716b1d6221ce32d77432b6de3f38e653a27/type-nats/int-bug.hs
I've tested this code on ghc 7.7.20130926 since I couldn't build the really latest ghc. I'm sorry if it is already fixed on the ghc head." nushio
9980 42 diatchki, dimitris, goldfire, gkarachalias TcS monad is too heavy Compiler 7.8.4 new normal 2015-01-13T14:04:29Z "The typechecker's constraint-solving monad, `TcS`, is simply built on top of `TcM`, but it doesn't use most of `TcM`'s facilities. That was fine while `TcS` was only called from the typechecker, but now (as part of [wiki:PatternMatchCheck fixing pattern-match overlap checking]) we invoke it from the desugarer.
It seems quite wrong to construct a vast, and unnecessary `TcM` context just to invoke `TcS`.
Better: make `TcS` into its own monad, with its own `TcSLclEnv`, built on `IOEnv` like the others.
Main objection: the plugins mechanism exposes `unsafeTcPluginTcM`, which would become unavailable. But it it used?" simonpj
10675 45 diatchki, dimitris, goldfire, jstolarek, osa1 GHC does not check the functional dependency consistency condition correctly Compiler 7.10.1 new normal 2015-07-27T07:37:57Z "Consider
{{{
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
FlexibleInstances, UndecidableInstances,
ScopedTypeVariables #-}
class C x a b | a -> b where
op :: x -> a -> b
instance C Bool [x] [x]
instance C Char x y => C Char [x] [Maybe y]
f x = op True [x]
}}}
Should these two instance declarations be accepted?
The two instances don't ''contradict'' each other, but neither do they agree as all published work on FDs says they should!
They are ''inconsistent'' in the sense of Definition 6 of the [http://research.microsoft.com/en-us/um/people/simonpj/papers/fd-chr/jfp06.pdf FDs through CHRs paper].
Sadly GHC does not currently reject these as inconsistent. As a result it'll use ''both'' instance for improvement. In the definition of `f` for example we get
{{{
C Bool [alpha] beta
}}}
where `x:alpha` and the result type of `f` is `beta`. By using both instances for improvement we get
{{{
C Bool [Maybe gamma] [Maybe gamma]
}}}
That can be solved, so we get
{{{
f :: Maybe x -> [Maybe x]
}}}
But where did that `Maybe` come from? It's really nothing to do with it.
Examples in the testsuite that exploit this loophole are
{{{
ghci/scripts ghci047
polykinds T9106
typecheck/should_compile FD4
typecheck/should_compile T7875
}}}
I'm not sure what the right thing here is.
" simonpj
8634 35 diatchki, martin.sulzmann@… "Relax functional dependency coherence check (""liberal coverage condition"")" Compiler 7.7 7.12.1 new high 2015-06-03T08:42:38Z "== Abstract ==
Hi! I'm writing a compiler, which produces Haskell code. I've discovered it is impossible to keep currently used features / logic using GHC 7.7 instead of 7.6
Below is more detailed description of the problem:
== The idea ==
I'm writing a [DSL][1], which compiles to Haskell.
Users of this language can define own immutable data structures and associated functions. By associated function I mean a function, which belongs to a data structure.
For example, user can write (in ""pythonic"" pseudocode):
{{{#!python
data Vector a:
x,y,z :: a
def method1(self, x):
return x
}}}
(which is equivalent to the following code, but shows also, that associated functions beheva like type classes with open world assumption):
{{{#!python
data Vector a:
x,y,z :: a
def Vector.method1(self, x):
return x
}}}
In this example, `method1` is a function associated with `Vector` data type, and can be used like `v.testid(5)` (where `v` is instance of `Vector` data type).
I'm translating such code to Haskell code, but I'm facing a problem, which I'm trying to solve for a long time.
== The problem ==
I'm trying to move the code from GHC 7.6 over GHC 7.7. The code works perfectly under GHC 7.6, but does not under GHC 7.7.
I want to ask you how can I fix it to make it working in the new version of the compiler?
== Example code ==
Lets see a simplified version of generated (by my compiler) Haskell code:
{{{#!haskell
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
import Data.Tuple.OneTuple
------------------------------
-- data types
------------------------------
data Vector a = Vector {x :: a, y :: a, z :: a} deriving (Show)
-- the Vector_testid is used as wrapper over a function ""testid"".
newtype Vector_testid a = Vector_testid a
------------------------------
-- sample function, which is associated to data type Vector
------------------------------
testid (v :: Vector a) x = x
------------------------------
-- problematic function (described later)
------------------------------
testx x = call (method1 x) $ OneTuple ""test""
------------------------------
-- type classes
------------------------------
-- type class used to access ""method1"" associated function
class Method1 cls m func | cls -> m, cls -> func where
method1 :: cls -> m func
-- simplified version of type class used to ""evaluate"" functions based on
-- their input. For example: passing empty tuple as first argument of `call`
-- indicates evaluating function with default arguments (in this example
-- the mechanism of getting default arguments is not available)
class Call a b where
call :: a -> b
------------------------------
-- type classes instances
------------------------------
instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_testid out where
method1 = (Vector_testid . testid)
instance (base ~ (OneTuple t1 -> t2)) => Call (Vector_testid base) (OneTuple t1 -> t2) where
call (Vector_testid val) = val
------------------------------
-- example usage
------------------------------
main = do
let v = Vector (1::Int) (2::Int) (3::Int)
-- following lines equals to a pseudocode of ` v.method1 ""test"" `
-- OneTuple is used to indicate, that we are passing single element.
-- In case of more or less elements, ordinary tuples would be used.
print $ call (method1 v) $ OneTuple ""test""
print $ testx v
}}}
The code compiles and works fine with GHC 7.6. When I'm trying to compile it with GHC 7.7, I'm getting following error:
{{{
debug.hs:61:10:
Illegal instance declaration for
‛Method1 (Vector a) Vector_testid out’
The liberal coverage condition fails in class ‛Method1’
for functional dependency: ‛cls -> func’
Reason: lhs type ‛Vector a’ does not determine rhs type ‛out’
In the instance declaration for
‛Method1 (Vector a) Vector_testid out’
}}}
The error is caused by new rules of checking what functional dependencies can do, namely `liberal coverage condition` (as far as I know, this is `coverage condition` relaxed by using `-XUndecidableInstances`)
== Some attemps to fix the problem ==
I was trying to overcome this problem by changing the definition of `Method1` to:
{{{#!haskell
class Method1 cls m func | cls -> m where
method1 :: cls -> m func
}}}
Which resolves the problem with functional dependencies, but then the line:
{{{#!haskell
testx x = call (method1 x) $ OneTuple ""test""
}}}
is not allowed anymore, causing a compile error (in both 7.6 and 7.7 versions):
{{{
Could not deduce (Method1 cls m func0)
arising from the ambiguity check for ‛testx’
from the context (Method1 cls m func,
Call (m func) (OneTuple [Char] -> s))
bound by the inferred type for ‛testx’:
(Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) =>
cls -> s
at debug.hs:50:1-44
The type variable ‛func0’ is ambiguous
When checking that ‛testx’
has the inferred type ‛forall cls (m :: * -> *) func s.
(Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) =>
cls -> s’
Probable cause: the inferred type is ambiguous
}}}
It is also impossible to solve this issue using type families (as far as I know). If we replace `Method1` type class and instances with following code (or simmilar):
{{{#!haskell
class Method1 cls m | cls -> m where
type Func cls
method1 :: cls -> m (Func cls)
instance Method1 (Vector a) Vector_testid where
type Func (Vector a) = (t1->t1)
method1 = (Vector_testid . testid)
}}}
We would get obvious error `Not in scope: type variable ‛t1’`, because type families does not allow to use types, which does not appear on LHS of type expression.
== The final question ==
How can I make this idea work under GHC 7.7? I know the new `liberal coverage condition` allows GHC devs make some progress with type checking, but it should somehow be doable to port idea working in GHC 7.6 over never compiler version.
(without forcing user of my DSL to introduce any further types - everything so far, like type class instances, I'm genarating using Template Haskell)
Maybe is there a way to indroduce an extension, which will disable liberal coverage condition in such situations?
There is also a StackOverflow discussion available, here: http://stackoverflow.com/questions/20778588/liberal-coverage-condition-introduced-in-ghc-7-7-breaks-code-valid-in-ghc-7-6
[1]: http://en.wikipedia.org/wiki/Domain-specific_language" danilo2
9113 22 dimitris@… Template Haskell should warn about non-exhaustive pattern matches Template Haskell 7.8.2 new normal 2014-05-15T21:23:00Z "When using Typed Template Haskell, There are no warings for non-exhaustive patterns inside the quote.
{{{
{-# LANGUAGE TemplateHaskell #-}
module Foo where
import Language.Haskell.TH.Lib
foo :: Maybe Int -> TExpQ Bool
foo x = [||case x of
Nothing -> False||]
}}}
Instead the warnings appear where the code is spliced.
{{{
{-# LANGUAGE TemplateHaskell #-}
module Bar where
import Foo
x = $$(foo (Just 1))
}}}" tvh
5320 22 dimitris@… check_overlap panic (7.1 regression) Compiler (Type checker) 7.1 7.12.1 simonpj new normal 2014-12-23T13:34:10Z "The attached program is rightfully rejected by GHC 7.0.4 (with {{{""Could not deduce (HMapClass f l) ...""}}}) but makes GHC HEAD panic:
{{{
$ ghc-7.3.20110713 Overlap.hs
[1 of 1] Compiling Overlap ( Overlap.hs, Overlap.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.3.20110713 for x86_64-unknown-linux):
check_overlap
main:Overlap.HDropClass{tc raS}
main:Overlap.PZero{tc raZ}
(main:Overlap.HMap{tc raN} f{tv adi} [sk] l{tv adk} [sk])
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
Both versions are built with the devel2 BuildFlavour.
" mikhail.vorozhtsov
4296 22 dimitris@… The dreaded SkolemOccurs problem Compiler 6.12.3 7.12.1 simonpj new low 2014-12-23T13:33:45Z "The ""!SkolemOccurs"" problem is a celebrated difficulty with combining (a) termination and (b) completeness, in this example:
{{{
type instance F [a] = [F a]
f :: (F [a] ~ a) => ...
}}}
Currently we err on the side of completeness, and lose termination:
{{{
Simple20.hs:9:1:
Context reduction stack overflow; size = 21
Use -fcontext-stack=N to increase stack size to N
co :: F [F (F (F (F (F (F (F (F (F (F a)))))))))]
~
F (F (F (F (F (F (F (F (F (F a)))))))))
co :: F (F (F (F (F (F (F (F (F a))))))))
~
[F (F (F (F (F (F (F (F (F (F a)))))))))]
co :: F [F (F (F (F (F (F (F (F (F a))))))))]
~
F (F (F (F (F (F (F (F (F a))))))))
co :: F (F (F (F (F (F (F (F a)))))))
~
[F (F (F (F (F (F (F (F (F a))))))))]
co :: F [F (F (F (F (F (F (F (F a)))))))]
~
F (F (F (F (F (F (F (F a)))))))
co :: F (F (F (F (F (F (F a))))))
~
[F (F (F (F (F (F (F (F a)))))))]
co :: F [F (F (F (F (F (F (F a))))))] ~ F (F (F (F (F (F (F a))))))
co :: F (F (F (F (F (F a))))) ~ [F (F (F (F (F (F (F a))))))]
co :: F [F (F (F (F (F (F a)))))] ~ F (F (F (F (F (F a)))))
co :: F (F (F (F (F a)))) ~ [F (F (F (F (F (F a)))))]
co :: F [F (F (F (F (F a))))] ~ F (F (F (F (F a))))
co :: F (F (F (F a))) ~ [F (F (F (F (F a))))]
co :: F [F (F (F (F a)))] ~ F (F (F (F a)))
co :: F (F (F a)) ~ [F (F (F (F a)))]
co :: F [F (F (F a))] ~ F (F (F a))
co :: F (F a) ~ [F (F (F a))]
co :: F [F (F a)] ~ F (F a)
co :: F a ~ [F (F a)]
co :: F [F a] ~ F a
co :: a ~ [F a]
co :: F [a] ~ a
}}}
" simonpj
8095 33 dimitris@…, jstolarek TypeFamilies painfully slow Compiler (Type checker) 7.6.3 7.12.1 new high 2015-05-31T20:32:02Z "I'm using the TypeFamilies extension to generate types that are quite large. GHC can handle these large types fine when they are created manually, but when type families get involved, GHC's performance dies.
Unlike in ticket #5321, using tail recursion does not eliminate the problem, and the order of arguments greatly affects compile time.
I've attached a file Types.hs that demonstrates the problems. This file generates another Haskell file which has the problems. It takes 3 flags. The first is the size of the type to generate, the second is which type family function to use, and the third is whether to call the type family or just use a manually generated type.
Here are my performance results:
Using non-tail recursion, I get these results. I have to increase the stack size based on the size of the type I want to generate.
{{{
$ ./Types 200 a a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=250
real 0m2.973s
$ ./Types 300 a a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=350
real 0m6.018s
$ ./Types 400 a a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=450
real 0m9.995s
$ ./Types 500 a a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=550
real 0m15.645s
}}}
Tail recursion generates much slower compile times for some reason, and I still need to adjust the stack size:
{{{
$ ./Types 200 b a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=250
real 0m16.120s
}}}
Changing the order of arguments to the recursive type family greatly changes the run times:
{{{
$ ./Types 200 c a > test.hs && time ghc test.hs > /dev/null -fcontext-stack=250
real 0m6.095s
}}}
Without the type family, I get MUCH better performance:
{{{
$ ./Types 10000 a d > test.hs && time ghc test.hs > /dev/null
real 0m2.271s
}}}" MikeIzbicki
4894 52 dimitris@…, mikhail.vorozhtsov@… Missing improvement for fun. deps. Compiler (Type checker) 7.1 ⊥ new normal 2011-05-01T09:51:29Z "The problem is illustrated by the following example:
{{{
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
class F a b | a -> b
f :: (F a b, F a c) => a -> b -> c
f _ = id
Results in the following error:
Could not deduce (b ~ c)
from the context (F a b, F a c)
bound by the type signature for f :: (F a b, F a c) => a -> b -> c
at bug.hs:6:1-8
`b' is a rigid type variable bound by
the type signature for f :: (F a b, F a c) => a -> b -> c
at bug.hs:6:1
`c' is a rigid type variable bound by
the type signature for f :: (F a b, F a c) => a -> b -> c
at bug.hs:6:1
Expected type: b -> c
Actual type: b -> b
In the expression: id
In an equation for `f': f _ = id
}}}
The issue seems to be related to Note [When improvement happens] in module TcInteract. It states that two ""givens"" do not interact for the purposes of improvement.
As far as I understand, the correct behavior should be to generate a new given equality, justified by the functional dependency on the class.
This is also related to bug #1241: in order to justify an improvement by functional dependency, we have to check that all instances are consistent with the dependency. Otherwise, the above function would turn into an ""unsafe cast"" function.
" diatchki
5927 60 dimitris@…, shane@…, tkn.akio@… "A type-level ""implies"" constraint on Constraints" Compiler (Type checker) 7.4.1 7.12.1 new normal 2014-12-23T13:34:10Z "I have a datatype:
{{{
data Exists c where Exists :: c a => a -> Exists c
}}}
I have an instance for it:
{{{
instance Show (Exists Show) where
show (Exists a) = show a
}}}
And that's alright, as far as it goes: any Exists Show can indeed itself be shown. But I want more. I want to be able to say:
{{{
instance (c `Implies` Show) => Show (Exists c) where
show (Exists a) = show a
}}}
In other words, I want to be able to say that any (Exists c) where the constraint c implies Show can be shown. For example, if Num still had a Show constraint, I wouldn't want to have to write a separate instance Show (Exists Num) to be able to show an Exists Num; I would want to be able to write a single instance (along the lines of the above) which works for both.
GHC clearly has this information: it lets me use a function of type {{{forall a. Eq a => a -> r}}} as one of type {{{forall a. Ord a => a -> r}}}, but not vice versa, so it knows that Ord implies Eq, but not vice versa. I've attached a file which demonstrates this and a couple of other examples.
What's not completely clear to me is what would be the appropriate way to be able to ask it about this. An Implies constraint to parallel the (~) constraint would work, but with what syntax? (Just straightforwardly call it Implies?) And what semantics -- what would be the kind of Implies? It's notable that in the above example its arguments aren't of type Constraint, but rather * -> Constraint, and for (* -> *) -> Constraint it could similarly work, and with MPTCs * -> * -> Constraint and (* -> *) -> (* -> *) -> Constraint and * -> (* -> *) -> Constraint and so on probably also make sense... but I have no idea how to formalize this, where the boundaries lie, and whether it makes any kind of sense. I can try to think harder about it if that would help, but hopefully the outlines of the situation are more immediately obvious to someone on the GHC team." illissius
4259 237 dimitris@…, v.dijk.bas@…, pumpkingod@…, nathanhowell@…, choener@…, shane@…, eir@…, hackage.haskell.org@…, andy.adamsmoran@…, jan.stolarek@… Relax restrictions on type family instance overlap Compiler (Type checker) 6.12.1 7.12.1 new normal 2014-12-23T13:34:10Z "The following reduced fragment of some real code is rejected, but could be accepted, by GHC:
{{{
{-# LANGUAGE TypeFamilies, EmptyDataDecls #-}
data True
type family LessEq a b :: *
type instance LessEq a a = True
type instance LessEq (f a) (f b) = LessEq a b
}}}
GHC says:
{{{
Conflicting family instance declarations:
type instance LessEq a a
-- Defined at /home/richards/.random/tf.hs:5:14-19
type instance LessEq (f a) (f b)
-- Defined at /home/richards/.random/tf.hs:6:14-19
}}}
This is entirely in line with the documentation, which requires the RHS to be structurally equivalent in the case of overlap. However, this rule is too restrictive. In the absence of -XUndecidableInstances, neither termination nor soundness would be sacrificed if the rule were relaxed to require extensional equality /after/ expanding the types as far as possible.
In particular (absent -XUndecidableInstances), such an expansion must terminate for the same reason that type families terminate in general. For soundness, suppose the resulting system is unsound, and consider the smallest type family application which has two possible distinct expanded types. We know the RHS of those types are equal after a partial expansion of only smaller (hence sound by minimality) type family applications, resulting in a contradiction.
In order to retain soundness in the presence of -XUndecidableInstances, any pair of type instances, where either instance could not be compiled without -XUndecidableInstances, would continue to use the current syntactic equality rule." lilac
3107 4 dons Over-eager GC when blocked on a signal in the non-threaded runtime Runtime System 6.10.1 7.12.1 new lowest 2014-12-23T13:33:22Z "Right now, in the non-threaded runtime, if you have the situation where all the threads are blocked on MVars, the deadlock detection / avoidance code runs a GC. This is fine, generally, but if they're blocked on MVars held by signal handlers, it has a profoundly bad effect on performance. In short, the runtime starts collection (blocking signals?), and we're stuck waiting for it to finish before handling signals. Or, if the signal doesn't come in, we sit waiting in a loop, garbage collecting.
It would be nice if the runtime either didn't trigger collection if signal handlers are in place, or, at the very least, held off on doing so for a nontrivial period of time." awick
2224 15 dons@… -fhpc inteferes/prevents rewrite rules from firing Code Coverage 6.8.2 7.12.1 andy@… new lowest 2015-03-04T17:22:14Z "Use case:
I'm writing tests for rewrite rules, and using HPC to determine if rules were fired (and their code exercised). HPC is quite cool here, since it lets us see which rules fired, without needing to explicitly export functions to test.
However, -fhpc seems to prevent many rules from firing (likely due to ticks getting in the way?)
For example:
{{{
import qualified Data.ByteString.Char8 as C
main = print (C.pack ""literal"")
}}}
When compiled normally, triggers a nice rewrite rule:
{{{
$ ghc -O2 A.hs -ddump-rule-firings -c
Rule fired: unpack
Rule fired: Class op show
Rule fired: unpack-list
Rule fired: ByteString packChars/packAddress
}}}
Now with -fhpc:
{{{
$ ghc -O2 A.hs -ddump-rule-firings A.hs -c -fhpc
Rule fired: unpack
Rule fired: Class op show
Rule fired: unpack-list
}}}
What's the best way to ensure the same code is exercised with and without -fhpc here? (I'd quite like to get this working, since rewrite rules benefit from testing.)" dons
2135 15 dons@… Warn if functions are exported whose types cannot be written Compiler 6.8.2 7.12.1 new lowest 2014-12-23T13:33:22Z "It should be possible to warn if a function is exported from a module whose type is hidden, and thus the function's type can't be written down directly by the user.
With the proliferation in type level programming in Haskell (and its use in libraries), situations
can arise where functions are exported from a module which can be used, but whose type cannote be written, but where the type is complex enough that it really is required to write it down for the code to compile. This happened recently in the takusen library.
A warning for this situation would help authors of libraries avoid this situation.
" dons
2289 206 dons@…, johan.tibell@…, michal.terepeta@…, tkn.akio@…, jwlato@…, alpmestan@…, hackage.haskell.org@…, jan.stolarek@…, mail@… Needless reboxing of values when returning from a tight loop Compiler 6.8.2 7.12.1 new lowest 2014-12-23T13:33:22Z "GHC wants to box up strict values when returning from tight inner loops, even when they're
immediately taken apart. This leads to redundant instructions in the bodies of tight loops,
and more code.
It affects, in particular, loops that result from fusion, which need to be tight, but often return multiple values via unlifted pairs.
Consider this program:
{{{
{-# OPTIONS -fexcess-precision #-}
{-# LANGUAGE TypeOperators #-}
import System.Environment
import Text.Printf
import Data.Array.Vector
mean :: UArr Double -> Double
mean arr = s / fromIntegral l
where
s :*: l = foldlU k (0 :*: 0) arr :: (Double :*: Int)
k (s :*: n) x = s+x :*: n+1
main = do
[d] Int#
-> Double#
-> (# Double, Int #)
$s$wfold_s1rB =
\ (sc_s1rr :: Double#)
(sc1_s1rs :: Int#)
(sc2_s1rt :: Double#) ->
case >## sc_s1rr y_a1pr of wild4_X1no {
False ->
$s$wfold_s1rB
(+## sc_s1rr 1.0)
(+# sc1_s1rs 1)
(+## sc2_s1rt sc_s1rr);
True -> (# D# sc2_s1rt, I# sc1_s1rs #)
};
} in
case $s$wfold_s1rB 2.0 1 1.0 of ww_s1qg { (# ww1_s1qi, ww2_s1qj #) ->
case ww1_s1qi of wild4_a1mC { D# x_a1mE ->
case ww2_s1qj of wild5_aP6 { I# x1_aP8 ->
case /## x_a1mE (int2Double# x1_aP8)
of wild21_a1mK { __DEFAULT ->
D# wild21_a1mK
}}}
But note, what's this?
{{{
True -> (# D# sc2_s1rt, I# sc1_s1rs #)
};
} in
case $s$wfold_s1rB 2.0 1 1.0 of ww_s1qg { (# ww1_s1qi, ww2_s1qj #) ->
case ww1_s1qi of wild4_a1mC { D# x_a1mE ->
case ww2_s1qj of wild5_aP6 { I# x1_aP8 ->
case /## x_a1mE (int2Double# x1_aP8)
}}}
The return values of what was a strict pair are boxed, placed in an unboxed tuple,
and then immediately unboxed and the division takes place.
Ok, let's isolate this. Here, the boxed return, from the inner loop:
{{{
mean_s19V :: Double#
-> Int#
-> Double#
-> (# Double, Int #)
mean_s19V =
\ (ds1_dD3 :: Double#)
(ds2_dD4 :: Int#)
(ds3_dD5 :: Double#) ->
case >## ds1_dD3 d#_aoG of wild4_Xw {
False ->
mean_s19V
(+## ds1_dD3 1.0)
(+# ds2_dD4 1)
(+## ds3_dD5 ds1_dD3);
True -> (# D# ds3_dD5, I# ds2_dD4 #)
};
} in
case mean_s19V 2.0 1 1.0 of wild4_Xr { (# ds1_dCV, ds2_dCW #) ->
case ds1_dCV of wild5_Xv { D# x_aoR ->
case ds2_dCW of wild6_Xy { I# y_aoS ->
case /## x_aoR (int2Double# y_aoS) of wild7_XB { __DEFAULT ->
D# wild7_XB
}}}
And the inner loop and exit:
{{{
s1bd_info:
-- what's this stuff?
leaq 32(%r12), %rax
cmpq %r15, %rax
movq %rax, %r12
ja .L17
-- ok, to business:
ucomisd 5(%rbx), %xmm5
ja .L19
movapd %xmm6, %xmm0
leaq -32(%rax), %r12
incq %rsi
addsd %xmm5, %xmm0
addsd .LC1(%rip), %xmm5
movapd %xmm0, %xmm6
jmp s1bd_info
.L19:
movq %rsi, -16(%rax)
movq $base_GHCziBase_Izh_con_info, -24(%rax)
movq $base_GHCziFloat_Dzh_con_info, -8(%rax)
movsd %xmm6, (%rax)
leaq -7(%rax), %rbx
leaq -23(%rax), %rsi
jmp *(%rbp)
}}}
Now, I can avoid the reboxing manually:
{{{
mean_s19R :: Double#
-> Int#
-> Double#
-> (# Double#, Int# #)
mean_s19R =
\ (ds1_dCZ :: Double#)
(ds2_dD0 :: Int#)
(ds3_dD1 :: Double#) ->
case >## ds1_dCZ d#_aoG of wild4_Xw {
False ->
mean_s19R
(+## ds1_dCZ 1.0)
(+# ds2_dD0 1)
(+## ds3_dD1 ds1_dCZ);
True -> (# ds3_dD1, ds2_dD0 #)
};
} in
case mean_s19R 2.0 1 1.0 of wild4_Xr { (# x_aoR, y_aoS #) ->
case /## x_aoR (int2Double# y_aoS) of wild5_Xv { __DEFAULT ->
D# wild5_Xv
}}}
And we get:
{{{
s1b9_info:
-- hey , our junk is gone!
ucomisd 5(%rbx), %xmm5
ja .L17
movapd %xmm6, %xmm0
incq %rsi
addsd %xmm5, %xmm0
addsd .LC1(%rip), %xmm5
movapd %xmm0, %xmm6
jmp s1b9_info
-- cool, that was it, let's go home:
.L17:
movapd %xmm6, %xmm5
movq %rsi, %rbx
jmp *(%rbp)
}}}
Which is a much better result. The loop is tighter.
What can be done here?" dons
427 47 dons@…, rturk@…, rrnewton Random.StdGen slowness Core Libraries ⊥ ekmett new normal 2014-10-07T05:50:46Z "{{{
Two (performance) problems in one:
{-# OPTIONS -fffi #-}
module Main (main) where
import Control.Monad
import Random
foreign import ccall unsafe ""random"" _crandom :: IO Int
randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = do
n SingI ('Frac a b) where
sing = SFrac (fromSing (sing :: Sing a)) (fromSing (sing :: Sing b))
instance Fractional r => SingE (Kind :: Frac) r where
fromSing (SFrac a b) = fromIntegral a/fromIntegral b
type (/) a b = 'Frac a b
}}}
" MikeIzbicki
8581 25 douglas.mcclean@… Add support for explicitly-bidirectional pattern synonyms Compiler 7.12.1 new normal 2015-04-06T08:45:16Z "Some patterns cannot, by themselves, be turned over into an expression, so they have to be defined as unidirectional. Maybe the most trivial example would be
{{{
pattern P -> _
}}}
Sometimes, however, it would be desirable to give an explicit way of turning these pattern synonyms into expressions. The PatternSynonyms wiki page has this example:
{{{
import qualified Data.Sequence as Seq
pattern Empty -> (Seq.viewl -> Seq.EmptyL)
pattern x :< xs -> (Seq.viewl -> x Seq.:< xs)
pattern xs :> x -> (Seq.viewr -> xs Seq.:> x)
}}}
It would make a ton of sense to be able to use this cons/snoc notation as ""constructors"" for `Seq`s.
The proposed syntax for this
{{{
pattern x :< xs -> (Seq.viewl -> x Seq.:< xs) where
x :< xs = x Seq.) representation and the Invariant class to GHC.Generics Compiler (Type checker) 7.7 new low 2013-11-11T16:29:05Z "We currently disallow any use of the parameter in the domain of (->).
{{{
newtype F a = F ((a -> Int) -> Int) deriving Generic1
:4:38:
Can't make a derived instance of `Generic1 (F g)':
Constructor `F' must use the last type parameter only as the last argument of a data type, newtype, or (->)
In the data declaration for `F'
}}}
!DeriveFunctor succeeds for this F.
I'd like to add this representation type to GHC.Generics and !DeriveGeneric.
{{{
newtype (f :->: g) a = FArrow1 (f a -> g a)
}}}
We could then represent the first example above. We could also derive the more interesting Generic1 (F g).
{{{
newtype F g a = F (g a -> Int) deriving Generic1
type instance Rep1 (F g) = Rec1 g :->: Rec0 Int
instance Generic1 (F g) where
to x = F $ unRec0 . unArrow1 x . Rec1
from (F x) = FArrow1 $ Rec0 . x . unRec1
}}}
Admittedly, there's not many generic definitions impeded by not having (:->:). Contra- and in-variant types are uncommon.
I'm suggesting this feature without strong motivating examples because I think this would streamline the implementation of -XDeriveGenerics in some ways while also making it more general — assuming that we added the Invariant class to base or ghc-prim.
{{{
class Invariant t where
invmap :: (a -> b) -> (b -> a) -> t a -> t b
invmap_covariant :: Functor t => (a -> b) -> (b -> a) -> t a -> t b
invmap_covariant f _ = fmap f
instance (Invariant f,Invariant g) => Invariant (FArrow f g) where
invmap co contra (FArrow h) = FArrow $ invmap co contra . h . invmap contra co
}}}
(Of course, Invariant should be a super class of Functor. :/ )
Now we can handle quite involved examples:
{{{
newtype F g h a = F (g (h a)) deriving Generic1
instance Invariant g => Generic1 (F g h) where
to x = invmap unRec1 Rec1 $ unComp1 x
from (F x) = Comp1 $ invmap Rec1 unRec1
}}}
All of that said, I'm mostly opening this ticket so I can get feedback on difficulties I might not be anticipating and have a place to reference from the compiler source code comments." nfrisby
5296 167 dsf@…, hackage.haskell.org@…, sweirich@…, mail@…, steven.keuchel@…, hamidhasan14@…, jan.stolarek@… Add explicit type applications Compiler (Type checker) 7.0.3 7.12.1 new low 2014-12-23T13:33:45Z "This example is derived from code in my application. It works, but I can't add a signature to it. In other places it is preventing some code from compiling at all.
{{{
{-# LANGUAGE KindSignatures, MultiParamTypeClasses, RankNTypes #-}
{-# OPTIONS -Wall #-}
module Test where
class C t1 t2 m where method :: Int -> m t2
f :: forall t1 t2 (m :: * -> *). C t1 t2 m => Int -> m t2
f x = method x
}}}" dsf
5619 6 dterei Shorter qualified import statements Compiler 7.2.1 7.12.1 new normal 2014-12-23T13:34:10Z "I would like to be able to write imports like
{{{
import qualified Data.Vector as V (Vector, fromList)
import Data.Vector ((!), (//))
}}}
as a single statement, like
{{{
import qualified Data.Vector ((!), (//)) as V (Vector, fromList)
}}}
Which seems to be compatible with the current import statement." YvesPares
3379 6 dterei GHC should use the standard binary package Compiler 6.10.4 7.12.1 new normal 2014-12-23T13:34:10Z "GHC should use the standard binary package, rather than reimplementing its functionality itself. If the current binary package is slower than GHC's Binary, then we should fix that.
There's some discussion about this in #3041.
" igloo
3704 6 dterei Using -shared without -dynamic should be rejected on linux Compiler 7.12.1 new low 2014-12-23T13:33:45Z "When trying to link with ghc -shared
{{{
$ ghc -v -fPIC -shared -o TestF.so TestF.hs
}}}
it adds a bunch of arguments of the form -lHSbase-4.2.0.0 to the linker command line
{{{
*** Linker:
/usr/bin/gcc -v -o TestF.so TestF.o -shared -Wl,-Bsymbolic -Wl,-soname,TestF.so
-L/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0 -L/usr/lib/ghc-6.12.0.20091126/integer-gmp-0.2.0.0
-L/usr/lib/ghc-6.12.0.20091126/ghc-prim-0.2.0.0 -L/usr/lib/ghc-6.12.0.20091126 -lHSbase-4.2.0.0
-lHSinteger-gmp-0.2.0.0 -lgmp -lHSghc-prim-0.2.0.0 -lHSffi
}}}
Unfortunately:
{{{
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.0.20091126.so
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0_p.a
}}}
The name of the .so has been mangled to include the compiler version - presumably for ABI reasons. Obviously the bug is that name on the linker command line has not been suitably mangled to match, so the linker goes ahead and tries to use the .a library, which doesn't work at all.
{{{
/usr/bin/ld: /usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a(Base__76.o):
relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile
with -fPIC
}}}
Tested on linux/amd64, with HEAD and stable snapshot. It may work on linux/i386 due to compatibility hacks in glibc, I haven't checked; it shouldn't work on anything else." asuffield
3767 6 dterei SpecConstr for join points Compiler 6.12.1 7.12.1 new low 2014-12-23T13:33:45Z "The attached file `Spec.hs` has a case (from Roman's fusion code) where `SpecConstr` is not doing the right thing. Let's look at one of the mutually recursive loops that `SpecConstr` generates for foo:
{{{
lvl_rzY :: GHC.Types.Int
lvl_rzY = GHC.Types.I# 2147483647
lvl1_rA0 :: Data.Either.Either GHC.Types.Int GHC.Types.Int
lvl1_rA0 = Data.Either.Left @ GHC.Types.Int @ GHC.Types.Int lvl_rzY
$s$wgo_szT :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int#
$s$wgo_szT =
\ (sc_sz6 :: GHC.Prim.Int#) (sc1_sz7 :: GHC.Prim.Int#) ->
let {
$w$j_syG
:: GHC.Prim.Int#
-> Data.Either.Either GHC.Types.Int GHC.Types.Int
-> GHC.Prim.Int#
[LclId, Arity=2, Str=DmdType LS]
$w$j_syG =
\ (ww_sy6 :: GHC.Prim.Int#)
(w2_sy8 :: Data.Either.Either GHC.Types.Int GHC.Types.Int) ->
case GHC.Prim.<=# ww_sy6 0 of _ {
GHC.Bool.False -> $wgo_syE (GHC.Prim.+# sc_sz6 ww_sy6) w2_sy8;
GHC.Bool.True -> $wgo_syE sc_sz6 w2_sy8
} } in
case GHC.Prim.># sc1_sz7 0 of _ {
GHC.Bool.False -> $s$wgo1_szS sc_sz6 ipv_swo;
GHC.Bool.True ->
case sc1_sz7 of wild1_awb {
__DEFAULT ->
case GHC.Prim.remInt# wild1_awb 2 of _ {
__DEFAULT -> $s$wgo_szT sc_sz6 (GHC.Prim.-# wild1_awb 1);
0 ->
case w1_syr of _ { GHC.Types.I# ww_sy6 ->
$w$j_syG
ww_sy6
(Data.Either.Left
@ GHC.Types.Int
@ GHC.Types.Int
(GHC.Types.I# (GHC.Prim.-# wild1_awb 1)))
}
};
(-2147483648) ->
case w1_syr of _ { GHC.Types.I# ww_sy6 ->
$w$j_syG ww_sy6 lvl1_rA0
}
}
};
}}}
Note that the join point has an argument of type `(Either Int Int)` but it is always called with `(Left (I# ))`. This means that the recursive call in the join point is always of the form `($wgo_syE (Left (I# )))` and we have a specialisation for that. However the join point itself doesn't scrutinse its argument, and that means that GHC ignores the potential specialisation.
Simon
" simonpj
3712 6 dterei Implement -dynamic-lib option Compiler 6.12.1 RC1 7.12.1 new low 2014-12-23T13:33:45Z "The proposal is to add a new option `-dynamic-lib`, to be used when building a shared library. It would be both a compile-time and a link-time option, and could be used with `--make` to build a complete shared library in one go. It would avoid the pitfalls caused by there being combinations of `-dynamic` and `-fPIC` don't do what the user expects.
Specifically, `-dynanmic-lib` would imply `-dyanamic`, `-fPIC` where necessary, and `-shared` when linking.
See #3705 for more discussion.
" simonmar
5140 6 dterei Fix LLVM backend for PowerPC Compiler (LLVM) 7.1 7.12.1 erikd new low 2014-12-23T13:33:45Z "LLVM backend does not work for PowerPC.
From bug #5131 davidt says the order of business is:
{{{
a) Get unregistered working.
b) Get registered without TABLES_NEXT_TO_CODE.
c) Get TABLES_NEXT_TO_CODE working.
d) Ask David where to go from there.
}}}
Actually there is now a guide of sorts [wiki:Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting here]." erikd
1176 6 dterei Infinite loop when printing error message Compiler 6.6 ⊥ thorkilnaur new low 2013-01-21T16:41:45Z "I am trying to compile a file that has a known compile error. Ghc gets into an infinite loop trying to output the error message.
Here's the session (captured using EMACS shell):
{{{
pberry@Dal:~/bridge_ghc_bug$ uname -a
Linux Dal 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux
pberry@Dal:~/bridge_ghc_bug$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
pberry@Dal:~/bridge_ghc_bug$ ghc -v --make main.hs
Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6
Using package config file: /usr/lib/ghc-6.6/package.conf
wired-in package base mapped to base-2.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.0
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: main.hs
Stable obj: []
Stable BCO: []
compile: input file main.hs
Created temporary directory: /tmp/ghc5182_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( main.hs, main.o )
*** Parser:
*** Renamer/typechecker:
main.hs:30:12:
No instance for (Show Rank)
arising from use of `show' at main.hs:30:12-19
Possible fix: add an instance declaration for (Show Rank)
In the first argument of `(~?=)', namely `show Ten'
In the expression: (show Ten) ~?= ""T""
In the second argument of `($)', namely
`[(show Two) ~?= ""2"", (show Three) ~?= ""3"", (show Four) ~?= ""4"",
(show Five) ~?= ""5"", (show Six) ~?= ""6"", (show Seven) ~?= ""7"",
(show Eight) ~?= ""8"", (show Nine) ~?= ""9"", (show Ten) ~?= ""T"",
}}}
At this point ghc goes into an (apparently) infinite loop outputting spaces. When I interrupt it using Ctrl-C, it says:
{{{
*** Deleting temp files:
Deleting: /tmp/ghc5182_0/ghc5182_0.s
Warning: deleting non-existent /tmp/ghc5182_0/ghc5182_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc5182_0
}}}
Here's the file main.hs:
{{{
import System
import Test.HUnit
import Control.Monad
import Data.List
data Card = Card Rank Suit
data Suit = Clubs | Diamonds | Hearts | Spades
deriving (Enum, Eq)
data Rank = Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten | Jack | Queen | King | Ace
deriving (Enum, Ord, Eq)
type Hand = [Card]
hand :: String -> Hand
hand = undefined
main = undefined
allTests = test $
[show Two ~?= ""2""
,show Three ~?= ""3""
,show Four ~?= ""4""
,show Five ~?= ""5""
,show Six ~?= ""6""
,show Seven ~?= ""7""
,show Eight ~?= ""8""
,show Nine ~?= ""9""
,show Ten ~?= ""T""
,hand ""AK76543/32/AK2/3"" ~?= exampleHand
]
where exampleHand = []
}}}" Paul_Berry@…
2459 6 dterei "can't link haskell without ""main"" function, or -no-hs-main broken on windows?" Driver 6.8.2 7.12.1 new lowest 2014-12-23T13:33:22Z "can't link haskell without ""main"" function, or -no-hs-main broken on windows?
The issue arose when trying to compile wxHaskell examples with a !WinMain entry point in
the executable rather than the standard ""main"" function, thereby stopping a new console
window being created when the application starts up, i.e. creating a ""windows"" application.
luckily (by chance, I think) the desired objective can be achieved without any change to the haskell
code as follows, with the support that gcc already provides for a !WinMain entry point,
utilising the wxHaskell example:
{{{
> ghc -o HelloWorl.o -fglasgow-exts -c HelloWorld.hs
> ghc -optl-mwindows -o HelloWorld.exe HelloWorld.o -package wxcore
}}}
OK, so what is the issue ? We what if we want to define our own !WinMain or utilise the
!WinMain or other entry point provided by another object file or code. According to the
ghc documentation the way it could be achieved would be, with this example ...
!MyHelloWorld.hs ..
{{{
> module Hello where
>
> foreign export ccall ""runHsMain"" runMain :: IO ()
>
> runMain = do
> putStrLn ""Hello World""
}}}
and mymain.c
{{{
#include ""HsFFI.h""
extern void __stginit_Hello ( void );
extern void runHsMain();
int main(int argc, char* argv[])
{
hs_init(&argc, &argv);
hs_add_root(__stginit_Hello);
runHsMain();
hs_exit();
return 0;
}
}}}
{{{
> ghc -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc -o hello.exe mymain.c MyHelloWorld.o MyHelloWorld_stub.o
> hello.exe
Hello World
}}}
all works fine, but dosn't ghc documentation say, the -no-hs-main option should be used ? OK so use it
{{{
> ghc -no-hs-main -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc -no-hs-main -o hello.exe mymain.c MyHelloWorld.o MyHelloWorld_stub.o
> hello.exe
Hello World
}}}
OK, works both with and without -no-hs-main, strange?
but how about if we want to define our own !WinMain or dllMain etc (i.e. no main at all)
winmain.c:
{{{
#include
#include ""HsFFI.h""
extern void __stginit_Hello ( void );
extern void runHsMain();
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpszCmdLine, int nCmdShow)
{
hs_init(0, 0);
hs_add_root(__stginit_Hello);
hs_exit();
return 0;
}
}}}
you can use the above haskell hello example or the wxHaskell !HelloWorld example
but with edits to main/module name as per !MyHelloWorld, call it !MyHelloWorldW.
But the above Haskell suffices as a test case, and is used in the
following.
linking with winmain, we get this error:
{{{
>ghc -no-hs-main -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to `
__stginit_ZCMain'
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to
`ZCMain_main_closure'
collect2: ld returned 1 exit status
}}}
it appears ghc does something like this (normal operation, for a standard haskell main)
* create bootstrapping that initialises the ghc runtime and adds the root !__stginit_ZCMain, and runs the haskell main
* create a ""c"" main that calls/executes the bootstrapping code
* the executables entry point will be set by default to the ""c"" ""main"" procedure
it seems that linking the haskell object with an object that already contains a main symbol will:
* suppress the creation of bootstrapping code
* executable entry point still set to the default (""main"")
this behaviour is exhibitted regardless of -no-hs-main option
When the haskell objects are linked with other objects and even though -no-hs-main option is
specified it appears that ghc:
* creates bootstrapping that initialises the ghc runtime and adds the root !__stginit_ZCMain, and runs the haskell main
* creates a main that calls/executes the bootstrapping code
* executable entry point still set to the default (""main"")
i.e. the same behaviour as for ""normal"" execution, this behaviour appears wrong, the behaviour should be:
* suppress the creation of bootstrapping code (initialisation of haskell
should be the responsibility of the external code, per guidlines)
* executable entry point still set to default
i.e., as in the above example hs_add_root initialises the root module (!__stginit_Hello)
and there is no requirement for an !__stginit_ZCMain.
you can get the above example to compile and link with ...
{{{
>ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
>ghc -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}
but if this is the wxHaskell !HelloWorld example, you would see that the it still starts up as a console
application and not a !WinMain (windows) application.
the effect of using th -main-is option is to insert a ""!___stginit_ZCMain"" symbol into the !HelloWorld.o
object. A ""c"" ""main"" will be created, initialising haskell and invoking the haskell main Hell.runMain.
The entry point of the executable will be this ""main"", i.e. regard,
[link with ldl-mwindows to set entry to win32,see what happens]
{{{
> ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}
the above will compile and run but, will not invoke the winmain, rather it will invoke the
automatically generated ""main"".
the following
{{{
> ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc -optl-mwindows -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
>winhello
}}}
will invoke the !WinMain routine as a windows application, (in this example a popup will be displayed
reporting an error ""hPutChar invalid arg bad file descriptor"", as it should), ignoring the haskell
supplied main/init.
BUT you shouldn't have to compile the haskell module with -main-is ... in order to get the overall exe to link , i.e. the following should work
{{{
>ghc -no-hs-main -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
>ghc -optl-mwindows -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}
but we get ...
{{{
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to `
__stginit_ZCMain'
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to
`ZCMain_main_closure'
collect2: ld returned 1 exit status
}}}
what should be:
* no-hs-main option should suppress the requirement for a !___stginit_ZCMain symbol, this should enable
the linking of, and specification of an arbitrary entry point into the executable external to the
haskell code.
i.e. the last example should work.
the -optl-mwindows on the ghc command line we can flip the .exe entry point for the executable to a windows
entry point, gcc seems to handle it as follows: if the above -mwindows option is given then the entry point
of the executable is set to !WinMainCRTStartup, which in turn calls the !WinMain function (if present) or
the supplied main, it also sets the subsystem to windows." jvl
2710 6 dterei -main-is flag in {-# OPTIONS #-} pragma not fully supported Compiler 6.8.3 7.12.1 infoneeded lowest 2015-04-02T19:09:59Z "The `-main-is` flag is dynamic an may therefore be placed inside the `{-# OPTIONS #-}` pragma. Version 6.8.3 of ''runghc'' respects this flag (that is, ''runghc'' works as expected), but this cannot be said of ''ghc''.
=== Example file ''T.hs'' ===
{{{
{-# OPTIONS -main-is T.main #-}
module T where
main :: IO ()
main = putStrLn ""Hello world""
}}}
=== Example execution ===
{{{
$ ghc --make -o t T.hs
[1 of 1] Compiling T ( T.hs, T.o )
Warning: output was redirected with -o, but no output will be generated
because there is no Main module.
}}}
=== Additional notes ===
This bug is related to ticket #1312, but the difference is that ticket #1312 only addressed ''runghc'', not ''ghc''." Stephan202
2460 6 dterei provide -mwindows option like gcc Compiler 6.8.2 7.12.1 new lowest 2014-12-23T13:33:22Z "provide a command line option -mwindows (aka main windows) to compile and link the code as a windows executable (i.e. WinMain). This is mearly a matter of passing through the option to gcc and would be trivial to implement. see #2459 for full discussion.
Why Bother ?
To enahnce ""User Friendliness"" and encourage gui users on win32 aka wxHaskell and Gtk2Hs users to produce application with ""Native"" look and feel." jvl
5615 41 dterei, carter.schonwald@…, tibbe ghc produces poor code for `div` with constant powers of 2. Compiler 7.4.1-rc1 7.12.1 daniel.is.fischer new normal 2014-12-23T13:34:10Z "The code for Int {{{(div x c)}}} where {{{c}}} is a constant of the form 2^n^ should be implemented with an arithmetic right shift, currently it's a call to a function. This optimization should be done for all signed types.
" Lennart
1371 37 dterei, hackage.haskell.org@… Add -O3 Compiler 6.6.1 ⊥ new normal 2014-01-12T22:58:10Z "It has been suggested that we should have an -O3 that trades off code size for speed. Things that we could do include bumping the threshold for some optimisations (inlining, SpecConstr, LiberateCase), and perhaps inlining some operations in the back-end.
Of course we should measure the effect of various settings on nofib/nobench and pick a good combination." simonmar
5641 32 dterei, mail@… The -L flag should not exist Profiling 7.2.1 7.12.1 new normal 2014-12-23T13:34:10Z Why does the -L flag exist? The .hp file should contain untruncated strings, and any truncation of the names should be done in hp2ps. augustss
1409 661 dterei, pho@…, alfonso.acosta@…, mnislaih@…, lazycat.manatee@…, alexander.dunlap@…, id@…, lennart@…, ben.franksen@…, nr@…, ndmitchell@…, asr, explicitcall@…, kolmodin@…, lambda-belka@…, analytic@…, tora@…, sveina@…, ganesh, illissius@…, hackage.haskell.org@…, skilpat@…, leon.p.smith@…, nathanhowell@…, singpolyma@…, hvr@…, ghc@…, roma@…, zaretskysa@…, eir@…, william.knop.nospam@… Allow recursively dependent modules transparently (without .hs-boot or anything) Compiler 6.10.2 ⊥ new normal 2015-07-24T04:48:28Z "Essentially, compile strongly-connected sets of modules like single modules are compiled (they have to have the same default and monomorphism-restriction, so it is like compiling one module, after the module/import fixpoint and name resolution are done).
This can increase the amount of recompilation necessary compared to using .hs-boot files, so it is probably desirable to still allow those. Of course, manually keeping .hs-boot files and {-#SOURCE#-} pragmas around (and synchronized with the real code) is a nuisance (though informative if one cares about minimizing the amount of recursion). I suspect that there can be situations where one level of export-subsets via .hs-boot files is not sufficient... (which would be one reason it wouldn't be easy to ""just"" treat a subset of each .hs file as its .hs-boot).
When not using --make mode, ghc would have to find the minimal module cycles somehow, and put just one "".hi-boots"" or "".his"", and .o I think, file somewhere (next to an arbitrary one of the modules I guess) in order that the compilation isn't repeated pointlessly for each module. And deal with which compiler flags are used. Maybe better not to allow it without --make.
In --make mode, such hackery should not be needed. This might also help deal with (work around?) such existing bugs with recursive modules and --make: #930 , #1072 , #1133 . The modules having different OPTIONS_GHC or LANGUAGE pragmas might still be tricky or impossible to accept, depending which ones they are and how much implementation effort it's worth investing in allowing that. (Although, class instances being overlappable might be advantageous to have implemented a per-class not per-module specification anyway, for example, so pragmas that affect less than the whole module could be added more easily.)" Isaac Dupree
10074 32 dterei, scpmw, simonmar, bgamari Implement the 'Improved LLVM Backend' proposal Compiler (LLVM) 7.12.1 thoughtpolice new high 2015-05-19T06:26:32Z "This is a meta ticket designed to reflect the current implementation status of the 'Improved LLVM Backend' proposal, documented here:
https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend" thoughtpolice
8974 16 dterei, simonmar 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults Compiler (LLVM) 7.9 7.12.1 infoneeded high 2015-08-02T12:28:32Z "{{{
-- test.hs
import System.Mem (performMajorGC)
main = performMajorGC >> putStrLn ""Done""
}}}
built with `ghc -pgmlo opt -pgmlc llc -fllvm --make test.hs` segfaults both for LLVM 3.4 and 3.5svn (taken from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64).
32-bit ghc-7.9.20140404+llvm produces good executable.
Adding `ArchX86_64` `OSMinGW32` case to `moduleLayout` in `compiler/llvmGen/LlvmCodeGen/Ppr.hs` improves things slightly (some code segfaulting without it starts to work) but still does not cure the code above.
Also I've found the Cmm produced for LLVM CG differs from that produced for NCG." awson
2725 23 dterei, simonmar, erikd Remove Hack in compiler/nativeGen/X86/CodeGen.hs Compiler (NCG) 6.11 7.12.1 thoughtpolice new low 2015-03-19T21:30:46Z "Remove the hack around Line 3914 labeled with:
{{{
-- HACK: On x86_64 binutils<2.17 is only able to generate PC32
-- relocations, hence we only get 32-bit offsets in the jump
-- table. As these offsets are always negative we need to properly
-- sign extend them to 64-bit. This hack should be removed in
-- conjunction with the hack in PprMach.hs/pprDataItem once
-- binutils 2.17 is standard.
}}}
This bug is intended for house keeping." clemens
3753 19 dtrebbien@… Make ghci's -l option consistent with GNU ld's -l option GHCi 6.12.1 7.12.1 new low 2014-12-23T13:33:45Z "Currently, ghci accepts -l options of the format -lxyz. On Linux, this is treated as a request for libxyz.so. The GNU ld -l option is more flexible. It accepts either -lxyz or -l xyz. Also, it accepts -l:filename or -l :filename. When this form is used, the filename is not modified by prepending ""lib"" and appending "".so"". I request that GNU ld's -l forms be accepted by ghci." hgolden
5266 49 dtrebbien@…, bernalex, hvr, thoughtpolice Licensing requirements and copyright notices None 7.12.1 new low 2014-12-23T13:33:45Z "I'm not sure where or how to bring this up, but I figured I would inform you that complying with the licensing requirements to distribute executables programmed in Haskell (using GHC) seems to be tiresome.
I have a personal project written in Haskell and Lua, and I recently tried to make sure that I comply with the necessary requirements to distribute it. My result was a 1660-line copyright file (http://www.houeland.com/kol/docs/copyright), which I believe is excessive.
This mostly stems from the use of BSD-style licenses for libraries, which require copyright notices to be reproduced for redistributions in binary form.
Many of them are based on code from the GHC project + the Haskell 98 Report + the Haskell Foreign Function Interface specification. I think it would be nice if at least those parts could clearly be distributed using only one reproduction of the GHC license (including allowing derived binary forms to not include the restrictions against claiming to be definitions of the Haskell 98 Language / Foreign Function Interface). Currently the GHC-based libraries have licenses that say they're derived from GHC and include the GHC license notice. The libraries are listed as BSD3 in cabal files, but it's not clear to me that the statement actually covers licensing for the entirety of the library (developments after the split), and whether all GHC-based libraries can currently be distributed using a single copyright notice.
Generally, many of the other available Haskell libraries also seem to use BSD-style licenses, which can be a hassle to comply with for binary redistributions, mostly when dependencies also use separate BSD-style licenses that must be included. Having a 'default' license in the Haskell community that's similar to Boost or zlib instead of BSD3 might be preferable for the many smaller libraries available. Many of the libraries actually have different licenses (but similar ones such as MIT, or people modifying parts of their license file) while being listed as BSD3 in cabal files.
I don't know exactly what you can do about this, but an easier licensing landscape for binary redistributions would certainly be nice. (And possibly tools for automatically listing licensing restrictions and producing copyright notices accurately.)
" houeland
9192 6 duncan Add sameByteArray# Compiler 7.8.2 new normal 2014-11-15T12:50:13Z We have `sameMutableByteArray#` so we ought to have `sameByteArray#` as well, allowing for cheap equality checks. tibbe
10064 6 duncan "Add support for ""foo""## literals to MagicHash" Compiler 7.8.4 new normal 2015-03-06T01:24:21Z "I'm working on a high-performance library for building up buffers of data. Appending ByteStrings works pretty well, but, for bytestring literals, it's faster to avoid the CAF (and it's associated tag check + indirect jump) entirely and append a zero-terminate MagicHash string literal via Addr#.
Then I discovered that it's 30% faster if you can avoid the strlen with an explicit length. See this benchmark: https://github.com/chadaustin/buffer-builder/blob/ac662962d6d3c21f206ab8e8121323b9f18677fa/bench/Bench.hs#L42
That API is not very pleasant, of course. :)
Thus, here is a feature request:
It would be great if ""foo""## produced (# Int#, Addr# #), where the Int# is the length of the buffer in bytes.
The compiler could enforce that the literal only contains 8-bit values.
" chadaustin
9133 6 duncan Improve parser error reporting in `ghc-pkg` ghc-pkg 7.8.2 7.12.1 new normal 2014-12-23T13:34:10Z "Here's what I was confronted recently due to a broken sandbox environment:
{{{
$ cabal info parsec
cabal: ghc-pkg: Data.Binary.Get.runGet at position 9583: demandInput: not enough bytes
}}}
The main problem is that this message is not very helpful (other than telling that `ghc-pkg` wasn't able to do something). Duncan told me, that the recent `binary` API now provides better facilities for error reporting. That could be used to improve the UI of `ghc-pkg` when reporting errors." hvr
4442 6 duncan Add unaligned version of indexWordArray# Compiler 7.1 7.12.1 ekmett new low 2014-12-23T13:33:45Z "`indexWordArray#` takes an offset in whole words, making it impossible to do unaligned reads on platforms that support such reads. This has performance implications for some programs e.g. implementations of !MurmurHash.
I propose we add versions of `indexWord*Array` that take byte offsets. The user is responsible for only using those on platforms that support them and the implementation is free to crash if they're used elsewhere.
" tibbe
9820 20 ecrockett0@… Apparently inconsistent behaviour in the presence of OverlappingInstances Compiler (Type checker) 7.8.3 new normal 2014-11-25T03:13:16Z "This report is inspired by http://stackoverflow.com/questions/27051640/strange-behavior-when-adding-constraint-to-instance
I'm not sure if it is a bug, but it certainly feels strange and inconsistent to me, so I'd like to get some clarification.
Here's a self-contained example of the behaviour:
{{{#!hs
{-# LANGUAGE FlexibleInstances, OverlappingInstances #-}
module Overlap where
class C a where
foo :: a -> a
instance C a where
foo = id
instance C Int where
foo = (+1)
-- Note that this one does not mention class C anywhere:
class D a where
bar :: a -> a
instance D a where
bar = foo -- this works and picks the 'C a' instance always
-- The following does not compile without IncoherentInstances:
{-
baz :: a -> a
baz = foo
-}
}}}
I'm surprised that the definitions of `bar` and `baz` are treated differently. Shouldn't they either both require `IncoherentInstances`, or both work?" kosmikus
9123 105 ecrockett0@…, ekmett@…, dima@…, douglas.mcclean@…, sweirich@… Need for higher kinded roles Compiler 7.8.2 7.12.1 goldfire new normal 2014-12-17T09:03:37Z "This [http://www.haskell.org/pipermail/ghc-devs/2014-May/004964.html thread] on ghc-devs identifies a real shortcoming of the new roles system. Here's a compact example, from the thread
{{{
class C m where
ret :: a -> m a
bind :: m a -> (a -> m b) -> m b
join :: m (m a) -> m a
newtype T m a = MkT (m a) deriving( C )
}}}
The `deriving(C)` is accepted without `join` in the class, but rejected when `join` is added.
{{{
T9123.hs:10:37:
Could not coerce from `m (m a)' to `m (T m a)'
because `m (m a)'
and `m (T m a)'
are different types.
arising from the coercion of the method `join'
from type `forall a. m (m a) -> m a'
to type `forall a. T m (T m a) -> T m a'
}}}
Note that the AMP proposal adds `join` to class `Monad`!
In one way it is rightly rejected: it really would be unsound to derive an instance for `C (T K)` where `K`'s argument had nominal (but not representational) role. But we have no way to limit the type constructors at which `T` can be used.
This deficiency is noted in the [http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ Safe Coercions paper], but this seems to be the first occasion on which it has bitten us badly.
Edward [http://www.haskell.org/pipermail/ghc-devs/2014-May/004974.html made a suggestion] on the thread." simonpj
9112 72 ecrockett0@…, hackage.haskell.org@…, remi.turk@… support for deriving Vector/MVector instances Compiler 7.8.2 new normal 2014-11-10T22:06:48Z "Since ghc-7.8, the following is no longer possible:
{{{
-- simplified example taken from the vector package
class MVectorClass (v :: * -> * -> *) a where
basicLength :: v s a -> Int
data family MVector s a
data instance MVector s Int -- implementation not important
newtype Age = Age Int deriving (MVectorClass MVector) -- rejected
}}}
Following from discussion in #8177, to enable this ghc would need to support data families with representational matching, such that `MVector s Int` and `MVector s Age` are representationally equal.
This has broken some code that previously worked, however as there are some workarounds I'm not sure how important it is." jwlato
9468 28 edsko, simonmar, mail@… Internal error: resurrectThreads: thread blocked in a strange way: 10 Runtime System 7.8.3 simonmar new normal 2014-08-19T12:09:48Z "When running this example program:
https://gist.github.com/nh2/0c68650b78b692e5f827#file-forkprocess-problem-hs
I get the error:
{{{
% ghc --make -O forkProcess-problem.hs -threaded && ./forkProcess-problem +RTS -N8
[1 of 1] Compiling Main ( forkProcess-problem.hs, forkProcess-problem.o )
Linking forkProcess-problem ...
forkProcess-problem: internal error: resurrectThreads: thread blocked in a strange way: 10
(GHC version 7.8.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
Also happens for GHC 7.6.3. My machines are Ubuntu 12.04 and 14.04." nh2
9470 44 edsko, simonmar, mail@…, snoyberg, ppud forkProcess breaks in multiple ways with GHC 7.6 Runtime System 7.8.3 simonmar new normal 2014-08-19T13:29:37Z "When I run this program using `forkProcess`
https://gist.github.com/nh2/0c68650b78b692e5f827#file-forkprocess-problem-hs
in GHC 7.6.3 on Ubuntu 12.04 and 14.04 I get at 4 different issues. Three of them (1-3) crash the program, and happen only on some startups, the fourth one is the part for which I originally wrote this test case.
1. A segfault shortly after startup (probably in the GC)
2. {{{internal error: resurrectThreads: thread blocked in a strange way: 10}}} at startup
3. A glibc {{{corrupted double-linked list}}} shortly after startup
4. The {{{running, killing by SIGTERM}}} case inside my program
Now come the details for each of them:
1. I managed to get a gdb trace of it (https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-69468-3-linux-segfault-gdb-txt) and also a trace with the {{{-debug}}} runtime (https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-6-3-linux-debug-segfault-gdb-txt). They suggest that the segfault is in {{{evacuate()}}}, and the {{{-debug}}} one says it's in the {{{LOOKS_LIKE_CLOSURE_PTR}}} part.
2. This is the same as my newly reported #9468 and I have no clue what that's about. Output: https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-6-3-linux-threaded-resurrectthreads-txt
3. This one happens very rarely; might be related to 1? Output: https://gist.github.com/nh2/0c68650b78b692e5f827#file-error-ghc-7-6-3-linux-glibc-txt
4. The problem here is the {{{Nothing}}} case: The child process didn't answer from the pipe, and that although it is still running, so it really should have answered. It seems that for every 20th fork or so, the child process just hangs.
All files, error outputs and IRC logs are also collected in this gist: https://gist.github.com/nh2/0c68650b78b692e5f827
For getting issues (1-3), you have to run them multiple times in order to reproduce; if they appear, they will appear within the first second after startup. Which of the issue appears is dependent on how many {{{_FORKS}}} you set (with a high number like the default 80, you mostly get issue 2; set down to 8 to make the other ones more probably) and with how many {{{+RTS -N}}} threads you run.
2 and 4 are definitely present in 7.8.3 as well.
For 1 and 3, it would be great if you could tell me whether these are known issues and are known to be fixed in 7.8." nh2
9974 17 eir@… Allow more general structural recursion without UndecidableInstances Compiler (Type checker) 7.11 new normal 2015-01-12T16:15:52Z "I bet this is a duplicate, but I couldn't find it.
A simple example from the `HList` package:
{{{#!hs
type family HRevApp (l1 :: [k]) (l2 :: [k]) :: [k]
type instance HRevApp '[] l = l
type instance HRevApp (e ': l) l' = HRevApp l (e ': l')
}}}
GHC 7.8.3 and 7.11 both complain about the second instance if `UndecidableInstances` is turned off, because the application is no smaller than the index head. Moreover, the same error occurs when the type family is closed. However, GHC already knows how to separate term-level definitions into recursive groups; applying this same analysis to the type family above would reveal that `HRevApp` is structurally recursive, and therefore decidable. It is key, in this case, that the instance for `[]` is visible from the instance declaration for `e ': l`, so such an analysis could only be done in module dependency order for open type families.
Side note: there is a (nasty) workaround available for the problem in this case:
{{{#!hs
type family HRevApp' (l1 :: [k]) (l1' :: [k]) (l2 :: [k]) :: [k]
type instance HRevApp' t '[] l = l
type instance HRevApp' (e ': l) (e' ': l') l'' = HRevApp' l l' (e ': l'')
type HRevApp l1 l2 = HRevApp' l1 l1 l2
}}}" dfeuer
7961 98 eir@…, adam.gundry@…, jan.stolarek@…, william.knop.nospam@… Remove restrictions on promoting GADT's Compiler 7.6.3 new normal 2015-04-06T01:13:28Z "(Also allow the promotion of data types whose kind is not (* -> ... -> *))
I have been using -XDataKinds lately to explore the sorts of dependently typed programming that are currently possible in GHC. I am particularly interested in DSL's and embedding other languages' type systems into Haskell so that GHC can help verify the correctness of the program fragments I construct for those languages. From my point of view as an end-user, the restrictions on what data get promoted is inconsistent and oftentimes annoying to deal with. There are two related issues on my end:
1. The restriction that a data type cannot have a kind mentioning a promoted kind means that the way I stratify my type machinery impacts whether or not GHC will promote everything as I would like.
2. The inability to use promoted GADT's forces me to encode relationships between my type building blocks in trickier ways, and sometimes I am simply unable to come up with an alternative.
I have found that these issues get in my way as a programmer of modest skill. Oftentimes I will explore a particular design but be forced to abandon it because my ""natural"" line of reasoning runs into GHC's restrictions. With sufficient cleverness you can do quite a lot of impressive stuff with the current system, but I am often not sufficiently clever nor am I equipped to determine when something is outright ''impossible''.
Lifting these restriction, from ''my'' point of view, would simplify the machinery a great deal and allow me to do type-level programming that is currently out of my reach. It would make the kind extensions more uniform and more complete to us end-users. #6024 would complete them in another way." danharaj
7870 159 eir@…, byorgey@…, ozgurakgun@…, rendel@…, ghc@…, emax@…, snoyberg, gridaphobe Compilatio​n errors break the complexity encapsulat​ion on DSLs, impairs success in industry Compiler (Type checker) 7.7 new normal 2015-05-24T02:40:52Z "From the paper ""Scripting the Type Inference Process"" -Bastiaan Heeren Jurriaan Hage S. Doaitse Swierstra:
... Combinator languages are a means of deﬁning domain speciﬁc languages embedded within an existing programming language, using the abstraction facilities present in the latter. However, since the domain speciﬁc extensions are mapped to constructs present in the underlying language, all type errors are reported in terms of the host language, and not in terms of concepts from the combinator library. In addition, the developer of a combinator library may be aware of various mistakes which users of the library can make, something which he can explain in the documentation for the library, but which he cannot make part of the library itself.
...As a result, the beginning programmer is likely to be discouraged from pro-gramming in a functional language, and may see the rejection of programs as a nuisance instead of a blessing. The experienced user might not look at the messages at all.
Definitively this is probably the biggest barrier for the acceptance of Haskell on Industry. We need to start with something not as sophisticated as the Helium paper ""Scripting the Type Inference Process"", but maybe a partial implementation of the techniques mentioned, so that the development can be enhanced in the future.
Maybe some kind of library that permits postprocessing of GHC errors and/or the identification of points in the current type checker where some kind of rules can be defined by the programmer can be the first step. " agocorona
3699 18 eir@… Wildcards in type functions Compiler (Type checker) 6.10.4 7.12.1 msosn new low 2015-07-22T12:46:15Z "I would like to be able to use wildcards in type synonym family instances, so that I can write:
{{{
type instance ErrorAlg (f :>: _) e a = ErrorAlg f e a
}}}
" MartijnVanSteenbergen
4139 49 eir@…, hackage.haskell.org@… Spurious non-exhaustive pattern match warnings are given using GADTs Compiler 7.4.1 new normal 2014-06-30T13:37:54Z "When using slightly complicated GADTs, GHC gives me erroneous non-exhaustive pattern match warnings. I have attached an example. I have observed this behavior in the four versions of ghc that I tried (6.10.4, and 6.12.{1,2,3}).
" blarsen
1612 8 eivuokko GHC_PACKAGE_PATH and $topdir bug Package system 6.6.1 ⊥ new lowest 2015-06-10T20:39:20Z "In ghc-pkg $topdir is replaced according to path to package that is considered global - the last on in GHC_PACKAGE_PATH (if it doesn't contain trailing ';')
Following shows how (head, 1.1.7) Cabal's haddock-command gets broken.
{{{
C:\Users\eivuokko>copy con temp.conf
[]
^Z
1 file(s) copied.
C:\Users\eivuokko>set GHC_PACKAGE_PATH=c:\tools\ghc\ghc-6.6.1\package.conf;c:\Us
ers\eivuokko\temp.conf
C:\Users\eivuokko>ghc-pkg field base haddock-interfaces
haddock-interfaces: c:\Users\eivuokko\html\libraries\base\base.haddock
C:\Users\eivuokko>set GHC_PACKAGE_PATH=
C:\Users\eivuokko>ghc-pkg field base haddock-interfaces
haddock-interfaces: C:/tools/ghc/ghc-6.6.1\html\libraries\base\base.haddock
C:\Users\eivuokko>
}}}" eivuokko
9370 6 ekmett unfolding info as seen when building a module depends on flags in a previously-compiled module Compiler 7.8.3 7.12.1 new high 2015-07-24T23:26:12Z "I've observed a blowup in ghc memory usage when invoked with parallel build flags.
to reproduce
{{{
cabal get xmlhtml-0.2.3.2
cabal install xmlhtml-0.2.3.2 --only-dependencies
cd xmlhtml-0.2.3.2
}}}
then
{{{
cabal clean ; cabal configure --ghc-options=""-j4"" ; time cabal build -j4 -v3
}}}
will take quite a while and use > 1gb of ram
whereas
{{{
cabal clean ; cabal configure --ghc-options=""-j1 ; time cabal build -j1 -v3
}}}
will use < 150mb of ram.
Based upon the output of cabal build -j4 -v3, it looks like the parallel build is spending a lottt more time in the simplifier passes. I'm not sure what changes between the parallel and sequential builds to change this. I'll try to dig into this more in a few days, but recording this problem now before i forget. (though of course any insights would be appreciated)" carter
9675 6 ekmett Unreasonable memory usage on large data structures Compiler 7.8.3 new normal 2015-07-03T19:30:10Z "I have attached a file that, when compiled, results in very large amount of memory usage by GHC.
The memory used is in the order of tens of gigabytes, but I've not been able to successfully compile the file due to lack of physical memory.
This is on Debian GNU/Linux (Jessie) using Haskell Platform 2014.2.0.0 with GHC 7.8.3." Polarina
3134 6 ekmett encodeFloat . decodeFloat Prelude 6.10.1 ⊥ new normal 2015-07-17T16:27:37Z "> (0.0/0.0)
NaN
> (uncurry encodeFloat . decodeFloat) (0.0/0.0)
-Infinity
It seems reasonable to expect NaN here." roland
9479 6 ekmett Report required constraints when reporting the type of a hole Compiler (Type checker) 7.8.3 new low 2015-03-11T10:13:02Z "For the following code
{{{
module Test where
test :: String
test = show _h
}}}
GHC currently reports:
{{{
Found hole ‘_h’ with type: a0
Where: ‘a0’ is an ambiguous type variable
Relevant bindings include
test :: String (bound at /tmp/Test.hs:4:1)
In the first argument of ‘show’, namely ‘_h’
In the expression: show _h
In an equation for ‘test’: test = show _h
}}}
It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like:
{{{
Found hole ‘_h’ with type: a0
Where: ‘a0’ is an ambiguous type variable
Applicable constraints: Show a0
Relevant bindings include
test :: String (bound at /tmp/Test.hs:4:1)
In the first argument of ‘show’, namely ‘_h’
In the expression: show _h
In an equation for ‘test’: test = show _h
}}}
I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing." dominiquedevriese
8767 57 ekmett, hvr, dfeuer, core-libraries-committee@… Add rules involving `coerce` to the libraries Core Libraries 7.9 7.12.1 ekmett new normal 2015-07-28T09:18:33Z "With #2110 fixed, we can now add rules like
{{{
{-# RULES ""map/coerce"" [0] map coerce = coerce #-}
}}}
to the standard libraries. But probably this should happen together or after #8718." nomeata
10071 45 ekmett, thoughtpolice, simonpj, oerjan, alanz Implement deprecation-warnings for class-methods to non-method transitions Compiler 7.8.4 7.12.1 new normal 2015-06-20T05:06:14Z "See Design/MethodDeprecations for details
" hvr
8171 16 ekmett@… Extending ExtendedDefaultRules Compiler 7.6.3 new normal 2015-07-03T15:54:58Z "The current `ExtendedDefaultRules` (see [http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules manual page]) is set up in a way that largely prevents it from being used for scenarios beyond what they get used for in GHCi today.
It would be great if there was an extra class that could be included in the list of acceptable classes for Rule 3.
{{{
class Defaulting a
}}}
The proposed change would be that Rule 3 under EDR can be be relaxed to: At least one of the classes Ci is numeric, or is `Show`, `Eq`, `Ord` or `Defaulting`.
I went with `Defaulting` rather than `Default`, because `Default` is a common class in use across the ecosystem from the `data-default` package, and I wanted to avoid gratuitous fallout.
This would permit projects like Shae Erisson's `ghclive` from last year that need to use defaulting to not have to shoe-horn unnecessary `Show` constraints onto functions.
Even better would be for that class to be polykinded!
That opens up possibilities for expert users to get defaulting to fire on arguments of other kinds, which is impossible under the current EDR." ekmett
7543 16 ekmett@… Constraint synonym instances Compiler 7.6.1 7.12.1 new normal 2015-03-16T18:39:51Z "It would be great if GHC could compile:
{{{
{-# LANGUAGE ConstraintKinds #-}
type Ring = Num
instance Ring [a] where
(+) = (++)
}}}
Currently this gives an error: `(+)` is not a visible method of class `Ring`. After removing the last line, the code compiles with warnings about missing methods." monoidal
4471 97 ekmett@…, dagitj@…, simon@…, shelarcy@…, ryan.gl.scott@… Incorrect Unicode output on Windows Console Compiler 6.12.3 7.12.1 new high 2015-03-09T19:26:24Z "To reproduce,
* start a windows console
* Change the console's font to a ttf unicode font, like ""Lucida Console"".
* Type ""chcp 65001"" to set it to the UTF-8 code page.
test.hs
{{{
main = putStrLn ""∷⇒∀→←⋯⊢""
}}}
Output to the console is garbled. `runghc test.hs`:
{{{
∷⇒∀→←⋯⊢
→←⋯⊢
⋯⊢
∷⇒∀→←⋯⊢→←⋯⊢←⋯⊢⋯⊢⊢⊢⊢: hFlush: permission denied (Permission denied)
}}}
Piping works correctly. `runghc test.hs > output && type output`:
{{{
∷⇒∀→←⋯⊢
}}}
ghci fails. `ghci test.hs`
{{{
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
∷*** Exception: : hPutChar: permission denied (Permission denied)
*Main>
}}}" sankeld
9210 59 ekmett@…, dimitris@…, diatchki, dreixel """overlapping instances"" through FunctionalDependencies" Compiler (Type checker) 7.8.2 new normal 2014-06-19T07:56:20Z "This program prints `(""1"",2)`, but if you reverse the order of the two instances, it prints `(1,""2"")`.
{{{
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
-- extracted from http://lpaste.net/105656
import Control.Applicative
import Data.Functor.Identity
modify :: ((a -> Identity b) -> s -> Identity t) -> (a -> b) -> (s -> t)
modify l f s = runIdentity (l (Identity . f) s)
class Foo s t a b | a b s -> t where
foo :: Applicative f => (a -> f b) -> s -> f t
instance Foo (x, a) (y, a) x y where
foo f (a,b) = (\fa -> (fa,b)) f a
instance Foo (a, x) (a, y) x y where
foo f (a,b) = (\fb -> (a,fb)) f b
main = print $ modify foo (show :: Int -> String) (1 :: Int, 2 :: Int)
}}}
Note that the two instances involved `Foo (Int, Int) (String, Int) Int String` and `Foo (Int, Int) (Int, String) Int String` are not actually overlapping. But, they have the same `a`, `b`, and `s` fields and it seems that this makes GHC think that either one is equally valid, thanks to the fundep." rwbarton
4413 21 ekmett@…, hvr (^^) is not correct for Double and Float Core Libraries 7.1 7.12.1 tcsavage new low 2014-12-23T13:33:45Z "Consider
{{{
Prelude> 2 ^^ (-1024)
0.0
Prelude> 0.5 ^^ 1024
5.562684646268003e-309
}}}
The cause is
{{{
x ^^ n = if n >= 0 then x^n else recip (x^(negate n))
}}}
If we change it to
{{{
x ^^ n = if n >= 0 then x^n else ((recip x)^(negate n))
}}}
it'll do the right thing for Double and Float, and I don't know of any type where it would produce incorrect results.
Does it need a library proposal or can the change be made without?" daniel.is.fischer
7542 93 ekmett@…, jwlato@…, hackage.haskell.org@…, pho@…, dfeuer GHC doesn't optimize (strict) composition with id Compiler 7.6.1 7.12.1 simonpj new normal 2014-12-23T13:34:10Z "Newtype constructors and selectors have no runtime overhead, but some uses of them do. For example, given `newtype Identity a = Identity { runIdentity :: a }`, `Identity` turns into `id`, but `Identity . f` turns into `id . f`, which is distinct from `f`, because it gets eta-expanded to `\x -> f x`.
It would be nice to be able to compose a newtype constructor with a function without any overhead. The obvious thing to try is strict composition:
{{{
(#) :: (b -> c) -> (a -> b) -> a -> c
(#) f g = f `seq` g `seq` \x -> f (g x)
}}}
In theory this should get rid of the eta-expansion. In practice, the generated Core looks like this:
{{{
foo :: (a -> b) -> [a] -> [b]
foo f = map (id # f)
-- becomes
foo = \f e -> map (case f of g { __DEFAULT -> \x -> g x }) e
}}}
Different variations of `(#)`, and turning `-fpedantic-bottoms` on, don't seem to affect this. A simpler version, `foo f = map (f `seq` \x -> f x)`, generates the same sort of Core.
In one library we resorted to defining a bunch of functions of the form `identityDot :: (a -> b) -> a -> Identity b; identityDot = unsafeCoerce`. It would be better to be able to rely on GHC to do the optimization directly, if we use strict composition anyway." shachaf
3632 22 erik.flister@… lift restrictions on records with existential fields, especially in the presence of class constraints Compiler 6.10.4 7.12.1 new low 2014-12-23T13:33:45Z "the attached file demos the use of a record with an existential field with a class constraint. it shows several cases where lifting the current restrictions on accessing and updating this field would be both well-defined and useful.
here is the record definition; the dur field is existential, but constrained to be in class NoteDur.
{{{
data Note = forall x . NoteDur x => Note {
midiNum :: Int -- 0-255
, vel :: Int -- 0-255
, chan :: Int -- 0-15
, measure :: Integral a => a
, beat :: Int
, subdiv :: RealFrac a => a -- % of beat
, dur :: x
}
}}}
here is a walk through of places in the code where the current restrictions are unnecessary and intrusive:
1. lines 64-95 -- these functions wouldn't be necessary if record update syntax were enabled for both existential and non-existential fields. i know 6.12 introduces it for non-existentials, but i don't see why it isn't also possible for existential fields (even without a class constraint). lines 33-35 and 60 show how much nicer it is to use regular updater syntax in this case.
2. Line 142. The same is true for existential accessors when there is a class constraint -- there's no need to restrict this situation because the accessor can have type:
{{{
fieldName :: (SomeClass x) => Record -> x
}}}
line 142 shows a case where this would be very nice to have.
3. line 100 + 107 -- the foralls could be implicit (maybe offer an extention that would allow them to be implicit)
4. lines 134-136 compared to 138-139 show how additional factoring could be achieved if one were allowed to pattern match on the type of an existential with class constraints.
5. lines 124-127 show how it would be nice to have existential classes
6. lastly, allow curried updater functions: `(rec {field = }) 5` instead of `(\x -> (rec {field = x})) 5`" eflister
3397 27 erik.flister@…, hvr :step hangs when -fbreak-on-exception is set GHCi 7.10.1-rc2 7.2.1 new normal 2015-04-14T23:54:25Z "Stepping through code (that I can step through fine when -fbreak-on-exception is no set) hangs at the same place each time. The function I started stepping was in one module and the hang was in another (not sure if this is significant).
Ctrl+C returns to the prompt (no other output) and a further :step at that point causes a ""not at breakpoint"".
I wonder if the flag is causing something to be evaluated a second time (I understand that can cause :step to hang).
Erik first noticed the problem in Leksah, but I can reproduce it in GHCi without using Leksah to control it.
I'll try to get a minimal test case together." hamish
3645 49 erik.flister@…, michal.terepeta@… Layout and pragmas Compiler (Parser) 6.10.4 7.12.1 new low 2014-12-23T13:33:45Z "With this module:
{{{
{-# LANGUAGE DeriveDataTypeable,
FlexibleContexts
#-}
module Foo where
}}}
GHC 6.12 says:
{{{
Cannot parse LANGUAGE pragma
Expecting comma-separated list of language options,
each starting with a capital letter
E.g. {-# LANGUAGE RecordPuns, Generics #-}
}}}
but this should probably be allowed. See #3519, #3616.
" igloo
9504 5 erikd LLVM backend TBAA is too aggressive Compiler (LLVM) 7.8.3 new normal 2015-03-12T04:27:54Z "At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias#HowtoTrackTBAAinformation there is written
> It [a memory load/store] is very rarely of the form:
> {{{
> x = Sp + 8
> I64[x] = ...
> }}}
> And when it is, 'it is' (unconfirmed) always deriving a ""heap"" pointer, ""stack"" pointers are always of the in-line variety.
In fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the ""other"" type, which cannot alias any non-""other"" address.
But it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the ""top"" ""type""." rwbarton
10671 5 erikd inplace/bin/ghc-stage1 doesn't respect --with-ld override Build System 7.10.1 new normal 2015-07-26T01:12:19Z "Building ghc 7.10.1 on RHEL 5.8. I need to override the old system linker which lacks features and performance. I get stage1 built but then it forgets the override.
Configure:
./configure --prefix=/home/cavtools/opt/ghc-7.10.1 --with-ld=/home/cavtools/64/pkg/bin/gld --with-ar=/home/cavtools/64/pkg/bin/gar --with-ranlib=/home/cavtools/64/pkg/bin/granlib
settings:
[(""GCC extra via C opts"", "" -fwrapv""),
(""C compiler command"", ""/usr/bin/gcc""),
(""C compiler flags"", "" -fno-stack-protector""),
(""C compiler link flags"", """"),
(""Haskell CPP command"",""/usr/bin/gcc""),
(""Haskell CPP flags"",""-E -undef -traditional ""),
(""ld command"", ""/home/cavtools/64/pkg/bin/gld""),
(""ld flags"", """"),
(""ld supports compact unwind"", ""YES""),
(""ld supports build-id"", ""YES""),
(""ld supports filelist"", ""NO""),
(""ld is GNU ld"", ""YES""),
(""ar command"", ""/home/cavtools/64/pkg/bin/gar""),
(""ar flags"", ""q""),
(""ar supports at file"", ""YES""),
(""touch command"", ""touch""),
(""dllwrap command"", ""/bin/false""),
(""windres command"", ""/bin/false""),
(""libtool command"", ""libtool""),
(""perl command"", ""/usr/bin/perl""),
(""target os"", ""OSLinux""),
(""target arch"", ""ArchX86_64""),
(""target word size"", ""8""),
(""target has GNU nonexec stack"", ""True""),
(""target has .ident directive"", ""True""),
(""target has subsections via symbols"", ""False""),
(""Unregisterised"", ""NO""),
(""LLVM llc command"", ""llc""),
(""LLVM opt command"", ""opt"")
]
inplace/lib/settings:
[(""GCC extra via C opts"", "" -fwrapv""),
(""C compiler command"", ""/usr/bin/gcc""),
(""C compiler flags"", "" -fno-stack-protector""),
(""C compiler link flags"", """"),
(""Haskell CPP command"",""/usr/bin/gcc""),
(""Haskell CPP flags"",""-E -undef -traditional ""),
(""ld command"", ""/home/cavtools/64/pkg/bin/gld""),
(""ld flags"", """"),
(""ld supports compact unwind"", ""YES""),
(""ld supports build-id"", ""YES""),
(""ld supports filelist"", ""NO""),
(""ld is GNU ld"", ""YES""),
(""ar command"", ""/home/cavtools/64/pkg/bin/gar""),
(""ar flags"", ""q""),
(""ar supports at file"", ""YES""),
(""touch command"", ""touch""),
(""dllwrap command"", ""/bin/false""),
(""windres command"", ""/bin/false""),
(""libtool command"", ""libtool""),
(""perl command"", ""/usr/bin/perl""),
(""target os"", ""OSLinux""),
(""target arch"", ""ArchX86_64""),
(""target word size"", ""8""),
(""target has GNU nonexec stack"", ""True""),
(""target has .ident directive"", ""True""),
(""target has subsections via symbols"", ""False""),
(""Unregisterised"", ""NO""),
(""LLVM llc command"", ""llc""),
(""LLVM opt command"", ""opt"")
]
Failure looks like:
""inplace/bin/ghc-stage1"" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -H32m -O -this-package-key ghcpr_8TmvWUcS1U1IKHT0levwg3 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-key rts -this-package-key ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -c libraries/ghc-prim/./GHC/IntWord64.hs -o libraries/ghc-prim/dist-install/build/GHC/IntWord64.p_o -dyno libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o
/usr/bin/ld: unrecognized option '--build-id=none'
/usr/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status
But why are you using /usr/bin/ld? I told you not to use /usr/bin/ld!" mfox
10456 5 erikd Wrong CPP during cross-compilation Build System 7.11 jakzale new low 2015-06-20T19:11:40Z "It appears that during cross-compilation the build system uses the wrong compiler as C preprocessor.
It may cause errors by passing incompatible flags to the cross-compiler --- for example when trying to cross-compile using 32-bit clang on a 64-bit system (sample output attached below).
{{{
/Users/jakub/src/nacl_sdk/pepper_canary/toolchain/mac_pnacl/bin/pnacl-clang -E
-DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -m64 -fno-stack-protector -Wall
-Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils
-Icompiler/stage1
-isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/proce_0hwN3CTKynhHQqQkChnSdH/include'
-isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/direc_3TcTyYedch32o1zTH2MR00/include'
-isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d/include'
-isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/time_Hh2clZW6in4HpYHx5bLtb7/include'
-isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/bytes_6vj5EoliHgNHISHCVCb069/include'
-isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/base_I5BErHzyOm07EBNpKBEeUv/include'
-isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include'
-isystem'/Applications/ghc-7.10.1.app/Contents/lib/ghc-7.10.1/include'
-Wno-unknown-pragmas -MM -x c compiler/ghci/keepCAFsForGHCi.c -MF
compiler/stage1/build/.depend-v.c_asm.bit pnacl-clang: Unrecognized option: -m64
Use '--help' for more information. make[1]: ***
[compiler/stage1/build/.depend-v.c_asm] Error 255 make: *** [all] Error 2
}}}" jakzale
9308 14 erikd, bgamari nofib fannkuch-redux runs perpetually with -fllvm Compiler (LLVM) 7.8.3 new normal 2015-07-31T11:40:02Z "Running the nofib benchmarks with make -k EXTRA_HC_OPTS=-fllvm on a HEAD build of ghc configured with perf-llvm (3.4.2) results in fannkuch-redux running in an infinite loop. The benchmark runs in about 3.5s without the -fllvm
{{{
HC = /Users/xx/Projects/ghc/inplace/bin/ghc-stage2
HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2
RUNTEST_OPTS = -ghc-timing
==nofib== fannkuch-redux: time to compile Main follows...
/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 -c Main.hs -o Main.o
<>
==nofib== fannkuch-redux: size of Main.o follows...
__TEXT __DATA __OBJC others dec hex
10333 497 0 0 10830 2a4e
==nofib== fannkuch-redux: time to link fannkuch-redux follows...
<>
==nofib== fannkuch-redux: size of fannkuch-redux follows...
__TEXT __DATA __OBJC others dec hex
4075520 446464 0 4295945496 4300467480 10053ed18
==nofib== fannkuch-redux: time to run fannkuch-redux follows...
../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11;
}}}" jrp
8695 108 erkokl@…, ekmett@…, me@…, felipe.lessa@…, core-libraries-committee@… Arithmetic overflow from (minBound :: Int) `quot` (-1) Documentation 7.6.3 7.12.1 new normal 2015-07-01T17:12:51Z "According to the documentation for Data.Int, “All arithmetic is performed modulo 2!^n, where n is the number of bits in the type.”
However, this promise is broken by the following exception:
{{{
Prelude> (minBound :: Int) `quot` (-1)
*** Exception: arithmetic overflow
}}}
(This also occurs with Int8, Int16, Int32, and Int64, and likewise for `div`.)
If all arithmetic is performed modulo 2!^n, I would rather expect the above to evaluate to `minBound`, since after all `minBound * (-1) == minBound`. The fact that an exception is raised adds an unnecessary burden in pure code to ensure `quot` (or `div`) is never called with these specific arguments." rleslie
9562 6 ezyang Type families + hs-boot files = unsafeCoerce Compiler 7.8.3 ezyang new high 2015-06-11T21:57:42Z "Consider the following bundle of modules:
A.hs:
{{{#!hs
{-# LANGUAGE TypeFamilies #-}
module A where
type family F a b
}}}
B.hs-boot:
{{{#!hs
module B where
import A
oops :: F a b -> a -> b
}}}
B.hs:
{{{#!hs
{-# LANGUAGE TypeFamilies #-}
module B where
import A
import C
type instance F a b = b
oops :: F a b -> a -> b
oops = const
}}}
C.hs:
{{{#!hs
module C (oops) where
import {-# SOURCE #-} B
}}}
D.hs:
{{{#!hs
{-# LANGUAGE TypeFamilies #-}
module D where
import A
import C
type instance F a b = a
unsafeCoerce :: a -> b
unsafeCoerce x = oops x x
}}}
Main.hs:
{{{#!hs
module Main where
import D ( unsafeCoerce )
main = print $ (unsafeCoerce True :: Int)
}}}
When loading these into GHCi, we quite reasonably get a type family instance overlap error. But, separate compilation leads to disaster:
{{{
rae:01:49:47 ~/temp/bug> ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3
rae:01:49:49 ~/temp/bug> ghc -c A.hs
rae:01:49:53 ~/temp/bug> ghc -c B.hs-boot
rae:01:49:58 ~/temp/bug> ghc -c C.hs
rae:01:50:09 ~/temp/bug> ghc -c B.hs
rae:01:50:13 ~/temp/bug> ghc -c D.hs
rae:01:50:17 ~/temp/bug> ghc Main.hs -o Unsafe
[6 of 6] Compiling Main ( Main.hs, Main.o )
Linking Unsafe ...
rae:01:50:23 ~/temp/bug> ./Unsafe
2882303761534249061
}}}
Yikes!
Proposed (terrible) solution: hs-boot files '''must''' list all type instance declarations in the corresponding modules. It may also be a good idea to require all normal instance declarations in the hs-boot file as well, because this same trick can be used to introduce incoherence (I think -- haven't tested).
This bug persists even if `Main` declares that it is `Safe`.
I've attached a tarball of the files for ease of testing.
(Credit to Edward Yang and Geoff Mainland, whose discussion provoked the line of inquiry that led to this discovery.)" goldfire
10661 6 ezyang Regression: hp2ps reports `integer unexpected` on new style package keys Profiling 7.11 7.12.1 new high 2015-07-20T20:53:48Z "hp2ps reports `integer unexpected` when run on a profile file created with HEAD. The profile file contains entries such as the following:
{{{
$ grep System.Random Test.hp
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
}}}
To reproduce, first install random (there might be a simpler way, but this one is required to run `make TEST=concprog002 WAY=threaded2_hT`, which is failing at the moment):
{{{
$ cabal install random==1.1 --with-ghc=ghc-7.11.20150711 -v0
}}}
Note the package key for random starts with a number:
{{{
$ ghc-pkg --package-db=.ghc/x86_64-linux-7.11.20150711/package.conf.d/ describe random | grep key
key: 9Kgekc9yEaLHLNUuw6paWL
}}}
Then create a heap profile for the following program with `-hT`, and try to run `hp2ps` on it:
{{{
$ cat Test.hs
import System.Random
main = sequence $ replicate 1000 (randomIO :: IO Int)
$ ghc-7.11.20150711 Test.hs -rtsopts -fforce-recomp -v0
$ ./Test +RTS -hT -i0.001
$ hp2ps Test.hp
hp2ps: Test.hp, line 12: integer unexpected
}}}
Note that in the profile file the entries for libraries like `base`, `ghc-prim` and `integer-gmp` don't contain package keys (maybe the entries for random shouldn't either?):
{{{
base:Data.Dynamic.Dynamic 24
integer-gmp:GHC.Integer.Type.Jp# 16
ghc-prim:GHC.Types.: 24
}}}" thomie
10330 6 ezyang Better Template Haskell error message locations Template Haskell 7.10.1 new normal 2015-06-04T07:56:46Z "Consider this TH splice
{{{
f x = $( [| let g x = (True && 'x', x) in g True |] )
}}}
or more generally
{{{
f x = $( g [| x |])
}}}
Two problems
1. If there is a type error in the spliced-in code, there is no record of the splice in the error message:
{{{
TH.hs:5:10:
Couldn't match expected type ‘Bool’ with actual type ‘Char’
In the second argument of ‘(&&)’, namely ‘'x'’
In the expression: (True && 'x')
In the expression: ((True && 'x'), x_a2qf)
}}}
I'd like to see
{{{
TH.hs:5:10:
Couldn't match expected type ‘Bool’ with actual type ‘Char’
In the second argument of ‘(&&)’, namely ‘'x'’
In the expression: (True && 'x')
In the splice: $( [| let g x = ... in g True |] ) M a
tc_extend_local_id_env th_lvl = if read ""foo""
then th_lvl `seq` return undefined
else return undefined
thLevel :: ThStage -> Int
thLevel Comp = 0
thLevel (Splice l) = l
thLevel (Brack l) = l
-- Dull code:
type M a = IOEnv TcLclEnv a
data TcLclEnv = TcLclEnv { tcl_th_ctxt :: !ThStage }
data ThStage = Comp | Splice Int | Brack Int
getEnv :: IOEnv env env
getEnv = IOEnv (\ env -> return env)
newtype IOEnv env a = IOEnv { unIOEnv :: env -> IO a }
instance Monad (IOEnv m) where
IOEnv m >>= f = IOEnv (\ env -> do r return a)
fail = error
}}}
Compiling with
{{{
ghc -O -ddump-simpl -ddump-stg -c Q.hs
}}}
we get, in the STG,
{{{
Q.$wa =
\r srt:(0,*bitmap*) [ww_sDx w_sDO]
case
case ww_sDx of wild_sEs {
Q.Comp -> Q.lvl;
Q.Splice l_sDA -> l_sDA;
Q.Brack l_sDC -> l_sDC;
}
of
tpl_sEt
{ GHC.Base.I# ipv_sEu ->
let { sat_sDN = NO_CCS Q.TcLclEnv! [ww_sDx]; } in
let {
sat_sDL =
\u []
case ww_sDx of wild_sEv {
Q.Comp -> Q.lvl;
Q.Splice l_sDH -> l_sDH;
Q.Brack l_sDJ -> l_sDJ;
};
} in Q.tc_extend_local_id_env sat_sDL sat_sDN w_sDO;
};
}}}
GHC seems to have inlined `level`, forced it (due to the seq), but passed along a second, inlined, unevaluated copy to `tc_extend_local_id_env`. So the whole environment is retained, defeating the purpose of the seq!
If I mark `level` as `NOINLINE` then the STG looks like this:
{{{
Q.a5 =
\r srt:(0,*bitmap*) [env_sD1 eta_sDh]
case env_sD1 of tpl_sDg {
Q.TcLclEnv ipv_sD5 ->
case
case ipv_sD5 of wild_sDN {
Q.Comp -> Q.lvl;
Q.Splice l_sD8 -> l_sD8;
Q.Brack l_sDa -> l_sDa;
}
of
level_sDc
{ __DEFAULT ->
case level_sDc of tpl1_sDf {
GHC.Base.I# ipv1_sDO -> Q.tc_extend_local_id_env tpl1_sDf tpl_sDg eta_sDh;
};
};
};
}}}
which fixes the env-retained problem, although I don't understand why two cases are done.
It would be nice not to have to resort to this level of trickery, though!
" igloo
5654 21 ezyang@…, scpmw Profiling semantics bug Profiling 7.2.1 7.12.1 simonmar new low 2015-02-02T09:12:24Z "GHC doesn't quite implement the new cost-centre stack semantics correctly. e.g.
{{{
{-# NOINLINE f #-}
f :: Int -> Int
f = {-# SCC f #-} g
{-# NOINLINE g #-}
g :: Int -> Int
g x = {-# SCC g #-} x + 1
main = print (f 3)
}}}
What we want is
{{{
CAF Main 106 0 0.0 0.7 0.0 21.7
f Main 201 1 0.0 0.0 0.0 0.0
main Main 200 1 0.0 20.9 0.0 21.0
f Main 202 0 0.0 0.0 0.0 0.1
g Main 203 1 0.0 0.1 0.0 0.1
}}}
but we get
{{{
CAF Main 106 0 0.0 0.7 0.0 21.6
f Main 201 1 0.0 0.0 0.0 0.0
main Main 200 1 0.0 20.9 0.0 20.9
g Main 202 1 0.0 0.0 0.0 0.0
}}}
The original flat CC profiler used to use `IND_PERM` indirections to handle this kind of thing, but we aren't doing that now." simonmar
9429 70 facundo.dominguez, m@…, edsko, ekmett, rrnewton, GregoryCollins Alternative to type family Any Compiler 7.9 new normal 2014-08-20T14:09:51Z "In GHC HEAD, `Any` is no longer a datatype. There are good reasons for this change, one of which was explained in #9097, the original ticket, and another in #9380. Unfortunately, a casualty of this change is that it is no longer easy to generalize the [https://hackage.haskell.org/package/rank1dynamic rank1dynamic package] to rank-1 types with type variables of arbitrary kind (not just `*`). We submitted a way to do so [https://github.com/haskell-distributed/rank1dynamic/pull/6 here], that exploits the fact that `Any` has the very magical property of inhabiting *all* kinds, including closed ones.
This works for GHC 7.8, but won't work in HEAD, because we require that there exists a `Typeable` instance for `Any`, just as there are `Typeable` instances for any other type one wishes to have instances for. The reason is that now that `Any` is a type family, `Any` is no longer a legal instance head.
There are several possible solutions that I see:
* while it's clearly dangerous for the compiler to be inserting the old `Any` during typechecking from the moment that we have computation in types over closed kinds, we may still want the old `Any`, say under a different name, as a backdoor. It wouldn't be used by the compiler during type checking - only by packages such as rank1dynamic. I believe that furthermore, if we restrict the old `Any` to not inhabit closed kinds, then none of the problems cited in the above tickets arise.
* Instead of making the new `Any` a type family, keep it a datatype, but ban it from inhabiting closed kinds. I don't know if such an `Any` would be sufficient for the purposes of GHC, however.
* Hardwire a `Typeable` instance for the `Any` type family (not sure if this makes sense)." mboes
3242 89 felipe.lessa@…, jwlato@…, hvr, oerjan@…, bjorn.buckwalter@… ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) GHCi 7.4.1 7.12.1 new normal 2014-12-23T13:34:10Z "On Windows, when attempting to use Hipmunk from ghci, it produces the error:
{{{
ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
}}}
To reproduce:
{{{
cabal install Hipmunk
ghci
:m + Physics.Hipmunk
initChipmunk
}}}
Presumably this has something to do with there being no libm on Windows." jeffz1
2940 22 felix.lequen@… Do CSE after CorePrep Compiler 6.10.1 7.12.1 simonpj new lowest 2014-12-23T13:33:22Z "Common sub-expression analysis is deliberately conservative, but it's really ''too'' conservative: we are missing obvious opportunities. Consider
{{{
{-# OPTIONS_GHC -XBangPatterns -XMagicHash #-}
module Foo where
import GHC.Base
-- CorePrep evaluates (reverse xs) twice
f xs = let !v1 = reverse (reverse xs)
!v2 = filter id (reverse xs)
in (v1, v2)
-- Even CSE inside CorePrep would not get this right;
-- the strict evaluation of (reverse xs) doesn't scope
-- over the non-strict version
g xs = reverse (reverse xs) ++ filter id (reverse xs)
-- Duplicate evaluation of (x +# 1#)
h :: Int# -> ( Int, Int )
h x = ( I# (x +# 1#), I# ((x +# 1#) *# 2#) )
}}}
If you compile this you'll see that there are obvious missed CSE opportunities in `f`, `g` and `h`; but they only show up after `CorePrep`.
I guess the right thing is to CSE after `CorePrep`, but then CSE would have to maintain the `CorePrep` invariants, which isn't trivial. Something to think about.
Simon" simonpj
5429 17 fischer@… Docase notation as GHC extension Compiler 7.12.1 tomasp new normal 2014-12-23T13:34:10Z "Many monads provide additional combinators for ''parallel composition'', ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with these 3 additional combinators a '''joinad'''.
The monads that implement (some of) these three operations include:
* '''Par monad''' for parallel programming implements ''parallel composition'' (run two computations in parallel) and ''aliasing'' (start computation and access the result in multiple other computations) and can be extended to support (non-deterministic) ''choice''
* '''Parsers''' can implement ''parallel composition'' as an intersection of languages (parse the same input using multiple parsers), which is useful for encoding validation rules and ''choice'' (use the result of a first parser that succeeds).
* '''Other monads''' that can be considered include the `Orc` monad (for concurrent orchestration) and the encoding of CHP (Communicating Haskell Processes).
The proposal is to implement the a GHC extension that allows the `docase` notation for working with ''joinads''. Using the `Par` monad as an example, the following snippet implements a function `all` which tests whether a predicate holds for all leaves of a tree:
{{{
all :: (a -> Bool) -> Tree a -> Par Bool
all p (Leaf v) = return (p v)
all p (Node left right) =
docase all p left, all p right of
False, ? -> return False
?, False -> return False
allL, allR -> return (allL && allR)
}}}
The left and right sub-trees are processed in parallel (using ''parllel composition''). The special pattern `?` denotes that the corresponding computation does not have to complete in order for the clause to match. This means that the first two clauses implement short-circuiting behavior (and can match even if the other branch is still being processed).
The operations used by the desugaring are expected to have the following types:
* `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by the recent patch that re-implements ''monad comprehensions'', so we can reuse it.
* `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as `mplus` from `MonadPlus`, but we require an operation that is left-biased. One possible option is to add `MonadOr` type class as suggested in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal.
* `malias :: m a -> m (m a)`[[br]]The operation ""starts"" a computation and returns a handle for accessing the result. It has been used e.g. by the authors of the `Orc` monad. For many simpler monads, this can be implemented as monadic `return`.
===Feedback===
I would appreciate any feedback from GHC users and developers! In particular, here are some general, as well as more specific questions that I've heard in the past:
* What existing monads can implement the interface? (I believe there are quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to know about more.)
* What to do about monads that implement only some operations? Currently, the `malias` operation has default implementation. If a `docase` notation has just a single clause, then `morelse` is not required. If it has multiple clauses, each having just a single ''binding pattern'' (non `?`) then `mzip` is not required.
* The laws - the paper includes detailed discussion about laws (e.g. why `mzip` should be symmetric and why `morelse` should have left-biase). Does the community agree with the laws, or do you suggest some changes?
* Syntax seems to be a tricky question - the notation intentionally resembles `case`, but it takes a list of arguments (of type `m a1`, ..., `m an`), so it is not using ''tuple syntax''. Is there any better alternative?
* Correspondence with ''monad comprehensions'' - the `docase` notation can express parallel composition in a similar way as ''monad comprehensions''. I think this parity is a good thing. However, it allows more expressivity in one direction (by adding choice) and less in another (no group/order by comprehensions). Do you think this is a good ballance?" tomasp
4426 76 fischer@…, id@…, ghc.haskell.org@… Simplify the rules for implicit quantification Compiler 6.12.3 7.12.1 new highest 2015-01-14T07:33:38Z "This thread http://www.haskell.org/pipermail/glasgow-haskell-users/2010-October/019360.html
convinced me that GHC's rules for implicit quantification are unnecessarily complicated.
-------------
== The current spec ==
The current spec seems to be this:
* Define an ""implicit quantification point"" to be (a) the type in a type signature `f :: type` if `type` does not start with `forall`; or (b) a type of form `(context => type)`, that is not immediately enclosed by an explicit `forall`
* At each implicit quantification point 'ty', working outside in, GHC finds all the type variables a,b,c in 'ty' that are not already in scope, and transforms 'ty' to (forall a,b,c. ty).
Note that
* The argument of a constructor is not an implicit quantification point, so that
{{{
data Foo = MkFoo (a -> a)
}}}
is an error, and does not mean
{{{
data Foo = MkFoo (forall a. a->a)
}}}
* Implicit quantification points may be nested but the inner ones are effectively no-ops. Example
{{{
f :: Int -> (Eq a => a -> a) -> Int
}}}
There are two quantification points: the whole type, and the `(Eq a => ...)`. But when the outer quantification point wraps forall a around it, the inner quantification point has no free variables to quantify. So we get
{{{
f :: forall a. Int -> (Eq a => a -> a) -> Int
}}}
--------------
== The new proposal ==
The proposed new rule is this:
* Implicit quantification applies only to an entire user type signature that does not start with `forall`.
* For such signatures, find all the type variables a,b,c in the signature that are not already in scope, and prefix the signature with `forall a,b,c.`
I believe that the only observable changes in behaviour would be
* In a data type declaration
{{{
data Foo = MkFoo (Eq a => a -> a)
}}}
you'd get an error ""a is not in scope"", just as you would with
{{{
data Foo = MkFoo (a->a)
}}}
To me this seems more consistent behavour.
* Inside an ''explicit'' `forall` you would get no ''implicit'' `foralls`:
{{{
f :: forall a. (Eq b => b->b) -> a -> a
}}}
would yield ""b is not in scope"", whereas at present it behaves like
{{{
f :: forall a. (forall b. Eq b => b->b) -> a -> a
}}}" simonpj
6040 10 fox@… Adding a type signature changes heap allocation into stack allocation without changing the actual type Compiler 7.4.1 7.12.1 simonpj new normal 2014-12-23T13:34:10Z "According to Milan Straka, changing
{{{
insert :: Ord k => k -> a -> Map k a -> Map k a
insert = go
where
STRICT_1_OF_3(go)
go kx x Tip = singleton kx x
go kx x (Bin sz ky y l r) = ...
}}}
to
{{{
insert :: Ord k => k -> a -> Map k a -> Map k a
insert = go
where
go :: Ord k => k -> a -> Map k a -> Map k a
STRICT_1_OF_3(go)
go kx x Tip = singleton kx x
go kx x (Bin sz ky y l r) = ...
}}}
changes how GHC allocates the argument, from heap to stack. Here's the relevant commit: https://github.com/haskell/containers/commit/32d84ba5eb82f34dbb8a8fabf07077d848cdb408
It includes this comment:
{{{
-- [Note: Type of local 'go' function]
-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- If the local 'go' function uses an Ord class, it must be given a type
-- which mentions this Ord class. Otherwise it is not passed as an argument and
-- it is instead heap-allocated at the entry of the outer method.
}}}
I find this quite alarming. The type of `k` above is already Ord k, so the extra type signature shouldn't make a difference in my opinion.
" tibbe
10368 9 fryguybob STM test failing on Armhf/Linux Compiler 7.11 7.12.1 new normal 2015-05-13T01:24:04Z "During validation on armhf/linux, I found that test T7815 had failed.
Unfortunately, it only fails intermittently on one quad core Arm board and not at all on another quad core Arm board. If I do 10 runs of the test like:
{{{
for x in $(seq 1 10) ; do testsuite/tests/rts/T7815 50000 +RTS -N2 ; echo $? ; done
}}}
one will fail at least 4 or 5 times and ocassionally as many as 9 or 10 times.
The two boards are:
* Inforce Computing ifc6540 with a Qualcomm Snapdragon 805 CPU.
* Radxa Rock with a Rockchip RK3199 CPU.
The ifc6540 is the one that fails.
@fryguybob suggests that this is actually a bug in the STM implementation that breaks on Arm because of Arm's weaker memory consistency model." erikd
8981 42 Fuuzetsu, sol@…, conal@… ghc-pkg complains about missing haddock interface files ghc-pkg 7.8.1 7.12.1 new normal 2015-05-23T21:26:54Z "As Conal reported on the mailing list[1], `ghc-pkg check` on Mavericks allegedly returns:
{{{
bash-3.2$ ghc-pkg check
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file
Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file
Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory
}}}
It's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not.
Marking for 7.8.2. I'm looking into this soon.
[1]http://www.haskell.org/pipermail/glasgow-haskell-users/2014-April/024846.html" thoughtpolice
3081 6 ganesh Double output after Ctrl+C on Windows Runtime System 6.10.1 ⊥ new normal 2011-03-16T11:00:33Z "{{{
C:\Temp>type Test.hs
import Control.Exception
import System.Cmd
main = system ""sleep 1m"" `finally` putStrLn ""goodbye""
C:\Temp>ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1
C:\Temp>ghc --make Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test.exe ...
C:\Temp>test.exe
^Cgoodbye
goodbye
C:\Temp>
}}}
The {{{^C}}} is the consoles way of saying that Ctrl+C was pressed - i.e. I ran the program and hit Ctrl+C while the sleep was still ongoing. I can replicate this issue from the DOS prompt and from the Cygwin prompt. It does not occur from GHCi." NeilMitchell
589 36 ganesh.sittampalam@… Various poor type error messages Compiler (Type checker) 6.4.1 ⊥ new low 2010-01-02T20:23:55Z "Hello,
I read the summary of the survey and noticed you wanted feedback on
where error messages could be improved. I looked up some (simple)
examples of type errors and ran them through ghc. I do not make any
claims to be an HCI expert, just a mere mortal with an opinion.
'''Type error 1'''
Code:
{{{
1 module Test2 where
2
3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2))
4 k = fib 's'
}}}
Error message:
{{{
Test2.hs:4:
No instance for (Num Char)
arising from use of `fib' at Test2.hs:4
In the definition of `k': k = fib 's'
}}}
This isn't a bad error message in my humble opinion, it does pinpoint
that I'm doing something wrong in line 4, and that there isn't an
instance for Num Char doesn't come as a surprise. However I think it
could have been more helpful by telling me that I tried to pass a Char
to a function which expected an (Ord a, Num a) => a as its parameter.
'''Type error 2'''
Code:
{{{
1 module Test4 where
2
3 k :: Int -> Int
4 k l = 2.0*l
}}}
Error message:
{{{
Test4.hs:4:
No instance for (Fractional Int)
arising from the literal `2.0' at Test4.hs:4
In the first argument of `(*)', namely `2.0'
In the definition of `k': k l = 2.0 * l
}}}
One reason this kind of error could happen is an inexperienced user
declaring the wrong type for his function, or not knowing that 2.0
would be interpreted as a Fractional.
'''Type error 3'''
Code:
{{{
1 module Test7 where
2
3 len' xs = head (xs) + (length xs)
4 o = len' ""GH""
}}}
Error message:
{{{
Test7.hs:4:
Couldn't match `Int' against `Char'
Expected type: [Int]
Inferred type: [Char]
In the first argument of `len'', namely `""GH""'
In the definition of `o': o = len' ""GH""
}}}
I ran this through Hugs version November 2002 and got this error
message:
{{{
ERROR ""Test7.hs"":4 - Type error in application
*** Expression : len' ""GH""
*** Term : ""GH""
*** Type : String
*** Does not match : [Int]
}}}
I find the Hugs message more clear, but that might be my background.
'''Type error 4'''
Code:
{{{
1 module Test8 where
2
3 f = head 3
}}}
Error message:
{{{
Test8.hs:3:
No instance for (Num [a])
arising from the literal `3' at Test8.hs:3
Possible cause: the monomorphism restriction applied to the following:
f :: a (bound at Test8.hs:3)
Probable fix: give these definition(s) an explicit type signature
In the first argument of `head', namely `3'
In the definition of `f': f = head 3
}}}
This one I find outright scary. For ""wrong = div 3 8 + 1/2"" it gives
an error message that somewhat helps me guess the error, but the above
doesn't even come close to helping me.
/ Peter
" Peter A Jonsson [pj@…
1475 202 ganesh.sittampalam@…, alfonso.acosta@…, mjm2002@…, Deewiant, merehap, ivan.perez@…, hackage.haskell.org@…, campersander@…, silvio.frischi@… Adding imports and exports with Template Haskell Template Haskell 6.8.2 ⊥ new normal 2015-06-12T08:10:02Z "(wished for by Adrian Hey in http://www.haskell.org/pipermail/template-haskell/2007-June/000598.html)
It would be useful to be able to add module exports with TH, although I'm not sure exactly how it would be done. Perhaps something like
{{{
$( do n a -> IO (Maybe a)
timeout n x =
do put ""Race starts ...""
resV >>
Race starts ...
Blocking ...
Evaluating ...
Waiting ...
Done waiting!
<<<
If you replace 'sum (repeat 1)' by 'last (repeat 1)' the
program hangs.
}}}" simonpj
3073 15 ganesh@… Avoid reconstructing dictionaries in recursive instance methods Compiler 6.10.1 7.12.1 new lowest 2014-12-23T13:33:22Z "Ganesh writes: I have a problem in GHC 6.10 with functions in a class instance calling
other functions in the same class instance. It seems that the dictionary
is freshly constructed for this call, despite being already available.
The reason I care is that I want to memoise some expensive computations
inside the dictionary for each instance. [Obviously I also have to make
sure that the dictionary isn't constructed multiple times by external
callers, but I can make other arrangements to ensure that.]
To see the problem in action, run main from the attached code. In GHC 6.8
and before, this only executes the trace statement once. In GHC 6.10, the
trace statement executes twice, at all optimisation levels.
This seems related to #2902, but I'm a little unclear on whether it's the same problem or not.
" simonpj
10271 7 garrett Typed Template Haskell splice difficulty when resolving overloading Compiler 7.10.1 new normal 2015-04-20T15:07:56Z "J Garrett Morris describes the following surprising behaviour for typed Template Haskell
{{{
{-# LANGUAGE TemplateHaskell, FlexibleInstances #-}
module PrintfLib where
import Language.Haskell.TH
class Printf t where
printf :: String -> Q (TExp String) -> Q (TExp t)
instance Printf [Char] where
tf s t | '%' `notElem` s = [|| $$t ++ s ||]
| otherwise = fail (""Unexpected format %""
++ [c])
where (_, _:c:_) = break ('%' ==) s
instance Printf t => Printf (Char -> t) where
printf s t
| c /= 'c' = fail (""Unexpected format %"" ++ [c] ++
"" for character"")
| otherwise = [|| \c -> $$(printf s''
[|| $$t ++ s' ++ [c] ||])
||]
where (s', '%':c:s'') = break ('%' ==) s
-------------------------
{-# LANGUAGE TemplateHaskell #-}
module Printf where
import PrintfLib
f :: Char -> String
f = $$(printf ""foo %c"" [||""""||])
h :: Char -> String
h y = $$(printf ""foo %c"" [||""""||]) y
}}}
Oddly, `f` typechecks but `h` does not, even though `h` is just an eta-expanded version of `f`:
{{{
Printf.hs:9:10:
No instance for (Printf t0) arising from a use of ‘printf’
The type variable ‘t0’ is ambiguous
Note: there are several potential instances:
instance Printf t => Printf (Char -> t) -- Defined in ‘PrintfLib’
instance Printf [Char] -- Defined in ‘PrintfLib’
In the expression: printf ""foo %c"" [|| """" ||]
}}}
What is going on? Here's the deal
* To run the splice, GHC must solve any constraints that arise form the expression `(printf ""foo %c"" ...)`.
* Since `printf` is overloaded, and overloaded on its result type, the type needed by the context of the splice is what determines which instance of `Printf` is needed.
* In `f` the context needs `Char -> String`, and so the call to `printf` must have type `TExpr (Char -> String)`, so we get the constraint `Printf (Char -> String)` which we can solve.
* But in `h` the rule for application tries to ''infer'' a type for the splice. So the context for the call just says `TExp t0` for some unification variable `t0`; and that leads to the insoluble constraint.
You may say that GHC should be cleverer, and push that type signature information into the application. And perhaps it should. But you can never win. For example:
{{{
hard x = [ $$(printf ""gluk"" [|| """" ||]), undefined :: Char -> String ]
}}}
Here the RHS of `hard` is a 2-element list. Since all elements of a list have the same type, the splice must have the same type as the second element of the list, namely `Char->String`. But seeing that would mean that we'd have to typecheck right-to-left. In general GHC tries very very hard NOT to depend on traversal order. There is no way in general to ensure that we have all the information now that constraint solving may ultimately produce.
I'm not sure what to do about this.
* It seldom matters, because resolving the overloading on the splice seldom depends on the result type.
* When it does matter, you can fix it by giving a type signature to the splice itself.
But it seems unsatisfactory. Ideas welcome.
" simonpj
10327 7 garrett Devise workaround for how infinite types prevent closed type family reduction Compiler 7.10.1 new normal 2015-04-21T00:59:42Z "Suppose we have
{{{
data a :+: b
type family Inj x y where
Inj a a = True
Inj b (b :+: c) = False
}}}
When we try to reduce `Inj f (f :+: g)`, it looks like we should just use the second equation. Instead, we fail to reduce. This is because GHC is worried about the possibility of the first equation firing, in the event that `f ~ (f :+: g)`. This fact can happen only if `f` is infinitely large. On the surface, this seems impossible, but shenanigans in this area can cause `unsafeCoerce`. See #8162.
I don't see an easy way to fix this, but the fact that GHC can't cope (well) with this example tells me something is wrong. Here is one idea of how to proceed:
If we somehow ensure at reduction time that `f` is finite, we're OK. If we need finiteness in terms, we use `deepseq`. Can we do this in types? I tentatively say ""yes"".
Imagine the following type family:
{{{
type family Seq (x :: a) (y :: b) :: b
type instance Seq True y = y
type instance Seq False y = y
}}}
To reduce, say, {{{b `Seq` 5}}}, we'd need to know concretely what `b` is. We can then build `Deepseq` similarly to how `deepseq` at the term level works.
The closed type family mechanism could then detect cases like `Inj`, where the whole infinite-type thing is causing trouble. (I conjecture that detecting this is not hard, as there's a specific line in the `Unify` module that triggers in the worry-about-infinite-types case.) In the case of `Inj`, something like `Inj f (f :+: g)` would reduce to {{{f `Deepseq` False}}}. Note that the call to `Seq` wouldn't be written in the closed type family definition, but would be inserted during reduction as appropriate.
This solution is ugly. And it requires magic to define `Seq` in types (we need an instance for every type!) and weird magic in closed type family reduction. The definition of `Deepseq` might also benefit from being magical. It would be annoying to explain to users, but no more so than the current crazy story. In general, I don't like this idea much, but I do think it would work.
In any case, this ticket is mainly to serve as a placeholder for any future thoughts in this direction. It's quite annoying to have the specter of infinite types cripple otherwise-sensible closed type families." goldfire
10568 16 George, trommler Regression from 7.8.4, loading GLUT into GHCI fails on the Mac Compiler 7.10.2-rc1 7.10.3 darchon new normal 2015-07-31T13:37:18Z "{{{
$ ghci -V
The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612
$ ghci -package GLUT
GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help
: can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13
Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib
Expected in: flat namespace
in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1-4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib)
}}}
This may be related to the fix for #10322 or the underlying problem reported there. The GLUT people are aware of this. They believe it is platform scpecific, a regression from 7.8.4 and probably a ghc issue. See https://github.com/haskell-opengl/GLUT/issues/19" George
7655 30 george.colpitts@…, hvr 7.6.2 Segmentation Fault/Bus Error in large exponentation GHCi 7.8.1-rc1 7.12.1 infoneeded normal 2015-04-13T00:42:29Z "Mac OS X 10.8.2. Haskell Platform 2012.4, 64-bit. GHCI 7.4.2.
Large exponentations cause bus errors or segmentation faults.
Examples:
{{{
~/src/haskell$ ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 12345678901234567890 ^ 12345
Bus error: 10
~/src/haskell$ ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 2384729837498237^23455
Segmentation fault: 11
}}}" Doug310
8736 40 george.colpitts@…, lukexi@… GHCi doesn't load .dyn_o files appropriately Compiler 7.8.1-rc2 7.12.1 thoughtpolice new high 2015-05-04T07:21:20Z "Now that GHCi generally defaults to dynamic linking, it handles dynamic object files. But it doesn't implicitly handle the `-dynamic-too` case appropriately:
{{{
$ cat Test.hs
main = return ()
$ ./inplace/bin/ghc-stage2 -dynamic Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./inplace/bin/ghc-stage2 --interactive Test
GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Ok, modules loaded: Main.
Prelude Main> ^D
$ ./inplace/bin/ghc-stage2 -dynamic-too Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./inplace/bin/ghc-stage2 --interactive Test
GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( Test.hs, interpreted )
Ok, modules loaded: Main.
*Main>
}}}
Also:
{{{
$ ./inplace/bin/ghc-stage2 --interactive Test.dyn_o
GHCi, version 7.8.20140130: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Warning: ignoring unrecognised input `Test.dyn_o'
Prelude>
}}}
but it does handle the `.o` case. This should all be fixed and merged to 7.8 since it'll likely be very annoying." thoughtpolice
5728 59 george.karachalias@…, tom.schrijvers@… Warnings from -fwarn-incomplete-record-updates even with all constructors matched Compiler 7.4.1 ⊥ new normal 2014-11-27T14:24:33Z "I don't think that the following should be considered an incomplete record update, since I match on the other constructor before the record update:
{{{
data Foo = None | Bar { baz :: Int }
quux :: Foo -> Foo
quux None = None
quux x = x { baz = 2 }
main :: IO ()
main = return ()
}}}
But it still throws a warning:
{{{
$ ghc -fwarn-incomplete-record-updates test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
test.hs:6:10:
Warning: Pattern match(es) are non-exhaustive
In a record-update construct: Patterns not matched: None
Linking test ...
}}}
" mjo
8238 16 ggreif@… Implement unloading of shared libraries Runtime System 7.7 7.12.1 new normal 2014-12-23T13:34:10Z "In #8039 we added support for unloading static objects from the runtime linker, with the GC detecting when there are no references left. We could add this functionality for shared libraries too, using `dl_iterate_phdr`.
@heisenbug's comment from #8039 with the relevant pointers:
[http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries Eli Bendersky's article] suggests to use the [http://linux.die.net/man/3/dl_iterate_phdr dl_iterate_phdr] function for finding information about loaded libraries. Seems to be linux only. There is a [http://stackoverflow.com/questions/10009043/dl-iterate-phdr-equivalent-on-mac workaround on OSX], though, on !StackOverflow.
And here is how Böhm-Demers-Weiser's GC implement a [https://github.com/ivmai/bdwgc/blob/master/dyn_load.c#L451 callback function for dl_iterate_phdr]." simonmar
7275 25 ghc@… Give more detailed information about PINNED data in a heap profile Compiler 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "This is particularly useful when tracking down memory leaks due to retaining (sub)bytestrings which themselves retain larger bytestrings. At the moment, all the profile tells us is that this memory is ""PINNED"" but it doesn't give us any info at all as to where the memory was allocated." edsko
2280 25 ghc@… randomR too slow Core Libraries 6.8.2 ⊥ ekmett new normal 2014-10-07T05:50:46Z "randomR is considerably slower than implementing it manually. Maybe I have not re-implemented it precisely, maybe it is just not inlined.
{{{
module Main (main) where
import System.Random (RandomGen(..), randomR, )
import qualified Data.ByteString as B
newtype KnuthRandomGen = KnuthRandomGen Int
{-# INLINE knuthFactor #-}
knuthFactor :: Int
knuthFactor = 40692
{-# INLINE knuthModulus #-}
knuthModulus :: Int
knuthModulus = 2^(31::Int)-249
-- we have to split the 32 bit integer in order to avoid overflow on multiplication
knuthSplit :: Int
knuthSplit = succ $ div knuthModulus knuthFactor
knuthSplitRem :: Int
knuthSplitRem = knuthSplit * knuthFactor - knuthModulus
instance RandomGen KnuthRandomGen where
{-# INLINE next #-}
next (KnuthRandomGen s) =
-- efficient computation of @mod (s*knuthFactor) knuthModulus@ without Integer
let (sHigh, sLow) = divMod s knuthSplit
in (s, KnuthRandomGen $ flip mod knuthModulus $
knuthSplitRem*sHigh + knuthFactor*sLow)
{-# INLINE split #-}
split (KnuthRandomGen s) =
(KnuthRandomGen (s*s), KnuthRandomGen (13+s))
{-# INLINE genRange #-}
genRange _ = (1, pred knuthModulus)
main :: IO ()
main =
do
-- for comparison: that's very fast
putStrLn ""constant""
B.writeFile ""random.out"" $ fst $
B.unfoldrN 10000000
(\g0@(KnuthRandomGen s) -> Just (fromIntegral s, g0))
(KnuthRandomGen 1)
-- 3 seconds on my machine
putStrLn ""immediate""
B.writeFile ""random.out"" $ fst $
B.unfoldrN 10000000
(\g0 -> let (w,g1) = next g0
in Just (fromIntegral (mod w 256), g1))
(KnuthRandomGen 1)
-- 10 seconds on my machine
putStrLn ""randomR""
B.writeFile ""random.out"" $ fst $
B.unfoldrN 10000000
(\g0 -> Just (let (w,g1) = randomR (0,255) g0
in (fromIntegral (w::Int), g1)))
(KnuthRandomGen 1)
{-
ghc -o dist/build/randomtest -O -Wall -package bytestring-0.9.0.5 -ddump-simpl-iterations speedtest/RandomTest.hs
-}
{-
bytestring-0.9.0.1 as shipped with GHC-6.8.2 does not inline Data.ByteString.unfoldrN
-}
}}}
Is this related to Ticket 427?
" guest
4980 25 ghc@… Warning about module abbreviation clashes Compiler 7.0.1 7.12.1 new low 2014-12-23T13:33:45Z "Please add the option -fwarn-module-rename-collision that makes GHC to do the following: If GHC encounters an import situation like
{{{
module Main where
import qualified Data.A as A
import qualified Control.A as A
}}}
then GHC should emit a warning like
{{{
Main.hs:3:0:
Main.hs:4:0:
Warning: Both Data.A and Control.A are renamed to A.
An identifier like A.ident can only be resolved,
if it is either in Data.A or Control.A.
Better rename both modules to different names.
}}}
Reason for this warning is, that if 'ident' is from Data.A as of writing Main, and later another variable named 'ident' is added to Control.A, then A.ident can no longer be resolved in Main. That is, by accidental module rename collisions even qualified imports carry the risk of future name collisions.
Related to #4977
" Lemming
3557 272 ghc@…, axman6@…, haskell.vivian.mcphail@…, pumpkingod@…, dterei, william.knop.nospam@…, Jake.McArthur@…, as@…, hackage.haskell.org@…, jystic@…, nightski@…, mle+hs@… CPU Vector instructions in GHC.Prim Data Parallel Haskell 6.11 ⊥ new normal 2014-12-02T20:08:48Z "It would be nice to have support for vector unit (MMX, SSE, AltiVec, and so on) operations in GHC. Currently Data Parallel Haskell cannot utilize vector units due to GHC's lack of support.
Those vector operations could be nicely used to get e.g. stereo signal processing for the price of mono signal processing.
Maybe those operations could be added to GHC.Prim, or because there are so many, to a new module, GHC.Prim.Vector.
" guest
9334 34 ghc@…, garrett "Implement ""instance chains""" Compiler (Type checker) 7.9 diatchki new normal 2015-04-20T15:06:17Z "It would be useful to implement a version of ""instance chains"" [1] in GHC, which would eliminate the need for OVERLAPPING_INSTANCES in most (all practcial?) programs.
The idea is that programmers can explicitly group and order instances into an ""instance chain"". For example:
{{{
instance (Monad m) => StateM (StateT s m) s where ...
else (MonadTrans t, StateM m s) => StateM (t m) s where ...
}}}
When GHC searches for instances, the instances in a chain are considered together and in order, starting with the first one:
1. If the goal matches the current instance's head, then this instance is selected and the rest are ignored, as if they were not there;
2. If the goal does not match the current instance's head, AND it does not unify with the current instance's head, then we skip the instance and proceed to the next member of the chain;
3. If the goal does not match the current instance's head, but it does unify with it, then we cannot use this chain to solve the goal.
In summary: earlier instances in a chain ""hide"" later instances, and later instances can be reached only if we are sure that none of the previous instance will match.
[1] http://web.cecs.pdx.edu/~mpj/pubs/instancechains.pdf" diatchki
4959 44 ghc@…, leroux@… Warning about variables with leading underscore that are used anyway Compiler (Parser) 7.0.1 7.12.1 new low 2014-12-23T13:33:45Z "I use -Wall all the time, which includes -fwarn-unused-binds and -fwarn-unused-matches that warn about variable bindings that are not used. It already spotted lots of mistakes for me. You can suppress the warning by prepending an underscore '_' to a variable name. However, I have recently seen code, where variable names with leading underscores are regularly used, where other programmers might have chosen trailing underscores or primes. I suspect that the programmer was not aware, that he disabled warnings about unused bindings this way. Thus I like to have a warning about underscored variables that are used in the sense of the definition given for -fwarn-unused-binds in http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html.
We still have to decide whether this warning should be part of -Wall or -fwarn-unused-binds or whether there should be a separate option like -fwarn-used-underscored-binds.
" Lemming
10567 9 gibiansky Redundant parser entry point Compiler 7.10.1 patch normal 2015-06-24T17:30:19Z The `stmt` parser is exposed under two different names. (`parseFullStmt` and `parseStatement`) It would be better to remove one of them (I would say `parseFullStmt`) in order to avoid confusion. mpickering
9630 5 gidyn compile-time performance regression (probably due to Generics) Compiler 7.9 7.12.1 simonpj new high 2015-07-25T21:32:43Z "This is a continuation of #9583
Compiling latest Cabal from Git's `Language.Haskell.Extension` module shows a significant performance regression with respect to GHC 7.8.3:
{{{
$ uname -a
Linux duo 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ git describe
cabal-install_merged-1912-g7161e4c
#############################################################################
$ /opt/ghc/7.8.3/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3
$ /opt/ghc/7.8.3/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs
<>
#############################################################################
$ /opt/ghc/head/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.9.20140923
$ /opt/ghc/head/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs
<>
}}}
Or in other words, this represents a ~7.7x ""memory in use"" and ~26x elapsed time regression" hvr
9087 5 gidyn Executables in the Linux binaries are not stripped Build System 7.8.2 new normal 2015-05-04T07:37:43Z "The executables inside the GHC binary tarball seem to come with debug information. Stripping it noticeably reduces the binary sizes:
{{{
$ file /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
/path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x6012a4c86cd3f410ca0e59ab4ac872ce740d03c6, not stripped
$ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
1,4M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
$ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
$ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
1021K /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/ghc
$ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
3,2M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
$ strip -s /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
$ du -sh /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
2,3M /path/to/ghc-7.8.2/lib/ghc-7.8.2/bin/haddock
}}}
Do we really need to include the debug info for exes?" refold
9669 5 gidyn Long compile time/high memory usage for modules with many deriving clauses Compiler 7.8.3 new normal 2015-07-09T00:03:18Z "I've seen many different people complain about this in various different contexts. One of the most common I personally see is when using Persistent with a large number of entities, which results in multi-minute build times for that single module. Usually, these reports have come from private repositories, which makes for a difficult repro. Also, the usage of Template Haskell in those modules tends to confuse the issue.
So I'd like to report this issue from a completely separate project, with the guess that this represents an issue that is affecting many other users. Steps to reproduce:
* `cabal unpack fpco-api-1.2.0.1`
* `cd fpco-api-1.2.0.1`
* `cabal install`
* `ghc --make -isrc/library src/library/FP/API/Types.hs`
* `touch src/library/FP/API/Types.hs`
Then, to see the time and memory usage of compiling just the one module, run:
* `time ghc -O2 --make -isrc/library src/library/FP/API/Types.hs +RTS -s`
On my system (16GB RAM, quadcore i7), the results are:
{{{
$ time ghc -O2 --make -isrc/library src/library/FP/API/Types.hs +RTS -s
[3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o )
51,846,533,568 bytes allocated in the heap
6,799,246,288 bytes copied during GC
389,297,584 bytes maximum residency (22 sample(s))
11,330,472 bytes maximum slop
1041 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 2041 colls, 0 par 9.19s 9.19s 0.0045s 0.0998s
Gen 1 22 colls, 0 par 4.33s 4.33s 0.1969s 0.5436s
TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.00s ( 0.00s elapsed)
MUT time 34.21s ( 37.74s elapsed)
GC time 13.52s ( 13.53s elapsed)
EXIT time 0.07s ( 0.07s elapsed)
Total time 47.81s ( 51.34s elapsed)
Alloc rate 1,515,662,937 bytes per MUT second
Productivity 71.7% of total user, 66.8% of total elapsed
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0
real 0m51.375s
user 0m50.864s
sys 0m0.456s
}}}
By contrast, with optimizations turned off:
{{{
$ time ghc -O0 --make -isrc/library src/library/FP/API/Types.hs +RTS -s
[3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o )
12,767,593,936 bytes allocated in the heap
1,078,202,664 bytes copied during GC
179,551,768 bytes maximum residency (13 sample(s))
6,684,544 bytes maximum slop
439 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 623 colls, 0 par 1.24s 1.24s 0.0020s 0.0651s
Gen 1 13 colls, 0 par 0.76s 0.76s 0.0586s 0.2397s
TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.00s ( 0.00s elapsed)
MUT time 8.28s ( 9.23s elapsed)
GC time 2.00s ( 2.00s elapsed)
EXIT time 0.05s ( 0.05s elapsed)
Total time 10.34s ( 11.28s elapsed)
Alloc rate 1,542,443,897 bytes per MUT second
Productivity 80.6% of total user, 73.9% of total elapsed
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0
real 0m11.304s
user 0m11.108s
sys 0m0.172s
}}}
and -O1:
{{{
$ time ghc -O1 --make -isrc/library src/library/FP/API/Types.hs +RTS -s
[3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o )
45,550,443,664 bytes allocated in the heap
5,721,700,512 bytes copied during GC
358,036,456 bytes maximum residency (21 sample(s))
9,167,176 bytes maximum slop
906 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 1642 colls, 0 par 7.70s 7.70s 0.0047s 0.1031s
Gen 1 21 colls, 0 par 3.68s 3.69s 0.1756s 0.4968s
TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.00s ( 0.00s elapsed)
MUT time 30.21s ( 33.09s elapsed)
GC time 11.38s ( 11.39s elapsed)
EXIT time 0.07s ( 0.07s elapsed)
Total time 41.68s ( 44.55s elapsed)
Alloc rate 1,507,571,106 bytes per MUT second
Productivity 72.7% of total user, 68.0% of total elapsed
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0
real 0m44.577s
user 0m44.164s
sys 0m0.368s
}}}
Note that this module is essentially just 900 lines of data declarations, with a large number of derived classes, and a few manually written helper functions and instances.
This high memory usage hasn't just resulted in user complaints: automated Jenkins and Travis jobs will often times fail without optimizations disabled, which can be problematic for proper testing and production code. In the case of fpco-api, I've worked around this by adding `-O0` to the cabal file, but it would be much nicer to not have to do that.
For some other examples of complaints along these lines:
* https://groups.google.com/d/msg/yesodweb/MX1bnOFu8Hc/VLQXhnvpIkMJ
* https://groups.google.com/d/msg/yesodweb/XPWixNjuOnM/FN26bmkudgwJ
I believe there are a few other threads discussing this, if it would be helpful. I did my testing on GHC 7.8.3 64-bit, Ubuntu 12.04." snoyberg
10374 5 gidyn Can't build GHC with a dynamic only GHC installation Build System 7.10.1 new normal 2015-05-04T07:16:34Z "When an installation of GHC doesn't include the vanilla ""way"", GHC cannot be built from this existing installation of GHC:
make[1]: *** No rule to make target `/packages/ghc_x86-7.8.3-10/.self/lib/x86/ghc-7.8.3/base-4.7.0.1/Prelude.hi', needed by `utils/hsc2hs/dist/build/Main.o'. Stop.
E.g. using the following mk/build.mk:
{{{
V = 0
GhcLibWays = dyn
SRC_HC_OPTS = -O -H64m
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -O2 -fasm
GhcHcOpts = -Rghc-timing
GhcLibHcOpts = -O2
DYNAMIC_BY_DEFAULT = YES
NoFibWays =
STRIP_CMD = :
}}}
Steps to reproduce:
1. build & install GHC using above configuration
2. rebuild GHC using above configuration, --with-ghc pointing to the installation created in step 1" jessicah
9646 5 gidyn Simplifer non-determinism leading to 8 fold difference in run time performance Compiler 7.8.3 7.10.1 new normal 2015-07-27T20:12:09Z "I've been chasing a weird performance bug for about a week now. I've reduced the testcase to the following git repo:
https://github.com/erikd/ghc-perfbug-test
The Readme.md file in that repo contains an explanation of how to reproduce the issue.
The benchmark program in the repo uses Criterion to test the performance of one particular function. Running the program in a particular way results into two significanlty different results.
The commands are:
{{{
make clean bench-integer.html
cp -f bench-integer.html bench-integer-slow.html
touch New3/GHC/Integer/Natural.hs && make bench-integer.html
}}}
The results for one function in the file `New3/GHC/Integer/Natural.hs` is 8 times slower in the first test that the second while the other test function always executes at about the speed.
I haven't been able to test this with ghc-7.6.3 because the code uses `isTrue#` which isn't available in 7.6.3.
Updated explanation:
Compiling the whole project results in the function under test running 4 times slower than the comparison. Touching the file containing the function under test and rebuilding the benchmark program results in the function under test runing 2 times faster than the comparison function.
Dumping intermediate files showed that the output of the simplifier was different enough to create this 8 fold difference in performance.
The simplifier should be deterministic. Same input file should result in the same simplifier output, preferably the output that results in 8 fold better performance.
" erikd
1851 5 gidyn """make install-strip"" should work" Build System 7.10.1-rc1 7.12.1 new normal 2015-01-26T15:34:12Z "With the bindists (not sure about a normal build tree) install-strip doesn't work:
{{{
$ make install-strip
make: *** No rule to make target `install-strip'. Stop.
$
}}}
It is defined in mk/install.mk, so it presumably is meant to. The blurb after running configure should mention it, too.
The target is described in the GNU coding standards: http://www.gnu.org/prep/standards/html_node/Standard-Targets.html
" igloo
7428 5 gidyn GHC compile times are seriously non-linear in program size Compiler 7.4.2 7.12.1 new normal 2015-06-16T14:37:33Z When compiling the attached code with -O2 GHC runs out of memory. Experimenting with different monad stacks shows exponential memory usage. nudded
8731 5 gidyn long compilation time for module with large data type and partial record selectors Compiler 7.8.1-rc1 7.12.1 new normal 2015-05-04T07:36:12Z "in both ghc 7.6 and 7.8rc, the Constants module in LLVM-General-Pure (and a few other similar modules) have surprisingly long (and noticable!) compilation times.
This seems to related to how GHC handles a many constructor data type with overlapping field names.
the time is nearly the same for building a static module with O1 and O2
{{{
carter repoScratcher/bad-ast » time ghc Constant.hs -O2 1 ↵
[1 of 1] Compiling Constant ( Constant.hs, Constant.o )
ghc Constant.hs -O2 7.52s user 0.23s system 99% cpu 7.755 total
}}}
{{{
carter repoScratcher/bad-ast » time ghc Constant.hs -O1
[1 of 1] Compiling Constant ( Constant.hs, Constant.o )
ghc Constant.hs -O1 6.62s user 0.20s system 100% cpu 6.768 total
}}}
heck even with -O0 its slow (though not terrible)
{{{
carter repoScratcher/bad-ast » time ghc Constant.hs -O0
[1 of 1] Compiling Constant ( Constant.hs, Constant.o )
ghc Constant.hs -O0 2.76s user 0.14s system 101% cpu 2.873 total
}}}
Seems like there might something wrong in how we handle data types like this, the complexity need not " carter
8287 5 gidyn exploring calling convention changes and related engineering for 7.10 Compiler 7.6.3 7.12.1 new normal 2015-05-04T07:38:28Z "I'm creating this as a master ticket for systematically exploring and benchmarking (possibly breaking) changes to the GHC calling convention. This work will initially focus on x86/x86_64, but may have larger scope.
Goals:
1. if possible, improve performance systematically for code run on recent CPU micro architecture generations (eg sandybridge, haswell, and future extensions like Knights Landing and Skylake), ideally without pessimizing code on other or older x86_64 micro-architectures
2. Try to bring native and llvm codegens closer to feature parity (or at the very least, do not widen their capability gap)
3. a few other pieces too, will amend this ticket as ideas / plans clarify" carter
8082 15 gidyn, simonmar Ordering of assembly blocks affects performance Compiler (NCG) 7.6.3 new normal 2015-03-30T08:22:16Z 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. jstolarek
8424 6 gintas quasi-quotes have carriage returns on Windows Template Haskell 7.6.3 new normal 2014-11-18T22:19:28Z "A Windows user rerported using Data.Text.IO.writeFile to write out quasi-quoted text.
writeFile automatically translates '\r' to ""\r\n"", so the user ended up writing out ""\r\r\n"" to a file.
Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns?
I asked this question on ghc-users and there was no response.
I am willing to make this fix if it is deemed appropriate." GregWeber
9014 41 gintas, thoughtpolice, RyanGlScott, Phyx- GHC 7.8.2 Win64 tarball includes gfortran/gcj/python Build System 7.8.3 7.12.1 Phyx- new normal 2015-08-02T12:09:04Z "The released Windows 64 tarball available at https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown-mingw32.tar.xz includes the following under `mingw/bin`:
* gfortran
* gcj
* python27.dll
* The whole Python 2.7 standard library (`mingw/bin/lib`)
These files have probably been included by mistake." refold
4370 240 giorgidze@…, ganesh, ezyang@…, jeroen.weijers@…, bos@…, mail@…, sebf@…, tyler@…, pumpkingod@…, leather@…, anton.nik@…, alex@… Bring back monad comprehensions Compiler 6.12.3 ⊥ new normal 2015-05-04T07:21:41Z "George Giorgidze writes: My colleagues and I are working on Haskell [http://www-db.informatik.uni-tuebingen.de/files/weijers/IFL2010complete.pdf embedded DSL for data-intensive and data-parallel applications]. The idea is to provide the Haskell list prelude combinators to manipulate database-resident data. The combinators are not executed in Haskell runtime, instead they are compiled down to SQL, executed on relational database systems and the results are marshalled back to Haskell for further in-heap processing or generation of new database-able embedded programs.
Although programming with the standard list processing combinators is feasible, the embedded programs are much more concisely formulated using the list comprehension notation, especially, when extended with [http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/ 'order by' and 'group by' constructs].
Unfortunately, in Haskell, the list comprehension notation is only available for processing lists.
In order to support the list comprehension notation, we have built a quasiquter that desugars the list comprehension notation, but, instead of generating code using the Haskell list prelude combinators the quasiquter generates code that uses list processing combinators from our embedded language.
Although the quasiquoting approach worked for us, it has a number of
drawbacks:
* Introduces extra syntactic noise
* Error messages are hard to understand as they refer to enerated code
* Needs to be re-implemented for every list-based embedded language
One way to address the aforementioned drawbacks is to define our queries as a monad (similar to list monad) and use the monad comprehension notation. The do notation can be used but it is less suited for query languages.
Unfortunately monad comprehensions were removed from Haskell, prior to Haskell 98. However, I think that the notation is extremely useful not only for lists, but for other list like data structures, list-based query languages (see above), maybe even for wider range of EDSLs and monads. I think the feature deserves to be supported at least as a GHC language extension.
Thus, I would like to propose to design and implement the monad comprehension notation as a GHC language extension. I am willing to invest some time and contribute to this effort.
One can also look at how recently introduced 'order by' and 'group by'
constructs generalise to monad comprehensions. If that works, one could implement even more ""stylish"" monad comprehension notation.
Feedback from GHC users and developers would be very much appreciated.
* Do you think that this is a good idea?
* Would you use monad comprehensions (if available) for your
library/EDSL/application?
* Do you think that it would be hard to integrate this extension into
current GHC codebase?
* Have you already thought about how to generalise 'order by' and 'group by' to monad comprehensions?
* Have you already thought about how to address the original objections to the monad comprehension notation?
" simonpj
7495 113 giorgidze@…, info@…, jeroen.weijers@…, eir@…, gershomb@… generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc Compiler 7.6.1 7.12.1 carter new normal 2015-06-11T17:28:58Z "First, sorry if I've missed an earlier request for this in trac; a few searches did not turn up anything relevant.
I've recently taken to doing a lot of work with heterogenous lists (thanks to the DataKinds work) and find the forced-cons-and-nil style of writing lists (e.g. ""a:+b:+c:+HN"") to be sort of unpleasant.
Would it be possible to allow rebinding list-literal syntax? Off the top of my head I think something like the following might be workable, if only I could stop [] and (:) from being in scope, even with -XNoImplicitPrelude. (Example requires -XDataKinds -XFlexibleInstances -XGADTs -XMultiParamTypeClasses -XTypeOperators)
{{{
class HasNil a where
([]) :: a
isNil :: a -> Bool
class HasCons e l l' | e l -> l', l' -> e l where
(:) :: e -> l -> l'
uncons :: l' -> Maybe (e,l)
-- For homogeneous lists...
instance HasNil [a] where
([]) = ([])
isNil = null
instance (a ~ a1, a ~ a2) => HasCons a [a1] [a2] where
(:) = (:)
uncons [] = Nothing
uncons (x:xs) = Just (x,xs)
-- For HLists...
data HList as where
HN :: HList '[]
(:+) :: a -> HList as -> HList (a ': as)
instance HasNil (HList '[]) where
([]) = HN
isNil = const True
instance (a ~ a1, as ~ as1) => HasCons a (HList as) (HList (a1 ': as1)) where
(:) = (:+)
uncons (a :+ as) = Just (a,as)
}}}" nwf
2986 38 glasgow-haskell-users@…, hvr :info printing instances often isn't wanted GHCi 6.10.1 7.12.1 Remi new lowest 2015-03-03T12:29:51Z ":info shows all instances of types/classes, which often obscures the info I'm actually interested in.
See the output of e.g. "":info Show"" or "":info [] Maybe Int"": The class and types are rather lost in between the instances. My proposal is to add an option to suppress the printing of instances. With the attached patch for 6.10.1 (although it applies to HEAD too), "":info -Show"" will only print the class." Remi
9017 8 goldfire Confusing error message with PolyKinds Compiler (Type checker) 7.8.2 new normal 2014-11-07T21:38:59Z "Consider the following example code:
{{{
import Control.Arrow
foo :: a b (m b)
foo = arr return
}}}
if we typecheck this we rightly get two errors about missing instances (Arrow a, Monad m). However, if we enable `PolyKinds` we get the following error message:
{{{
T.hs:4:7:
Kind incompatibility when matching types:
a0 :: * -> * -> *
a :: k1 -> k -> *
Expected type: a b (m b)
Actual type: a0 b0 (m0 b0)
Relevant bindings include foo :: a b (m b) (bound at T.hs:4:1)
In the expression: arr return
In an equation for ‘foo’: foo = arr return
}}}
I can ''sort of'' see where this is coming from if I think really hard :), so perhaps it's not a bug per se, but it's definitely confusing; and it's a pity that a type error (forgotten type qualifier) is reported as a kind error." edsko
10490 8 goldfire Missing binder type check in coercion equality test? Compiler (Type checker) 7.11 new normal 2015-06-07T11:31:49Z "I was reading the equality testing code for coercions and I noticed this line:
{{{
coreEqCoercion2 env (ForAllCo v1 co1) (ForAllCo v2 co2)
= coreEqCoercion2 (rnBndr2 env v1 v2) co1 co2
}}}
This doesn't test if the types of the binders are equal. Should it? (Or is the type always trivially the same?)" ezyang
10715 8 goldfire Possible regression in Coercible a (X a) between 7.8 and 7.10 Compiler 7.10.1 goldfire new normal 2015-07-31T16:03:52Z "In upgrading to7.10, code of the form
{{{#!hs
{-# LANGUAGE FlexibleContexts #-}
import Data.Coerce (coerce, Coercible)
data X a
doCoerce :: Coercible a (X a) => a -> X a
doCoerce = coerce
}}}
fails to compile in 7.10.1 and 7.10.2 with the error
{{{
testCoerce.hs:6:13:
Could not deduce (a ~ X a)
from the context (Coercible a (X a))
bound by the type signature for
doCoerce :: Coercible a (X a) => a -> X a
at testCoerce.hs:6:13-41
‘a’ is a rigid type variable bound by
the type signature for doCoerce :: Coercible a (X a) => a -> X a
at testCoerce.hs:6:13
Relevant role signatures: type role X phantom
In the ambiguity check for the type signature for ‘doCoerce’:
doCoerce :: forall a. Coercible a (X a) => a -> X a
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature for ‘doCoerce’:
doCoerce :: Coercible a (X a) => a -> X a
}}}
while it works in 7.8.4.
Surprisingly (to me at least), the code works in 7.10.1 and 7.10.2 if I change it to
{{{#!hs
{-# LANGUAGE FlexibleContexts #-}
import Data.Coerce (coerce, Coercible)
data X a
doCoerce :: Coercible a (X b) => a -> X a
doCoerce = coerce
}}}
while it fails to compile in 7.8.4 with the error
{{{
testCoerce.hs:6:13:
Could not coerce from ‘a’ to ‘X b0’
because ‘a’ and ‘X b0’ are different types.
arising from the ambiguity check for ‘doCoerce’
from the context (Coercible a (X b))
bound by the type signature for
doCoerce :: Coercible a (X b) => a -> X a
at testCoerce.hs:6:13-41
The type variable ‘b0’ is ambiguous
In the ambiguity check for:
forall a b. Coercible a (X b) => a -> X a
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature for ‘doCoerce’:
doCoerce :: Coercible a (X b) => a -> X a
}}}
The coercion pattern may look a bit funny, but it is rather useful when one has newtypes of the form
{{{#!hs
newtype Y = Y (ForeignPtr Y)
}}}
which appear naturally when writing bindings to C libraries, and one wants to get access to the underlying ForeignPtr from Y (here X is ForeignPtr). The relevant Coercible instance here is Coercible Y (ForeignPtr Y), as above.
I would have expected the version with context ""Coercible a (X a)"" to be accepted, as 7.8.4 does, since it seems to be a specialization of the more general coerce, but maybe I am missing something?" inaki
3483 8 goldfire "Some mechanism for eliminating ""absurd"" patterns" Compiler 6.10.4 7.12.1 new low 2014-12-23T13:33:45Z "This is to help with type-level programming and doing dependent-like programming in Haskell.
{{{
data TEq :: * -> * -> * where
TEq :: TEq a a
-- This declaration fails to compile because bringing (Int ~ Bool)
-- into scope on the RHS is unsound.
broken :: TEq Int Bool -> Int
broken TEq = 1
-- Proposal:
-- ""!"" replaces ""="" in function declaration to say ""this pattern is absurd""
proposal :: TEq Int Bool -> r
proposal TEq !
-- If, for some reason the pattern match succeeds,
-- (basically, someone broke type safety with unsafeCoerce)
-- the result could be something like calling:
-- error ""absurd pattern at FILE:LINE""
}}}
I'm not sure that ""!"" works with Haskell's syntax, but it does call attention to the pattern.
The idea is that anywhere that putting ""= some_rhs"" would cause the compiler to fail because it can prove that the type environment is unsound in some fashion, you could use ""!"" to give a valid function definition.
The same extension would be used for case statements, of course.
See also #2006, which is related in spirit if not in implementation." ryani
8477 18 goldfire, diatchki Allow inferring ambiguous types Compiler (Type checker) 7.6.3 new normal 2014-11-18T19:26:33Z "Previous versions of ghc could infer types that are potentially ambiguous. This allowed things like http://okmij.org/ftp/Haskell/TypeLambdaVal.hs or assigning keyword args functions to variables http://code.haskell.org/~aavogt/HList/docs/HList/Data-HList-Keyword.html. Presently (7.6 and 7.7), you need to write a type signature yourself to allow such definitions, which in these situations doubles the amount of code to write. For the keyword case, the workaround is to use the kw function to apply the keyword function instead of ordinary function application.
More related discussion http://www.haskell.org/pipermail/glasgow-haskell-users/2013-October/024404.html" aavogt
8177 71 goldfire, hackage.haskell.org@…, ecrockett0@…, dmcclean Roles for type families Compiler 7.6.3 ⊥ goldfire new normal 2014-11-10T21:43:52Z "Now that we have [wiki:Roles roles], it might be helpful to be able to give a role signature for a data/type family.
At the moment, data/type family constructors have all parameters conservatively assigned to be role `N`. Thus
{{{
data family D a -- Parameter conservatively assumed to be N
class C a where
op :: D a -> a
instance C Int where ....
newtype N a = MkN a deriving( C ) -- Rejected
}}}
The generalised-newtype-deriving clause `deriving( C )` is rejected because `D` might use its parameter at role `N` thus:
{{{
data instance D [b] = MkD (F b) -- F is a type function
}}}
It would be strictly more expressive if we could
* '''Declare''' the roles of D's arguments (as we can declare their kinds). E.g.
{{{
data family D a@R
}}}
* '''Check''' that each family instance obeys that role signature. E.g. given the preceding role signature, reject this instance:
{{{
data instance D [b] = MkD (F b) -- F is a type function
}}}
I think there is no technical difficulty here. Just a question of doing it." simonpj
9918 14 goldfire, oleg GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family Compiler 7.8.3 new normal 2015-01-13T09:47:28Z "We hoped that closed type families could replace overlapping
instances. It is not currently the case: GHC can resolve overlapping
instances but cannot resolve the similar closed type family.
I'm attaching a minimized example of program where it can
be observed. This is reproducible on ghc-7.8.3 and HEAD." qnikst
10701 9 GregWeber -fth-dec-file uses qualified names from hidden modules Template Haskell 7.10.1 7.12.1 new normal 2015-07-30T23:16:46Z "In cross compilation builds, the current TH situation is a bit of a showstopper. However, much TH code is 'safe' to cross-compile. Before the TH situation is solved, it would be great if GHC could automate as much of the work-around process as possible. -dth-dec-file is a big step on the way to create a non-TH version of the source. However, there are some problems with the generated code. One is that qualified names from hidden modules are used. A instance declaration for Aeson.ToJSON is outputted as follows:
{{{#!hs
instance Data.Aeson.Types.Class.ToJSON InputDropboxFiles where
}}}
Ideally, GHC would be able to combine the splice output with the original file, replacing all $() with the corresponding splice, and even generate correct imports. I personally think this would be a great solution to the TH problem. Most cross-compilation projects could just generate the non-TH version with the host GHC, and the few that depends on architecture specific variables can be edited before cross-compiled" Fabian
10702 9 GregWeber -fth-dec-file uses qualified names in binding positions Template Haskell 7.10.1 7.12.1 new normal 2015-07-30T23:12:16Z "{{{#!hs
instance Data.Aeson.ToJSON InputDropboxFiles where
Data.Aeson.toJSON x@(InputDropboxFiles {})
= Data.Aeson.object
(Data.Maybe.catMaybes
[Just
((Data.Aeson..=) ""root"" (inputDropboxFilesRoot x)),
Just
((Data.Aeson..=) ""path"" (inputDropboxFilesPath x)),
fmap
((Data.Aeson..=) ""rev"") (inputDropboxFilesRev x),
Just
((Data.Aeson..=)
""access_token"" (inputDropboxFilesAccess_token x))])
}}}
Data.Aeson.toJSON should be toJSON at line 2" Fabian
10703 9 GregWeber -fth-dec-file can't handle lambdas Template Haskell 7.10.1 7.12.1 new normal 2015-07-31T08:44:43Z "{{{#!hs
instance Data.TH.Object.Object InputDropboxFiles String Language.JavaScript.Interpret.Primitive where
toObject x@(InputDropboxFiles {})
= fromList
(Data.Maybe.catMaybes
[Just
(\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr)
""root"" (inputDropboxFilesRoot x)),
Just
(\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr)
""path"" (inputDropboxFilesPath x)),
fmap
(\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr) ""rev"")
(inputDropboxFilesRev x),
Just
(\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr)
""access_token"" (inputDropboxFilesAccess_token x))])
}}}
{{{#!hs
(\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr)
""root"" (inputDropboxFilesRoot x))
}}}
should be
{{{#!hs
((\ k_axsq v_axsr -> (k_axsq, Data.TH.Convert.convert v_axsr))
""root"" (inputDropboxFilesRoot x))
}}}
ie. the lambda needs parentheses around it." Fabian
4479 45 griba2001@…, adam.gundry@… Implement Dot as Postfix Function Apply Compiler (Type checker) 7.5 7.12.1 new low 2015-05-04T07:20:10Z A request to implement [https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix Dot as Postfix Function Apply]. gidyn
10486 10 gridaphobe Allow addTopDecls to create annotations Template Haskell 7.10.1 new normal 2015-06-20T08:55:33Z Currently addTopDecls is [https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/compiler/typecheck/TcSplice.hs#L811 restricted] to creating function, value, and foreign import declarations. Lifting this restriction allows one to create annotations without any issues, as far as I can tell. spinda
10044 10 gridaphobe Wrong line number reported with CPP and line beginning with # Compiler 7.10.1-rc2 new low 2015-07-10T22:48:37Z "If I compile
{{{
{-# LANGUAGE CPP #-}
module Bug where
{-
# hi there!
-}
*
}}}
I'm told of a parse error for the `*` on line 10. But that `*` is line 9!
The problem is that, with `CPP` on, the line number counter gets confused if a line begins with a #, perhaps after whitespace.
I actually hit this and was confused in real code." goldfire
2427 74 gwern0@…, id@…, nathanhowell@… Allow compilation of source from stdin Compiler 6.8.3 ⊥ new normal 2013-02-23T01:43:28Z "Hiya. So, as part of how the Hint library (a wrapper around the GHC API operates), it has to generate a file in /tmp containing module boilerplate and the supplied code of interesting, and it then evaluates it*. But for my mueval code (which uses Hint), I'd like to disable file creation entirely through resource limits, and so it would be much better for Hint if it could instead just create the string and pipe it right into GHC. This avoids any file creation (which may not be possible for any number of reasons besides resource limits, like LiveCDs or read-only disks). But in my experiments, and those of #haskell, GHC determinedly blocks any attempt - you can't simply pipe it in with |, you can't use /dev/stdin, can't use one of the file descriptors, etc.
So what I would like is to be able to do:
{{{
$ echo ""import qualified Data.List\nmain = print $ Data.List.intersperse 'f' ""ggggg""
""fgfgfgfgfgfg""
}}}
(Why can't I use ghc -e? Doesn't do imports of any kind, and if mueval is to replicate lambdabot's functionality, it needs to be able to import many libraries qualified.**)
* It has to do this roundabout hackish thing because alas, the GHC API seems to allow functions from any module whatsoever to be called as long as they are named qualified, even if the appropriate module had not been allowed in. The magnitude of this as a security hole is obvious.
** Why qualified? Too many of the basic libraries have name collisions. Can't remove them, as it'd be silly to have only half the base libraries or whatever, but can't just blindly import them as you'll get conflicts." guest
4114 71 gwern0@…, merehap@…, tafryn@…, simon@… Add a flag to remove/delete intermediate files generated by GHC Compiler 6.10.4 7.12.1 VictorDenisov new normal 2015-06-04T15:00:24Z "See for example http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files or
http://www.haskell.org/pipermail/xmonad/2010-May/010180.html /
Currently GHC generates *.o and *.hi files for executables, possibly quite a few. They take up space, filenames, and interfere with tab-completion.
(And they may be worse than that. I occasionally see users in #xmonad who seem to have subtle compilation issues after upgrades linked to stale .hi and .o files.)
There doesn't seem to be any good way to remove the intermediates for a program like Xmonad. They can't be redirected to /dev/null, it's a potential security problem to redirect them to /tmp, and removing them manually is difficult (Xmonad could hardwire in removeFiles of 'xmonad.o' and 'xmonad.hi', but what about the arbitrary user modules in ~/.xmonad/lib? Now one needs to start working with globs or utilities like 'find'...).
Of course, GHC knows precisely what's being generated, and could easily remove them. So another flag in the line of -fforce-recompilation seems warranted; perhaps -fforce-no-intermediates?" guest
7862 29 hackage.haskell.org@… Could not deduce (A) from the context (A, ...) Compiler (Type checker) 7.8.3 new normal 2014-11-11T13:10:06Z "The following code doesn't compile and produces a strange error:
{{{
{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
module Numeric.AD.Internal.Tower () where
type family Scalar t
newtype Tower s a = Tower [a]
type instance Scalar (Tower s a) = a
class (Num (Scalar t), Num t) => Mode t where
() :: t -> t -> t
instance (Num a) => Mode (Tower s a) where
Tower as _ = undefined
where
_ = (Tower as) (Tower as)
instance Num a => Num (Tower s a) where
}}}
{{{
src/Numeric/AD/Internal/Tower.hs:17:24:
Could not deduce (Num (Scalar (Tower s a)))
arising from a use of `'
from the context (Num (Scalar (Tower s a)), Num (Tower s a), Num a)
bound by the instance declaration
at src/Numeric/AD/Internal/Tower.hs:14:10-36
Possible fix:
add an instance declaration for (Num (Scalar (Tower s a)))
In the expression: (Tower as) (Tower as)
In a pattern binding: _ = (Tower as) (Tower as)
In an equation for `':
(Tower as) _
= undefined
where
_ = (Tower as) (Tower as)
}}}
Furthermore, Removing the {{{Num (Scalar t)}}} constraint from the {{{Mode}}} class produces a different strange error:
{{{
src/Numeric/AD/Internal/Tower.hs:17:24:
Overlapping instances for Num (Tower s0 a)
arising from a use of `'
Matching givens (or their superclasses):
(Num (Tower s a))
bound by the instance declaration
at src/Numeric/AD/Internal/Tower.hs:14:10-36
Matching instances:
instance Num a => Num (Tower s a)
-- Defined at src/Numeric/AD/Internal/Tower.hs:19:10
(The choice depends on the instantiation of `a, s0')
In the expression: (Tower as) (Tower as)
In a pattern binding: _ = (Tower as) (Tower as)
In an equation for `':
(Tower as) _
= undefined
where
_ = (Tower as) (Tower as)
}}}" alang9
855 47 hackage.haskell.org@…, ekmett@… Improvements to SpecConstr Compiler 6.4.2 ⊥ new normal 2013-08-24T20:42:59Z "There are a series of possible improvemnts to SpecConstr, described in
the source code. {{{compiler/specialise/SpecConstr}}}
* Specialising for constant parameters
* Specialising for lambda parameters
* Two ideas to do with strictness that look more tricky
Some of them look quite straightforward." simonpj
947 47 hackage.haskell.org@…, jwlato@… ghc -O space leak: CSE between different CAFs Compiler 6.5 ⊥ new normal 2012-10-16T00:13:34Z "Consider the following program for generating the 1,000,000th prime:
{{{
module Main (main) where
sieve0 (n:ns) (p:ps)
| p*p == n = sieve0 (filter (\n -> n`mod`p /= 0) ns) ps
| otherwise = n:sieve0 ns (p:ps)
primes0 :: [Int]
primes0 = 3:sieve0 [5,7..] primes0
primes :: [Int]
primes = 2:3:sieve0 [5,7..] primes0
main = print $ primes !! 1000000
}}}
The intention of the separate primes0 function is to limit the number of primes that need to be held in memory. Unfortunately, ghc -O combines the common subexpressions in primes0 and primes so this effort is wasted. The resulting program needs noticably more memory than required, as can be seen by replacing the definition of {{{primes}}} by
{{{
primes = 2:3:sieve0 (iterate (2+) 5) primes0
}}}
which prevents the CSE from happening.
Excerpt of {{{+RTS -s}}} output, original version:
{{{
12,099,221,160 bytes allocated in the heap
279,720,116 bytes copied during GC
15,834,912 bytes maximum residency (6 sample(s))
}}}
modified version that prevents CSE:
{{{
127,736,408 bytes copied during GC (scavenged)
233,388 bytes copied during GC (not scavenged)
30,624 bytes maximum residency (1 sample(s))
}}}
Tested with ghc 6.4.2 and a current (as of 2006-10-17) darcs ghc 6.5." int-e@…
7647 113 hackage.haskell.org@…, mnislaih@…, bgamari@…, tkn.akio@…, f@…, MikeIzbicki UNPACK polymorphic fields Compiler 7.6.1 7.12.1 new normal 2015-07-27T15:43:53Z "comment:9:ticket:3990 mentions the possibility of unpacking polymorphic fields. To quote:
[…]
What I mean by ""polymorphic unpack"" is this:
{{{
data Poly a = MkP Bool {-# UNPACK #-} a
data Mango = MkMango {-# UNPACK #-} (Poly Int)
}}}
Now a value of type Poly t would be represented using two pointer fields, as usual (ie the UNPACK would have no direct effect on Poly). But a Mango value would be represented thus:
{{{
data Mango = MkMangoRep Bool Int#
MkMango :: Poly Int -> MangoRep
MkMango (MkP b (I# i)) = MkMangoRep b i
-- Pattern match (MkMango p -> rhs)
-- is transformed to (MkMangoRep b i -> let p = MkP b (I# i) in rhs
}}}
Something like that would be rather nice. This ticket is just a reminder.
Thanks,[[br]]
/Liyang" liyang
7277 34 hackage.haskell.org@…, nh2 Recompilation check fails for TH unless functions are inlined Template Haskell 7.4.2 7.12.1 new normal 2014-12-23T13:34:10Z "Even though [http://hackage.haskell.org/trac/ghc/ticket/481 Issue 481] is marked as closed, the fix is only partial. If a function inside $( ... ) is not inlined, then the dependency check fails. Attached is a full example, built around the following code:
{{{
#ifdef NO_INLINE
{-# NOINLINE libraryFunction #-}
#endif
libraryFunction :: Q Exp
libraryFunction = [e| ""Return X"" |]
}}}
And the test:
{{{
case_library_function = $( libraryFunction ) @?= ""Return A""
}}}
Here is are the relevant parts of RUNME.LOG:
{{{
+ rm -rf dist
+ cabal configure --enable-tests
Resolving dependencies...
Configuring dependency-bug-0.0.1...
+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Main:
library function: [Failed]
expected: ""Return A""
but got: ""Return B""
Test Cases Total
Passed 0 0
Failed 1 1
Total 1 1
Test suite Test: FAIL
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
0 of 1 test suites (0 of 1 test cases) passed.
}}}
This is as expected; we changed the source to ""Return B"" but the test expects the library to ""Return A"" so it fails. So far, so good. However:
{{{
+ rm -rf dist
+ cabal configure --enable-tests -fwithout-inline
Resolving dependencies...
Configuring dependency-bug-0.0.1...
+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package dependency-bug-0.0.1 ... linking ... done.
Loading package filepath-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package old-time-1.1.0.0 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package unix-2.5.1.1 ... linking ... done.
Loading package directory-1.1.0.2 ... linking ... done.
Loading package cpphs-1.14 ... linking ... done.
Loading package haskell-src-exts-1.13.5 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package regex-base-0.93.2 ... linking ... done.
Loading package regex-posix-0.95.2 ... linking ... done.
Loading package language-haskell-extract-0.2.1 ... linking ... done.
Loading package ansi-terminal-0.5.5 ... linking ... done.
Loading package ansi-wl-pprint-0.6.4 ... linking ... done.
Loading package extensible-exceptions-0.1.1.4 ... linking ... done.
Loading package hostname-1.0 ... linking ... done.
Loading package time-1.4 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package text-0.11.2.3 ... linking ... done.
Loading package xml-1.3.12 ... linking ... done.
Loading package test-framework-0.6.1 ... linking ... done.
Loading package test-framework-th-0.2.2 ... linking ... done.
Loading package HUnit-1.2.5.1 ... linking ... done.
Loading package test-framework-hunit-0.2.7 ... linking ... done.
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
}}}
As you can see, without-inline the 2nd build did not recompile the test, even though it should have. It only re-linked the test, so it kept seeing ""Return A"" even though the library actually does ""Return B"".
In my real code, there are no NO/INLINE pragmas; however, the TH code is complex enough that it is not inlined, which causes the same problem. I had to use the pragma to keep the example short." orenbenkiki
5298 63 hackage.haskell.org@…, pho@…, jpm@… Inlined functions aren't fully specialised Compiler 7.0.3 7.12.1 new low 2014-12-23T13:33:45Z "When a function is inlined, it can expose other functions as candidates for specialisation, but GHC doesn't specialise them.
For instance, given the two modules
{{{
module A where
{-# INLINABLE fac #-}
fac :: Num a => a -> a
fac 0 = 1
fac n = n * fac (n-1)
{-# INLINE f #-}
f :: Num a => a -> a
f a = fac a
}}}
{{{
module B where
import A
g :: Int -> Int
g x = f x
}}}
we see that f is inlined, but fac isn't specialised for Ints:
{{{
B.g :: Int -> Int
[GblId,
Arity=1,
Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0] 30 0}]
B.g =
\ (x_ary :: Int) ->
A.fac @ Int $fNumInt x_ary
}}}
Removing the INLINE pragma on f doesn't help.
Either of the following changes will cause fac to be specialised:
* adding {-# SPECIALISE f :: Int -> Int #-} to module B
* defining ""g x = fac x"" instead
This happens with both GHC 7.0.3 and GHC HEAD" reinerp
3990 92 hackage.haskell.org@…, reiner.pope@…, tomberek@…, tkn.akio@… UNPACK doesn't unbox data families Compiler 7.0.3 7.12.1 new low 2014-12-23T13:33:45Z "Here is an example:
{{{
data family Complex a
data instance Complex Double = CD {-# UNPACK #-} !Double
{-# UNPACK #-} !Double
data T = T {-# UNPACK #-} !(Complex Double)
}}}
We would like T to just store two Double# but that doesn't happen. Contrast this with
{{{
data Complex_Double = CD {-# UNPACK #-} !Double
{-# UNPACK #-} !Double
data T = T {-# UNPACK #-} !Complex_Double
}}}
" rl
7152 39 hackage.haskell.org@…, rwbarton Add flag to configure that skips overwriting of symlinks on install Build System 7.4.2 7.12.1 thoughtpolice new normal 2015-02-01T21:02:30Z Sometimes when I'm installing a GHC release candidates I'd like to install the RC without overwriting the `ghc` etc symlinks in `/usr/local/bin`. It would be convenient to have a configure flag that told the install step to only install the versioned binaries (e.g. `ghc-6.2.1`) in `/usr/local/bin`, without the symlinks. tibbe
4243 45 hackage.haskell.org@…, simonmar, osa1 Make a proper options parser for the RTS Runtime System 6.13 7.12.1 carlostome new normal 2015-07-09T12:31:00Z "The RTS options parsing is getting increasingly crufty, and the new `rtsOptsEnabled` options have made it even worse. We should really have a proper options parser.
" igloo
4459 68 haskell.vivian.mcphail@…, mmitar@…, leather@… Polymorphic Data.Dynamic GHC API 7.1 7.12.1 vivian new low 2014-12-23T13:33:45Z "At some point in the compilation process an expression acquires a fully-specified, possibly polymorphic, type. If we add an operation that join that type and that expresssion, say `TypedAny`, then we can implement the part of #4316 requested by mitar.
In GHCi we can evaluate `HValue`s '''and also''' string them together with `bind` statements.
The function
{{{
applyDynamic :: TypedAny -> TypedAny -> Maybe TypedAny
}}}
includes in its implementation a dictionary lookup and possible dynamic object linking for class methods.
the function
{{{
fromDynamic :: TypedAny -> Maybe a
}}}
like `applyDynamic`, runs the typechecker at runtime to unify (and possibly link) the dynamic type (!TypedAny) and the static type (a).
''Conjecture '' Since we already have `typecase` (classes), with type families, this feature provides/simulates dependent types." vivian
8032 31 haskell@… Worker-wrapper transform and NOINLINE trigger bad reboxing behavior Compiler 7.7 new normal 2013-07-08T22:32:26Z "(Note: I've updated the ticket with a simpler test-case).
NOINLINE and the worker-wrapper transform sometimes interact poorly to cause unnecessary extra reboxing.
{{{
module Gnam where
data D = D Int
foo k d@(D e) =
let loop i
| i < e = loop (i + 1)
| otherwise = baz k d i
in loop 0
where {-# NOINLINE baz #-}
baz k d i = k (d, i)
}}}
This results in the following STG:
{{{
Gnam.$wfoo
:: forall t_alo.
((Gnam.D, GHC.Types.Int) -> t_alo) -> GHC.Prim.Int# -> t_alo
[GblId,
Arity=2,
Caf=NoCafRefs,
Str=DmdType C(S)L,
Unf=OtherCon []] =
\r [w_sob ww_so3]
let {
e_so4 :: GHC.Types.Int
[LclId, Unf=OtherCon []] =
NO_CCS GHC.Types.I#! [ww_so3]; } in
let {
wild_so6 :: Gnam.D
[LclId, Unf=OtherCon []] =
NO_CCS Gnam.D! [e_so4];
} in
}}}
This worker function needs to box its arguments so that they can be passed to baz. However, the only invocation of wfoo already had these arguments available:
{{{
Gnam.foo [InlPrag=INLINE[0]]
:: forall t_alo.
((Gnam.D, GHC.Types.Int) -> t_alo) -> Gnam.D -> t_alo
[GblId,
Arity=2,
Caf=NoCafRefs,
Str=DmdType C(S)U(U(L)),
Unf=OtherCon []] =
\r [w_son w1_soh]
case w1_soh of _ {
Gnam.D ww_sok ->
case ww_sok of _ {
GHC.Types.I# ww2_soo -> Gnam.$wfoo w_son ww2_soo;
};
};
}}}
The problem seems to lie in how the worker wrapper transformation operates. Before, the STG is:
{{{
Gnam.foo =
\ (@ t_alr)
(k_aeM [Dmd=Just C(S)] :: (Gnam.D, GHC.Types.Int) -> t_alr)
(d_aeN [Dmd=Just U(U(L))] :: Gnam.D) ->
case d_aeN of wild_X5 { Gnam.D e_aeO [Dmd=Just U(L)] ->
letrec {
loop_smj [Occ=LoopBreaker] :: GHC.Types.Int -> t_alr
[LclId,
Arity=1,
Str=DmdType U(L) {aeM->C(S) aeO->U(L)},
Unf=Unf{Src=, TopLvl=False, Arity=1, Value=True,
ConLike=True, WorkFree=True, Expandable=True,
Guidance=IF_ARGS [20] 112 0}]
loop_smj =
\ (i_aeU [Dmd=Just U(L)] :: GHC.Types.Int) ->
case i_aeU of wild_alU { GHC.Types.I# x_alW [Dmd=Just L] ->
case e_aeO of _ { GHC.Types.I# y_am0 [Dmd=Just L] ->
case GHC.Prim.
baz_smn @ t_alr @ Gnam.D @ GHC.Types.Int k_aeM wild_X5 wild_alU;
GHC.Types.True -> loop_smj (GHC.Types.I# (GHC.Prim.+# x_alW 1))
}
}
}; } in
loop_smj lvl_smr
}
}}}
Notice that wild_alU is being properly used in the result. After the worker wrapper transformation, foo is now:
{{{
Gnam.foo =
\ (@ t_alp)
(w_sn7 [Dmd=Just C(S)] :: (Gnam.D, GHC.Types.Int) -> t_alp)
(w_sn8 [Dmd=Just U(U(L))] :: Gnam.D) ->
case w_sn8 of w_sn8 { Gnam.D ww_sna ->
case ww_sna of ww_sna { GHC.Types.I# ww_snc ->
$wfoo_sng @ t_alp w_sn7 ww_snc
}
}
}}}
So it seems that we should also pass along the evaluated variables, in case they are used. There is a tradeoff here, in that we will require more arguments to the function than if we just reconstructed it. However, if we smarten up worker-wrapper so that it drops unused arguments, this could be a win when not all of the fields are used, e.g. if we add another field to D:
{{{
Gnam.foo [InlPrag=INLINE[0]]
:: forall t_alp.
((Gnam.D, GHC.Types.Int) -> t_alp) -> Gnam.D -> t_alp
[GblId,
Arity=2,
Caf=NoCafRefs,
Str=DmdType C(S)U(U(L)L),
Unf=OtherCon []] =
\r [w_som w1_sof]
case w1_sof of _ {
Gnam.D ww_soj ww1_soo ->
case ww_soj of _ {
GHC.Types.I# ww3_son -> Gnam.$wfoo w_som ww3_son ww1_soo;
};
};
}}}
Now ww1_soo is passed, even though it is only ever used to rebox the value. I think there is a comment to this effect in the simplifier already. Passing boxed value would require exactly the same number of function arguments, but save on a heap allocation!" ezyang
9291 9 heisenbug Don't reconstruct sum types if the type subtly changes Compiler 7.8.2 new normal 2014-10-22T23:38:23Z "Consider this test case:
{{{
module Main (main) where
fun :: Either Int String -> Either String String
fun x = case x of
Left int -> Left (show int)
Right str -> Right str
{-# NOINLINE fun #-}
main :: IO ()
main = do
l Data.Either.Either GHC.Base.String GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType ]
Main.fun =
\ (x_aur :: Data.Either.Either GHC.Types.Int GHC.Base.String) ->
case x_aur of _ [Occ=Dead] {
Data.Either.Left int_aus ->
Data.Either.Left
@ GHC.Base.String
@ GHC.Base.String
(GHC.Show.$fShowInt_$cshow int_aus);
Data.Either.Right str_aCG ->
Data.Either.Right @ GHC.Base.String @ GHC.Base.String str_aCG
}
}}}
There would be less allocations and probably perform better if we just coerced `x` into the new type. Because the coercion is common code, this also means that if hypothetically some other sum type which had 15 constructors, and only 3 had subtle type changes, 12 of the case branches could be CSE'd into the single coerce greatly reducing code generated and also hinting the inliner better." schyler
3372 41 howard_b_golden@…, ezyang@… Allow for multiple linker instances Compiler 7.12.1 new low 2014-12-23T13:33:45Z "Right now there is only one RTS linker with a single symbol table.This means, for example, that one cannot have multiple instances of the GHC interpreter in the same process running simultaneously.
" jcpetruzza
10571 3 hvr GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts Compiler 7.10.1 new high 2015-07-03T16:15:44Z "For numbers other than 1, anyway.
{{{
$ ghc -e 'Data.Bits.shiftL 1 (-1)'
-9223372036854775808
$ ghc -e 'Data.Bits.shiftL 2 (-1)'
zsh: segmentation fault ghc -e 'Data.Bits.shiftL 2 (-1)'
$ ghc -e 'Data.Bits.shiftL 100 (-1)'
zsh: segmentation fault ghc -e 'Data.Bits.shiftL 100 (-1)'
}}}
This also happens with a compiled program. It doesn't with {{{shiftR}}} in either case though.
Side notes:
- On OS X, when the first operand is also negative, I get a {{{bus error}}} instead of a {{{segmentation fault}}}. Linux gives {{{segmentation fault}}} on both.
- On Linux, you have to use {{{ghci}}} instead of {{{-e}}}, for some (probably unrelated?) reason)." anders_
8123 3 hvr GHCi warns about -eventlog even though it's sometimes necessary GHCi 7.6.3 new normal 2015-07-19T21:49:19Z "If I invoke GHCi as {{{ghci -eventlog}}}, it says: {{{Warning: -debug, -threaded and -ticky are ignored by GHCi}}}. However, the flag does make a difference, in that GHCi will be able to load object files that were compiled using {{{-eventlog}}}. For this reason, I don't think {{{-eventlog}}} should trigger the warning.
Also runghc has the same issue." akio
8316 3 hvr GHCi debugger segfaults when trying force a certain variable GHCi 7.6.3 new normal 2014-11-19T20:48:04Z "The file Test.hs has following definitions:
{{{
whnf :: a -> IO ()
whnf a = a `seq` (return ())
foo :: [Int]
foo = [1..]
}}}
Calling ghci as:
{{{
ghci Test.hs -ignore-dot-ghci
}}}
and bebugging foo like this:
{{{
*Main> :b foo
Breakpoint 0 activated at Test.hs:5:7-11
*Main> foo
Stopped at Test.hs:5:7-11
_result :: [Int] = _
[Test.hs:5:7-11] *Main> :p foo
foo = (_t1::[Int])
[Test.hs:5:7-11] *Main> whnf _t1
}}}
results in this segault:
{{{
: internal error: TSO object entered!
(GHC version 7.6.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci
}}}" guest
8487 3 hvr Debugger confuses variables GHCi 7.7 new normal 2015-03-23T05:24:57Z "Consider the following example:
{{{
import Control.Exception
f = do
ma return a
Left err -> return $ show (err :: SomeException)
where
a :: String
a = error ""hi""
}}}
Load into ghci, set a breakpoint on the 5th line, then run f:
{{{
:break 5
f
}}}
You will get
{{{
Stopped at Ex.hs:(5,3)-(7,53)
_result :: IO String = _
a :: Either SomeException String = Left _
}}}
This doesn't make sense. `a` has type `String`; it is `ma` that has type `Either SomeException String`." edsko
8645 3 hvr Improper response from GHCI terminal after importing Gnuplot package GHCi 7.6.3 infoneeded normal 2014-11-17T13:59:04Z "I recently tried one simple example on plotting using Haskell wrapper for Gnuplot on ubuntu using this example:[http://www.linuxquestions.org/questions/blog/hydramax-533365/quick-and-dirty-plotting-with-haskell-gnuplot-35230/] . It works fine, but after I close the graph window and type anything in GHCI terminal, it doesn't show it being typed. On entering text and pressing return it executes it in a normal way.
I tried with unloading all modules but to no avail. Has someone else faced it earlier ?
GHC : 7.6.3 Linux : Ubuntu 12
" pankajsejwal
8925 3 hvr :print and :sprint sometimes fully evaluates strings GHCi 7.8.1 new normal 2014-04-12T12:12:54Z "Not too confident in my terminology but `:sprint`ing a string that has been evaluated down to its spine seems to fully evaluate the string:
{{{
Prelude> let a = map (Debug.Trace.trace ""!!!"") ""abc""
Prelude> a `seq` ()
()
Prelude> :sprint a
a = _ : _ -- looks fine
Prelude> length a
3
Prelude> :sprint a
a = ""!!! -- strange!
a!!!
b!!!
c""
}}}
What I expect to see is `a = [_,_,_]`. `:print` behaves similarly. Since neither `:print` nor `:sprint` is supposed to force any evaluation this seems like a bug. At least it can make debugging quite confusing if you're not aware of it!" soapie
8948 3 hvr Profiling report resolution too low Profiling 7.6.3 new normal 2014-04-02T16:07:55Z "When running criterion benchmarks under profiling, the criterion internals usually dominate the report. That means that the code you actually care about ends up with very low percentages:
{{{
individual inherited
COST CENTRE MODULE no. entries %time %alloc %time %alloc
...
Full Data.HashMap.Base 360 725180 0.2 0.5 0.4 0.9
Leaf/neq Data.HashMap.Base 364 5151 0.0 0.0 0.0 0.0
BitmapIndexed/update Data.HashMap.Base 362 227250 0.1 0.2 0.2 0.3
BitmapIndexed/insert Data.HashMap.Base 365 78376 0.0 0.0 0.0 0.0
Leaf/neq Data.HashMap.Base 363 132411 0.0 0.1 0.0 0.1
BitmapIndexed/insert Data.HashMap.Base 361 191597 0.0 0.1 0.0 0.1
BitmapIndexed/update Data.HashMap.Base 357 4545 0.0 0.0 0.0 0.0
BitmapIndexed/insert Data.HashMap.Base 359 3030 0.0 0.0 0.0 0.0
Leaf/neq Data.HashMap.Base 358 1515 0.0 0.0 0.0 0.0
BitmapIndexed/insert Data.HashMap.Base 356 1414 0.0 0.0 0.0 0.0
Leaf/neq Data.HashMap.Base 355 101 0.0 0.0 0.0 0.0
Empty Data.HashMap.Base 354 101 0.0 0.0 0.0 0.0
}}}
If you're interested in comparing the relative time spent in these functions, that's not really possible as these numbers have too low accuracy." tibbe
9173 3 hvr Better type error messages Compiler 7.8.2 new normal 2015-07-31T17:37:42Z "Generating better type-error messages is a hoary chestnut, but Herbert brought my attention to [https://pay.reddit.com/r/haskell/comments/26tcrk/curious_with_a_bit_of_beginner_ranting_about_some/ this thread on reddit], which has the following idea.
At the moment, from
{{{
module Foo where
addThree = \x -> x + 3 :: Int
y = addThree $ Just 5
}}}
we get this error:
{{{
Foo.hs:2:20
Couldn't match expected type `Int' with actual type `Maybe a0'
In the return type of a call of `Just'
In the second argument of `($)', namely `Just 5'
In the expression: addThree $ Just 5
}}}
Maybe we could generate this instead
{{{
Foo.hs:2:20
inferred: ""Just 5"" has type ""Maybe a0""
expected: second argument of ""($)"" must have type ""Int""
in the expression: addThree $ Just 5
}}}" simonpj
9280 3 hvr GHCi crash: illegal text-relocation to _ in _ from _ in _ for architecture x86_64; relocation R_X86_64_PC32 against undefined symbol _ can not be used when making a shared object GHCi 7.8.2 new normal 2014-07-07T15:20:06Z "Given a statically-linked Haskell object file, interactive GHCi 7.8.2 crashes.
{{{
$ cat >Foo.hs <: user specified .o/.so/.DLL could not be loaded (mylib.so: cannot open shared object file: No such file or directory)
Whilst trying to load: (dynamic) mylib.so
Additional directories searched: (none)
It's interesting that GHCi searches ./ and identifies the correct object file, but then fails to load it. I have also tried the path ./*.so, mylib.so and ./mylib.so for the GHCi option.
However, if I move mylib.so to a directory ./Temp,
$ ghci Foo Temp/*.so
loads without issue." crockeea
9643 3 hvr ghci must be restarted to use break point more than once? GHCi 7.8.3 new normal 2014-11-10T19:46:04Z "When I set a break point (in main say) I stop there when I run
the function, but if I run the function again the break point is
ignored. Restarting ghci and resetting the break point makes it
effective again, but this seems strange. Is this a bug or a feature?
Also, when I run :trace after stopping at a break point, the remainder of the function is run, and :back complains that I cannot go backwards because I am not at a break point.
Thanks,
Dominick" dsamperi
9765 3 hvr Strange behavior of GC under ghci GHCi 7.8.3 new normal 2014-11-06T07:38:42Z "Releasing the result of `newForeignPtr nullFunPtr nullPtr` end in core dump, due to the fact that finalizer function is set to null pointer.
When I run something like this in GHCI:
{{{#!hs
> import System.Mem
> import Foreign.Ptr
> import Foreign.ForeignPtr
> import System.IO.Unsafe
> import qualified Data.Map as Map
> a print a
fromList [(1,0x0000000000000000)]
> performGC
> ^D
Leaving GHCi.
[1] 3782 segmentation fault (core dumped) ghci
}}}
it wont crash until exit from ghci which is correct. But if I do something similar but using `let` binding it will crash even if variable `a` didn't lose its scope
{{{#!hs
> import System.Mem
> import Foreign.Ptr
> import Foreign.ForeignPtr
> import System.IO.Unsafe
> import qualified Data.Map as Map
> let a = Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr)
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
> print a
fromList [(1,0x0000000000000000)]
[1] 3842 segmentation fault (core dumped) ghci
}}}
Why is there a difference between doing it with `do` notation and with `let` binding?
I also expected that if I rebind variable `a` it will lose it's scope and will be released but it is not (see below)
{{{#!hs
> import System.Mem
> import Foreign.Ptr
> import Foreign.ForeignPtr
> import System.IO.Unsafe
> import qualified Data.Map as Map
> a print a
fromList [(1,0x0000000000000000)]
> a performGC
> -- no crash, varaible a not released
}}}
" remdezx
9979 3 hvr Performance regression GHC 7.8.4 to GHC HEAD Compiler 7.11 new normal 2015-03-02T13:52:16Z "Testing with HEAD 023439980f6ef6ec051f676279ed2be5f031efe6
Baseline: GHC 7.8.4
{{{
ghc-config 7.8.4
cabal unpack haskell-src-exts
cd haskell-src-exts-1.16.0.1/
cabal install --dependencies-only
time (cabal clean && cabal build)
real 2m38.696s
user 5m17.256s
sys 3m44.732s
}}}
Test : GHC HEAD
{{{
ghc-config 7.11.20150112
cabal install --dependencies-only
time (cabal clean && cabal build)
real 3m35.027s
user 6m45.664s
sys 5m15.220s
}}}" alanz
10160 3 hvr GHCi :sprint has odd/unhelpful behavior for values defined within the REPL GHCi 7.8.4 new normal 2015-04-19T18:25:10Z "Wanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain this. I don't think it technically violates Haskell Report requirements, but it makes :sprint considerably less useful if you're teaching somebody non-strictness.
Examples with code in the REPL:
{{{
Prelude> let x = [1, 2, 3 :: Integer]
Prelude> :sprint x
x = [1,2,3]
-- errr, what?
Prelude> let x = Just (1 :: Integer)
Prelude> :sprint x
x = Just 1
Prelude> let just = Just
Prelude> let x = just (1 :: Integer)
Prelude> :sprint x
x = _
Prelude> let x = Just (undefined :: Integer)
Prelude> :sprint x
x = Just _
Prelude> let x = just (undefined :: Integer)
Prelude> :sprint x
x = _
Prelude> let x = [1, 2, 3 :: Integer]
Prelude> let y = x
Prelude> :sprint y
y = [1,2,3]
Prelude> let x = 1 : 2 : (3 :: Integer) : []
Prelude> :sprint x
x = [1,2,3]
Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)]
Prelude> :sprint x
x = _
Prelude> let y = (:)
Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` []))
Prelude> :sprint x
x = _
Prelude> x
[1,2,3]
Prelude> :sprint x
x = [1,2,3]
}}}
So the behavior here seems to be:
Constructors used directly in the construction of data and are not passed functions (including polymorphic vals awaiting concrete instances)/bottoms are immediately evaluated
Example, but with loading data from a file:
Contents of the file:
{{{
x :: Num a => [a]
x = [1, 2, 3]
}}}
GHCi session:
{{{
Prelude> :t x
x :: Num a => [a]
Prelude> :sprint x
x = _
Prelude> x
[1,2,3]
Prelude> :sprint x
x = _
-- ^^ this is expected
}}}
Then when x is loaded from a file, but has a different type:
{{{
Prelude> :t x
x :: [Integer]
Prelude> :sprint x
x = _
Prelude> head x
1
Prelude> :sprint x
x = [1,2,3]
-- ^^ this is not
}}}
Now, this is a bit confusing. Earlier I was able to get :sprint to return [1, _, _] when I evaluated head x, but a couple hours later when I went to write this ticket, I couldn't reproduce that behavior.
Is there documentation that explains:
1. Why data is shown as having been evaluated at time of declaration (seemingly) by :sprint when it's defined in the GHCi
2. Why declaring code in GHCi and loading it from a file behaves differently with :sprint (I considered let expression in the implicit GHCi do-block...couldn't find anything to explain this)
3. Why evaluating 'head x' forces the other values as well
Are any of these behaviors a bug? If not, are they documented anywhere? Is the ""eager"" treatment of constructors in GHCi a performance thing? That seems strange given I didn't have -fobject-code turned on.
:sprint not demonstrating semantics that match what I expect from a non-strict language hinders its utility as a teaching tool and means the only robust option for learners that I can find is testing evaluation with bottom values.
{{{
-- So that you know i picked ""7.8.4"" as the version consciously
[callen@atlantis ~/Work/fpbook]$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
[callen@atlantis ~/Work/fpbook]$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
}}}" bitemyapp
10179 3 hvr Kinds missing from types in ghci GHCi 7.10.1-rc2 new normal 2015-03-23T13:18:37Z "{{{
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
data family F (a:: k)
foo :: F (m :: [()]) -> a
foo = undefined
bar :: F (m :: [[()]]) -> a
bar = undefined
}}}
according to GHCi, both `foo` and `bar` have type `F m -> a` but `[foo, bar]` fails" br1
10477 3 hvr Tab-completing in a directory with Unicode heiroglyph crashes ghci GHCi 7.10.1 new normal 2015-06-04T16:22:42Z "With a file called 𓅖.hs in `C:\Users\acfoltzer`, the following in `cmd.exe`:
{{{
C:\Users\acfoltzer>chcp 65001
Active code page: 65001
C:\Users\acfoltzer>ghci
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> :l C:\cygwin\home\acfoltzer\
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.10.1 for i386-unknown-mingw32):
Enum.toEnum{Word16}: tag (78166) is outside of bounds (0,65535)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
Here, I'm setting the code page first according to the various bits of folk wisdom on the Internet about getting Unicode to properly display in `cmd.exe`. I don't get this crash with a Cygwin terminal, but rather see `??.hs`.
I came across this because I was getting the same exception in the Cryptol REPL, so I suspect it's not unique to GHCi, but is rather something fishy in base." acfoltzer
10576 3 hvr REPL returns list of all imported names when operator completion requested GHCi 7.8.4 Geraldus new normal 2015-07-03T17:53:58Z "When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions.
For example, if you simply start GHCi and run `:complete repl "">>""` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also.
In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge.
GHCi behaves similarly with following queries:
{{{
:complete repl ""(>>""
:complete repl ""Prelude.>>""
:complete repl ""Prelude.(>>""
}}}
I only tested this on OS X 10.9, GHC 7.8.4
" Geraldus
10579 3 hvr full module names of names not in scope have gone missing in ghci GHCi 7.11 simonpj new normal 2015-07-07T07:29:52Z "Compare
{{{
rwbarton@morphism:/tmp$ ghci-7.10.1
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> :t GHC.Read.readPrec
GHC.Read.readPrec
:: Read a => Text.ParserCombinators.ReadPrec.ReadPrec a
}}}
with
{{{
rwbarton@morphism:/tmp$ ~/ghc/inplace/bin/ghc-stage2 --interactive
GHCi, version 7.11.20150624: http://www.haskell.org/ghc/ :? for help
Prelude> :t GHC.Read.readPrec
GHC.Read.readPrec :: Read a => ReadPrec a
}}}
The `Text.ParserCombinators.ReadPrec.` bit can be quite helpful, was it suppressed intentionally?" rwbarton
10616 3 hvr Panic in ghci debugger with PolyKinds and PhantomTypes GHCi 7.10.1 new normal 2015-07-08T21:00:39Z "Potentially related: #10617 (I noticed that one first, and in simplifying the code it changed to this error - note TcUnify.hs vs TcType.hs)
The code
{{{#!hs
{-# LANGUAGE PolyKinds #-}
data D a = A | B
f d@A = const True d
f B = False
}}}
when loaded in ghci, runs fine without breakpoints, but panics when breaking on {{{f A}}}, thus:
{{{
*Main> f A
True
*Main> :break 5
Breakpoint 0 activated at DebuggerCrash.hs:5:9-20
*Main> f A
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
ASSERT failed! file compiler/typecheck/TcUnify.hs line 1138 k_amp
}}}
It is fine in 7.4.1 and 7.8.1.
It panics in 7.10.1 and HEAD@d71b65f53a1daa2631d2c818c7ea6add77813532
Without one (or both) of PolyKinds or the phantom type it runs fine.
{{{uname -a: Linux cam-05-unx 3.5.0-54-generic #81~precise1-Ubuntu SMP Tue Jul 15 04:02:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux}}}
{{{
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
}}}
With {{{ghci-7.10.1 -v}}}
{{{
ghci-7.10.1 -v ./DebuggerCrash.hs
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.8.2
Using binary package database: /5playpen/t-bepric/ghc-7.10.1-build/inplace/lib/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace
wired-in package base mapped to base-4.8.0.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace
wired-in package ghc mapped to ghc-7.10.1-inplace
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
Loading package ghc-prim-0.4.0.0 ... linking ... done.
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/5playpen/t-bepric/ghc-7.10.1-build/libraries/integer-gmp2/dist-install/build --print-file-name libgmp.so
Loading package integer-gmp-1.0.0.0 ... linking ... done.
Loading package base-4.8.0.0 ... linking ... done.
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace
wired-in package base mapped to base-4.8.0.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace
wired-in package ghc mapped to ghc-7.10.1-inplace
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep []
Upsweep completely successful.
*** Deleting temp files:
Deleting:
*** Chasing dependencies:
Chasing modules from: *DebuggerCrash.hs
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2015-07-08 14:18:11 UTC
ms_mod = Main,
ms_textual_imps = [import (implicit) Prelude]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file DebuggerCrash.hs
Created temporary directory: /tmp/ghc22370_0
*** Checking old interface for Main:
[1 of 1] Compiling Main ( DebuggerCrash.hs, interpreted )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size of Desugar (before optimization)
= {terms: 16, types: 26, coercions: 0}
Result size of Desugar (after optimization)
= {terms: 12, types: 18, coercions: 0}
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 12, types: 20, coercions: 0}
Result size of Simplifier = {terms: 12, types: 20, coercions: 0}
*** Tidy Core:
Result size of Tidy Core = {terms: 12, types: 20, coercions: 0}
*** CorePrep:
Result size of CorePrep = {terms: 16, types: 30, coercions: 0}
*** ByteCodeGen:
Upsweep completely successful.
*** Deleting temp files:
Deleting: /tmp/ghc22370_0/ghc22370_2.c /tmp/ghc22370_0/ghc22370_1.o
Warning: deleting non-existent /tmp/ghc22370_0/ghc22370_2.c
Warning: deleting non-existent /tmp/ghc22370_0/ghc22370_1.o
Ok, modules loaded: Main.
*Main> f A
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
True
*Main> :break 5
Breakpoint 0 activated at DebuggerCrash.hs:5:9-20
*Main> f A
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
ASSERT failed! file compiler/typecheck/TcUnify.hs line 1138 k_amp
}}}
" bjmprice
10617 3 hvr Panic in GHCi debugger with GADTs, PolyKinds and Phantom types GHCi 7.10.1 new normal 2015-07-08T14:55:01Z "Potentially related: #10616 (I noticed this one first, and in simplifying the code it changed to that error - note TcUnify.hs vs TcType.hs)
The code
{{{#!hs
{-# LANGUAGE GADTs , PolyKinds #-}
data AppTreeT (a::k) where
Con :: AppTreeT a
App :: AppTreeT a -> AppTreeT b -> AppTreeT (a b)
tmt :: AppTreeT (Maybe Bool)
tmt = App (Con :: AppTreeT Maybe) Con
f :: AppTreeT a -> Bool
f (App (c@Con) _) = const True c
f _ = False
}}}
when loaded in ghci runs fine without breakpoints, but panics when breaking on {{{f (App )c@Con) _) = ...}}}:
{{{
*Main> f tmt
True
*Main> :break 11
Breakpoint 0 activated at DebuggerCrash2.hs:11:21-32
*Main> f tmt
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150708 for x86_64-unknown-linux):
ASSERT failed! file compiler/typecheck/TcType.hs line 739 k_anx
}}}
It fails to load in 7.4.1: {{{DebuggerCrash2.hs:3:19: parse error on input `k'}}}
It fails to load in 7.8.2:
{{{
DebuggerCrash2.hs:5:50:
Kind occurs check
The first argument of ‘a’ should have kind ‘k0’,
but ‘b’ has kind ‘k0 -> k1’
In the type ‘AppTreeT (a b)’
In the definition of data constructor ‘App’
In the data declaration for ‘AppTreeT’
}}}
It has the panic in both 7.10.1 and HEAD@d71b65f53a1daa2631d2c818c7ea6add77813532
{{{uname -a: Linux cam-05-unx 3.5.0-54-generic #81~precise1-Ubuntu SMP Tue Jul 15 04:02:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux}}}
{{{
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
}}}
With {{{ghci-7.10.1 -v}}}
{{{
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.8.2
Using binary package database: /5playpen/t-bepric/ghc-7.10.1-build/inplace/lib/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace
wired-in package base mapped to base-4.8.0.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace
wired-in package ghc mapped to ghc-7.10.1-inplace
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
Loading package ghc-prim-0.4.0.0 ... linking ... done.
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/5playpen/t-bepric/ghc-7.10.1-build/libraries/integer-gmp2/dist-install/build --print-file-name libgmp.so
Loading package integer-gmp-1.0.0.0 ... linking ... done.
Loading package base-4.8.0.0 ... linking ... done.
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace
wired-in package base mapped to base-4.8.0.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-inplace
wired-in package ghc mapped to ghc-7.10.1-inplace
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from:
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep []
Upsweep completely successful.
*** Deleting temp files:
Deleting:
*** Chasing dependencies:
Chasing modules from: *DebuggerCrash2.hs
Stable obj: []
Stable BCO: []
unload: retaining objs []
unload: retaining bcos []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2015-07-08 13:56:59 UTC
ms_mod = Main,
ms_textual_imps = [import (implicit) Prelude]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file DebuggerCrash2.hs
Created temporary directory: /tmp/ghc22446_0
*** Checking old interface for Main:
[1 of 1] Compiling Main ( DebuggerCrash2.hs, interpreted )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size of Desugar (before optimization)
= {terms: 32, types: 72, coercions: 1}
Result size of Desugar (after optimization)
= {terms: 26, types: 55, coercions: 0}
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 24, types: 79, coercions: 2}
Result size of Simplifier = {terms: 21, types: 76, coercions: 2}
*** Tidy Core:
Result size of Tidy Core = {terms: 31, types: 109, coercions: 4}
*** CorePrep:
Result size of CorePrep = {terms: 45, types: 157, coercions: 5}
*** ByteCodeGen:
Upsweep completely successful.
*** Deleting temp files:
Deleting: /tmp/ghc22446_0/ghc22446_2.c /tmp/ghc22446_0/ghc22446_1.o
Warning: deleting non-existent /tmp/ghc22446_0/ghc22446_2.c
Warning: deleting non-existent /tmp/ghc22446_0/ghc22446_1.o
Ok, modules loaded: Main.
*Main> f tmt
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
True
*Main> :break 11
Breakpoint 0 activated at DebuggerCrash2.hs:11:21-32
*Main> f tmt
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
ASSERT failed! file compiler/typecheck/TcType.hs line 730 k_an3
}}}
" bjmprice
10633 3 hvr GHCi segfaults on arm GHCi 7.10.1 new normal 2015-07-12T13:11:57Z "I define a data type:
{{{#!hs
data Tree a = Leaf a | Tree { left :: Tree a
, right :: Tree a } deriving Show
}}}
Then I create a few named trees:
{{{#!hs
testTree0 = Leaf 0
testTree1 = Tree (Leaf 0) (Leaf 0)
testTree2 = Tree testTree0 testTree0
testTree3 = Tree testTree1 testTree1
testTree4 = Tree (Tree (Leaf 0) (Leaf 0)) (Tree (Leaf 0) (Leaf 0))
}}}
This segfaults in GHCi (works fine with non-interactive GHC):
{{{#!hs
main = print testTree3
}}}
== Notes ==
* testTree3 and testTree4 represent the same tree, constructed in different ways. However, testTree3 segfaults when it tries to print the second testTree1; testTree4 does not.
* entering 'print testTree1' twice segfaults, but only if it is twice in a row.
* strangely enough, printing testTree4 repeatedly does not segfault.
* printing testTree0 many times in a row doesn't segfault either.
* printing testTree2 segfaults.
It seems to be something to do with repetition or reevaluation of the same named structure. I haven't yet managed to determine whether the print is relevant or whether it's forcing the evaluation of the data structure that causes the segfault (Can't remember how to force a list but discard the result). I have attached the the output from running ghci with +RTS -Di. Let me know if there's anything else I should try." Thra11
8642 3 hvr Allow GHCi to print non-pretty forms of things. GHCi 7.9 new normal 2014-07-29T19:50:05Z "Currently when we ask GHCi for :info or :type of something, it will do things like splitting over multiple lines and all that eye candy that people like to see. This however makes it more difficult for people to write text editor plugins &c that rely on GHCi output.
Currently one has to write parsers to stitch the GHCi output back together which is fairly error prone and not really future-proof.
Is there any chance for a more machine-friendly output?" Fuuzetsu
9360 3 hvr GHCi: Behave nicely on `-e`, like `ghc` and other programs GHCi 7.8.2 lukyanov new normal 2015-03-19T12:02:31Z "Like many programming language environments, GHC offers a handy `-e` option for evaluating an expression, then returning to the shell.
{{{
$ ghc -e '2 + 2'
4
}}}
One would expect the interpreter, GHCi, to offer a similar flag, but it surprisingly rejects it.
{{{
ghci -e '2 + 2'
ghc: on the commandline: cannot use `--interactive' with `-e'
Usage: For basic information, try the `--help' option.
}}}
I think this behavior is quite unintuitive--when I pass `-e ` to ghci, or pass `--interactive -e ` to ghc, I expect the expression to be evaluated as the leading expression in an interactive interpreter session.
Could we please tweak ghc like this to make it slightly more intuitive when these flags are used together?" mcandre
9690 3 hvr in GHCi map `:editNNN` to $EDITOR +NNN GHCi 7.8.3 new normal 2014-10-14T07:53:13Z "I suggest to treat GHCi REPL commands `:editNNN` (as well as equivalent abbreviations, like `:eNNN` ) where `NNN` is a natural number, as invocations of the text editor with a `+NNN` option.
Rationale: When I see a type error in line 42 then I'd like to visit this line directly with `:e42`. Optionally one could implement `:eNNN:CCC` to also target the column `CCC` in that line.
`emacs`, `vi` and `pico` all implement the option `+NNN` to land in the line `NNN`." heisenbug
9887 3 hvr No message when GCHI reusing compiled code GHCi 7.8.3 new normal 2015-03-02T00:49:56Z "Running "":l Main.hs"" at the GHCI prompt would load the compiled module. I am new to Haskell and this was a stumbling block that made it so that I could not interactively debug my code with GHCI. Deleting the object files was suggested to me on IRC and that allowed me to get the ""*Main"" prompt I was looking for. A message warning users ""reusing compiled code"" would likely save some future users some time." jsrice
9995 3 hvr :info enhancements GHCi 7.8.4 new normal 2015-03-06T01:07:28Z "`:info` is a very useful ghci command, but there are several improvements that could be made:
1. It would be useful if `:i` showed not only which module a name is defined in, but which module(s) it was imported from in the current session.
2. A variant of `:i` that just prints a definition, rather than a definition and all instances, would be useful in many cases. E.g. `:i Show` prints the definition of `Show`, but then it prints so many instances that the definition is scrolled way off the screen.
3. `:i ->` is a parse error; it should behave like `:i (->)`, the way it works for other type-level operators.
4. hvr had some more suggestions: ""finding out which package a module belongs to"", ""and what module an 'as'-alias is associated with"". (Currently I think modules are out of `:info`'s scope, but perhaps it would be a useful addition.)" shachaf
9996 3 hvr Support symbols in GHCi tab completion GHCi 7.8.4 new normal 2015-01-16T01:23:05Z Right now, when typing e.g. `>` followed by two tabs, GHCi shows every name in scope rather than just names beginning with `>`. It even lists operators as possible completions, but ignores it when you type the beginning of an operator's name. It would be better if it could actually complete every option it shows as a possible completion. shachaf
10249 3 hvr Suboptimal error message with deferred type errors GHCi 7.10.1 new normal 2015-04-06T20:48:57Z "{{{#!hs
$ ghci -fdefer-type-errors -ignore-dot-ghci
GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help
Prelude> _
:2:1: Warning:
Found hole ‘_’ with type: IO t0
Where: ‘t0’ is an ambiguous type variable
In the first argument of ‘GHC.GHCi.ghciStepIO ::
IO a_aly -> IO a_aly’, namely
‘_’
In a stmt of an interactive GHCi command:
it IO a_aly _
*** Exception: :2:1:
Found hole ‘_’ with type: IO t0
Where: ‘t0’ is an ambiguous type variable
In the first argument of ‘GHC.GHCi.ghciStepIO ::
IO a_aly -> IO a_aly’, namely
‘_’
In a stmt of an interactive GHCi command:
it IO a_aly _
(deferred type error)
Prelude>
}}}
It should ideally not expose `ghciStepIO` to the user." Iceland_jack
10323 3 hvr Add Android and iOS Operating Systems in Trac Trac & Git hvr new normal 2015-04-18T15:41:05Z These are sufficiently different from Linux/MacOS X to be distinguished from those Operating System values, and sufficiently mainstream to not fall under Other. rwbarton
1407 3 hvr Add the ability to :set -l{foo} in .ghci files GHCi 6.6.1 7.10.1 archblob new normal 2015-06-12T08:02:34Z "Currently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ignored in both 6.4.2 and 6.6.
The only other place it would make sense to pass it would be as something like OPTIONS_GHC, but that results in ""unknown flags in {-# OPTIONS #-} pragma: -lidn"" in 6.4.2 and appears to be silently ignored in 6.6." guest
10053 3 hvr "Regression on MacOS platform, error in ghci calling main after loading compiled code: ""Too late for parseStaticFlags...""" GHCi 7.10.1-rc2 7.10.3 new normal 2015-06-15T14:29:47Z " ghci
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help
Prelude> :load rsa
Ok, modules loaded: Main.
Prelude Main> :show modules
Main ( rsa.hs, rsa.o )
Prelude Main> main
Too late for parseStaticFlags: call it before runGhc or runGhcT
Exception: ExitFailure 1
Prelude Main>
note, there is no failure if I load interpreted code" George
10520 3 hvr RecordWildCards causes “is not a (visible) field of constructor” in ghci GHCi 7.10.1 7.10.3 merge normal 2015-06-15T16:44:24Z "{{{
% ghc -ignore-dot-ghci -e 'data Foo = Bar { baz :: Integer } deriving Show' -e 'Bar 42' -e '(Bar 42){ baz = 43 }' -e 'Bar { baz = 42 }'
Bar {baz = 42}
Bar {baz = 43}
Bar {baz = 42}
}}}
{{{
% ghc -ignore-dot-ghci -XRecordWildCards -e 'data Foo = Bar { baz :: Integer } deriving Show' -e 'Bar 42' -e '(Bar 42){ baz = 43 }' -e 'Bar { baz = 42 }'
Bar {baz = 42}
Bar {baz = 43}
:1:7:
‘baz’ is not a (visible) field of constructor ‘Bar’
}}}
{{{
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.1
}}}
" ion1
1620 3 hvr ModBreaks.modBreaks_array not initialised GHCi 7.8.2 7.12.1 new normal 2014-12-23T13:34:10Z "Somehow the following came up:
*** Exception: ModBreaks.modBreaks_array not initialised" guest
7133 3 hvr GHCi: strange behaviour after CTRL-C, followed by 'hPutChar: resource vanished (Broken Pipe)' when quitting GHCi 7.4.1 7.12.1 tibbe infoneeded normal 2014-12-23T13:34:10Z "Example: (launching GHCi from Terminal.app)
{{{
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 1
1
Prelude> [1..]
^CPrelude> 1
^CPrelude> 10
^CPrelude> 1+2
^CPrelude> :q
: hPutChar: resource vanished (Broken pipe)
}}}
This behaviour does not occur when I run GHCi from within Aquamacs (some output elided):
{{{
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 1
1
Prelude> [1..]
[1,2,3,4,5, ... 475,476,47 ^C ^C7,478,479,480, ... 539,540,541Interrupted.
Prelude> 1
1
Prelude> :q
Leaving GHCi.
Process haskell finished
}}}
I'm using the Haskell Platform for Mac OSX, 2012.2.0.0 32 bit, running on OSX 10.6.8." DuncanMortimer
9034 3 hvr GHCi panics when given C++ object file on GNU/Linux GHCi 7.8.2 7.12.1 new normal 2014-12-23T13:34:10Z "When given a C++ object file, GHCi panics saying that it can't find standard C++ symbols the object file relies on. If foo.cc contains
{{{#!C++
#include
extern ""C""
void foo ()
{
std::cout << ""bar"";
}
}}}
and is compiled with
{{{
g++ -fPIC -c -o foo.o foo.cc
}}}
then
{{{
ghci foo.o -lstdc++
}}}
fails with
{{{
GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) foo.o ... ghc: panic! (the 'impossible' happened)
(GHC version 7.8.2 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc14109_0/ghc14109_1.so: undefined symbol: _ZSt4cout
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
It makes no difference to add -L which was, IIRC, necessary in older versions of GHC. This applies to only GHCi with C++ -- GHC can link C++ object files just fine, while GHCi has no trouble loading C object files." jun0
9046 3 hvr Panic in GHCi when using :print GHCi 7.8.2 7.12.1 new normal 2014-12-23T13:34:10Z "When using names generated by :print, GHCi panics sometimes. According to #ghc, this is reproducible on ''x86_64-apple-darwin'' as well, but is not an issue in ''7.6.3 x86_64 linux''.
{{{
> let a = [1]
> :print a
a = (_t1::Num t => [t])
> :t _t1
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.2 for x86_64-unknown-linux):
tcTyVarDetails t{tv avD} [tv]
> _t1
}}}
From playing around with it a bit, this seems to have something to do with polymorphic values.
{{{
-- No panic
> let a = [1 :: Int]
> let a = 1 :: Int
> let a = ""hello""
-- Panic
> let a = [1]
> let a = 1
> let a = ""hello"" -- With -XOverloadedStrings
}}}" quchen
5850 3 hvr Greater customization of GHCi prompt GHCi 7.4.1 7.12.1 jlengyel patch normal 2015-03-02T16:03:47Z "GHCi is bit more than a Haskell interpreter. With the {{{:!}}} and {{{:cd}}} commands, we have trivial access to the shell, making it often unnecessary to leave GHCi. For this reason GHCi has become my *de facto* primary shell.
The GHCi prompt therefore needs to show a bit more than just Haskell information. Most importantly, the current working directory is often important to me.
[http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/ghci-commands.html We can indeed customize the GHCi prompt] using {{{:set prompt}}}. This takes the form of a string with a single escape sequence: {{{%s}}}, which is replaced with a list of currently loaded modules.
Most shells allow arbitrary user customization of the prompt. The {{{bash}}} prompt has [http://tldp.org/HOWTO/Bash-Prompt-HOWTO/bash-prompt-escape-sequences.html numerous escape sequences for useful information], and if those aren't enough, it allows [http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x279.html arbitrary command calls].
GHCi should gain similar customization abilities. Ways to implement this may include:
1. addition of more escape sequences, like {{{%pwd}}}.
2. addition of a single extra escape sequence with one parameter (an external command call), like like {{{%call(pwd --logical)}}}.
3. redesigning the {{{:set prompt}}} option to take not a {{{String}}} but a Haskell function, like {{{[Module] -> IO String}}}.
Option 2 would probably have the best power-to-simplicity ratio." JamesFisher
8751 3 hvr Show parenthesised output of expressions in ghci GHCi 7.6.3 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "Operator fixity can be a source of bugs (even for experienced users!),[#point1 (1)] precedence levels may vary between languages and then there are user-defined operators.
Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`:
{{{
ghci> :paren 2 + 10 * 4 / 3
2 + ((10 * 4) / 3)
ghci> :paren \a b → a == b || b && a == (b == a) || b
\ a b -> (a == b) || ((b && (a == (b == a))) || b)
ghci> :paren 5 + 1 `mod` 2
5 + (1 `mod` 2)
ghci> :paren 5 * 1 `mod` 2
(5 * 1) `mod` 2
}}}
A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting.
[=#point1 (1)] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence]" Iceland_jack
10678 3 hvr integer-gmp's runS seems unnecessarily expensive Compiler (CodeGen) 7.10.1 new normal 2015-07-27T20:59:19Z "integer-gmp uses an unsafePerformIO-like operation to work with mutable BigNats (unsafePerformIO and even the IO type are not yet available, since integer-gmp is a dependency of base):
{{{
type S s a = State# s -> (# State# s, a #)
-- NB: equivalent of GHC.IO.unsafeDupablePerformIO, see notes there
runS :: S RealWorld a -> a
runS m = lazy (case m realWorld# of (# _, r #) -> r)
{-# NOINLINE runS #-}
}}}
It's tempting to think of such an operation as ""free"" like an unsafeCoerce, but it is actually somewhat expensive.
Consider `plusBigNat` for instance. (Most BigNat operations have a similar structure.)
{{{
plusBigNat :: BigNat -> BigNat -> BigNat
plusBigNat x y
| isTrue# (eqBigNatWord# x 0##) = y
| isTrue# (eqBigNatWord# y 0##) = x
| isTrue# (nx# >=# ny#) = go x nx# y ny#
| True = go y ny# x nx#
where
go (BN# a#) na# (BN# b#) nb# = runS $ do
mbn@(MBN# mba#) unsafeFreezeBigNat# mbn
_ -> unsafeSnocFreezeBigNat# mbn c#
nx# = sizeofBigNat# x
ny# = sizeofBigNat# y
}}}
The assembly for `go` begins
{{{
00000000000001d0 :
1d0: 49 83 c4 28 add $0x28,%r12
1d4: 4d 3b a5 58 03 00 00 cmp 0x358(%r13),%r12
1db: 77 26 ja 203
1dd: 49 c7 44 24 e0 00 00 movq $0x0,-0x20(%r12)
1e4: 00 00
1e2: R_X86_64_32S .text+0x38
1e6: 4d 89 74 24 e8 mov %r14,-0x18(%r12)
1eb: 49 89 7c 24 f0 mov %rdi,-0x10(%r12)
1f0: 49 89 74 24 f8 mov %rsi,-0x8(%r12)
1f5: 4d 89 04 24 mov %r8,(%r12)
1f9: 4d 8d 74 24 e1 lea -0x1f(%r12),%r14
1fe: e9 00 00 00 00 jmpq 203
1ff: R_X86_64_PC32 integerzmgmp_GHCziIntegerziType_runS_info-0x4
203: ... ; heap overflow
}}}
This allocates a 5-word closure (containing `a#`, `na#`, `b#`, `nb#`) whose code is at `.text+0x38` and passes it to `runS`, which does some `stg_ap`-y things to call back into the closure, which reads its free variables back from the heap and finally does all the real work. Altogether it's around two dozen instructions compared to if we could call directly from `go` to the argument of `runS`.
The old integer-gmp somehow avoided this particular overhead by instead using the implicit ""unsafePerformIO"" of a foreign import prim which performed both the allocation and the addition. Is this overhead a necessary consequence of doing the work in multiple steps in Haskell?
I understand that we cannot allow everything to be inlined and, for example, the `newBigNat#` to be shared between a `plusBigNat` and `minusBigNat` with the same arguments. But once `runS` has done its job of keeping the `newBigNat#/c_mpn_add/unsafeFreeze*` together, it would be nice to eliminate it completely in the backend when compiling `go`, or any inlined version of `go`.
I'm not sure whether this should be fixed in the code generator or in integer-gmp itself. I'm also aware that this is a tricky subject but haven't really done my homework on the related tickets, so I might be missing something important!" rwbarton
10691 3 hvr certain operations in new integer-gmp are too lazy libraries (other) 7.10.1 new normal 2015-07-27T07:46:52Z "This came up in #ghc the other day.
{{{
rwbarton@morphism:~$ ghci-7.10.1
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> undefined * 0
0
}}}
For consistency not just with Int, but also other integer-* implementations, this should be undefined.
Also affected is for example `andInteger`." rwbarton
9916 3 hvr "ghc -e "":foo bar"" exit status is inconsistent" GHCi 7.8.3 new low 2014-12-22T03:35:18Z "Since #7962 `ghc -e EXPR` exits with status code 1 if `EXPR` fails to compile. While it's undocumented, `ghc -e` does also accept anything that's valid input to GHCi, including GHCi commands like `:t`. In this case, the exit code of `ghc -e` is not always 1 when the command apparently failed. For example, all of:
{{{
ghc -e ':t'
ghc -e ':t +'
ghc -e ':t ='
ghc -e ':t x'
ghc -e ':l nonexistentfile.hs'
}}}
exit with status code 0. But `ghc -e ':l a'` exits with status code 1, because `a` is not a (possible) module name or a source file.
(At the code level, `ghc -e "":foo bar""` currently exits with status code 1 when the function for `:foo` raises an exception, and with status code 0 in all other cases.)" rwbarton
10462 3 hvr GHCi doesn't work Any and missing RealWorld foreign prim imports GHCi 7.10.1 new low 2015-06-04T07:40:53Z "Here are two issues with our GHCi support for foreign prim imports:
Here is a program that works:
{{{
{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}
module Serum where
import GHC.Exts
foreign import prim ""cheneycopy"" cheneycopy :: Word# -> State# RealWorld -> (# State# RealWorld, Word# #)
}}}
If I remove the world token passing, as in here:
{{{
{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}
module Serum where
import GHC.Exts
foreign import prim ""cheneycopy"" cheneycopy :: Word# -> Word#
}}}
I get:
{{{
(GHC version 7.10.1 for x86_64-unknown-linux):
ByteCodeGen.generateCCall: missing or invalid World token?
}}}
Another error is if I try to pass Any as an argument:
{{{
{-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-}
module Serum where
import GHC.Exts
foreign import prim ""cheneycopy"" cheneycopy :: Any -> State# RealWorld -> (# State# RealWorld, Word# #)
}}}
Then I get:
{{{
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
primRepToFFIType
}}}
Note to anyone who is running into this problem: an easy workaround is to use `-fobject-code` which bypasses bytecode generation." ezyang
9748 3 hvr Disambiguate IO actions in GHCi with :set +t GHCi 7.8.2 new low 2015-07-03T11:05:58Z "Currently GHCi's `:set +t` displays the same type for the following:
{{{#!hs
% ghci -ignore-dot-ghci
GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :set +t
Prelude> 'a'
'a'
it :: Char
Prelude> return 'a'
'a'
it :: Char
Prelude> return 'a' :: IO Char
'a'
it :: Char
}}}
A user at `#haskell-beginners` ran into a problem where they mistook an expression that defaulted to IO for a pure expression (`Id . even pure 5`), `:set +t` was suggested but ended up showing the incorrect type:
{{{#!hs
ghci> Id . even pure 5
Id False
it :: Id Bool
}}}
This is bad for pedagogical reasons, it would be an improvement to display the following:
{{{#!hs
Prelude> :set +t
Prelude> 'a'
'a'
it :: Char
Prelude> return 'a'
'a'
it :: Char return 'a' :: IO Char
'a'
it :: Char :set -XScopedTypeVariables
Prelude> a :: Char foo.m <
BOOL is_main_thread()
{
return [NSThread isMainThread];
}
EOF
}}}
{{{
$ cat >Main.hs < main
2014-07-07 12:28:21.811 ghc[37395:1103] *** NSForwarding: warning: selector (0x10ddef328) for message 'isMainThread' does not match selector known to Objective C runtime (0x7fff8ea15881)-- abort
2014-07-07 12:28:21.813 ghc[37395:1103] +[NSThread isMainThread]: unrecognized selector sent to class 0x7fff75535280
2014-07-07 12:28:21.814 ghc[37395:1103] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSThread isMainThread]: unrecognized selector sent to class 0x7fff75535280'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff8bb4825c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff85029e75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8bb4b02d +[NSObject(NSObject) doesNotRecognizeSelector:] + 205
3 CoreFoundation 0x00007fff8baa6322 ___forwarding___ + 1010
4 CoreFoundation 0x00007fff8baa5ea8 _CF_forwarding_prep_0 + 120
5 ??? 0x000000010ddef31a 0x0 + 4527682330
6 ??? 0x000000010ddf02f5 0x0 + 4527686389
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6
}}}
" mietek
9364 12 hvr, cheater GHCi (or haskeline?) confused by non-single-width characters GHCi 7.8.3 new normal 2014-07-25T11:38:52Z "Hi,
there's an issue in the GHCi prompt.
To reproduce:
1. Do everything in Linux (I don't have other operating systems); I'm using a version of the gnome 2 gnome-terminal.
2. Use the following to colourise the prompt in GHCi:
echo -e :set prompt '""\033[32;1m%s\033[34;1m>\033[0m ""' >> ~/.ghc/ghci.conf
3. Import quite a few modules (say, 5 to 10 should be enough)
4. Give the prompt enough text that it wraps around. It's best if you start the text with -- so that it's a comment and doesn't produce any output. For example, say I entered ""-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"", I now see the following:
*Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
(do note that the first set of b's is located on the same line as the prompt, and the second is located under the prompt)
5. Press Enter. You should now see:
*Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
*Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid>
6. Press Ctrl-P or the up arrow key to select the previous history item. You will now see the following:
*Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
*Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
7. Press Ctrl-A or the Home cursor key to go to the beginning of the text entry, and then type X. You will now see the last prompt to be:
*Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbX-- bbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
8. If you press Enter, you will find out that prompt was actually (without line breaks):
X-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
I tried resizing the terminal window to 45 chars to make the lines above shorter; I imported Data.Monoid and Data.Functor in a new GHCi. The prompt contained garbage, most likely badly wrapped escape codes. See attachment.
As both likely are a single bug in disguise, I include both reports in this ticket.
Creating a test case for whether things actually work in a terminal might be difficult, but creating test for whether things get wrapped correctly (and not testing how things work out in a terminal) should be simple if annoying." cheater
7860 41 hvr, core-libraries-committee@… Add more bit fiddling functions to 'integer-gmp' Core Libraries 7.6.3 new normal 2014-11-26T16:13:21Z "Current implementation of 'integer-gmp' uses only a subset of ""bit fiddling"" features, [http://gmplib.org/manual/Integer-Logic-and-Bit-Fiddling.html provided] by the GMP library. The ones missing are:
{{{
* mpz_popcount
* mpz_setbit
* mpz_clrbit
}}}
I think it would be nice to add these functions in addition to 'testBitInteger'. Would you accept a patch?" lebedev
8772 41 hvr, core-libraries-committee@… ghci should save history more often Core Libraries 7.6.3 ekmett upstream normal 2014-11-16T14:46:29Z "It is very annoying if `ghci` crashes (due to using a foreign library wrongly, for example), and then the history is lost. It should be simple to save each line to history before it is being executed.
Maybe a good task for new contributors?" nomeata
9306 11 hvr, ekmett Crash when shifting Integers too far left Core Libraries 7.8.3 ekmett new normal 2014-10-07T05:48:24Z "When shifting an Integer very far left, the RTS crashes. On x86_64:
Prelude Data.Bits> 1 `shiftL` 100000000000000000000000 == 1
gmp: overflow in mpz type
Aborted
I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code compiled by ghc." dfeuer
9434 11 hvr, ekmett GHC.List.reverse does not fuse Core Libraries 7.9 infoneeded normal 2014-10-07T05:48:24Z "As Edward Kmett speculated could be the case a couple months ago, Joachim Breitner's call arity analysis makes the Prelude version of `reverse` better than GHC's version. It's less clear to me whether it's beneficial to wrap it in `build`, but I think the answer is ''probably'' yes, based on the fact that doing so turns `foldr c n $ reverse xs` into `foldl (flip c) n xs`.
{{{#!hs
{-# INLINE reverse #-}
reverse :: [a] -> [a]
reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs
}}}
This simplifies to
{{{#!hs
Rec {
poly_go_r2uL
poly_go_r2uL =
\ @ a_a2nn ds_a2xO eta_Xh ->
case ds_a2xO of _ {
[] -> eta_Xh;
: y_a2xT ys_a2xU -> poly_go_r2uL ys_a2xU (: y_a2xT eta_Xh)
}
end Rec }
reverse
reverse = \ @ a_a2nn eta_B1 -> poly_go_r2uL eta_B1 ([])
}}}
which looks about the same as the current version in GHC.List.
Behold the beauty when it is applied to an unfold (with a fusion-friendly version of `unfoldr`):
{{{#!hs
testReverseUnfoldr f q0 = reverse (unfoldr f q0)
}}}
simplifies to
{{{#!hs
testReverseUnfoldr
testReverseUnfoldr =
\ @ a_a2w3 @ b_a2w4 f_a2mn q0_a2mo ->
letrec {
go_a1QX
go_a1QX =
\ b1_a1Hy eta_B1 ->
case f_a2mn b1_a1Hy of _ {
Nothing -> eta_B1;
Just ds_d2d8 ->
case ds_d2d8 of _ { (a1_a1Hz, new_b_a1HA) ->
go_a1QX new_b_a1HA (: a1_a1Hz eta_B1)
}
}; } in
go_a1QX q0_a2mo ([])
}}}
This looks exactly like a hand-written `unfoldl`!" dfeuer
9936 11 hvr, ekmett Data.Fixed truncates 5.17 to 5.16 libraries/base 7.6.3 new normal 2014-12-30T11:04:15Z "`(realToFrac (5.17 :: Double) :: Centi) == 5.16`
is true -- it should be false.
The offender seems to be the assumption in `fromRational`:
`fromRational r = withResolution (\res -> MkFixed (floor (r * (toRational res))))`
Uses `floor` assuming that the underlying floating point value is stored purely and not as 0.999999 or similar -- switching it to `round` fixes this issue." singpolyma
10169 11 hvr, ekmett bracket not running the final action on termination through SIGTERM libraries/base 7.6.3 new normal 2015-03-19T12:42:53Z "If a program compiled with GHC receives a SIGTERM signal, while in a bracket, the final action of the bracket isn't executed. This can be tested with this program:
{{{#!hs
import Control.Exception
import Control.Concurrent
main = bracket (return ""ending"")
(\x -> putStrLn x)
(\_ -> threadDelay 10000000000)
}}}
When running this and interrupting with ctrl-c (thus SIGINT) it prints ""ending"", like expected. When interrupting it with {{{killall -TERM test}}} (assuming the program was named test) ""ending"" isn't printed and the program terminates immediately. It prints a system specific message though." Kritzefitz
10412 11 hvr, ekmett isAlphaNum includes mark characters, but neither isAlpha nor isNumber do libraries/base 7.10.1 new normal 2015-05-13T22:30:01Z "{{{#!hs
> isMark '\768'
True
> isAlphaNum '\768'
True
> (isAlpha '\768', isNumber '\768')
(False,False)
}}}
This behavior comes from this piece in WCsubst.c:
{{{
unipred(u_iswalnum,(GENCAT_LT|GENCAT_LU|GENCAT_LL|GENCAT_LM|GENCAT_LO|
GENCAT_MC|GENCAT_ME|GENCAT_MN|
GENCAT_NO|GENCAT_ND|GENCAT_NL))
}}}
I'm not sure what should be done here. Is it a bug with isAlpaNum? Or with isAlpha? How does it correspond to iswalnum's behavior in C++?
(And if it's a feature and not a bug, then it should definitely be documented.)" Artyom.Kazak
10484 11 hvr, ekmett hPutBuf crashes when trying to write a large string to stdout (resource exhausted) libraries/base 7.8.3 new normal 2015-06-04T13:02:23Z "The following program crashes when I try to write a byte string larger than 61kb to stdout:
{{{#!hs
import qualified Data.ByteString.Char8 as BS
main = BS.putStrLn $ BS.replicate (62 * 1024) 'x'
}}}
When I run the above, I get the following runtime error:
{{{
: hPutBuf: resource exhausted (Not enough space)
}}}
GHC versions tested: 7.6.3 and 7.8.3 (both 32 and 64 bit)
OS: Windows 7 and Windows Server 20008R2
The issue is not reproducible with the Linux version of GHC. It is also not reproducible if I use the Lazy variant of the byte strings.
Note: The Linux version of the program was tested with GHC 7.6.3 because this is the one I have on my Ubuntu machine. " bayloff
10084 11 hvr, ekmett Data.List should have a takeLastN function libraries/base 7.8.4 new normal 2015-02-12T14:49:58Z "A natural compliment to the `take` function that instead takes `n` elements from the end of the list rather than from the start would be very useful.
I'm surprised it's not defined in base because it seems to be a common operation that is not trivial to define in an efficient way. See http://www.joachim-breitner.de/blog/600-On_taking_the_last_n_elements_of_a_list" leonbaum2
10163 11 hvr, ekmett Export typeRepKinds in Data.Typeable libraries/base 7.10.1-rc3 new normal 2015-05-25T23:31:38Z 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. RyanGlScott
10365 11 hvr, ekmett Make Semigroup as a superclass of Monoid libraries/base 7.10.1 ekmett new normal 2015-06-15T09:16:55Z See http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-td5767835.html gidyn
10609 11 hvr, ekmett Make up instances libraries/base 7.10.1 patch normal 2015-07-07T09:55:17Z "The following instances are missing as of now.
* Foldable ZipList
* Traversable ZipList
* Functor Complex
* Foldable Complex
* Traversable Complex
* Applicative Complex
* Monad Complex
* Monoid a => Monoid (Identity a)
* Storable ()
Original discussion: https://mail.haskell.org/pipermail/libraries/2015-June/025886.html" fumieval
9542 11 hvr, ekmett GHC-IO-Handle-Text.hPutStr' and writeBlocks look like they need refactoring Core Libraries 7.8.2 ekmett new normal 2014-10-07T05:48:24Z The boundary between `writeBlocks` and `hPutStr'` looks badly drawn, with pieces of buffering type on either side. I would also speculate that one or more CRLF-related helper functions may be in order. dfeuer
9970 11 hvr, ekmett Export more types in GHC.RTS.Flags libraries/base 7.10.1-rc1 7.10.3 RyanGlScott merge normal 2015-07-22T10:58:59Z "There are some ADTs in {{{GHC.RTS.Flags}}} that have arguments whose types are not exported. These types are:
* {{{GiveGCStats}}} (found in {{{GCFlags}}})
* {{{DoCostCentres}}} (found in {{{CCFlags}}})
* {{{DoHeapProfile}}} (found in {{{ProfFlags}}})
* {{{DoTrace}}} (found in {{{TraceFlags}}})
This makes it pretty difficult to do anything useful with them, since they can't be pattern-matched.
In addition, there are some unexported type synonyms:
* {{{type Time = Word64}}}
* {{{type Nat = #{type unsigned int} }}} (likely a {{{Word32}}})
The Haddock docs for {{{GHC.RTS.Flags}}} don't give much of an indication of what {{{Time}}} and {{{Nat}}} are, and since they're already documented in [https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/GHC/RTS/Flags.hsc;0bef02e49fb2907989127d77ae61ed48ba87ae18$50-54 the source], they should probably be exported." RyanGlScott
10193 11 hvr, ekmett TypeRep Show instance doesn't add parens around type operators libraries/base 7.10.1-rc3 7.12.1 new normal 2015-04-06T22:18:21Z "The following code
{{{#!hs
{-# LANGUAGE AutoDeriveTypeable #-}
{-# LANGUAGE TypeOperators #-}
import Data.Typeable
data a :*: b = Pair a b
main = print (typeOf (Pair 'a' 'b'))
}}}
prints
{{{#!hs
:*: Char Char
}}}
which is not valid Haskell. I belive it should print
{{{#!hs
(:*:) Char Char
}}}
In my particular case I am using Hint to interpret a type involving type operators. Hint uses showed TypeRep as a type annotation:
{{{#!hs
let type_str = show $ Data.Typeable.typeOf wit
...
let expr_typesig = concat [parens e, "" :: "", type_str]
}}}
What results in a parse error.
I can write a patch if someone confirms that's the desired behavior and doesn't break anything." pawel.nowak
8010 11 hvr, ekmett Add forkOSUnmasked (patch) Core Libraries 7.7 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "This patch simply adds `forkOSUnmasked` to Control.Concurrent:
{{{
-- | Like 'forkIOWithUnmask', but the child thread is a bound thread,
-- as with 'forkOS'.
forkOSWithUnmask :: ((forall a . IO a -> IO a) -> IO ()) -> IO ThreadId
forkOSWithUnmask io = forkOS (io unsafeUnmask)
}}}
I ran `sh validate`, and no new failures were introduced. I'll push it to master in a few days, unless someone objects.
For GHC < 7.8, `forkOSWithUnmask` can be achieved using `forkOS` and [http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/Control-Exception.html#v:block block], but `block` is removed in GHC 7.8. `unsafeUnmask` can still be imported from `GHC.IO`, however." joeyadams
8532 11 hvr, ekmett Hyperbolic arc cosine fails on (-1) :: Complex r. Core Libraries 7.6.3 ekmett new low 2014-10-07T05:48:24Z "When allowing for complex results, the hyperbolic arc cosine is continuously defined on all ℝ.
In the {{{(x < (-1))}}} real ray of the complex plane, {{{acosh}}} equals {{{\z -> i * pi + acosh(abs z)}}}, which works fine for almost all arguments. Thus, {{{acosh (-1)}}} should equal {{{i * pi}}}; however due to the implementation as
{{{
acosh z = log (z + (z+1) * sqrt ((z-1)/(z+1)))
}}}
where the denominator in the root becomes zero at {{{z = -1}}}, this comes out as {{{NaN :+ NaN}}}.
Could be fixed trivially by adding a special case
{{{
acosh ((-1):+0) = 0:+pi
}}}
to the {{{instance (RealFloat a) => Floating (Complex a)}}} in {{{Data.Complex}}}." leftaroundabout
9283 11 hvr, ekmett bad autoconf variable names Core Libraries 7.9 ekmett new low 2014-10-07T05:48:24Z "{{{
if test ""$ac_cv_header_sys_epoll_h"" = yes -a ""$ac_cv_func_epoll_ctl"" = yes; then
AC_DEFINE([HAVE_EPOLL], [1], [Define if you have epoll support.])
fi
if test ""$ac_cv_header_sys_event_h"" = yes -a ""$ac_cv_func_kqueue"" = yes; then
AC_DEFINE([HAVE_KQUEUE], [1], [Define if you have kqueue support.])
AC_CHECK_SIZEOF([kev.filter], [], [#include
struct kevent kev;])
AC_CHECK_SIZEOF([kev.flags], [], [#include
struct kevent kev;])
fi
if test ""$ac_cv_header_poll_h"" = yes -a ""$ac_cv_func_poll"" = yes; then
AC_DEFINE([HAVE_POLL], [1], [Define if you have poll support.])
fi
}}}
The `AC_DEFINE` lines for `HAVE_KQUEUE` and `HAVE_POLL` don't do anything, because earlier we have
{{{
AC_CHECK_FUNCS([epoll_ctl eventfd kevent kevent64 kqueue poll])
}}}
and that already defines `HAVE_KQUEUE` (and sets `ac_cv_func_kqueue`) when the `kqueue` function is found.
Not entirely sure what the right thing to do is here, do we rely on having a prototype for `kqueue` in `sys/event.h` specifically? Technically that wouldn't be what we check for even if we used a renamed `HAVE_KQUEUE` variable.
AFAIK this doesn't cause any real problems except that it really confused me when I tried to simulate not having `poll` by moving `/usr/include/poll.h` away temporarily." rwbarton
10055 11 hvr, ekmett Offer PolyKinded instances for Data.Fixed.HasResolution libraries/base 7.8.4 new low 2015-02-01T02:17:52Z "Now that we have `DataKinds` and `PolyKinds`, how about offering an instance of `Data.Fixed.HasResolution` for type level natural numbers. For example
{{{#!hs
instance KnownNat n => HasResolution (n :: Nat) where
resolution proxy = 10 ^ natVal proxy
}}}
or even
{{{#!hs
instance KnownNat n => HasResolution (n :: Nat) where
resolution = natVal
}}}
This will make it very easy to create fixed-point types on the fly. For example, it would be possible to say `0.3 :: Fixed 17`.
The following extensions are required for that to work: `DataKinds`, `PolyKinds`, `FlexibleInstances`, and `UndecidableInstances`.
" redneb
10266 11 hvr, ekmett Split base for Backpack libraries/base 7.11 ezyang new low 2015-06-03T19:12:38Z "Let's resurrect #1338 and #1580. Our new concrete goal is to have users be able to replace 'base' with 'base-sig', which is some signature representing the modules from 'base' which we depend on. Since 'base' is a big, complicated package, the ability to specify subsets of 'base' is very useful: it can be used to define things like Haskell'98 base, base without any unsafe operations, etc.
Right now, all wired in things live in ghc-prim (I believe). This is good, since we can't reasonably abstract wired in things away with a signature: GHC will always put them in some well-known place. However, this is not enough: there are many known-key/Rdr things the compiler knows about too, which need to be placed in specific package + module locations for GHC to be able to reference them; e.g. when deriving instances, etc.
At the moment, most of these identifiers live in 'base', which is no good: even if we make base sig abstract, GHC will still go right ahead and try to use a specific implementation of base. So, here's the proposal: all non-rebindable GHC-known identifiers (as per PrelNames) should be moved to ghc-prim (or perhaps a new package? I don't really care either way) and reexported from the old packages which they were available from base. The further upshot is base now truly can have an implementation replaced: ghc-prim is the ONLY package which must be used verbatim (since GHC hardcodes to it.)
I'll try to work out in detail what moves, how to avoid orphan instances, etc. " ezyang
2614 11 hvr, ekmett Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` Core Libraries 6.8.3 7.12.1 mjg new low 2014-12-23T13:33:45Z "It is desirable to have an enumeration of values that might end up in `Sys.Info.os` and `Sys.Info.arch`. Only after much reading of Cabal files and such have I learnt that the former includes (at least) `linux`, `darwin`, `windows` and `freebsd`. (And not, for example, `win32`.)
This is only a minor annoyance and I will likely never need to bother with it again -- though I guess I'm still not sure what Solaris is called -- probably `solaris` -- I've got the pattern now, but it would have been much better to see a list." jsnx
10067 49 hvr, ekmett, core-libraries-committee@… The Read Integer instance is too slow Core Libraries 7.11 7.12.1 new high 2015-03-09T19:26:24Z "The current implementation of the Read Integer instance has quadratic complexity and thus performs badly on large inputs. On my system, it takes 65 seconds to perform the following:
{{{#!hs
read (take 1000000 $ cycle ""1234567890"") :: Integer
}}}
Note that we already provide an ad-hoc instance for Show Integer, so maybe we can do the same for Read Integer.
" redneb
10039 49 hvr, ekmett, core-libraries-committee@… Make Const (Control.Applicative) kind polymorphic in its second argument Core Libraries 7.8.4 ekmett new normal 2015-02-05T16:41:01Z "Is there any reason why `Const` isn't kind polymorphic?
{{{#!hs
newtype Const a (b :: k) = Const { getConst :: a }
deriving (Generic, Generic1)
}}}
An example where I need it is for [[http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs|interpreting typed PHOAS]], the following fails to compile complaining that `The first argument of ‘PTerm’ should have kind ‘Ty -> *’, but ‘Const Char’ has kind ‘* -> *’`:
{{{#!hs
{-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-}
import Control.Applicative
data Ty = TyBool | TyArr Ty Ty
data PTerm :: (Ty -> *) -> Ty -> * where
Var :: v t -> PTerm v t
Tru :: PTerm v 'TyBool
Fals :: PTerm v 'TyBool
App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2
Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2)
newtype Term t = Term (forall v. PTerm v t)
showT :: Term t -> String
showT (Term pterm) = show' 'a' pterm
where
show' :: Char -> PTerm (Const Char) t -> String
show' _ (Var (Const c)) = [c]
show' _ Tru = ""True""
show' _ Fals = ""False""
show' s (App x y) = ""("" ++ show' s x ++ "") "" ++ show' s y
show' s (Abs f) = [s] ++ "". "" ++ show' (succ s) (f (Const s))
}}}
but it compiles if one defines a bespoke form of `Const` with kind `* -> Ty -> *` (or the more general suggestion at the beginning of the ticket), I implemented all the related instances from `Control.Applicative` and it compiled without a hitch. Relevant discussion: a [[http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in-data-declaration|question on StackOverflow]] that predates the `PolyKinds` extension effectively wants to define `type Const' (a :: * -> *) = Const Integer a` which would be possible if it were kind polymorphic." Iceland_jack
2496 49 hvr, ekmett, core-libraries-committee@… Invalid Eq/Ord instances in Data.Version Core Libraries 6.8.3 7.12.1 new normal 2015-05-12T04:34:19Z "(From Adrian Hey)
In Data.Version we have:
{{{
data Version =
Version {versionBranch :: [Int]
,versionTags :: [String]
}
instance Eq Version where
v1 == v2 = versionBranch v1 == versionBranch v2
&& sort (versionTags v1) == sort (versionTags v2)
-- tags may be in any order
instance Ord Version where
v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2
}}}
The ""laws"" for valid Eq/Ord instances were argued about recently but the H98 report seems reasonably clear that (==) is supposed to test for equality and the compare method is supposed to define a total ordering. There is also an implied but not explicitly stated law that:
{{{
(x == y = True) (x `compare` y = EQ)
}}}
and also this I guess..
{{{
(x == y = False) ~(x `compare` y = EQ)
}}}
This law is implied by the Eq constraint on the Ord class (which seems to serve no purpose otherwise).
See also:
[http://www.haskell.org/pipermail/haskell-prime/2008-March/002330.html]
" guest
10022 49 hvr, ekmett, core-libraries-committee@… Clean up GHC.RTS.Flags Core Libraries 7.10.1-rc1 7.12.1 ekmett new normal 2015-03-02T12:55:57Z There's some cleanup to do for `GHC.RTS.Flags`, based on the comments in https://ghc.haskell.org/trac/ghc/ticket/5364#comment:11 thoughtpolice
9638 49 hvr, ekmett, core-libraries-committee@… Speed up Data.Char.isDigit Core Libraries 7.9 7.12.1 ekmett new normal 2015-07-01T17:05:39Z "`isDigit` is currently defined like this:
{{{#!hs
isDigit :: Char -> Bool
isDigit c = c >= '0' && c <= '9'
}}}
This will short-circuit the right way if you're looking for digits mixed with spaces, but the wrong way if you're looking for digits mixed with letters. It also requires a conditional jump to do that short-circuiting (confirmed by inspecting the assembly). It should be better to use an unsigned comparison instead:
{{{#!hs
isDigit :: Char -> Bool
isDigit c = (fromIntegral (ord c) :: Word) - 48 <= 9
}}}
The interesting section looks like this
{{{
movq 7(%rbx),%rax
addq $-48,%rax
cmpq $9,%rax
setbe %al
movzbl %al,%eax
shlq $3,%rax
movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax),%rbx
addq $8,%rbp
jmp *(%rbp)
}}}
or like this with -fllvm:
{{{
movq 7(%rbx), %rax
addq $-48, %rax
cmpq $10, %rax
sbbq %rax, %rax
andq $8, %rax
movq ghczmprim_GHCziTypes_Bool_closure_tbl(%rax), %rbx
movq 8(%rbp), %rax
addq $8, %rbp
jmpq *%rax # TAILCALL
}}}" dfeuer
9631 49 hvr, ekmett, core-libraries-committee@… Comment in GHC.Base about GHC.Prim does not appear to be correct Core Libraries 7.8.3 7.12.1 ekmett new low 2015-02-22T13:26:04Z "The comment reads
{{{
GHC.Prim Has no implementation. It defines built-in things, and
by importing it you bring them into scope.
The source file is GHC.Prim.hi-boot, which is just
copied to make GHC.Prim.hi
}}}
It does not appear that any files by these names exist." dfeuer
9496 49 hvr, ekmett, core-libraries-committee@… Simplify primitives for short cut fusion Core Libraries 7.8.3 ⊥ dfeuer new lowest 2014-11-12T17:32:36Z "Currently, there appear to be two production primitives, `build` and `augment` (although I may have missed some). There are multiple consumption primitives (at least: `foldr`, `head`, `and`, `or`, `any`, and `all`). The rule sets for some producers seem to forget to handle `augment`, and the `augment/augment` rule is omitted as ""true, but not, I think, useful"".
A number of other functions are instead rewritten into `foldr` forms, and then written back if they don't fuse.
== What to do: ==
Personally, I'd be very tempted to start by saying `build g = augment g []` (or ''possibly'' even `build g = extend [] g []` if I can ever get that idea to work) and cut the problem in half. The main problem I see with this is if other people are importing `GHC.Exts` or `GHC.Base`, writing things with `build`, and expecting them to fuse. One way to deal with this, perhaps, is to hack a special rule into the RULES compiler to recognize `GHC.Base.build` on the LHS of RULES and replace it with the appropriate `augment` form, emitting a warning.
Where to go after that: the question remains whether it's best in general to rewrite a form to `foldr` to make it fuse, or to fuse directly with `augment`. The answer presumably depends, at least in part, on whether there are additional `foldr`-based rules we may want to add that would take advantage of the effort put into the translation back from the `foldr` form. I would conjecture that most such rules we could want would go beyond what the RULES system actually can do. That said, if we can find a way to use `foldr` forms without the horrible pain of translating back from them, that would be a very good thing." dfeuer
9848 63 hvr, ekmett, dfeuer, core-libraries-committee@…, akio List.all does not fuse Core Libraries 7.9 ekmett new normal 2015-08-02T09:32:26Z "{{{
primes = 2:3:filter isPrime [5,7..] :: [Int]
isPrime x = all (/= 0) . map (x `rem`) . takeWhile ((<= x) . (^2)) $ primes
main = print . length . takeWhile (<= 2^24) $ primes
}}}
{{{
12,133,812,164 bytes allocated in the heap
53,433,372 bytes copied during GC
14,235,488 bytes maximum residency (7 sample(s))
1,110,916 bytes maximum slop
30 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 56357 colls, 0 par 0.094s 0.125s 0.0000s 0.0001s
Gen 1 7 colls, 0 par 0.031s 0.034s 0.0049s 0.0154s
INIT time 0.000s ( 0.000s elapsed)
MUT time 8.094s ( 8.069s elapsed)
GC time 0.125s ( 0.159s elapsed)
EXIT time 0.000s ( 0.003s elapsed)
Total time 8.219s ( 8.231s elapsed)
%GC time 1.5% (1.9% elapsed)
Alloc rate 1,499,158,259 bytes per MUT second
Productivity 98.5% of total user, 98.3% of total elapsed
}}}
{{{
Rec {
$sgo1_r2RE :: GHC.Prim.Int# -> [Int] -> Data.Monoid.All
[GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ]
$sgo1_r2RE =
\ (sc_s2PS :: GHC.Prim.Int#) (sc1_s2PT :: [Int]) ->
case sc_s2PS of _ [Occ=Dead] {
__DEFAULT -> go_r2RF sc1_s2PT;
0 ->
GHC.Types.False
`cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All)
}
go_r2RF :: [Int] -> Data.Monoid.All
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType ]
go_r2RF =
\ (ds_a1YK :: [Int]) ->
case ds_a1YK of _ [Occ=Dead] {
[] ->
GHC.Types.True
`cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All);
: y_a1YP ys_a1YQ ->
case y_a1YP of _ [Occ=Dead] { GHC.Types.I# x_a1Tk ->
case x_a1Tk of _ [Occ=Dead] {
__DEFAULT -> go_r2RF ys_a1YQ;
0 ->
GHC.Types.False
`cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All)
}
}
}
end Rec }
lvl4_r2RG :: Int -> Data.Monoid.All
[GblId, Arity=1, Str=DmdType]
lvl4_r2RG =
\ (x_aqY [OS=ProbOneShot] :: Int) ->
case x_aqY of _ [Occ=Dead] { GHC.Types.I# y_a1Uc ->
case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# 4 y_a1Uc)
of _ [Occ=Dead] {
False ->
GHC.Types.True
`cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All);
True ->
$sgo1_r2RE
(GHC.Prim.remInt# y_a1Uc 2)
(letrec {
go1_a1S5 [Occ=LoopBreaker] :: [Int] -> [Int]
[LclId, Arity=1, Str=DmdType ]
go1_a1S5 =
\ (ds_a1S6 :: [Int]) ->
case ds_a1S6 of _ [Occ=Dead] {
[] -> GHC.Types.[] @ Int;
: y1_X1T4 ys_X1T6 ->
case y1_X1T4 of _ [Occ=Dead] { GHC.Types.I# x1_X1VM ->
case GHC.Prim.tagToEnum#
@ Bool (GHC.Prim.<=# (GHC.Prim.*# x1_X1VM x1_X1VM) y_a1Uc)
of _ [Occ=Dead] {
False -> GHC.Types.[] @ Int;
True ->
GHC.Types.:
@ Int
(case x1_X1VM of wild5_a1TE {
__DEFAULT ->
case GHC.Prim.remInt# y_a1Uc wild5_a1TE
of wild6_a1TJ { __DEFAULT ->
GHC.Types.I# wild6_a1TJ
};
(-1) -> GHC.Real.$fIntegralInt1;
0 -> GHC.Real.divZeroError @ Int
})
(go1_a1S5 ys_X1T6)
}
}
}; } in
go1_a1S5 Main.main3)
}
}
}}}
foldr, however, fuse just fine:
{{{
primes = 2:3:filter isPrime [5,7..] :: [Int]
isPrime x = foldr (&&) True . map (/= 0) . map (x `rem`) . takeWhile ((<= x) . (^2)) $ primes
main = print . length . takeWhile (<= 2^24) $ primes
}}}
{{{
365,770,752 bytes allocated in the heap
48,197,488 bytes copied during GC
13,031,232 bytes maximum residency (7 sample(s))
1,570,524 bytes maximum slop
28 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 694 colls, 0 par 0.016s 0.029s 0.0000s 0.0005s
Gen 1 7 colls, 0 par 0.031s 0.032s 0.0046s 0.0146s
INIT time 0.000s ( 0.000s elapsed)
MUT time 3.438s ( 3.439s elapsed)
GC time 0.047s ( 0.062s elapsed)
EXIT time 0.000s ( 0.003s elapsed)
Total time 3.484s ( 3.504s elapsed)
%GC time 1.3% (1.8% elapsed)
Alloc rate 106,406,036 bytes per MUT second
Productivity 98.7% of total user, 98.1% of total elapsed
}}}
{{{
lvl4_r2qr :: Int -> Bool
[GblId, Arity=1, Str=DmdType]
lvl4_r2qr =
\ (x_aqW [OS=ProbOneShot] :: Int) ->
case x_aqW of _ [Occ=Dead] { GHC.Types.I# y_a1tq ->
case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# 4 y_a1tq)
of _ [Occ=Dead] {
False -> GHC.Types.True;
True ->
case GHC.Prim.remInt# y_a1tq 2 of _ [Occ=Dead] {
__DEFAULT ->
letrec {
go_a1ud [Occ=LoopBreaker] :: [Int] -> Bool
[LclId, Arity=1, Str=DmdType ]
go_a1ud =
\ (ds_a1ue :: [Int]) ->
case ds_a1ue of _ [Occ=Dead] {
[] -> GHC.Types.True;
: y1_X1vf ys_X1vh ->
case y1_X1vf of _ [Occ=Dead] { GHC.Types.I# x1_X1x9 ->
case GHC.Prim.tagToEnum#
@ Bool (GHC.Prim.<=# (GHC.Prim.*# x1_X1x9 x1_X1x9) y_a1tq)
of _ [Occ=Dead] {
False -> GHC.Types.True;
True ->
case x1_X1x9 of wild6_X1x3 {
__DEFAULT ->
case GHC.Prim.remInt# y_a1tq wild6_X1x3 of _ [Occ=Dead] {
__DEFAULT -> go_a1ud ys_X1vh;
0 -> GHC.Types.False
};
(-1) -> GHC.Types.False;
0 -> case GHC.Real.divZeroError of wild7_00 { }
}
}
}
}; } in
go_a1ud Main.main3;
0 -> GHC.Types.False
}
}
}
}}}
And List.all from ghc 7.8 base library does fuse, so this is regression.
Windows 8.1 x64,
ghc --info:
{{{
[(""Project name"",""The Glorious Glasgow Haskell Compilation System"")
,(""GCC extra via C opts"","" -fwrapv"")
,(""C compiler command"",""$topdir/../mingw/bin/gcc.exe"")
,(""C compiler flags"","" -U__i686 -march=i686 -fno-stack-protector"")
,(""C compiler link flags"","""")
,(""Haskell CPP command"",""$topdir/../mingw/bin/gcc.exe"")
,(""Haskell CPP flags"",""-E -undef -traditional "")
,(""ld command"",""$topdir/../mingw/bin/ld.exe"")
,(""ld flags"","""")
,(""ld supports compact unwind"",""YES"")
,(""ld supports build-id"",""NO"")
,(""ld supports filelist"",""NO"")
,(""ld is GNU ld"",""YES"")
,(""ar command"",""$topdir/../mingw/bin/ar.exe"")
,(""ar flags"",""q"")
,(""ar supports at file"",""YES"")
,(""touch command"",""$topdir/touchy.exe"")
,(""dllwrap command"",""$topdir/../mingw/bin/dllwrap.exe"")
,(""windres command"",""$topdir/../mingw/bin/windres.exe"")
,(""libtool command"","""")
,(""perl command"",""$topdir/../perl/perl.exe"")
,(""target os"",""OSMinGW32"")
,(""target arch"",""ArchX86"")
,(""target word size"",""4"")
,(""target has GNU nonexec stack"",""False"")
,(""target has .ident directive"",""True"")
,(""target has subsections via symbols"",""False"")
,(""Unregisterised"",""NO"")
,(""LLVM llc command"",""llc"")
,(""LLVM opt command"",""opt"")
,(""Project version"",""7.9.20141129"")
,(""Project Git commit id"",""447f592697fef04d1e19a2045ec707cfcd1eb59f"")
,(""Booter version"",""7.8.3"")
,(""Stage"",""2"")
,(""Build platform"",""i386-unknown-mingw32"")
,(""Host platform"",""i386-unknown-mingw32"")
,(""Target platform"",""i386-unknown-mingw32"")
,(""Have interpreter"",""YES"")
,(""Object splitting supported"",""YES"")
,(""Have native code generator"",""YES"")
,(""Support SMP"",""YES"")
,(""Tables next to code"",""YES"")
,(""RTS ways"",""l debug thr thr_debug thr_l thr_p "")
,(""Support dynamic-too"",""NO"")
,(""Support parallel --make"",""YES"")
,(""Support reexported-modules"",""YES"")
,(""Support thinning and renaming package flags"",""YES"")
,(""Uses package keys"",""YES"")
,(""Dynamic by default"",""NO"")
,(""GHC Dynamic"",""NO"")
,(""Leading underscore"",""YES"")
,(""Debug on"",""False"")
,(""LibDir"",""D:\\msys32\\usr\\local\\lib"")
,(""Global Package DB"",""D:\\msys32\\usr\\local\\lib\\package.conf.d"")
]
}}}
" klapaucius
10068 35 hvr, ekmett, gridaphobe, j.waldmann Make the runtime reflection API for names, modules, locations more systematic Compiler 7.8.4 7.12.1 new high 2015-07-14T05:58:07Z "Currently in `base` we have
* `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and `srcLocModule`
* `Data.Typeable.Internals`: the data type `TyCon` contains `tyConPackage`, `tyConModule` and `tyConName`.
* `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`, `dataTypeModule` and `dataTypeName`
* `Data.Data`: the data type `DataType` (yes the capitalisation differs!) contains a field `tycon :: String`, and there are functions `tyconModule :: String -> String`, and `tyconUQname :: String -> String`, for parsing that string and extracting the module name and tycon name.
* `GHC.StaticPtr`: the data type `StaticPtrInfo` contains `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s). Oh, and `spInfoSrcLoc :: (Int,Int)` too!
* `GHC.Stack.ccSrcSpan :: Ptr CostCentre -> IO CString` stores a source location in a C structure, and returns it as a `CString`.
This is madness! Six different representations for the same information in one package!
Let's fix this by defining some shared data types, for
* `Module` = `ModuleName` + package
* `Entity` = `Module` + unqualified name
There would be a tiresome changeover period; but `Typeable` and `StaticPtr` are in flux anyway.
Would anyone be willing to lead on this?
" simonpj
10380 62 hvr, ekmett, liyang, AndreasVoellmy, basvandijk, kazu-yamamoto """thread blocked indefinitely"" exception while blocking on a socket" libraries/base 7.10.1 new normal 2015-05-11T03:24:59Z "First start a TCP server, e.g. nc.
{{{
% nc localhost -l 1234 > /dev/null
}}}
On another shell, compile the following program and run it:
{{{
% ghc -threaded sock.hs
% ./sock localhost 1234
receiver: thread blocked indefinitely in an MVar operation
}}}
{{{#!hs
{-# LANGUAGE ViewPatterns #-}
import Control.Applicative -- GHC 7.8 compatibility
import Control.Concurrent
import qualified Control.Exception as Ex
import Control.Monad
import qualified Data.ByteString.Char8 as S
import Network.Socket
import qualified Network.Socket.ByteString as Sock
import Network.BSD (getHostByName, hostAddresses)
import System.Environment
import System.Mem
main :: IO ()
main = do
[host, read -> fromInteger -> port] IO () -> IO ()
forkVerbose name act = void $ forkIO $ do act; msg ""exiting normally""
`Ex.catch` \e -> msg $ show (e :: Ex.SomeException)
where
msg s = putStrLn $ name ++ "": "" ++ s
connectTo :: HostName -> PortNumber -> IO Socket
connectTo hostName port = do
addr lookupHost hostName
sock IO HostAddress
lookupHost name = do
hostInfo error (""Invalid host name: "" ++ name)
(a:_) -> return a
}}}
GHC 7.8.3 doesn't have this problem.
I suspect that this is a regression in the event manager. When there is an event, `GHC.Event.Manager.onFdEvent` seems to remove all callbacks associated to the `fd`, whether or not they match the current event. In the program above, the callback for `recv` may be removed permanently when the socket becomes ready for `send`ing, causing the ""receiver"" thread to deadlock." akio
10149 19 hvr, ekmett, qnikst The argument of mask does not always restore the masking state libraries/base 7.8.4 new normal 2015-03-12T19:04:44Z "In the documentation of `mask` and `uninterruptibleMask` it is claimed that the `restore` argument restores the masking state. However this is not true in the following programs:
{{{#!hs
mask_ $ -- start with exceptions masked
mask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $
restore $ getMaskingState >>= print
}}}
{{{#!hs
uninterruptibleMask_ $ -- start with exceptions uninterruptibly masked
uninterruptibleMask $ \restore -> forkIOWithUnmask $ \unmask -> unmask $
restore $ getMaskingState >>= print
}}}
The expected result is that `getMaskingState` would produce `MaskedInterruptible` and `MaskedUninterruptible`, however, in both cases it gives Unmasked.
Either the documentation needs to be changed, or the implementation must really restore the masking state in these cases." facundo.dominguez
10457 21 hvr, ekmett, simonmar Revise/remove custom mapM implementation for lists libraries/base 7.10.1 7.12.1 patch normal 2015-06-09T04:36:38Z "Recently, Simon Marlow asked why the list instance for Traversable had a custom mapM implementation that used the Monad operations. Having looked a bit, I don't think there's any good reason. The only fusion that the custom mapM can participate in is due to it being written as foldr, but traverse is, as well. So as long as 'mapM = traverse' is able to inline appropriately, there should be no difference.
Further, this can be changed, in principle, for 7.10.2. It doesn't change any types, only the implementation.
mapM = traverse is the class default definition, so this could possibly be completed by just removing the custom definition.
Link to the libraries thread: https://mail.haskell.org/pipermail/libraries/2015-May/025708.html" dolio
9795 19 hvr, ekmett, thomie Debug.Trace.trace is too strict libraries/base 7.8.3 7.12.1 new normal 2015-03-01T15:07:02Z "Consider the following toy example:
{{{#!hs
import Debug.Trace
f n
= let res = g n
in (trace $ unlines [""in: "" ++ show n, ""out: "" ++ show res])
res
where
g n = if n <= 1000 then n+1 else g n
main
= print $ [f 500, f 302, f 2000, f 22]
}}}
When run it outputs:
{{{
in: 500
out: 501
in: 302
out: 303
^C
}}}
In a real example, for a program that hangs, where one only ''suspects'' that `f` may be the culprit, and where `f` is being called from various places with different values, this output is not very useful (and in fact, it is misleading).
My mental model of the `trace` function is something along these lines:
{{{#!hs
myTrace :: String -> a -> a
myTrace s a
= unsafePerformIO $ do
putStrLn s
return a
}}}
and in fact, replacing `trace` by `myTrace` in the example above one gets the more useful:
{{{
in: 500
out: 501
in: 302
out: 303
in: 2000
^C
}}}" jcpetruzza
9729 11 hvr, ezyang GHCi accepts invalid programs when recompiling GHCi 7.8.3 new normal 2014-12-03T13:40:37Z "Here's what's happening:
Module A imports module B. Module B contains a function with constraints that are '''required''' to compile module B. If I load module A in GHCi, I can remove some (required) constraints on the function in module B and GHCi will successfully reload module B.
My example uses the [https://hackage.haskell.org/package/syntactic syntactic] library. I attempted to recreate the situation I just described without syntactic, but I was unsuccessful.
Module A.hs:
{{{
#!haskell
module A where
import B
import Data.Syntactic.Sugar.BindingT ()
main = print ""hello""
}}}
Module B.hs:
{{{
#!haskell
{-# LANGUAGE GADTs, TypeOperators, FlexibleContexts #-}
module B where
import Data.Syntactic
data Let x where
Let :: Let (a :-> (a -> b) :-> Full b)
share :: (Let : b) ~ (Internal a -> Internal b), -- remove me
Syntactic a, Syntactic b,
Syntactic (a -> b),
SyntacticN (a -> (a -> b) -> b)
(ASTF sup (Internal a) ->
ASTF sup (Internal (a -> b)) ->
ASTF sup (Internal b)))
=> a -> (a -> b) -> b
share = sugarSym Let
}}}
Here's a terminal transcript:
{{{
$ ghci A
[1 of 2] Compiling B ( testsuite/B.hs, interpreted )
[2 of 2] Compiling A ( testsuite/A.hs, interpreted )
Ok, modules loaded: A, B.
>
(Now remove the constraint from B and save. This *should* break module B)
> :r
[1 of 2] Compiling B ( testsuite/B.hs, interpreted )
Ok, modules loaded: A, B.
> :q
$ ghci B
[1 of 2] Compiling B ( testsuite/B.hs, interpreted )
testsuite/B.hs:21:9:
Could not deduce (Internal (a -> b) ~ (Internal a -> Internal b))
}}}
If I had to guess what's going on, it's that GHCi is remembering the instance that A imports from BindingT:
{{{
instance (...) => Syntactic (a -> b) where
type Internal (a -> b) = Internal a -> Internal b
}}}
This instance implies the constraint that module B needs, however it should never be visible to module B. GHCi seems to be ignoring that and using the instance to recompile module B.
When compiling from scratch, module B is compiled first, so of course the instance (and therefore the constraint) are not visible." crockeea
7789 30 hvr, george.colpitts@… GHCI core dumps when used with VTY GHCi 7.4.2-rc1 7.12.1 new normal 2014-12-23T13:34:10Z "Load the attached script in ghci:
{{{
$ghci ghci-coredumper.hs
}}}
(you need the vty-menu package from hackage) and type die
{{{
>die
}}}
You may see a menu with a set of ten numbers. If you do press enter repeatedly. Eventually it will core dump(at least it does for me) Unfortunately I have been unable to collect this core dump, but here is the output at least:
{{{
7f7ad1fc4000-7f7ad1fc5000 rwxp 000fd000 00:10 2839271 /usr/lib/libm-2.17.so
7f7ad1fc5000-7f7ad2032000 r-xp 00000000 00:10 3028085 /usr/lib/libgmp.so.10.1.1
7f7ad2032000-7f7ad2231000 ---p 0006d000 00:10 3028085 /usr/lib/libgmp.so.10.1.1
7f7ad2231000-7f7ad2232000 r-xp 0006c000 00:10 3028085 /usr/lib/libgmp.so.10.1.1
7f7ad2232000-7f7ad223b000 rwxp 0006d000 00:10 3028085 /usr/lib/libgmp.so.10.1.1
7f7ad223b000-7f7ad2252000 r-xp 00000000 00:10 2839310 /usr/lib/libpthread-2.17.so
7f7ad2252000-7f7ad2451000 ---p 00017000 00:10 2839310 /usr/lib/libpthread-2.17.so
7f7ad2451000-7f7ad2452000 r-xp 00016000 00:10 2839310 /usr/lib/libpthread-2.17.so
7f7ad2452000-7f7ad2453000 rwxp 00017000 00:10 2839310 /usr/lib/libpthread-2.17.so
7f7ad2453000-7f7ad2457000 rwxp 00000000 00:00 0
7f7ad2457000-7f7ad245a000 r-xp 00000000 00:10 2839316 /usr/lib/libdl-2.17.so
7f7ad245a000-7f7ad2659000 ---p 00003000 00:10 2839316 /usr/lib/libdl-2.17.so
7f7ad2659000-7f7ad265a000 r-xp 00002000 00:10 2839316 /usr/lib/libdl-2.17.so
7f7ad265a000-7f7ad265b000 rwxp 00003000 00:10 2839316 /usr/lib/libdl-2.17.so
7f7ad265b000-7f7ad265d000 r-xp 00000000 00:10 2839280 /usr/lib/libutil-2.17.so
7f7ad265d000-7f7ad285c000 ---p 00002000 00:10 2839280 /usr/lib/libutil-2.17.so
7f7ad285c000-7f7ad285d000 r-xp 00001000 00:10 2839280 /usr/lib/libutil-2.17.so
7f7ad285d000-7f7ad285e000 rwxp 00002000 00:10 2839280 /usr/lib/libutil-2.17.so
7f7ad285e000-7f7ad2865000 r-xp 00000000 00:10 2839273 /usr/lib/librt-2.17.so
7f7ad2865000-7f7ad2a64000 ---p 00007000 00:10 2839273 /usr/lib/librt-2.17.so
7f7ad2a64000-7f7ad2a65000 r-xp 00006000 00:10 2839273 /usr/lib/librt-2.17.so
7f7ad2a65000-7f7ad2a66000 rwxp 00007000 00:10 2839273 /usr/lib/librt-2.17.so
7f7ad2a66000-7f7ad2ac0000 r-xp 00000000 00:10 3403181 /usr/lib/libncursesw.so.5.9
7f7ad2ac0000-7f7ad2cbf000 ---p 0005a000 00:10 3403181 /usr/lib/libncursesw.so.5.9
7f7ad2cbf000-7f7ad2cc3000 r-xp 00059000 00:10 3403181 /usr/lib/libncursesw.so.5.9
7f7ad2cc3000-7f7ad2cc5000 rwxp 0005d000 00:10 3403181 /usr/lib/libncursesw.so.5.9
7f7ad2cc5000-7f7ad2ce6000 r-xp 00000000 00:10 2839312 /usr/lib/ld-2.17.so
7f7ad2e39000-7f7ad2eba000 rwxp 00000000 00:00 0
7f7ad2ee4000-7f7ad2ee6000 rwxp 00000000 00:00 0
7f7ad2ee6000-7f7ad2ee7000 r-xp 00021000 00:10 2839312 /usr/lib/ld-2.17.so
7f7ad2ee7000-7f7ad2ee8000 rwxp 00022000 00:10 2839312 /usr/lib/ld-2.17.so
7f7ad2ee8000-7f7ad2ee9000 rwxp 00000000 00:00 0
7fff979b8000-7fff979d9000 rwxp 00000000 00:00 0 [stack]
7fff979fe000-7fff97a00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Neúspěšně ukončen (SIGABRT) (core dumped [obraz paměti uložen])
}}}
Sometimes it dumps immediately, sometimes it takes a while.
Sometimes the errors are different:
{{{
*** Exception: user error (Terminal does not define required capability ""cup"")
*Main>
}}}
{{{
*** Exception: user error (Terminal does not define required capability ""setab"")
*Main>
: hWaitForInput: end of file
}}}
But mostly it just core dumps." timthelion
9648 25 hvr, ndmitchell@… ghci fails to reload after deleting/creating an imported module GHCi 7.8.3 new normal 2014-11-10T17:26:25Z "If you start GHCi with a 2 module program, delete the child module, reload, you get an error (as expected). If you recreate the child module and reload, it reloads the child module but erroneously claims that parent can't find the child.
Note that if you rename the child to something else, then rename it back, then the test works - so it seems the reappearance and the file stamp confuses ghci. Spotted while working on ghcid: https://github.com/ndmitchell/ghcid
{{{
$ echo module Util where > Util.hs
$ echo ""import Util; main = print 1"" > Main.hs
$ ghci Main.hs
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 2] Compiling Util ( Util.hs, interpreted )
[2 of 2] Compiling Main ( Main.hs, interpreted )
Ok, modules loaded: Util, Main.
*Main> :!del Util.hs -- on Linux --> :!rm Utils.hs
*Main> :r
Main.hs:1:8:
Could not find module `Util'
It is a member of the hidden package `ghc-7.8.3'.
Use -v to see a list of the files searched for.
Failed, modules loaded: Util, Main.
*Main> :!echo module Util where > Util.hs
*Main> :r
[1 of 2] Compiling Util ( Util.hs, interpreted )
[2 of 2] Compiling Main ( Main.hs, interpreted ) [Util changed]
Main.hs:1:1:
Failed to load interface for `Util'
It is a member of the hidden package `ghc-7.8.3'.
Use -v to see a list of the files searched for.
Failed, modules loaded: Util.
}}}
" NeilMitchell
9089 17 hvr, nsch, ibotty Local .ghci_history GHCi 7.8.2 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "Hello,
It would be nice to allow a local .ghci_history to be used (when available) instead of the global .ghc/ghci_history.
This would be similar in behaviour to the .ghci rules:
http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/ghci-dot-files.html
And I believe this should not be too complicated to do (I can even try it myself, if there is interest)." jcristovao
8713 22 hvr, ptrommler@… Avoid libraries if unneeded (librt, libdl, libpthread) GHCi 7.6.3 new normal 2015-07-31T09:09:08Z "I have GHC on an unusual system [1]
libdl.so.1, librt.so.1 and some others are ""filter libraries"": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-)
Unfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this:
{{{
# ghci -package unix
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package unix-2.7.0.0 ... : can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type)
}}}
The unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains.
I use the attached patch for GHC 7.6.3 to fix this issue.
In general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB
[1] http://osdyson.org" ip1981
9394 13 hvr, rodlogic Show data/type family instances with ghci's :info command GHCi 7.6.3 javran new normal 2015-05-18T18:36:59Z "Current version of ghci (7.6.3) does not show data instances. For example, I have some Yesod application and I want to see all data constructors of (Route App) data family instance:
{{{#!hs
*Application> :info Route App
class Eq
(Route
a) => yesod-routes-1.2.0.6:Yesod.Routes.Class.RenderRoute a where
data family Route a1
...
-- Defined in `yesod-routes-1.2.0.6:Yesod.Routes.Class'
instance Eq (Route App) -- Defined at Foundation.hs:48:1
instance Read (Route App) -- Defined at Foundation.hs:48:1
.................
}}}
It just shows info about `Route`, then info about `App` separately. When I try this:
{{{#!hs
*Application> :info (Route App)
:1:2: parse error on input `Route'
}}}
I am getting parse error.
I offer to use this syntax (with parentheses) to show info about instance of data/type family, namely, data constructors and such stuff, just like for ordinal `data`." s9gf4ult
10059 16 hvr, RyanGlScott :i doesn't work for ~ GHCi 7.11 new normal 2015-07-29T15:30:34Z "{{{#!hs
Prelude> :set -XTypeOperators
Prelude> :i (~)
:1:2: parse error on input ‘~’
Prelude> :k (~)
(~) :: k -> k -> Constraint
}}}" dfeuer
9431 13 hvr, simonmar integer-gmp small Integer multiplication does two multiplications on x86 Compiler (NCG) 7.9 new normal 2014-11-13T02:00:23Z "`timesInteger` begins thusly:
{{{
timesInteger :: Integer -> Integer -> Integer
timesInteger (S# i) (S# j) = if isTrue# (mulIntMayOflo# i j ==# 0#)
then S# (i *# j)
else -- ...
}}}
The x86 backend implements `mulIntMayOflo#` as a (word, word) -> double word multiplication, followed by bit manipulation to test for overflow of the low word. Then, if there was no overflow, on the next line we multiply the operands again.
We should be able to do better here. We need a new primop that combines `mulIntMayOflo#` with the actual multiplication result, at least in the non-overflow case (though with some more work we might be able to turn the double word result directly into a large Integer), and then we need to update `timesInteger` to use it.
The LLVM backend probably has the same behavior, though it might be smart enough to notice that the multiplication is repeated; I haven't checked its assembly output." rwbarton
5188 13 hvr, simonmar Runtime error when allocating lots of memory Runtime System 6.12.1 7.12.1 infoneeded low 2015-03-06T22:50:00Z "In GHCI execute
{{{
let powers = 2:map (2^) powers
powers
}}}
When calculating the fourth element of the list, you get the following error message:
{{{
: internal error: getMBlock: mmap: Invalid argument
(GHC version 6.12.1 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
If you have trouble reproducing the bug, try substituting an other number for 2 in the code, e.g. I have also got that error message when I defined powers as:
{{{
let powers = 4:map (4^) powers
}}}
and
{{{
let powers = 13:map (13^) powers
}}}
" knyblad
8733 40 hvr, simonmar, andreas.voellmy@… I/O manager causes unnecessary syscalls in send/recv loops Runtime System 7.6.3 7.12.1 new normal 2014-12-23T13:34:10Z "Network applications often call `send` followed by `recv`, to send a message and then read an answer. This causes syscall traces like this one:
{{{
recvfrom(13, ) -- Haskell thread A
sendto(13, ) -- Haskell thread A
recvfrom(13, ) = -1 EAGAIN -- Haskell thread A
epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager)
recvfrom(14, ) -- Haskell thread B
sendto(14, ) -- Haskell thread B
recvfrom(14, ) = -1 EAGAIN -- Haskell thread B
epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager)
}}}
The `recvfrom` call always fails, as the response from the partner we're communicating with won't be available right after we send the request.
We ought to consider descheduling the thread as soon as sending is ""done"". The hard part is to figure out when that is.
See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example." tibbe
8732 33 hvr, simonmar, idhameed@… Global big object heap allocator lock causes contention Runtime System 7.6.3 7.12.1 simonmar new normal 2015-02-03T20:55:28Z "The lock `allocate` takes when allocating big objects hurts scalability of I/O bound application. `Network.Socket.ByteString.recv` is typically called with a buffer size of 4096, which causes a `ByteString` of that size to be allocated. The size of this `ByteString` causes it to be allocated from the big object space, which causes contention of the global lock that guards that space.
See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example.
" tibbe
8572 12 hvr, simonpj Building an empty module with profiling requires profiling libraries for integer-gmp Compiler 7.7 7.12.1 infoneeded normal 2014-11-22T08:20:53Z "{{{
#!haskell
{-# LANGUAGE NoImplicitPrelude #-}
module A where
}}}
{{{
$ ghc-stage2 -prof -c A.hs
Top level:
Failed to load interface for ‛GHC.Integer.Type’
Perhaps you haven't installed the profiling libraries for package ‛integer-gmp’?
Use -v to see a list of the files searched for.
}}}
I can't built module `A` without profiling libraries for `integer-gmp`, even though I don't use `integer-gmp` anywhere in the module.
This happens because the `Tidy Core` pass attempts to look up the `mkInteger` name (in order to desugar integer literals) even when there are no integer literals in the module.
The obvious fix is to lazily look up `mkInteger` in `Coreprep.lookupMkIntegerName`:
{{{
#!diff
diff --git a/compiler/coreSyn/CorePrep.lhs b/compiler/coreSyn/CorePrep.lhs
index 5e0cd65..9836982 100644
--- a/compiler/coreSyn/CorePrep.lhs
+++ b/compiler/coreSyn/CorePrep.lhs
@@ -56,6 +56,7 @@ import Config
import Data.Bits
import Data.List ( mapAccumL )
import Control.Monad
+import System.IO.Unsafe ( unsafeInterleaveIO )
\end{code}
-- ---------------------------------------------------------------------------
@@ -1119,6 +1120,7 @@ lookupMkIntegerName dflags hsc_env
else if thisPackage dflags == integerPackageId
then return $ panic ""Can't use Integer in integer""
else liftM tyThingId
+ $ unsafeInterleaveIO
$ initTcForLookup hsc_env (tcLookupGlobal mkIntegerName)
mkInitialCorePrepEnv :: DynFlags -> HscEnv -> IO CorePrepEnv
}}}
This way, we don't attempt to look up `mkInteger` until we actually need it, i.e. if there are integer literals that we must desugar.
Relevant commits are 2ef5cd26db27543ac8664a3d18f45550d0109a8b and fdd552e0ecaa17300670a48562995040e1d6687e" parcs
10458 22 hvr, trommler, bgamari GHCi fails to load shared object (the 'impossible' happened) GHCi 7.10.1 7.10.3 new high 2015-07-22T16:08:01Z "I have a project that uses two external libraries, namely `-lcrypt` and `-lpcre`. Building with `cabal` and running the resulting executable works as expected, but I'm having trouble starting a REPL in GHCi:
{{{
% cabal repl
Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0...
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
/usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
}}}
The error suggests I need `-fPIC`, and this seems to help the `-lcrypt` case, but now I get:
{{{
% cabal repl --ghc-options=""-fPIC""
Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0...
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc21539_0/libghc21539_2.so: undefined symbol: pcre_callout
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
FYI the C type of `pcre_callout` is a little unusual:
{{{
extern int (*pcre_callout)(pcre_callout_block *);
}}}
In other words it is a global variable (pointer to function), not a function itself.
Any advice is welcome, including the proper way to start GHCi given these external dependencies, as well as on this apparent bug." rleslie
9277 19 hvr, tulcod, george GHCi panic: Loading temp shared object failed: Symbol not found GHCi 7.8.2 new normal 2015-01-18T19:17:54Z "When given a Objective-C object file referencing a symbol available in a system framework, interactive GHCi 7.8.2 panics saying it can't find the symbol the object file relies on.
Start with an Objective-C source file, defining a function to be used via the FFI:
{{{
$ cat >foo.m <
BOOL is_main_thread()
{
return [NSThread isMainThread];
}
EOF
}}}
{{{
$ cat >Main.hs <> return ()))
make_empty_table:: ST s (STArray s (Int, Int) (Maybe ep))
make_empty_table =
unsafeNewArray_ ((1, 1), (16384, 16384))
}}}
This was tested with 6.9.20071018 on an athlon-xp, and confirmed by dcoutts also on x86-64 with ghc-6.8.0.20071015.
" guest
1826 17 iampure@… unable to list source for should never occur GHCi 6.8.1 ⊥ new normal 2013-01-26T23:50:09Z "I get the very unhelpful ""unable to list source for "". I would like to get one of the following two responses, the last one is best.
{{{
Do this and that to list source
}}}
{{{
We currently cannot list source, because you did and that Do you still want to list source although it requires to do that and that(for example automatically recompiling and reexecuting it until the same program point) [Y/n]?
}}}" guest
9573 25 Iceland_jack, carter, hvr Add warning for invalid digits in integer literals Compiler (Parser) 7.9 7.12.1 vlopez new normal 2014-12-23T13:34:10Z "In its latest version, GHC can parse binary (with `-XBinaryLiterals`), octal and hexadecimal literals:
{{{#!hs
> 0b101010
> 0o52
> 0x2A
}}}
Currently, the parser/lexer reads digits from the input as long as they are valid for the specified radix. All subsequent digits are interpreted as a new, separate token.
If the user uses a digit which isn't valid for the radix, it may be reported with a non-obvious error message, or interpreted in surprising ways:
{{{#!hs
> :t 0o567
0o576 :: Num a => a
> :t 0o5678
0o5678 :: (Num (a -> t), Num a) => t
> :t 0x1bfah
:1:7: Not in scope: ‘h’
> replicate 0o5678
[8,8,8,8,8,8,8...
}}}
We suggest warning the user when a literal of this sort is written, while respecting any other error messages and the original behaviour.
More specifically, the parser or lexer would give a warning if a token starting with an alphanumeric character is found immediately after a numeric literal, without a blank between them.
" vlopez
1526 30 id@… -fobject-code doesn't apply to expressions typed at the prompt Compiler 6.7 ⊥ new normal 2013-01-22T23:29:18Z "While looking to see if I could easily fix #1525 myself, I saw a suspicious modification to the unboxed tuples error; examining more closely:
{{{
stefan@stefans:~/qhc/qhc-desugar/Qhc/TypeCheck$ ghci
Loading package base ... linking ... done.
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.7.20070612, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Prelude> :set -fglasgow-exts
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
Possibly due to foreign import/export decls in source.
Workaround: use -fobject-code, or compile this module to .o separately.
Prelude> :set -fobject-code
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
Possibly due to foreign import/export decls in source.
Workaround: use -fobject-code, or compile this module to .o separately.
Prelude>
}}}
so the suggested workaround doesn't actually work. I can certainly imagine a model of GHC compilation where the NCG doesn't support anonymous modules; in which case the easiest fix would be to tweak the error message. But interactive, optimizing, native compilation *does* sound like a cool and relatively cheap-to-implement feature :)" sorear
1628 30 id@… warning(s) for using stolen syntax that's not currently enabled Compiler 6.6.1 ⊥ new low 2013-01-26T22:24:56Z "Turning on `-fglasgow-exts` makes {{{f x = id$x}}} break. I propose having a flag to warn about things like this, enabled by `-Wall`. To be precise, ""stolen syntax"" is syntax that means something valid in (usually) Haskell98 and something different with some extension enabled. If there are syntax-stealing extensions implemented by other non-GHC compilers, we may want to warn about those too. (This includes all keywords, possibly other words like ""forall"", ""exists"", ""family"", unicode symbols for `->` and others...)
If anyone actually agrees on or implements a (optional) change to unary-minus, this would subsume the warning aspects of #1318." Isaac Dupree
1349 207 id@…, pho@…, bos@…, johan.tibell@…, kolmodin@…, slyfox@…, coreyoconnor@…, illissius@…, hackage.haskell.org@… Generalise the ! and UNPACK mechanism for data types, to unpack function arguments Compiler 6.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "See this thread:
http://www.nabble.com/More-speed-please!-t3411977.html
Briefly the idea is to allow
{{{
data T = MkT (!Int -> Bool)
}}}
to make a `MkT` hold strict functions only. Anyone unpacking a `MkT` can assume the function is strict; and anyone building a `MkT` gets a strictness wrapper aound whatever function they supply, so even if they supply a lazy function, it's made strict.
Seems like a natural generalisation of the existing strictness and UNPACK mechanism for data types.
Lots of details in the thread above.
Simon" simonpj
2893 131 id@…, reiner.pope@…, illissius@…, sjoerd@…, shane@…, ggreif@… "Implement ""Quantified contexts"" proposal" Compiler 6.10.1 ⊥ new normal 2014-07-14T07:56:25Z "See: http://haskell.org/haskellwiki/Quantified_contexts
Motivating example is collapsing insomeway-identical classes such as Monoid and MonadPlus into a single class (with accompanying functions)." porges
7104 18 idhameed@… Add tryWriteTBQueue to Control.Concurrent.STM.TBQueue Core Libraries 7.4.2 7.12.1 simonmar new normal 2014-12-23T13:34:10Z "I'd like a ""try"" variant of writeTBQueue, so part of my application can react to the queue overflowing by returning a ""queue is full"" status.
Attached is a series of patches, the last of which adds {{{writeTBQueue}}}. The other patches fix a couple minor issues:
* Force capacity computations, so a long series of {{{readTBQueue}}} calls won't lead to a stack overflow.
* Guard against negative queue size given to {{{newTBQueue}}} and {{{newTBQueueIO}}}.
----
While we're at it, I have a couple general questions about retry and orElse:
* Is {{{atomically (retry `orElse` return ())}}} guaranteed to not be interruptible by an asynchronous exception when exceptions are masked?
* Is there a performance benefit to avoiding retry when possible? I'd imagine not, since this should only involve throwing away a few transaction log entries.
If {{{atomically (retry `orElse` return ())}}} is guaranteed to not be interruptible, and if there is no performance benefit to avoiding retry, then it seems there's little point in having any of the try* functions.
In the documentation for Control.Exception, it lists operations that are guaranteed to not be interruptible. One of them is:
* STM transactions that do not use retry
This is a useful property, and is expected of any ""try"" function. However, {{{tryReadTBQueue}}} ""uses"" {{{retry}}}.
I did a quick test, and it looks like {{{atomically (retry `orElse` return ())}}} is not interruptible:
{{{
import Control.Concurrent
import Control.Concurrent.STM
import Control.Exception
import Control.Monad
repeatSTM :: STM () -> IO ()
repeatSTM = replicateM_ 50000000 . atomically
main :: IO ()
main = do
finished IO [String]
data GHC = GHC { }
data NHC = NHC { }
ghc :: GHC
ghc = GHC { }
nhc :: NHC
nhc = NHC { }
instance Compiler GHC
instance Compiler NHC
data MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
instance Compiler MkCompiler where
getInstalledPackages (MkCompiler c) = getInstalledPackages c
compilers :: [MkCompiler]
compilers = [MkCompiler ghc, MkCompiler nhc]
}}}
There's two language features we want to make this really nice:
1. Letting us call the data type `Compiler` rather than `MkCompiler`. That would mean separating the class and type namespaces.
2. Letting us derive the Compiler instance for `MkCompiler`.
For the latter we would want either:
{{{
newtype MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
deriving Compiler
}}}
or
{{{
data MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
deriving Compiler
}}}
The advantage of the first is that newtype deriving already exists as a concept so that's nice and consistent. The problem is we do not allow newtypes that use existentials. From an implementation point of view, it's clear that the representations cannot be equal because of the need to store the class dictionary. From a semantic point of view however it's not obvious that existentials with class contexts are illegitimate in newtypes. The underlying implementation would of course have to be an extra layer of boxing, so like data but with the pattern match behaviour newtype." duncan
2933 63 ingmar@…, pho@…, karel.gardas@… LDFLAGS ignored by build system Build System 6.10.1 7.12.1 new lowest 2014-12-23T13:33:22Z "I have required libs installed in `/opt/csw/lib` which is not on the ordinary system linker path. This includes things like `libgmp` etc. That means that to link ghc I want to pass `-R/opt/csw/lib` so that at runtime I do not need to set `LD_LIBRARY_PATH`.
The `./configure --help` mentions `LDFLAGS` however this is ignored. When building gcc the equivalent makes everything work out fine. It would be nice if this were supported.
Note also that `--with-gmp-includes` and `--with-gmp-libraries` are only half helpful. They add -L and -I options during the build only. That lets ghc link stuff using gmp. There are still two problems however:
* Running such programs does not work if the gmp lib dir is not on the standard runtime linker path (which is quite likely given that it was not on the standard compile-time linker path).
* It does not cause the final built ghc to automatically use -L/path/to/gmp/lib. Again I think if it's using `-L/path/to/gmp/lib` it should also use `-R/path/to/gmp/lib` or it'll link but not run.
Some people claim that -R is evil. If we think it is evil and we choose not to use it for `--with-gmp-includes` and `--with-gmp-libraries` then those two become less than useful and it becomes more important to support `LD_OPTIONS`/`LDFLAGS` properly so that distros like the Solaris CSW can use it. For example, see http://www.opencsw.org/standards/pkg-walkthrough which recommends:
{{{
export LD_OPTIONS='-R/opt/csw/lib/$ISALIST -R/opt/csw/lib -L/opt/csw/lib'
}}}
Note: the workaround is to modify the driver script of the bootstrapping ghc and add `-optl-R/the/extra/lib` and then do the same for the script template that will get used by the stage1/2 inplace and final ghc, or to temporarily use LD_LIBRARY_PATH and modify the final ghc driver script during/after install." duncan
5722 53 ireney.knapp@…, hvr@…, klao@… GHC inlines class method forever Compiler 7.2.1 ⊥ simonpj new normal 2014-06-30T09:42:06Z "irene-knapp showed me this over IRC, I refined the test case a bit:
{{{
{-# LANGUAGE FlexibleContexts, MultiParamTypeClasses #-}
module Bug () where
class C a b where
discord :: C a b => a b () -- Remove the constraint and it works
rhyme :: a b ()
instance C (,) b => C (,) [b] where
discord = discord
rhyme = discord
}}}
GHC 7.2.2 compiling this with -O loops forever. I've worked out:
* The `C a b` context in the class is completely superfluous but the bug isn't triggered without it.
* The pattern of recursion in the two method signatures is fragile: `rhyme = rhyme` doesn't trigger the bug, for example.
* Adding a `NOINLINE discord` stops the bug from triggering. Similarly, compiling without optimisations doesn't trigger the bug.
* While it's looping, GHC slowly but steadily chews through all of your memory." benmachine
7258 66 iustin@…, pho@…, dterei, bgamari, asr, gidyn Compiling DynFlags is jolly slow Compiler 7.6.1 7.12.1 simonpj new normal 2015-07-09T00:02:42Z "Compiling `DynFlags` really takes a long time these days.
Ian thinks that it's due to the `Read` and `Show` instances he has added (see attached `W2.hs`.
Simon M suggests: instead of using `Read/Show`, you could generate some code in `mkDerivedConstants` to use `ReadP` and `Outputable`, which should be much smaller and faster.
This ticket is
* To see if we can speed up compilation of `DynFlags`
* To check WHY it is so slow. Are there any lessons we can learn or ways to make it compile faster? Is it tickling some asymptotically-bad corner of the compiler?
Simon" simonpj
8128 22 jan.stolarek@… Standalone deriving fails for GADTs due to inaccessible code Compiler (Type checker) 7.7 new normal 2014-11-16T18:44:36Z "Consider the following:
{{{
{-# LANGUAGE StandaloneDeriving, GADTs, FlexibleInstances #-}
module StandaloneDerivingGADT where
data T a where
MkT1 :: T Int
MkT2 :: (Bool -> Bool) -> T Bool
deriving instance Show (T Int)
}}}
This gives the error:
{{{
StandaloneDerivingGADT.hs:9:1:
Couldn't match type ‛Int’ with ‛Bool’
Inaccessible code in
a pattern with constructor
MkT2 :: (Bool -> Bool) -> T Bool,
in an equation for ‛showsPrec’
In the pattern: MkT2 b1
In an equation for ‛showsPrec’:
showsPrec a (MkT2 b1)
= showParen
((a >= 11)) ((.) (showString ""MkT2 "") (showsPrec 11 b1))
When typechecking the code for ‛showsPrec’
in a standalone derived instance for ‛Show (T Int)’:
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for ‛Show (T Int)’
}}}
The derived instance declaration matches on all the constructors, even if they cannot possibly match. It should omit obviously inaccessible constructors so that this example is accepted. For reference, the derived code is:
{{{
instance GHC.Show.Show
(StandaloneDerivingGADT.T GHC.Types.Int) where
GHC.Show.showsPrec _ StandaloneDerivingGADT.MkT1
= GHC.Show.showString ""MkT1""
GHC.Show.showsPrec a_aij (StandaloneDerivingGADT.MkT2 b1_aik)
= GHC.Show.showParen
((a_aij GHC.Classes.>= 11))
((GHC.Base..)
(GHC.Show.showString ""MkT2 "") (GHC.Show.showsPrec 11 b1_aik))
GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0)
}}}
The same problem applies to other derivable classes (e.g. `Eq`)." adamgundry
8423 22 jan.stolarek@… contraint solver doesn't reduce reducible closed type family expressions (even with undecidable instances!) Compiler (Type checker) 7.7 7.12.1 new normal 2014-12-23T13:34:10Z "attached is an example where the type checker isn't ""computing"" in the closed type families, or at least doing a one step reduction.
this makes sense, given that type families only compute when instantiated...
But if we could partially evaluate closed type families (or at least do a one step reduction), the attached example code would type check!
interestingly, depending on what order the cases for the PSum are written, the type error changes!
I guess I want an ""eager matching"" closed type family, that when partially instantiated will patch on the first pattern it satisfies, to complement ordered type families.
attached is a toy example where I otherwise need an unsafeCoerce to make things type check" carter
8707 22 jan.stolarek@… Kind inference fails in data instance definition Compiler 7.7 new low 2014-03-12T11:16:50Z "Consider the following shenanigans:
{{{
{-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs #-}
data family SingDF (a :: (k, k2 -> *))
data Ctor :: k -> *
data instance SingDF (a :: (Bool, Bool -> *)) where
SFalse :: SingDF '(False, Ctor)
}}}
HEAD reports (with `-fprint-explicit-kinds`)
{{{
Data constructor ‛SFalse’ returns type ‛SingDF
Bool k '('False, Ctor k)’
instead of an instance of its parent type ‛SingDF Bool Bool a’
In the definition of data constructor ‛SFalse’
In the data instance declaration for ‛SingDF’
}}}
I see two problems here:
1) Kind inference should fix the problem. If I add a kind annotation to `Ctor`, the code works. GHC should be able to infer this kind annotation for me.
2) The error message is not particularly helpful. GHC 7.6.3 had a more verbose, but more helpful message." goldfire
8156 22 jan.stolarek@… amd64 + in-tree gmp build broken Build System 7.7 7.12.1 infoneeded low 2014-12-23T13:33:45Z "Currently, the GHC build system has an in-tree GMP. This GMP seems to
be used only if there is no usable GMP found on the system and the
user didn't provide one using configure flags.
When we build GHC using an external shared version of GMP, the
resulting GHC is dynamically linked against GMP and also the
generated programs are linked dynamically against GMP.
When the in-tree GMP is used, it is built statically, even if the GHC
we are building is shared GHC on GNU/Linux. This feature is currently
broken on amd64 (#4366, #4022), but is working currently
very well on Linux i686.
Apart from the breakage this setting is very flexible and I'd be very
happy if it were possible to keep it, in spite of removeal requests
like #4374.
When there is a system GMP, nothing would change, this is the most
typical usage, e.g. distributions are all building this way.
On the other hand, if the user removes his GMP (maybe we should
provide an option to explicity trigger this in ./configure, instead of
having to remove GMP); she can build a GHC that is not linked
dynamically against GMP and the resulting programs are not linked
either. This makes it possible to generate binaries that link
dynamically against libc (no -static) which is quite compatible
amongst versions, but doesn't require a libgmp.so to run. For binary
deployments this seems to be the best kind of setup nowadays.
Now, if we were only able to fix this for amd64. See this:
https://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
On amd64 we can continue to compile GMP statically and link into the
binary library, we just have to compile GMP with the fPIC. I attached
the patch to fix this. Previously a similar patch has been rejected
in #4022 because ""this shouldn't
be platform specific"", but this is clearly not the case, this is
specific to amd64.
Tadaaaam:
{{{
errge@sid64:~/ghc/inplace/bin$ cat test.hs
main = print (2^100)
errge@sid64:~/ghc/inplace/bin$ ./ghc-stage2 test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
errge@sid64:~/ghc/inplace/bin$ ./test
1267650600228229401496703205376
errge@sid64:~/ghc/inplace/bin$ ldd ./test
linux-vdso.so.1 (0x00007fff79962000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b9a83000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b987a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b9676000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b92c6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe4b90a6000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe4b9d83000)
}}}
No GMP!
I attach the build file patch to the bugreport.
So, can we please apply this patch and just keep the in-tree GMP?
" errge
2731 22 jan.stolarek@… Avoid unnecessary evaluation when unpacking constructors Compiler 6.8.3 7.12.1 new lowest 2014-12-23T13:33:22Z "
Consider
{{{
data T a = MkT !a
foo :: T (a,b) -> a
foo (MkT (x,y)) = x
}}}
GHC will extract the first component of the `MkT`, ''evaluate it'', and then extract the first component of the pair. The evaluation step isn't needed, since the component is known to be already-evaluated. `UNPACK` directives won't work here, because the component is polymorphic.
In the email thread, Tyson posted an example where this extra eval made a significant difference to his inner loop:
[http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015796.html]
Simon
" simonpj
5567 72 jan.stolarek@…, brooks.brian@…, rwbarton, erikd, michalt LLVM: Improve alias analysis / performance Compiler (LLVM) 7.12.1 dterei new normal 2015-05-09T18:03:09Z " * LLVM doesn't generate as good as code as we feel it should in many situations
* Why?
* We've often felt its a alias anlysis issue.
* I'm a little more doubtful of that than others (I feel its part of the bigger problem, not the whole thing).
* I think there may be some register allocation / instruction selection / live range splitting issue going on.
* We could also do with looking at what optimisation passes we should run and in what order...
Here is some work Max did on the alias issue, his results for nofib weren't good:
http://blog.omega-prime.co.uk/?p=135
So this ticket is just a high level ticket about figuring out and improving the performance of LLVM backend." dterei
10116 83 jan.stolarek@…, george.karachalias@…, tom.schrijvers@… Closed type families: Warn if it doesn't handle all cases Compiler 7.8.4 new normal 2015-02-26T16:10:12Z "Right now, I can do the following:
{{{#!hs
data Foo = A | B
type family Bar (n :: 'Foo) where
Bar 'A = Int
}}}
I would like to be warned if I write a partial type function like this because partial functions are almost always a mistake." andrewthad
2387 48 jan.stolarek@…, mail@… Optimizer misses unboxing opportunity Compiler 6.8.2 7.12.1 new lowest 2014-12-23T13:33:22Z "In my studying of the fannkuch benchmark, I've discovered (I think) another missed optimization. A scaled down illustration goes as follows:
{{{
{-# LANGUAGE TypeOperators, BangPatterns #-}
module Main (main) where
import Control.Monad.ST
import System.Environment
data (:*:) a b = !a :*: !b
whileLoop :: Int -> ST s Int
whileLoop = go 0
where
go !n k
| k == 0 = return n
| otherwise = go (n+1) (k-1)
{-# INLINE whileLoop #-}
iter :: Int -> Int -> ST s (Bool :*: Int)
iter k n = do
k' >= \k' -> return $! max k k'
b Int -> ST s Int
mainLoop k n = do
done :*: k' Int# -> STRep s_aem Int
$wpoly_go_r1aE =
\ (@ s_aem)
(ww_s18Y :: Int#)
(ww1_s192 :: Int#)
(eta_s19w :: State# s_aem) ->
case ww1_s192 of wild_XF {
__DEFAULT ->
$wpoly_go_r1aE @ s_aem (+# ww_s18Y 1) (-# wild_XF 1) eta_s19w;
0 -> (# eta_s19w, I# ww_s18Y #)
}
}}}
Note, the return type is a boxed Int. The function is only used once, like so:
{{{
...
case $wpoly_go_r1aE @ s_aem 0 40 w_s19f of wild_aFw { (# new_s_aFB, r_aFC #) ->
case r_aFC of wild1_aG9 { I# y_aGb ->
case <=# ww_s199 y_aGb of wild2_aGd {
False ->
...
}}}
In other words, go boxes its results at the end of the loop, and the function that uses it immediately looks inside the box for the value. In this particular micro-benchmark, the boxed value (wild1_aG9 above) is actually used in the case where mainLoop returns the boxed value. However, in the larger benchmark I pulled this from, that is not the case in several areas (only the unboxed value is used, but it still goes through a box). Either way, the boxed value is only used at the end of the loop (and not every time there), and on every other iteration, this results in superfluous allocation.
I'll attach a manually unboxed version I wrote (it also has iter and max manually inlined to mainLoop, since that makes it easier to write; the core for the above shows that they are getting inlined properly, so I assume that isn't the issue). Using +RTS -sstderr shows that (running 100 million iterations here), the manually unboxed version allocates 50 kilobytes on the heap, and runs in around 15 seconds, whereas the version above that doesn't get unboxed does 1.6 gigabytes of heap allocation, and takes 18 seconds (in the larger benchmark, such extra boxing would happen perhaps 40 million times over the course of the program).
Thanks for your help." dolio
8048 41 jan.stolarek@…, schyler, simonmar Register spilling produces ineffecient/highly contending code Compiler (CodeGen) 7.6.3 ⊥ new normal 2014-03-20T14:15:19Z "The native codegen and llvm both produce ineffecient code for functions using structures with many strict fields or unboxed values.
Consider the following program:
{{{
{-# LANGUAGE BangPatterns #-}
module Spill where
import GHC.Exts
data S = S !Int !Int !Int !Int !Int !Int !Int !Int !Int
spill :: S -> S -> S -> S
spill (S !a !b !c !d !e !f !g !h !i) (S !j !k !l !m !n !o !p !q !r) (S !s !t !u !v !w !x !y !z _)
= S (a + j + s) (b + c) (k + r) (a + b + c + d + e + f + g + h + i) (j + k + l + m + n + o + p + q + r) (s + t + u + v + w + x + y + z) (a + b + c) (j + k + l) (s + t + u)
}}}
Parts of the code produced for this (which is identical regardless of -funbox-strict-fields) looks like:
{{{
_cnc:
addq $80,%r12
cmpq 144(%r13),%r12
ja _cni
movq $Spill.S_con_info,-72(%r12)
movq 32(%rbp),%rax
movq %rax,-64(%r12)
movq 24(%rbp),%rax
movq %rax,-56(%r12)
movq 16(%rbp),%rax
movq %rax,-48(%r12)
movq 8(%rbp),%rax
movq %rax,-40(%r12)
movq 40(%rbp),%rax
movq %rax,-32(%r12)
movq 48(%rbp),%rax
movq %rax,-24(%r12)
movq 56(%rbp),%rax
movq %rax,-16(%r12)
movq 64(%rbp),%rax
movq %rax,-8(%r12)
movq 7(%rbx),%rax
movq %rax,0(%r12)
leaq -71(%r12),%rbx
addq $72,%rbp
jmp *0(%rbp)
}}}
{{{
_csv:
movq 63(%rbx),%rax
movq %rax,-56(%rbp)
movq 55(%rbx),%rax
movq %rax,-48(%rbp)
movq 47(%rbx),%rax
movq %rax,-40(%rbp)
movq 39(%rbx),%rax
movq %rax,-32(%rbp)
movq 31(%rbx),%rax
movq %rax,-24(%rbp)
movq 23(%rbx),%rax
movq %rax,-16(%rbp)
movq 71(%rbx),%rax
movq %rax,-8(%rbp)
movq 15(%rbx),%rax
movq %rax,0(%rbp)
}}}
And likewise for LLVM:
{{{
.LBB10_1: # %coZ
movq 7(%rbx), %rcx
movq $Spill_S_con_info, 8(%rax)
movq 8(%rbp), %rdx
movq %rdx, 16(%rax)
movq 16(%rbp), %rdx
movq %rdx, 24(%rax)
movq 24(%rbp), %rdx
movq %rdx, 32(%rax)
movq 32(%rbp), %rdx
movq %rdx, 40(%rax)
movq 40(%rbp), %rdx
movq %rdx, 48(%rax)
movq 48(%rbp), %rdx
movq %rdx, 56(%rax)
movq 56(%rbp), %rdx
movq %rdx, 64(%rax)
movq 64(%rbp), %rdx
movq %rdx, 72(%rax)
movq %rcx, (%r12)
movq 72(%rbp), %rax
leaq 72(%rbp), %rbp
leaq -71(%r12), %rbx
jmpq *%rax # TAILCALL
}}}
Quoting from #ghc ""the [register allocator] core algo is '96 vintage"". Improvements are needed;
* Take into consideration pipelining and handle spills less dramatically, attempting to reduce register contention
* Sink memory reads in order to reduce register pressure
" schyler
9157 32 jan.stolarek@…, simonmar cmm common block not eliminated Compiler 7.8.2 new normal 2015-03-05T08:10:15Z "For the toTuple# function (in the attached file) GHC generates a cmm switch statement, with all the alternatives, unsurprisingly, the same. Yet, cmm common block elimination does not kick in.
In this particular example, the whole case statement could be annihilated, because all alternatives lead to the same code.
BTW, this is how they match in France.
{{{
#!ocaml
type alt = A of int | B of int | C of int | D of int
let g x = match x with A v | B v | C v | D v -> v
}}}" wojteknar
10599 4 jb55 "Template Haskell doesn't allow `newName ""type""`" Template Haskell 7.10.2-rc2 7.12.1 goldfire new high 2015-07-06T23:08:05Z "Using `type` as a name is, of course, forbidden. OTOH, `type_1` is allowed as a name.
However, using GHC 7.10.1 and `ghc --make T.hs` on files:
{{{#!hs
-- T.hs
{-# LANGUAGE TemplateHaskell #-}
module T where
import Q
test
-- Q.hs
module Q where
import Language.Haskell.TH
test :: Q [Dec]
test = do
t : can't load .so/.DLL for: /usr/lib/libcurses.so (-lncursesw: cannot open shared object file: No such file or directory)
}}}
After some searching I narrowed down the issue to `/usr/lib/libcurses.so` file. In Arch, this file contains `INPUT(-lncursesw)`. If I change it to `INPUT(libncursesw.so)` or `INPUT(/usr/lib/libncursesw.so)` it works fine. Symlinking `/usr/lib/libcurses.so` to `/usr/lib/libncursesw.so` also works.
This bug seems to be connected to #2615. GHC still doesn't follow `INPUT` commands containing `-llibrary` form. Ld documentation allows this: {{{If you use `INPUT (-lfile)', ld will transform the name to libfile.a, as with the command line argument `-l'}}}. (https://sourceware.org/binutils/docs/ld/File-Commands.html)" mmikolajczyk
3549 19 jmillikin@… unlit does not follow H98 spec Compiler 6.10.4 ⊥ patch normal 2015-07-24T07:58:35Z "The Haskell 98 spec has this to say about the [http://haskell.org/onlinereport/syntax-iso.html Latex \begin{code} \end{code}] style:
An alternative style of literate programming is particularly suitable for use with the LaTeX text processing system. In this convention, only those parts of the literate program that are entirely enclosed between \begin{code}...\end{code} delimiters are treated as program text; all other lines are comment. More precisely:
* Program code begins on the first line following a line that begins \begin{code}.
* Program code ends just before a subsequent line that begins \end{code} (ignoring string literals, of course).
The key phrases are ""a line that begins \begin{code}"" and ""line that begins \end{code}"". This means the semantics is something like:
{{{
classifyLine s
| ""\\begin{code}"" `isPrefixOf` s = BeginCode
| ""\\end{code}"" `isPrefixOf` s = EndCode
}}}
GHC's `unlit` C program uses:
{{{
if (strcmp(buf, ""\\begin{code}"") == 0)
return BEGIN;
}}}
The equivalent semantics in the style above would be:
{{{
classifyLine s
| ""\\begin{code}"" == s = BeginCode
| ""\\end{code}"" == s = EndCode
}}}
It seems fairly clear from the spec that GHC's unlit program is wrong in this respect.
The practical consequence is that Cabal's unlit and GHC's one do not match and this [http://haskell.org/pipermail/haskell-cafe/2009-September/066780.html catches people out]. There is [http://www.haskell.org/haskellwiki/Literate_programming#Hiding_code_from_Haskell explicit advice on the Haskell wiki] recommending that people take advantage of this GHC bug." duncan
7602 102 johan.tibell@…, chak@…, anton.nik@…, george.colpitts@…, simonmar Threaded RTS performing badly on recent OS X (10.8?) Runtime System 7.12.1 thoughtpolice new high 2015-02-21T13:20:09Z "This ticket is to remind us about the following problem: OS X is now using llvm-gcc, and as a result GHC's garbage collector with -threaded is much slower than it should be (approx 30% slower overall runtime). Some results here: [http://www.haskell.org/pipermail/cvs-ghc/2011-July/063552.html]
This is because the GC code relies on having fast access to thread-local state. It uses one of two methods: either a register variable (gcc only) or `__thread` variables (which aren't supported on OS X). To make things work on OS X, we use calls to `pthread_getspecific` instead (see #5634), which is quite slow, even though it compiles to inline assembly.
I don't recall which OS X / XCode versions are affected, maybe a Mac expert could fill in the details.
We have tried other fixes, such as passing around the thread-local state as extra arguments, but performance wasn't good. Ideally Apple will implement TLS in OS X at some point and we can start to use it.
A workaround is to install a real gcc (using homebrew?) and use that to compile GHC. Whoever builds the GHC distributions for OS X should probably do it that way, so everyone benefits.
" simonmar
5539 293 johan.tibell@…, chowells79@…, bgamari@…, pho@…, rl, bos@…, alexey.skladnoy@…, choener@…, aruiz@…, idhameed@…, hackage.haskell.org@…, ekmett@…, gregmainland@…, george.colpitts@… GHC panic - Simplifier ticks exhausted Compiler 7.3 7.12.1 simonpj new normal 2015-07-02T18:40:35Z "When trying to install `blaze-builder` with a freshly installed GHC 7.3.20111007 linux/amd64 build, the following panic occurs:
{{{
$ cabal install blaze-builder
Resolving dependencies...
Configuring blaze-builder-0.3.0.1...
Building blaze-builder-0.3.0.1...
Preprocessing library blaze-builder-0.3.0.1...
...
[10 of 13] Compiling Blaze.ByteString.Builder.HTTP ( Blaze/ByteString/Builder/HTTP.hs, dist/build/Blaze/ByteString/Builder/HTTP.o )
[11 of 13] Compiling Blaze.ByteString.Builder.Int ( Blaze/ByteString/Builder/Int.hs, dist/build/Blaze/ByteString/Builder/Int.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.3.20111007 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying UnfoldingDone a_s9oE{v} [lid]
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: 5123
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}" hvr
5218 226 johan.tibell@…, dons, dcoutts, pho@…, lykahb@…, reiner.pope@…, alexey.skladnoy@…, wren@…, patrick@…, hackage.haskell.org@…, tkn.akio@… Add unpackCStringLen# to create Strings from string literals Compiler 7.0.3 7.12.1 thoughtpolice new normal 2015-07-30T12:35:06Z "GHC insert calls to `unpackCString#` to convert string literals to `String`s. Libraries like bytestring use rewrite rules to match on this call to optimize code like `pack (unpackCString# s)`.
If GHC would instead use a version of unpackCString#, say unpackCStringLen#, that includes the (statically known) length, creating `ByteString`s from literals could be a constant time operation instead of a linear time operation.
Another use case, which motivated this ticket, is appending string literals to builders (e.g. using `Data.Binary.Builder.fromByteString`). For small strings the most efficient way to append a string to the builder is to copy the statically allocated string directly into the builder's output buffer. If the string length was known statically, we could do this efficiently using `memcpy` or even using a small unrolled loop.
" tibbe
10601 45 johan.tibell@…, duncan@… GHC should be distributed with debug symbols Build System new normal 2015-07-06T09:10:52Z "Now that we have the capability of producing code with DWARF symbols, we should distribute GHC with them, or at least give the option.
The DWARF symbols in these case would be both for the C RTS and for the base Haskell libraries shipped with GHC. Building GHC with said symbols amounts to adding
{{{
GhcRtsHcOpts += -g
GhcLibHcOpts += -g
}}}
to `mk/build.mk`." bitonic
5059 40 johan.tibell@…, ekmett@… Pragma to SPECIALISE on value arguments Compiler 7.0.3 7.12.1 new low 2014-12-23T13:33:45Z "I've sometimes found myself wishing for this pragma to get some ""partial evaluation on the cheap"". The idea is to allow something like:
{{{
defaultOpts :: Options
defaultOpts = ...
{-# SPECIALISE f defaultOpts :: Int -> Int #-}
f :: Options -> Int -> Int
f opts x = ... f opts ...
}}}
This would desugar into this additional code:
{{{
{-# RULES ""f/spec"" f defaultOpts = f_spec_1 #-}
f_spec_1 = (\opts x -> ... ... f opts ...) defaultOpts -- NB: body of f duplicated
}}}
The hope is that the simplifier and RULE matcher will tidy this up so we get a nice loop back to f_spec_1 with the body of the function specialised for the particular opts.
This is useful when functions are called often with particular arguments. An example would be where ""f"" is an edit-distance function which takes costs to be assigned to each edit, strings to be compared and returns an integer distance. In my library, the costs are given almost always going to be the default ones so I want to make that case fast, but I want to allow the user to supply their own set.
This pragma is somewhat subsumed by:
1. SpecConstr, if the options are algebraic data/literals that are also scrutinised by the body of f
2. Static argument transformation, except that the RULE based strategy achieves more code sharing compared to SAT
I think that pragma might be a relatively simple to implement nice-to-have feature." batterseapower
7482 35 johan.tibell@…, hvr, ekmett GHC.Event overwrites main IO managers hooks to RTS libraries/base 7.4.1 7.8.1 new normal 2014-11-27T23:04:19Z "The IO manager registers two file descriptors with the RTS which the RTS uses to send control and wakeup signals to the IO manager. The main IO manager is started up by default and registers some file descriptors that it has allocated with the RTS.
The base package also exposes a GHC.Event module which when initialized will also register files with the RTS, overwriting the main IO manager's files. Now the RTS can no longer signal the main IO manager." AndreasVoellmy
4937 127 johan.tibell@…, pumpkingod@…, as@…, michal.terepeta@…, dterei, hackage.haskell.org@… Remove indirections caused by sum types, such as Maybe Compiler 7.0.1 7.12.1 new normal 2014-12-23T13:34:10Z "While null pointers cause correctness issues in languages that allow them, they do have one benefit over `Maybe` when used to represent nullable values: they allow encoding the absence of a value cheaply. Using `Maybe` to represent a nullable value adds an extra indirection (pointer) to get to the wrapped value.
We could use the bits set by pointer tagging to encode that the pointer points directly to the value, rather than to an intermediate constructor. I believe JHC takes this approach.
A motivating example is this implementation of a hash array mapped trie (HAMT): A HAMT stores key/value pairs and subtrees in two arrays.
{{{
data Node k v = MkNode (Array (Maybe k)) (Array (Either v (Node k v))
}}}
Iff index `i` in the first array is `Nothing`, the second array contains a Node at index `i`, otherwise it contains a value.
Adding an extra indirection, using `Maybe` or `Either`, adds both space (in terms of extra points and data constructor headers) and time (in terms of additional cache misses and branches).
" tibbe
7325 48 johan.tibell@…, simonmar, AndreasVoellmy threadDelay mistreats minBound and maxBound in some configurations Runtime System 7.6.1 7.12.1 new high 2015-07-26T09:32:52Z "threadDelay currently treats minBound and maxBound incorrectly in some cases. This breaks the following idiom ([http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async.html#Concurrently as seen in the async package]):
{{{
forever (threadDelay maxBound)
}}}
On Linux (Ubuntu 10.04 64-bit) without -threaded, {{{threadDelay maxBound}}} returns immediately. For lower numbers on the same order of magnitude, it behaves non-deterministically. For example, given this program:
{{{
import Control.Concurrent
import Control.Monad
main = forM_ [6244222868950683224..] $ \i -> do
print i
threadDelay i
}}}
threadDelay returns immediately in some cases but not in others. If I compile and run it in bash like this:
{{{
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound
}}}
The bug usually appears, but if I run it like this:
{{{
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs
./threadDelay-maxBound
}}}
The bug does not appear (threadDelay blocks like it should). Thus, the program is affected by a very subtle difference in how it is invoked. Perhaps it is sensitive to file descriptor numbers.
On Windows without -threaded, {{{threadDelay maxBound}}} seems to work, but {{{threadDelay minBound}}} blocks rather than returning immediately." joeyadams
10411 21 JohnWiegley, gershomb Neighbour let-bindings are not reported as relevant Compiler 7.10.1 new normal 2015-05-23T06:32:19Z "{{{
> :set -fno-max-relevant-binds
> let a = True; b = _ in undefined
:3:19:
Found hole ‘_’ with type: t1
Where: ‘t1’ is a rigid type variable bound by
the inferred type of b :: t1 at :3:15
Relevant bindings include
b :: t1 (bound at :3:15)
it :: t (bound at :3:1)
In the expression: _
In an equation for ‘b’: b = _
In the expression:
let
a = True
b = _
in undefined
}}}
Somehow a is not there, even though b itself is.
Tested with 7.8.3 and 7.10.1" Feuerbach
4102 161 josefs@…, gabriel@…, dterei, rrnewton@…, wren@…, johan.tibell@…, mle+hs@…, dfeuer, hvr, ekmett Bit manipulation built-ins Core Libraries 6.12.2 7.12.1 ekmett new normal 2014-12-23T13:34:10Z "So far Haskell/GHC lacks more HL bit manipulation instructions which on many platform can be compiled to single instruction. Probably the good guide are those implemented in LLVM:
- byte swap
- population count
- number of leading zeros
- number of trailing zeros
All of them can be implemented in terms of Data.Bits - however not quite in efficient way (like looping over patterns)." uzytkownik
10598 20 jpm@…, oerjan DeriveAnyClass and GND don't work well together Compiler 7.11 new normal 2015-07-22T21:24:37Z "I think we definitely have a bug here, but I'm not sure what it really is.
Here's the program:
{{{
newtype MyMaybe a = MyMaybe (Maybe a)
deriving (Functor, Show)
main = print $ MyMaybe $ Just (10 :: Int)
}}}
I'm using GHC 7.10.1.
{{{
➜ deriveany_bug ghc --make -fforce-recomp Test.hs -XDeriveAnyClass -XGeneralizedNewtypeDeriving
[1 of 1] Compiling Main ( Test.hs, Test.o )
Test.hs:2:13:
Can't make a derived instance of ‘Functor MyMaybe’
(even with cunning newtype deriving):
You need DeriveFunctor to derive an instance for this class
Try GeneralizedNewtypeDeriving for GHC's newtype-deriving extension
In the newtype declaration for ‘MyMaybe’
}}}
Just to try, changing argument order:
{{{
➜ deriveany_bug ghc --make -fforce-recomp Test.hs -XGeneralizedNewtypeDeriving -XDeriveAnyClass
[1 of 1] Compiling Main ( Test.hs, Test.o )
Test.hs:2:13:
Can't make a derived instance of ‘Functor MyMaybe’
(even with cunning newtype deriving):
You need DeriveFunctor to derive an instance for this class
Try GeneralizedNewtypeDeriving for GHC's newtype-deriving extension
In the newtype declaration for ‘MyMaybe’
}}}
It works fine if I remove `DeriveAnyClass`:
{{{
➜ deriveany_bug ghc --make -fforce-recomp Test.hs -XGeneralizedNewtypeDeriving
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
}}}
GHC HEAD is failing in exactly the same way.
User manual is saying this in 7.5.6:
> In case you try to derive some class on a newtype, and -XGeneralizedNewtypeDeriving is also on, -XDeriveAnyClass takes precedence.
But then why is it telling me to enable `GeneralizedNewtypeDeriving` in the error message? Even if I already enabled it?
Also, maybe it could try `GND` when `DeriveAnyClass` fails? Because the doc is saying `DeriveAnyClass` has precedence but doesn't specify what happens if it fails.
EDIT: I'd like to work on this myself if experts here help me figuring the right behavior here." osa1
9276 3 jrp audit ghc floating point support for IEEE (non)compliance Compiler 7.8.2 7.12.1 carter new normal 2014-12-27T20:59:20Z "As best I can determine, ghc has never been closely audited for conformance to IEEE-754 (floating point) standard and currently is a bit far from providing a compliant implementation.
This impacts both a number of other tasks i wish to do for ghc **and** much of my own use of haskell is in a floating point heavy workloads, I will do a bit of leg work to:
a) improve test suite support for checking for compliance
b) write some patches to provide portable compliant primops for the operations which need compiler support
c) try to determine how to allow ghc optimizer to be a bit more aggressive in a sound way in the presence of floating point.
(this may grow into a few subtickets, we'll see)" carter
8832 9 jstolarek Constant-folding regression wrt `clearBit (bit 0) 0 ` Compiler 7.8.1-rc2 7.12.1 new high 2015-06-11T18:00:27Z "While implementing `zeroBits` (see [83bd2f5fc7e/base]) I noticed that constant folding of the expression `clearBit (bit 0) 0` regressed (and improved at the same time) from GHC 7.6.3 to GHC 7.8.1, specifically, the following module
{{{#!haskell
{-# LANGUAGE CPP #-}
module M where
import Data.Bits
import Data.Int
import Data.Word
#define T(s,T) \
s :: T ; \
s = clearBit (bit 0) 0 ; \
T(i,Int)
T(i8,Int8)
T(i16,Int16)
T(i32,Int32)
T(i64,Int64)
T(w,Word)
T(w8,Word8)
T(w16,Word16)
T(w32,Word32)
T(w64,Word64)
T(z,Integer)
}}}
compiled with GHC 7.8.1RC2 results in the following Core output:
{{{#!haskell
-- GHC 7.8.1RC2
i = I# (andI# 1 (notI# 1))
i8 = I8# 0
i16 = I16# 0
i32 = I32# 0
i64 = I64# 0
w = W# (__word 0)
w8 = W8# (__word 0)
w16 = W16# (__word 0)
w32 = W32# (__word 0)
w64 = W64# (__word 0)
z2 = $w$cbit 0
z1 = complementInteger z2
z = andInteger z2 z1
}}}
Thus, `i` and `z` are not properly constant-folded in GHC 7.8.1RC2. With GHC 7.6.3, however, `i` and `z` were properly folded to `0`:
{{{#!haskell
-- GHC 7.6.3
i = I# 0
i8 =
case $fBitsInt8_$cbit i of _ { I8# x#_aDf ->
case $fBitsInt8_$cbit i of _ { I8# x#1_aDr ->
I8#
(word2Int#
(and#
(int2Word# x#_aDf)
(xor# (int2Word# x#1_aDr) (__word 18446744073709551615))))
}
}
i16,i32,i64 -- equivalent to i8
w = W# (__word 0)
w8 =
case $fBitsWord8_$cbit i of _ { W8# x#_aEV ->
case $fBitsWord8_$cbit i of _ { W8# x#1_aF5 ->
W8# (and# x#_aEV (xor# x#1_aF5 (__word 255)))
}
}
w16,w32,w64 -- equivalent to w8
z = __integer 0
}}}
" hvr
9661 18 jstolarek, bgamari Branchless ==# is compiled to branchy code Compiler 7.9 bgamari new normal 2015-04-20T06:13:16Z "This started as a comment on #6135, but Jan Stolarek requested that I file a separate report. The branchless tests `#`, `<=#`, and `>=#`, and their wordy cousins, seem to work properly, but `==#` and `eqWord#` don't. If I write
{{{#!hs
foo x = tagToEnum# ((x # 100#) `orI#`
(x ==# 12#) `orI#` (x ==# 15#))
}}}
I get (in 7.8.3 and in 7.9)
{{{#!hs
IsDigit.foo :: GHC.Prim.Int# -> GHC.Types.Bool
[GblId,
Arity=1,
Caf=NoCafRefs,
Str=DmdType ,
Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True,
Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False)
Tmpl= \ (x3_a2if [Occ=Once!] :: GHC.Prim.Int#) ->
case x3_a2if of wild_Xe {
__DEFAULT ->
GHC.Prim.tagToEnum#
@ GHC.Types.Bool
(GHC.Prim.orI# (GHC.Prim.# wild_Xe 100));
12 -> GHC.Types.True;
15 -> GHC.Types.True
}}]
IsDigit.foo =
\ (x3_a2if :: GHC.Prim.Int#) ->
case x3_a2if of wild_Xe {
__DEFAULT ->
GHC.Prim.tagToEnum#
@ GHC.Types.Bool
(GHC.Prim.orI# (GHC.Prim.# wild_Xe 100));
12 -> GHC.Types.True;
15 -> GHC.Types.True
}}}
and branching assembly to match. Jan Stolarek indicates this is probably a problem with constant folding." dfeuer
8871 19 jstolarek, simonmar No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm Compiler (CodeGen) 7.9 new normal 2014-11-07T14:08:32Z "Hello,
on SPARC and I also guess on PPC it's possible to get following line in optimized Cmm code:
{{{
I64[BaseReg + 784] = I64[BaseReg + 784];
}}}
this line is then translated by NCG wasting 5 isns on SPARC at least. Don't know PPC. I'm not sure if this is possible to duplicate this on i386 due to fewer regs. Generally speaking you need to have 32bit target with more regs available. Interesting fact is that such line is not presented in non-optimized Cmm, but is presented in optimized one. Both optimized and non-optimized Cmms attached. Both get from compiling T7507 testcase by stage1 compiler on SPARC:
{{{
/home/karel/vcs/ghc-src/ghc-sparc-reg_ncg/inplace/bin/ghc-stage1 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7507.hs -O -ddump-opt-cmm > T7507.opt-cmm-sparc-reg-ncg
}}}
Of course non-opt Cmm is got by -ddump-cmm instead of -ddump-opt-cmm.
If you need more simplified testcase, then following code is usable too:
{{{
module Main where
import Data.Int
main = print ( ( 2 ^ 6 ) :: Int64 )
}}}" kgardas
4029 33 judah.jacobson@…, blarsen ghci leaks memory when loading a file GHCi ⊥ new normal 2010-08-11T13:27:23Z "In the 6.12 series, ghci leaks memory when loading definitions. This appears to be a regression from previous releases. The problem appears in both 6.12.1 and 6.12.2, but not in 6.8.3 or 6.10.4.
As a test, take the attached Hello World file, fire up ghci, and :load Hello.hs. Watch the memory usage of ghci---each time you repeat the load command, the memory usage of the process grows. (It grows slowly on this simple example, but on a real project, the growth can be several megabytes per :load.)
I discovered this due to my workflow. When programming Haskell, I typically use emacs with haskell-mode, and frequently reload the definitions of the code I am working on. After upgrading to 6.12.1, after coding for some time, I noticed my 8GB machine was swapping. (It is faster to :reload the file rather than :load, and reloading doesn't appear to suffer from the memory leak, but sometimes I switch between modules and :reload is not applicable.)
My workaround for now is to regularly restart my ghci processes to prevent their memory usage from growing so much that my system starts swapping.
I have observed this bug on 32- and 64-bit GHCi on various versions of Ubuntu, on both Intel and AMD processors.
" blarsen
9655 16 jwlato@… Do not UNPACK strict fields that are very wide Compiler 7.8.3 new normal 2014-10-02T07:27:56Z "John Lato [http://www.haskell.org/pipermail/ghc-devs/2014-September/006473.html writes] (a propos of another discussion): ""This is possibly unrelated, but the setup seems almost identical to a very similar problem we had in some code, i.e. very long compile times (6+ minutes for 1 module) and excessive memory usage when compiling generic serialization instances for some data structures.
In our case, I also thought that INLINE functions were the cause of the problem, but it turns out they were not. We had a nested data structure, e.g.
{{{
> data Foo { fooBar :: !Bar, ... }
}}}
with `Bar` a very wide product type (~150 fields).
Even when we explicitly NOINLINE'd the function that serialized Bar, GHC still created a very large helper function of the form:
{{{
> serialize_foo :: Int# -> Int# -> ...
}}}
where the arguments were the unboxed fields of the Bar structure, along with the other fields within Foo. It appears that even though the serialization function was NOINLINE'd, it simply created a Builder, and while combining the Builder's ghc saw the full structure. Our serializer uses blaze, but perhaps Binary's builder is similar enough the same thing could happen.
Anyway, in our case the fix was to simply remove the bang pattern from the 'fooBar' record field.""
So the question is: '''should GHC auto-unpack a strict argument of a data constructor, if the argument type is a very wide product type?'''. I think ""no"". The unpacking can save allocation (by allocating one object instead of two) but it can also increase it (at a pattern matching site). So it should probably only happen automatically for sufficiently narrow types.
How narrow? We need some testing, but my guess is three or four words. Maybe a flag to set the size? (Maybe not worth the pain.)
Incidentally, the choice can already be manually controlled with `{-# UNPACK #-}` and `{-# NOUNPACK #-}` pragmas." simonpj
4451 16 jwlato@… Re-linking avoidance is too aggressive Compiler 7.1 7.12.1 new normal 2014-12-23T13:34:10Z "I'm constantly annoyed by having to `rm` the binary when I want to relink with different options (`-rtsopts`, `-threaded`, etc.). We only check the date of the binary against the date of the object files and relink if it is out of date, we should really check whether the options have changed or not too.
Similar problems exist in ordinary `.hs` recompilation (see #437), but the solutions will be different, so it makes sense to have a separate ticket.
One solution is to store information about what settings were in effect when linking in the binary, perhaps in a special section that isn't loaded during execution. We already compile a C file during linking to support `-rtsopts`, so we could add some magic asm to it, and then use `objdump` during linking to extract the information from the existing binary if there is one.
" simonmar
7245 16 jwlato@… INLINEing top-level patterns causes ghc to emit 'arity missing' traces Compiler 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "When an INLINE pragma is specified on a pattern, ghc-7.6.1 shows some internal trace messages.
{{{
module Foo where
{-# INLINE widths #-}
widths :: [Int]
widthMonth, widthYear :: Int
widths@[widthMonth, widthYear] = [1,2]
}}}
{{{
~/Downloads$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.1
~/Downloads$ ghc Foo.hs -O
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
makeCorePair: arity missing widths{v aeJ} [lid]
}}}
I'm not certain that specifying an INLINE pragma in this context even makes sense, in which case perhaps a more useful warning could be produced." jwlato
3960 20 jwlato@…, rl ghc panic when attempting to compile DPH code Data Parallel Haskell 6.12.1 7.12.1 rl new lowest 2014-12-23T13:33:22Z "the function ""tmpfn"" in the attached code causes ghc to panic (the 'impossible' happened). This bug is present in ghc 6.12.1 and 6.13.20100226
{{{
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.1 for i386-apple-darwin):
VectMonad.lookupFamInst: not found:
dph-seq:Data.Array.Parallel.Lifted.PArray.PData{tc rq5}
(dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
ghc-prim:GHC.Types.Double{(w) tc 3u},
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
ghc-prim:GHC.Types.Double{(w) tc 3u},
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
(dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Double{(w) tc 3u})),
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
ghc-prim:GHC.Types.Double{(w) tc 3u},
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
(dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Double{(w) tc 3u})),
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
ghc-prim:GHC.Types.Double{(w) tc 3u})
}}}" jwlato
7606 97 jwlato@…, wren@…, hackage.haskell.org@…, ikke+ghc@… Stride scheduling for Haskell threads with priorities Runtime System 7.7 7.12.1 ezyang new normal 2014-12-23T13:34:10Z "Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue. This patch set replaces this scheduler with 'stride scheduling', as described by Waldspurger and Weihl '95, which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round-robin scheduler completely with this scheduler.
Here are nofib benchmarks comparing the old scheduler to the new:
{{{
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
Min -0.0% -52.2% -18.8% -18.6% -83.1%
Max +1.0% +4.2% +4.9% +5.1% +7.7%
Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9%
}}}
Here are some technical details:
* Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.)
* The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed.
* We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down.
* `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some.
* Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad.
* We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support.
* Sleeping and blocked tasks do not get any 'bonus' for being blocked.
* In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly. Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too.
I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft:
{{{
type Tickets = Int
-- | Maximum number of tickets we support a thread having. (Currently 2 >> 20)
-- Note that this doesn't bound the *global* maximum tickets.
maxTickets :: Tickets
-- | Changes the number of tickets allocated to a thread. The ticket count must
-- not be less than or equal to zero, or greater than maxTickets. (Corresponds
-- to setTickets# primop)
setTickets :: ThreadId -> Tickets -> IO ()
-- | Returns the number of tickets currently allocated to a thread. (Corresponds to
-- getTickets# primop)
getTickets :: ThreadId -> IO Tickets
-- | Atomically performs a linear transformation on the number of tickets a thread;
-- e.g. scaling the number of tickets by a rational number, adding another fixed
-- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g.
-- if the net amount of tickets is reduced, then the returned result is positive;
-- if the net amount of tickets is increased, the returned result is negative.
-- In the absence of concurrent threads, the following property holds forall
-- t, m and x:
--
-- do r Ratio Int -> Tickets -> IO Tickets
-- | Forks a new thread, transferring some percentage of tickets from the current
-- thread to it (so the net number of tickets stays constant.) Fails if the rational
-- is greater than 1 or less than or equal to zero, or if there are not enough tickets
-- in the current thread.
forkIOWith :: IO a -> Ratio Int -> IO ThreadId
}}}" ezyang
8957 25 kacktusdev@…, hvr ghci's :l -> internal error: evacuate: strange closure type 8306 GHCi 7.6.3 new normal 2014-04-04T22:26:50Z "GHCi crashes when :loading a file. Unfortunately I can't reproduce the bug, so this one's gonna be lots of information that probably will help very little.
This is the actual error message:
{{{
*CommonStatistics Data.List> :l SimpleCellularALife
[1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted )
: internal error: evacuate: strange closure type 8306
(GHC version 7.6.3 for i386_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
}}}
This one was the error I was working on, i.e. the (legit) error in the previous call: (Including this because it gives you a clue what I was working on, I was mostly fiddling around with parens in placeAgents' gnd function)
{{{
*CommonStatistics Data.List> :l SimpleCellularALife
[1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted )
[2 of 2] Compiling SimpleCellularALife ( SimpleCellularALife.hs, interpreted )
SimpleCellularALife.hs:70:28:
Couldn't match expected type `Array i0 e0'
with actual type `Ground'
In the return type of a call of `ground'
In the first argument of `(!)', namely `ground (tiles w)'
In the expression: (ground (tiles w) ! (fst $ head grp))
SimpleCellularALife.hs:70:36:
Couldn't match expected type `Tile'
with actual type `Array Coordinates Tile'
In the return type of a call of `tiles'
In the first argument of `ground', namely `(tiles w)'
In the first argument of `(!)', namely `ground (tiles w)'
Failed, modules loaded: CommonStatistics.
}}}
Included Source Files - CommonStatistics.hs:
{{{
module CommonStatistics where
type Memory = [Int]--Internal state of an Agent.
data StatUpdate = StatUpdate{
newVictories :: [Int] -- by agentID
} deriving (Show)
data Agent = Agent{
agentID :: Int,
sourcePath :: FilePath, --path to .hs source file. relative to executable
doFunc :: [String] -> Memory -> (Memory, [String]),
evFunc :: [String] -> Memory -> (Memory, String),
personalMemory :: Memory
}
instance Show Agent where
show (Agent {
agentID = aID,
sourcePath = path,
doFunc = forgetit,
evFunc = forgetittoo,
personalMemory = mem
}) = show (aID, path, mem)
}}}
And SimpleCellularALife.hs: (I am not exactly confident that this is the version that caused the error. I sadly can't reproduce it, so there's no confirming that.
{{{
module SimpleCellularALife where
import Data.Array
import Data.List
import System.Random
import CommonStatistics
data Ground = Ground {
food :: Int
}
data Entity = Entity{
ai :: Agent,
health :: Int
}
data Tile = Tile{
ground :: Ground,
entities :: [Entity]
}
data World = World {
tiles :: Array Coordinates Tile
}
type Coordinates = (Int, Int)
getRandomPosition :: RandomGen t => World -> t -> (t, Coordinates)
getRandomPosition w rand =
let
((minx, miny), (maxx, maxy)) = bounds $ tiles w
(x, rand2) = randomR (minx, maxx) rand
(y, rand3) = randomR (miny, maxy) rand2
in
(rand3, (x, y))
placeAgents :: RandomGen t => World -> [Agent] -> t -> (t, World)
placeAgents w agents rand =
let
createTileUpdates (ag:ags) wrld rnd =
let
(rnd2, coords) = getRandomPosition wrld rnd
(rnd3, restUpd) = createTileUpdates ags wrld rnd2
in (rnd3, (coords, ag) : restUpd)
createTileUpdates [] wrld rnd = (rnd, [])
(rand2, assocList) = createTileUpdates agents w rand
groupedAssocList = groupBy (\(c1, a1) (c2, a2) -> c1 == c2) $ sortBy (\(c1, a1) (c2, a2) -> compare c1 c2) assocList
gnd grp = ground ((tiles w) ! (fst $ head grp))
condenseGroup grp = (fst $ head grp, Tile{ground = gnd grp, entities = snd $ unzip grp})
--map condenseGroup groupedAssocList --::(Coordinates, Tile)
in
(rand, w)
--placeAgents (placeAgent w firstAg x y) agents rand3
}}}
Someone suggested that this might've been GHCI running out of memory. I am as of writing this at 66% out of 4GB used. The GHCI instance was opened for an extended period of time, so it might have racked up quite a bit of RAM usage. I can say though that considering the file sizes, 1.3GB of RAM usage seems unreasonable.
And because I haven't yet written enough, here are all the variations of the line I was working on that could've caused it. Pulled them out of my text editor's buffer.
{{{
gnd grp = (ground (tiles w) ! fst $ head grp)
gnd grp = (ground (tiles w) ! (fst $ head grp)
gnd grp = (ground (tiles w) ! (fst $ head grp))
gnd grp = (ground ((tiles w) ! (fst $ head grp))
gnd grp = ground ((tiles w) ! (fst $ head grp))
}}}" guest
7610 23 karel.gardas@… Cross compilation support for LLVM backend Compiler (LLVM) 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "Top level bug to track supporting cross compilation in LLVM backend.
Mostly this shouldn't be too bad but I haven't tried it and know of at least a few significant issues." dterei
4016 14 kazu@… Strange display behaviour in GHCi Compiler 6.12.2 7.12.1 new low 2014-12-23T13:33:45Z "Kazu encountered another GHCi oddity. Try "":browse Prelude"" in GHCi. With 6.12 we get
{{{
data Integer
= integer-gmp:GHC.Integer.Type.S# GHC.Prim.Int#
| integer-gmp:GHC.Integer.Type.J# GHC.Prim.Int# GHC.Prim.ByteArray#
}}}
Why do we get the `integer-gmp:` prefix? There is no ambiguity here. (GHC 6.10 didn't do this, but that's because `Integer` was in the `base` package, whereas now `Integer` is in `integer-gmp`.)
" simonpj
7374 92 kazu@…, carter.schonwald@…, duncan@…, pho@… rule not firing Compiler 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "In the code below, the rule appears not to fire.
Based on the bytestring rules, reported as broken here:
http://www.haskell.org/pipermail/glasgow-haskell-users/2012-August/022775.html
{{{
ghc -O --make h.hs -ddump-simpl -fforce-recomp -Wall
}}}
{{{
module Q (f) where
{-# NOINLINE f #-}
f :: Bool -> String
f c = g ((==) c)
{-# NOINLINE g #-}
g :: (Bool -> Bool) -> String
g _ = ""g""
h :: Bool -> String
h _ = ""h""
{-# RULES ""MyRule"" forall x . g ((==) x) = h x #-}
}}}
{{{
==================== Tidy Core ====================
Result size of Tidy Core = {terms: 25, types: 21, coercions: 0}
lvl_rkK :: GHC.Types.Char
[GblId, Caf=NoCafRefs, Str=DmdType m]
lvl_rkK = GHC.Types.C# 'h'
lvl1_rkL :: [GHC.Types.Char]
[GblId, Caf=NoCafRefs, Str=DmdType]
lvl1_rkL =
GHC.Types.:
@ GHC.Types.Char lvl_rkK (GHC.Types.[] @ GHC.Types.Char)
h_reA :: GHC.Types.Bool -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
h_reA = \ _ -> lvl1_rkL
lvl2_rkM :: GHC.Types.Char
[GblId, Caf=NoCafRefs, Str=DmdType m]
lvl2_rkM = GHC.Types.C# 'g'
lvl3_rkN :: [GHC.Types.Char]
[GblId, Caf=NoCafRefs, Str=DmdType]
lvl3_rkN =
GHC.Types.:
@ GHC.Types.Char lvl2_rkM (GHC.Types.[] @ GHC.Types.Char)
g_rez :: (GHC.Types.Bool -> GHC.Types.Bool) -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
g_rez = \ _ -> lvl3_rkN
Q.f [InlPrag=NOINLINE] :: GHC.Types.Bool -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
Q.f =
\ (c_aeC :: GHC.Types.Bool) ->
g_rez (GHC.Classes.$fEqBool_$c== c_aeC)
}}}
" igloo
4372 85 kfisher@…, gershomb@…, michael@…, pho@… Accept expressions in left-hand side of quasiquotations Template Haskell 6.12.3 7.12.1 new normal 2015-04-19T21:35:06Z "Gershom Bazerman (gershomb@gmail.com) writes: Attached is an experimental patch (not read for prime-time) that extends quasiquotation syntax. At the moment, quasiquoters can only be single identifiers of type `QuasiQuoter` (and of course declared outside the current module). This patch allows an entire expression of type `QuasiQuoter` in the quoter position. The staging restriction is extended to all free variables in the quasiquoter expression.
So if `qq1 :: Int -> QuasiQuoter`, one can now write `[$qq1 12 | ... |]`
This syntax would be quite useful for my own project (jmacro), and from discussions at ICFP, to others who also are beginning to take serious advantage of quasiquotation.
Here's one use case. Suppose jmt is a `QuasiQuoter` which returns both a parsed Javascript expression and its ""module signature"" (or ""typing environment"" if you prefer). Then, one can pass that typing environment directly into another quasiquoter in a different module, so that further code can be typechecked at compile-time with functions defined in the first quasiquote available to the Javascript typechecker. This style of programming is currently possible, but it requires defining additional new modules which contain `QuasiQuoters` parameterized with each successive typing environment.
There are a number of tricky choices made in this patch, not all of which are perhaps correct.
First, currently, the quoter and quotation are lexed and parsed as a single token. To avoid reinvoking the lexer and/or parser, now '[$' is lexed as one token, and a flag is set in the lexer state which lexes the `|...|]` (i.e. the quotation) as a single quotation on encountering the first vbar. This means that guards can't be used inside a quasiquoter expression -- i.e. `[$let x | True = 1 in qq1 x|..|]` would fail to parse. This also means that while now in ghc 7, one can write `[qq|..]`, to parse a full expression rather than identifier, we need the dollar sign as well.
The former problem (stealing guards within quasiquoter expressions) can be fixed by a syntax change which moves from a single vbar to a new symbol (perhaps `$|` or `||` ?) to signal the transition between the quoter expression and the quote itself. I tend to feel that the loss of guards within quasiquoter expressions is not too painful, however. Adding a new symbol between quoter and quotee also would simplify the necessary changes to the lexer, removing the need to set a special flag in the lexer state.
The second problem (need to reintroduce a dollar) is somewhat irritating, but not terribly so. One could either introduce the dollar in all cases, which allows simplifying the lexer and parser, or keep the dollarless syntax as well for single identifiers, which adds both complexity and duplicate syntax, but keeps the default case especially lightweight.
The patch as it stands introduces ""extended quasiquotations"" as an orthogonal change that doesn't affect the existing quasiquotation machinery, and, at the moment, only allows for quasiquotations of expressions (i.e., not patterns, etc.).
If there is sentiment that this is useful and could be accepted, modulo whatever requested tweaks, I'd be happy to do whatever work is necessary -- implementing changes, adding documentation, pushing the changes through to quasiquoters in other positions, etc.
" simonpj
9989 16 kgadek@… GHCI is slow for precompiled code GHC API 7.8.3 new normal 2015-01-19T17:22:42Z "Hello! We found that loading compiled and optimised `accelerate` code into ghci works much much slower than code run directly.
(I'm marking it as a ghc-api bug, because I noticed this behavior while using it)
Here is the example:
{{{#!hs
module Main where
import Data.Array.Accelerate as A
import Data.Array.Accelerate.CUDA as C
import Data.Time.Clock (diffUTCTime, getCurrentTime)
main :: IO ()
main = do
start :l Main
Ok, modules loaded: Main.
Prelude Main> main
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package unix-2.7.0.1 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package process-1.2.0.0 ... linking ... done.
Loading package stm-2.4.4 ... linking ... done.
Loading package SafeSemaphore-0.10.1 ... linking ... done.
Loading package mtl-2.1.3.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package fclabels-2.0.2.2 ... linking ... done.
Loading package text-1.1.1.3 ... linking ... done.
Loading package hashable-1.2.3.1 ... linking ... done.
Loading package primitive-0.5.4.0 ... linking ... done.
Loading package vector-0.10.12.2 ... linking ... done.
Loading package hashtables-1.2.0.1 ... linking ... done.
Loading package unordered-containers-0.2.5.1 ... linking ... done.
Loading package accelerate-0.15.0.0 ... linking ... done.
Loading package byteable-0.1.1 ... linking ... done.
Loading package cryptohash-0.11.6 ... linking ... done.
Loading package cuda-0.6.5.1 ... linking ... done.
Loading package exception-transformers-0.3.0.4 ... linking ... done.
Loading package exception-mtl-0.3.0.5 ... linking ... done.
Loading package old-time-1.1.0.2 ... linking ... done.
Loading package polyparse-1.11 ... linking ... done.
Loading package cpphs-1.18.6 ... linking ... done.
Loading package haskell-src-exts-1.16.0.1 ... linking ... done.
Loading package syb-0.4.4 ... linking ... done.
Loading package th-lift-0.7 ... linking ... done.
Loading package safe-0.3.8 ... linking ... done.
Loading package th-expand-syns-0.3.0.4 ... linking ... done.
Loading package th-reify-many-0.1.2 ... linking ... done.
Loading package th-orphans-0.8.3 ... linking ... done.
Loading package haskell-src-meta-0.6.0.8 ... linking ... done.
Loading package srcloc-0.4.1 ... linking ... done.
Loading package mainland-pretty-0.2.7 ... linking ... done.
Loading package symbol-0.2.4 ... linking ... done.
Loading package language-c-quote-0.8.0 ... linking ... done.
Loading package accelerate-cuda-0.15.0.0 ... linking ... done.
Array (Z) [1000001.0]
0.256128s
}}}
It takes `0.26 s` to finish. On other computer, using `criterion`, we observed even a `50x` difference.
Why is it working so slow, isn't ghci just to load function and simply call it?
Here is how execution time changes for different matrix sizes. For comparison we have also measured time of interpreted code (without precompiling).
{{{
size | compiled | precompiled | interpreted
---------+-----------+--------------+------------
100 | 0.054076s | 0.082686s | 0.151857s
1000 | 0.054509s | 0.08305s | 0.135452s
10000 | 0.055405s | 0.08469s | 0.12632s
100000 | 0.057768s | 0.093011s | 0.155359s
1000000 | 0.089811s | 0.251359s | 0.202022s
10000000 | 0.397642s | 1.400603s | 0.898547s
}}}
We believe that problem lies on the side of `ghci` rather than `accelerate`, how could we confirm this?
Moreover and even more important is there any workaround for it, if we need this precompiled code running fast in production environment?
Any guidance will be appreciated." remdezx
8151 7 kgardas ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails Compiler 7.4.2 new normal 2015-07-31T14:07:18Z "when i'm compiling this test.hs with ghc -thread ./test.hs
and then execute it i get
Starting Subprocess
Exit code: ExitFailure 127
This error code indicates that command isn't found (i have ghc in /usr/local/bin)
and it's specified in PATH variable, however it acts as if it's not even there
however if i remove -threaded flag and recompile code again, it works
Starting Subprocess
ghc: no input files
Usage: For basic information, try the `--help' option.
Exit code: ExitFailure 1
" troydm
10172 7 kgardas Cross-platform sed Build System 7.11 new normal 2015-03-19T22:11:03Z "It's quite easy to accidentally use GNU extensions in sed expressions, which means Solaris builds start failing. See https://phabricator.haskell.org/D740 for an example.
What should we do? Here are a few possibilities:
* Force use of POSIX sed with `--posix` flag. I haven't tested, but maybe this won't work if Solaris sed chokes on the `--posix`. Alternately, use `$(SED)` and add `--posix` only if it's supported
* Detect GNU sed in autoconfigure and use `$(SED)` in all Makefile scripts
* Stop using sed in the scripts for something else
I don't know if this admonition applies to other random POSIX tools we use." ezyang
8910 7 kgardas cross compiling for x86_64 solaris2 Compiler 7.8.1-rc2 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "using a ""gcc -m64"" and a working ghc-7.8.0.20140228-i386-unknown-solaris2 I was able to create a 64Bit ghc-stage2 compiler that can compile a simple hello world program but may create binaries from larger sources that seg-fault. In particular ""ghc-stage2 --interactive"" seg-faults:
{{{
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[New LWP 2 ]
[New LWP 3 ]
[New LWP 4 ]
GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-simple ... linking ... done.
Loading package base ... linking ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00000000041ea4c0 in ?? ()
(gdb) bt
#0 0x00000000041ea4c0 in ?? ()
#1 0x000000000369cf92 in resolveObjs ()
#2 0x000000000206de99 in cplU_info ()
#3 0x000000000000000c in ?? ()
#4 0x0000000003d0fe09 in base_GHCziEventziManager_zdLr88clvl8_closure ()
#5 0x0000000000000000 in ?? ()
}}}
The content of my mk/build.mk is just
{{{
INTEGER_LIBRARY = integer-simple
}}}
Creating a binary-dist also worked, but unpacking and ""gmake install"" failed at first because old-time, haskell98 and haskell2010 libraries were missing due to ""!CrossCompiling"" in ghc.mk and the second time with:
{{{
Reading package info from ""rts/dist/package.conf.install"" ... done.
""utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist"" register libraries/ghc-prim dist-install ""/local/home/maeder/haskell/ghc-7.8-x64-static/lib/ghc-7.8.0.20140228/bin/ghc"" ""/local/home/maeder/haskell/ghc-7.8-x64-static/lib/ghc-7.8.0.20140228/bin/ghc-pkg"" ""/local/home/maeder/haskell/ghc-7.8-x64-static/lib/ghc-7.8.0.20140228"" '' '/local/home/maeder/haskell/ghc-7.8-x64-static' '/local/home/maeder/haskell/ghc-7.8-x64-static/lib/ghc-7.8.0.20140228' '/local/home/maeder/haskell/ghc-7.8-x64-static/share/doc/ghc/html/libraries' NO
ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi
magic number mismatch: old/corrupt interface file? (wanted 129742, got
33214052)
gmake[1]: *** [install_packages] Fehler 1
}}}
What am I doing wrong for cross compiling? There is also #8378 using a different build host. #8713 also seem to use x86_64 solaris2 libs.
" maeder
8362 61 kjetil@…, core-libraries-committee@… Filesystem related tests failed on solaris (SmartOS) Core Libraries 7.6.3 7.12.1 new normal 2015-02-22T13:09:39Z "Getting filesystem (files/permissions) related test faiures on SmartOS (32bit).
{{{
$ uname -a
SunOS pkgx86 5.11 joyent_20130919T215407Z i86pc i386 i86pc Solaris
}}}
Unexpected failures: `TEST=""openFile003 getPermissions001 processGroup002 user001 posix005""`
The testsuite output is attached." leroux
9349 16 klao@… excessive inlining due to state hack Compiler 7.8.3 new normal 2015-06-02T17:37:32Z 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.) rwbarton
8924 16 koen@… "Text.ParserCombinators.ReadP needs some kind of ""commit"" or ""cut"" to force a single parse.." Compiler 7.6.3 new normal 2014-03-24T09:57:29Z "The ReadP monad maintains all possible parses of its input, rather than being left-biased as most parsers are. However this is not always quite the Right Thing. I maintain the Data.Decimal library. The Read instance for Data.Decimal up to 0.3.1 had the following behaviour:
{{{
reads ""34.567e8 foo"" :: [(Decimal, String)] = [(34.0,"".567e8 foo""),(34.567,""e8 foo""),(3.4567e9,"" foo"")]
}}
Clearly only the last parse in the list is the Right Thing, and any parser which returns ""34.0"" when given ""34.567"" is doing it wrong.
The problem came from the implementation of ""optional"". In numbers only the integer part is mandatory, with the fractional and exponent parts being optional. So I wrote my parser with the fractional part parsed like this:
{{{
fractPart read ""((((((((((C))))))))))"" :: Exp
}}}
Even this simple expression may take several seconds to parse. It gets worse if you keep adding parenthesis. And even worse if you add more infix constructors...." jcpetruzza@…
2641 58 koen@…, lennart@…, ekmett@… Revise the rules for -XExtendedDefaultRules Compiler 6.8.3 7.12.1 new lowest 2014-12-23T13:33:22Z "The `-XExtendedDefaultRules` flag is very liberal about type-class defaults. Perhaps too liberal:
{{{
> *Main> quickCheck (\xs -> reverse xs == xs)
> +++ OK, passed 100 tests.
}}}
Not good (reverse on lists is not the identity function). I expect a type error! Reason: reverse on list of () is indeed the identity function!
[http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules The rules] are currently these:
* All of the classes Ci are single-parameter type classes.
* At least one of the classes Ci is numeric, or is Show, Eq, or Ord.
Maybe we should tighten up the second rule to say:
* '''All''' of the classes Ci is numeric, or is Show, Eq, or Ord.
Then the Quickcheck example would not bogusly succeed in typechecking, because there's an `Arbitrary` constraint involved.
This ticket is to record the idea and canvas opinion. Record thoughts below.
See also
* #2853
* #2854" simonpj
10487 30 kosmikus, omeragacan@… DeriveGeneric breaks when the same data name is used in different modules Compiler 7.10.1 7.12.1 osa1 new highest 2015-07-18T09:14:36Z "That's the error you like too see, or rather not. ;(
{{{
[180 of 289] Compiling Agda.TypeChecking.Serialise ( src/full/Agda/TypeChecking/Serialise.hs, dist-2.4.2.4/build/Agda/TypeChecking/Serialise.o )
src/full/Agda/TypeChecking/Serialise.hs:1:1:
Duplicate instance declarations:
instance GHC.Generics.Datatype Agda.TypeChecking.Serialise.D1Name
-- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1
instance GHC.Generics.Datatype Agda.TypeChecking.Serialise.D1Name
-- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1
src/full/Agda/TypeChecking/Serialise.hs:1:1:
Duplicate instance declarations:
instance GHC.Generics.Constructor
Agda.TypeChecking.Serialise.C1_0Name
-- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1
instance GHC.Generics.Constructor
Agda.TypeChecking.Serialise.C1_0Name
-- Defined at src/full/Agda/TypeChecking/Serialise.hs:1:1
}}}
Problems:
* no position in file
* system generated names D1Name, C1_0Name
* obvious bogus (same instance cannot be defined twice at same location)
* leads me to suspect bug in Generics rather than in my code
Reproduce:
* git clone agda/agda from github,
* checkout this commit
https://github.com/agda/agda/commit/46823536559276807639488eae151a0e855fdb95
* and try to compile with
{{{
make install-bin
}}}" andreas.abel
345 39 kyrab@… GADT - fundep interaction Compiler (Type checker) 6.4 ⊥ simonpj new low 2009-11-19T12:53:27Z "{{{
GADTs and fundeps don't seem to interact in the way
that I (perhaps naively) expect. I expected that for
each case, the type variables would be instantiated
according to the type of the constructors, and then the
fundep would be used to figure out the result type.
{-# OPTIONS_GHC -fglasgow-exts #-}
data Succ n
data Zero
class Plus x y z | x y -> z
instance Plus Zero x x
instance Plus x y z => Plus (Succ x) y (Succ z)
infixr 5 :::
data List :: * -> * -> * where
Nil :: List a Zero
(:::) :: a -> List a n -> List a (Succ n)
append :: Plus x y z => List a x -> List a y -> List a z
append Nil ys = ys
append (x ::: xs) ys = x ::: append xs ys
{-
GHC 6.4 says:
Couldn't match the rigid variable `y' against `Succ z'
`y' is bound by the type signature for `append'
Expected type: List a y
Inferred type: List a (Succ z)
In the expression: x ::: (append xs ys)
In the definition of `append': append (x ::: xs) ys
= x ::: (append xs ys)
-}
}}}" bring
7048 35 la@…, iavor.diatchki@… Add the ability to statically define a `FunPtr` to a haskell function Compiler 7.4.2 7.12.1 new normal 2014-12-23T13:34:10Z "Lauri Alanko [http://haskell.1045720.n5.nabble.com/Static-non-exported-stubs-td5713489.html suggests] that there should be a way to define a callback to a haskell function statically (i.e. without using a dynamic wrapper).
It is currently possible to do so only by exporting the function and reimporting it as a function pointer:
{{{
foreign export ccall ""my_callback"" myCallback :: IO ()
foreign import ccall ""&my_callback"" myCallbackPtr :: FunPtr (IO ())
}}}
but of course this not ideal because it creates an extra symbol (and is quirky).
A possible new syntax could be:
{{{
foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback
}}}
or variations thereof. We probably want to keep `import` (rather than `export` or some new keyword), since this declaration brings something into scope, like a normal FFI import." pcapriotti
5910 16 leather@… Holes with other constraints Compiler (Type checker) 7.5 7.12.1 new normal 2015-01-19T14:54:16Z "Hello. As can be seen on http://hackage.haskell.org/trac/ghc/wiki/Holes and http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021670.html, we've been working on adding holes to GHC. I'm opening this ticket about a specific problem I've been having, and I hope someone has a suggestion of how to do it correctly.
As holes work quite similarly to implicit parameters (see the wiki-page for a comparison), we started out in the same way as implicit parameters. Typechecking of a hole generates a constraint (a new type of constraint), and the constraint solver will try to find the right type for each hole. The difference is that hole constraints never show up in a type, but their type is printed separately. This currently works correctly for simple typechecking, but it has some problems when other constraints are generated too. A simple example:
{{{
test :: String
test = show _h
}}}
Here, the {{{_h}}} denotes a hole named ""h"". If this function is defined like this inside a module it will currently fail:
{{{
test2.hs:2:8:
No instance for (Show a0)
arising from a use of `show'
The type variable `a0' is ambiguous
Possible fix: add a type signature that fixes these type variable(s)
In the expression: show (_h)
In an equation for `test': test = show (_h)
Failed, modules loaded: none.
}}}
The problem is that the {{{Show}}} constraint is still there. If the type signature is omitted and the monomorphism restriction off, we can see that the types found are:
{{{
Found the following holes:
_h :: GHC.Show.Show a => a
...
test :: Show a => String
}}}
The problem is the {{{Show a}}} that is irrelevant to the actual type of {{{test}}}, but nevertheless it's there.
How do other approaches handle this?
'''undefined''':
{{{
test :: String
test = show undefined
}}}
Gives the same ambiguity error, even if the signature is omitted.
'''Implicit parameters''':
{{{
test = show ?h
}}}
This works, but generates the following type signature:
{{{
test :: (Show a, ?h::a) => String
}}}
So, as I'd want to use it, this is wrong. It has the right ingredients, but I'd want:
{{{
test :: (?h :: (Show a) => a) => String
}}}
For implicit parameters the difference doesn't matter too much, as implicit parameters are still parameters: they still show up in the type signature. A hole is not required to be a parameter, so it's more important that every constraint only shows up where it's necessary.
So the problem is that I don't know how to select from the constraints only those that are applicable to the expression/function itself, and those that apply to which of the holes. I've tried typechecking all of the holes first, but I don't know how to determine how to change the constraint set after that. If you need more information about how it currently works, or have any feedback on this approach, please let me know. I'm still quite unfamiliar with the architecture of GHC. :)
----
I'm attaching a patch against the master branch on git with my current work in case someone is interested in trying it. Note that the code generation is pretty much a stub and it will panic if you try to run a function with a hole. It will print the holes of an expression if you invoke {{{:t}}} (it doesn't currently print the holes when loading a module, but it should still print them with {{{:t}}} on a function from the module). Also, I do not recommend building stage 1 with this, as some packages have some issues. Easiest is to build stage 1 and the packages without these changes and then applying the patch and then building only stage 2." xnyhps
7492 16 leather@… Generic1 deriving: Can we replace Rec1 f with f :.: Par1? Compiler 7.7 7.12.1 dreixel new normal 2014-12-23T13:34:10Z "It seems like `Rec1 f` is isomorphic to `f :.: Par1`. Is it possible and beneficial to replace the former with the latter and deprecate/remove `Rec1`?
1. Currently, a parameter type is found in `Par1` or `Rec1`. By removing `Rec1`, there would be only one place for parameters. This simplifies generic functions.
2. It is in the interest of reducing redundancy in the representation, something that appears to be consistent with the design of the representation types (e.g. using the same type for multiple meanings)." spl
9198 4 lelf large performance regression in type checker speed in 7.8 Compiler (Type checker) 7.8.2 7.12.1 new high 2015-07-22T12:35:19Z "it was recently demonstrated on the haskell-cafe mailing list that the following code takes measurably longer to type check in GHC 7.8.2 than in GHC 7.6.
http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html
the program example is as follows
{{{
begin :: Monad m => (m () -> t) -> t
begin cont = cont (return ())
a :: IO a -> (IO () -> t) -> t
a m cont = cont (m >> putStrLn ""a"")
end :: t -> t
end m = m
main = begin a a a a a a a a a a a a a a a a a a end
}}}
takes about a second to type check in ghc 7.8, and is ""instant"" in 7.6 ()
each additional a doubles the time to type check the program
{{{
main = begin a a a a a a a a a a a a a a a a a a a a a a a a end
}}}
takes longer than I have the patience to wait :) (so more than 5 seconds)
the author of the email notes that a related program
{{{
main = id id id id id id id id id id id
id id id id id id id id id id id (return ())
}}}
has the exponential complexity in both 7.8.2 and 7.6.2
This It could very well be that some of the type checker changes between 7.8 and 7.6 enlarged the space of programs that trip up exponential worst case behavior, but one way or another understanding *why* this happened" carter
10478 4 lelf Shorter import syntax Compiler 7.10.1 new normal 2015-06-04T20:10:08Z "It would be helpful to support a short syntax for importing unqualified identifiers while establishing a short qualified name. An example of the proposed syntax is,
{{{#!hs
import Data.Map (Map) as M
}}}
The desired semantics are that `Map` be imported unqualified, and `M` be defined as an alias for `Data.Map`. This replaces the existing convention of writing,
{{{#!hs
import Data.Map (Map)
import qualified Data.Map as M
}}}
The proposed syntax is currently an error, I think, so adding support for it should not break anything." acowley
10652 13 lelf, bgamari Better cache performance in Array# Compiler 7.10.1 new normal 2015-07-29T17:45:13Z "A common use case for arrays is to loop over them, performing an operation on each element of the array. For `ByteArray#`s, this is guaranteed to have good cache performance: When element `i` is accessed, the CPU's prefetcher will ensure that the element `i+1` is already sitting in cache, so the next loop will not suffer a cache miss. Currently, the `Array#` and `SmallArray#` types do not significantly benefit from the prefetcher. This feature request asks for a few new primops that would improve the situation.
My understanding is that the ""raw"" element in an `Array#` is actually a pointer to the region in memory associated with the ""logical"" element of the array. When looping, the subsequent pointers are guaranteed to get prefetched, but the subsequent logical element is not guaranteed to be prefetched. In particular, if we'll only get the benefits of prefetching on the logical elements if we're lucky enough that the memory manager happened to allocate these logical elements on the heap next to each other. I don't know enough about GHC internals to check the source code, but my experiments demonstrate that this is not currently happening in my use case, resulting in rather significant performance degradations. (The experiments are rather complicated, so I'm not attaching them.)
I propose adding the primops:
{{{
packArray# :: Array# a -> b -> b
packSmallArray# :: SmallArray# a -> b -> b
packMutableArray# :: MutableArray# s a -> State# s -> State# s
packSmallMutableArray# :: SmallMutableArray# s a -> State# s -> State# s
}}}
These operations would have the semantic effect of noops, with the exception that they request that the logical elements in the arrays be arranged adjacently in memory. Thus, future loops over the arrays would benefit from CPU prefetching. There are a number of ways the memory manager could handle these requests, and I don't particular care which is chosen. For example, the memory manager could rearrange the memory immediately or wait until the next garbage collection pass and do it then." MikeIzbicki
7662 74 lelf, jwlato@…, ikke+ghc@…, simonmar, idhameed@… Improve GC of mutable objects Runtime System 7.7 ⊥ new normal 2015-06-27T03:03:56Z "Haskell is a purely functional language at its core, but it can be also used for workloads involving mutation; it is for these workloads that our GC can be pretty poorly tuned (historically, we’ve fixed these issues case-by-case when they were causing problems for users, e.g. #650). Fortunately, the question of generational garbage collection in the face of lots of mutability is a well-studied one (c.f. the JVM) so this bug asks whether or not we can systematically appropriate any of the machinery developed here for GHC. Some ideas include:
* Utilizing card marking at the page level for write barriers, instead of our current mutable lists,
* Separating mutable and immutable (and lazy) data on the heaps, to make the previous scheme more likely to work well,
* Organizing our generations in different pages, so that checking the generation of any object is as simple as a pointer comparison,
* Figure out if we can do better than permanently keeping all mutable arrays permanently on the mutable list (which is really killer when you have lots of tiny mutable arrays),
* More mutable closure types to remove the indirection that would normally result from an IORef (actually, you can UNPACK these, and I’m not 100% what happens in that case; it depends on how MutVar#s are represented)
There’s probably more things but this is just a start to get things rolling. Test cases and benchmarks also appreciated!" ezyang
4012 242 lelf, mail@…, the.dead.shall.rise@…, id@…, shacka@…, mail@…, pumpkingod@…, fuuzetsu@…, tkn.akio@…, juhpetersen, cheecheeo@…, bill@… Compilation results are not deterministic Compiler 6.12.2 7.12.1 niteria patch high 2015-07-23T12:58:21Z "There are some issues with non-determinism in the output of GHC, which means that compilations are not repeatable. This affects some users (e.g. Debian packagers) who need to be able to get repeatable hashes for the packages of a GHC build.
The cases we know about that lead to non-deterministic results are:
* The `spec_ids` (specialised Ids) attached to an Id have a non-deterministic ordering
* CSE can give different results depending on the order in which the bindings are considered, and since the ordering is non-deterministic, the result of CSE is also non-deterministic. e.g. in `x = z; y = z; z = 3`, where `y` and `x` are exported, we can end up with either `x = y; y = 3` or `y = x; x = 3`.
* There seems to be something unpredictable about the order of arguments to SpecConstr-generated specialisations, see [http://www.haskell.org/pipermail/glasgow-haskell-users/2011-April/020287.html]
* The wrappers generated by the `CApiFFI` extension have non-deterministic names. (see comment:15 below).
* See comment:76 for another, different, example
'''Old ticket description follows'''
Short story: if you use ghc-6.12.1.20100318 (or similar, probably
ghc-6.12.1 release will produce the same results) to bootstrap
ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12,
those two instances of ghc-6.12 will have different ABI hashes and
interfaces in the ghc package. If you use ghc-6.10 for the
bootstrapping, you'll even get differences in the ghc, base and
Cabal packages.
Long story: see logfiles and descriptions at http://darcs.volkswurst.de/boot-tests/ (note that the logfiles are quite large, I really don't want to attach 150 MB of logs to this ticket)." kili
1974 36 lennart.augustsson@… "length ""foo"" doesn't work with -XOverloadedStrings" Compiler 6.8.1 ⊥ new normal 2012-09-07T01:49:42Z "The extensions to the defaulting rule for -XOverloadedStrings aren't sufficient to make {{{length ""foo""}}} typecheck without an annotation. The reason is that we end up with a constraint {{{IsString [a]}}}, and we would somehow have to decide to instantiate a to Char to get the hoped-for behaviour.
It would be nice if this could be made to work (perhaps just with -XExtendedDefaultRules), if a solution can be found without too much hacking." ganesh
1420 64 lennart.augustsson@…, claudiusmaximus@… Automatic heap profile intervals Profiling 6.7 7.12.1 new lowest 2014-12-23T13:33:22Z "When doing heap profiling it is sometimes hard to know what a good sampling interval is. Make it too small and it takes forever, make it too coarse and the resolution is bad.
In hbc the default setting was to automatically adjust the interval. It starts out very small, but as samples accumulate it gets larger and larger. This is a nice compromise." guest
1614 22 lennart@… Type checker does not use functional dependency to avoid ambiguity Compiler (Type checker) 6.7 ⊥ new normal 2013-01-27T14:46:24Z "Compiling the following module gives an error
{{{
module X where
class C a | -> a
instance C Int
unC :: (C a) => a -> Int
unC i = undefined
test :: Int
test = unC undefined
}}}
Error message:
{{{
X.hs:13:7:
Ambiguous type variable `a' in the constraint:
`C a' arising from a use of `unC' at X.hs:13:7-19
Probable fix: add a type signature that fixes these type variable(s)
}}}
But that is just plain wrong. The functional dependency in the definition of C forces a to be Int. No other type is possible. So what's ambiguous about that?" guest
3138 22 lennart@… Returning a known constructor: GHC generates terrible code for cmonad Compiler 6.10.1 7.12.1 new lowest 2014-12-23T13:33:22Z "Lennart reports that GHC generates very poor code for his cmonad package.
If you want to look at a simple example, look at the Inf.hs example
included in package `cmonad-0.1.1`.
It's very simple, and ghc generates fantastically bad code for it.
It would be great if you could nail down why it's so amazingly unoptimal.
Even with everything inlined and no overloading left, ghc seems to
ignore the INLINE directives and use dictionaries left and right.
When I looked at it a year ago or so, it was a return of one
constructor in a sum. That is, a function always returns the same constructor, so the case
analysis of the return value is not needed; it should be returned as
an unboxed tuple instead
Another unrelated problem, I think, is that ghc needs to promote
in-memory variables to registers when possible.
Perhaps the new code generator has such a transformation?
" simonpj
2356 81 lennart@…, chak@…, mjm2002@…, leather@… GHC accepts multiple instances for the same type in different modules Compiler 6.8.3 ⊥ new low 2014-07-11T17:11:19Z "as mentioned by Simon PJ in this thread:
http://www.haskell.org/pipermail/haskell/2008-June/020436.html
here is the example, spelled out:
{{{
module B0 where
class C a where c :: a -> String
data T = T deriving Show
module B1 where
import B0
instance C T where c _ = ""B1""
b = c T
module B2 where
import B0
instance C T where c _ = ""B2""
b = c T
module Main where
import B1
import B2
main = print (B1.b,B2.b)
}}}
this is accepted without flags or errors and prints `(""B1"",""B2"")`.
the [http://haskell.org/onlinereport/decls.html#sect4.3.2 language report, section 4.3.2] clearly states:
A type may not be declared as an instance of a particular class more than once in the program.
" claus
3052 43 lennart@…, illissius@… ghc FFI doesn't support thiscall Compiler (FFI) 6.10.1 7.12.1 new low 2014-12-23T13:33:45Z "The ghc FFI does not support the ""thiscall"" calling convention.
This is the calling convention used by Microsoft C++ for calling methods.
It's like the stdcall calling convention, except that the ""this"" pointer is passed in ECX.
Without this calling convention it's impossible to interact with (Msft) C++ objects.
" augustss
5063 87 leon.p.smith@…, v.dijk.bas@…, bos, core-libraries-committee@… unix package has untracked dependency on libbsd Core Libraries 7.0.3 7.12.1 trommler new low 2015-03-01T06:07:35Z "See ticket #4974 about unix-compat failing to build.
That is just a symptom. The real problem is that the unix package installs a HsUnix.h file which is broken on some target platforms, standard linux platforms.
HsUnix.h contains:
{{{
#ifdef HAVE_LIBUTIL_H
#include
#endif
}}}
If the system that the package is built on has libbsd installed then it'll use it. But if the target system does not have this C lib then the HsUnix.h header is broken on such systems.
Why does the unix package optionally depend on libbsd? Is it really needed?
If it is needed then the distro packages need to be modified so that the unix package has dependency on libbsd-dev.
This raises another issue: we should be able to check that all the headers we install on a target actually work on that target. This check should be run as part of the ghc and HP release testing process." duncan
3452 22 leroux@…, hvr Show type of most recent expression in GHCi GHCi 6.10.4 7.12.1 new lowest 2014-12-23T13:33:22Z Currently, any expression resulting in a value with no `Show` instance results in an error message. This is confusing for new users (especially if they don't yet understand typeclasses) and overly verbose for experienced users. Instead, the REPL should simply display the type of the expression, as if the user had used `:t`. ozy
1012 62 leuschner@…, ozgurakgun@…, m@… ghc panic with mutually recursive modules and template haskell Template Haskell 6.8.2 7.12.1 new lowest 2014-12-23T13:33:22Z "When compiling the files below using ghc --make Main.hs I get the following error:
{{{
[1 of 5] Compiling ModuleA[boot] ( ModuleA.hs-boot, nothing )
[2 of 5] Compiling ModuleC ( ModuleC.hs, ModuleC.o )
[3 of 5] Compiling ModuleB ( ModuleB.hs, ModuleB.o )
Loading package base ... linking ... done.
Loading package template-haskell ... linking ... done.
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for powerpc-apple-darwin):
Maybe.fromJust: Nothing
}}}
ModuleA.hs:
{{{
module ModuleA where
import ModuleB
}}}
ModuleA.hs-boot:
{{{
module ModuleA where
}}}
ModuleB.hs:
{{{
{-# OPTIONS -fth #-}
module ModuleB where
import ModuleC
$(nothing)
}}}
ModuleC.hs:
{{{
module ModuleC where
import Language.Haskell.TH
import {-# SOURCE #-} ModuleA
nothing = return [] :: Q [Dec]
}}}
Main.hs:
{{{
module Main.hs
import ModuleA
main = return ()
}}}" guest
4942 44 lightwing15@…, fryguybob@… GHC.ConsoleHandler does not call back application when Close button is pressed GHC API 6.12.3 7.12.1 new low 2014-12-23T13:33:45Z "The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.
{{{
import Control.Concurrent (threadDelay)
import GHC.ConsoleHandler
import System.IO
onConsoleEventReceived :: ConsoleEvent -> IO ()
onConsoleEventReceived event = withFile ""console_event.log"" AppendMode $ \ file -> do
hPutStrLn file $ case event of
ControlC -> ""Received Ctrl-C event""
Break -> ""Received Ctrl-Break event""
Close -> ""Received X button event""
_ -> ""Received other console event""
hFlush file
main :: IO ()
main = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)
}}}
The host OS is Windows XP SP3.
Please let me know if you need any more info." Amatic
9878 40 m@…, alexander.vershilov@… Static pointers in GHCi cause panic Compiler 7.9 7.10.1 new normal 2015-06-11T17:29:48Z "I load this module into ghci
{{{#!hs
{-# LANGUAGE StaticPointers #-}
module Static where
import GHC.StaticPtr
f = deRefStaticPtr (static True)
}}}
and get a panic upon evaluating `f`
{{{
> f
ghc: panic! (the 'impossible' happened)
(GHC version 7.9.20141210 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc30486_0/ghc30486_5.so: undefined symbol: Static_sptEntryZC0_closure
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
Am I doing static pointers right?" monoidal
9903 45 m@…, alexander.vershilov@…, hvr GHCi produces a cryptic message when using HPC GHCi 7.9 new normal 2014-12-22T05:17:45Z "The following test produces an impolite response from GHCi
{{{
$ cat t.hs
g :: Int
g = 1 + 1
$ ghc-stage2 --interactive t.hs -fhpc
GHCi, version 7.9.20141217: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( t.hs, interpreted )
Ok, modules loaded: Main.
*Main> g
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.9.20141217 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc25774_0/ghc25774_5.so: undefined symbol: _hpc_tickboxes_Main_hpc
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
Discovered while investigating #9878." facundo.dominguez
7919 56 mail@…, simonmar, george.colpitts@… Heap corruption (segfault) from large 'let' expression Runtime System 7.6.3 7.12.1 new high 2015-07-31T18:18:04Z "The attached test program reliably triggers an assertion in the storage manager with the `-debug` rts.
{{{
LargeUse: internal error: ASSERTION FAILED: file rts/sm/GCUtils.c, line 208
(GHC version 7.6.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
This behaviour is reproducible with many recent ghc versions (tried 7.6.3, 7.4.2, 6.12.3) and all fail at the same assertion when using the `-debug` rts. (Without `-debug` we get a more random variety of segfaults and GC errors.)
It looks like a pretty clear case of heap corruption. I'll explain why...
The test program uses TH to generate a program that looks like this:
{{{
data Large = Large Int Int ... -- 512 non-strict Int fields
test =
let step (Large i1 i2 ... i512) =
let j1 = i1 + i4
j2 = i2 + i7
...
j511 = i511 + i510
j512 = i512 + i1
in Large j1 j2 ... j512
in runSteps step 100000 (Large 1 1 ... 1)
-- basically an unfoldr:
runSteps :: (state -> (state, Int)) -> Int -> state -> [Int]
runSteps f n i | n <= 0 = []
| otherwise = case f i of
(i', r) -> r : runSteps f (n - 1) i'
}}}
We use TH to generate this program, and we use a ""size"" parameter that determines size of the data constructor (and corresponding letrec). This makes it easy to find the size threshold where it fails.
For small sizes this program works fine, and for larger values it triggers the assert. With ghc 7.6.3 on a x86-64 machine, the magic threshold is 511: that is, the program works fine with size 510 and hits the assertion at size 511. This is suspiciously close to 512. And of course on a 64bit machine 512 * 8 is 4k, which is the storage manager's block size. And the failing assertion is in a bit of the storage manager that is dealing with blocks...
{{{
// If this block does not have enough space to allocate the
// current object, but it also doesn't have any work to push, then
// push it on to the scanned list. It cannot be empty, because
// then there would be enough room to copy the current object.
if (bd->u.scan == bd->free)
{
ASSERT(bd->free != bd->start);
push_scanned_block(bd, ws);
}
}}}
So it looks very much like we have a situation where something is writing over the end of a block and messing up the SM's data structures.
But, it is not nearly as simple as the data constructor being too big. We can demonstrate other programs that use much larger data constructors without any problem at all. Our suspicion falls on the big letrec.
Indeed with this program if we change the data constructor to have strict fields then it no longer fails, and we can run it with much larger data constructor sizes. What would be different between strict and non-strict fields here? Well, one observation is that when it is strict then ghc can (and does) turn the code into a big cascade of case expressions, while when it is non-strict then the STG code is all 'let's.
{{{
case tpl_s6jQ of tpl_s6Ak {
__DEFAULT ->
case tpl_s6jS of tpl_s6Al {
__DEFAULT ->
case tpl_s6jU of tpl_s6Am {
-- etc for all 500+ elements
}}}
versus
{{{
let {
sat_s5UK :: GHC.Types.Int
[LclId] =
\u [] GHC.Num.$fNumInt_$c+ i511_s5Ly i1_s5E9; } in
let {
sat_s62X :: GHC.Types.Int
[LclId] =
\u [] GHC.Num.$fNumInt_$c+ i510_s5R2 i509_s5UG; } in
let {
sat_s62W :: GHC.Types.Int
[LclId] =
\u [] GHC.Num.$fNumInt_$c+ i509_s5UG i506_s5UC; } in
-- etc for all 500+ elements
}}}
Note also, that it is nothing to do with the obvious space leak here. If we modify the code to generate an NFData instance and to use deepseq at each iteration then we eliminate the space leak, but we keep the big stg 'let', and it still fails." duncan
9020 24 mail@… Massive blowup of code size on trivial program Compiler 7.8.2 7.12.1 nomeata new normal 2015-07-31T15:05:50Z "The test `simplCore/should_compile/simpl015` was leading to massive compile times. This is weird: it looks like:
{{{
main = do { return ()
; return ()
... hundreds more times ...
; return () }
}}}
It turns out that the cause was over-eager eta-expansion. Each `return ()` gives a top-level PAP thus
{{{
lvl17 :: IO ()
lvl17 = returnIO ()
}}}
But these definitions are then eta-expanded, thus:
{{{
lvl17 = ((\eta. returnIO () |> sym g) eta) |> g
where g :: State# RealWorld -> (# State# RealWorld, () #)
~
IO ()
}}}
Now in general it makes sense to eta-expand through newtypes (as is done here), because it exposes more lambadas. But it really doesn't make sense to eta-expand a PAP like this.
Fortunately the fix is easy: use `exprArity` rather than `manifestArity` in `SimplUtils.tryEtaExpandRhs`.
The effect on `simpl015` is dramatic: compiler allocation drops from 6.6G to 812M; and residency drops from 1.8G to 45M." simonpj
3769 24 mail@… Add manpages for programs installed alongside ghc Documentation 6.12.1 ⊥ new normal 2012-10-02T22:56:01Z "The following programs installed with GHC (specifically, using the Mac OS X installer, though I suspect this applies to all platforms) do not have manpages:
* `ghc-pkg`
* `ghci` (Technically, its manpage is the same as `ghc`'s, but there's no `ghci.1` symlink to `ghc.1`, so `man ghci` fails to find anything.)
* `haddock`
* `hp2ps`
* `hpc`
* `hsc2hs`
* `runghc`
* `runhaskell`
I think that's all of them.
I realize that not all of these programs (e.g., `haddock`) are truly part of GHC, but the ones that are still need manpages. If the problem is that writing *roff is hard, and you don't mind mooching off other languages, might I refer you to [http://perldoc.perl.org/perlpod.html POD]/[http://perldoc.perl.org/pod2man.html pod2man]?" Minimiscience
9118 24 mail@… Can't eta-reduce representational coercions Compiler 7.8.2 new low 2015-05-19T10:24:54Z "When I say
{{{
import Data.Type.Coercion
import Data.Coerce
import Data.Proxy
eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g
eta2 _ = Coercion
}}}
I get
{{{
Could not coerce from ‘f’ to ‘g’
because ‘f’ and ‘g’ are different types.
arising from a use of ‘Coercion’
from the context (Coercible (f a) (g a))
bound by the type signature for
eta2 :: Coercible (f a) (g a) => Proxy a -> Coercion f g
at /Users/rae/temp/Roles.hs:5:9-56
In the expression: Coercion
In an equation for ‘eta2’: eta2 _ = Coercion
}}}
Unlike the case for #9117, this one is ''not'' expressible in Core. (At least, I don't see a way to do it.) So, to do this, we would have to update Core and then update the constraint solver. I ''do'' think this would be type safe. But, I also think it's reasonable to wait for someone with a real use case to shout before doing this. The only use case I have is to be able to do this:
{{{
-- says that a's parameter is representational
class Rep (a :: k1 -> k2) where
co :: Coercible x y => Coercible (a x) (a x)
instance Rep f => Rep (Compose f) where ...
}}}
" goldfire
1885 24 mail@… Improve CPR analysis Compiler 6.8.1 7.12.1 new lowest 2014-12-23T13:33:22Z "When a function returns a ''nested'' data structure, GHC should expose that fact to the caller. This can make a very big difference in inner loops. A good example is the following message (from GHC users http://www.haskell.org/pipermail/glasgow-haskell-users/2007-November/013454.html).
Compile the attached files thus:
{{{
ghc --make Unpacked.hs -O2 -cpp -DPOLY_SAME
}}}
and similarly with `DPOLY_OTHER`. The `POLY_OTHER` case does a lot more allocation because a key function isn't inlined.
{{{
$wa_r1Wb :: GHC.Prim.Addr#
-> GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
OtherP.C
GHC.Float.Double (OtherP.C GHC.Float.Double
(OtherP.C GHC.Float.Double ())) #)
[GlobalId]
[Arity 2
NoCafRefs
Str: DmdType LL]
$wa_r1Wb =
\ (ww_s1S5 :: GHC.Prim.Addr#) (w_s1S7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->
case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld ww_s1S5 0 w_s1S7
of wild2_a1xI { (# s2_a1xK, x_a1xL #) ->
let {
ipv_XGd [Just L] :: GHC.Prim.Addr#
[Str: DmdType]
ipv_XGd = GHC.Prim.plusAddr# ww_s1S5 8 } in
case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld ipv_XGd 0 s2_a1xK
of wild21_X1yK { (# s21_X1yN, x1_X1yP #) ->
case GHC.Prim.readDoubleOffAddr#
@ GHC.Prim.RealWorld (GHC.Prim.plusAddr# ipv_XGd 8) 0 s21_X1yN
of wild22_X1yU { (# s22_X1yX, x2_X1yZ #) ->
(# s22_X1yX,
OtherP.C
@ GHC.Float.Double
@ (OtherP.C GHC.Float.Double (OtherP.C GHC.Float.Double ()))
(GHC.Float.D# x_a1xL)
(OtherP.C
@ GHC.Float.Double
@ (OtherP.C GHC.Float.Double ())
(GHC.Float.D# x1_X1yP)
(OtherP.C @ GHC.Float.Double @ ()
(GHC.Float.D# x2_X1yZ) GHC.Base.())) #)
} } }
}}}
" simonpj
7206 77 mail@…, carter.schonwald@…, snoyberg, edsko, ekmett Implement cheap build Compiler 7.4.2 ⊥ simonpj new normal 2015-02-22T12:27:36Z "We sometimes see stuff like this:
{{{
f n ps = let ys = [1..x]
in map (\zs. ys ++ zs) ps
}}}
You might think the `(++)` would fuse with the `[1..x]`, via foldr/build fusion, but it doesn't. Why not? Because it would be WRONG to do so in this case:
{{{
f ns ps = let ys = map expensive ns
in map (\zs. ys ++ zs) ps
}}}
If we fused the `(++)` with the `map` we might call `expensive` once for each element of `ps`.
This is fairly easy to fix. The point is that `[1..x]` is cheap; we'd prefer to fuse it even if doing so involves computing 1, 1+1, 2+1, etc multiple times. Suppose we express this fact thusly:
{{{
enumFromTo lo hi = cheapBuild (\cn. ....lo...hi...)
map f xs = build (\cn. ...f...xs...)
}}}
Now we want the `foldr/cheapBuild` rule to fire even if that would involve duplicating the call to `cheapBuild`. And we already have a way to do that: we make `cheapBuild` into a `CONLIKE` function.
Happily it's almost all simply a change to the libraries, not the compiler itself.
I just need to execute on this, but I keep failing to get round to it. Below is the beginning. One missing piece is that I need to replace the hack for `build` in the occurrence analyser, so that it works for `cheapBuild` too. (At least until we have Ilya's cardinality analyser.)
Simon
{{{
diff --git a/GHC/Base.lhs b/GHC/Base.lhs
index 6a36eb5..b78edf5 100644
--- a/GHC/Base.lhs
+++ b/GHC/Base.lhs
@@ -304,6 +304,12 @@ build :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]
build g = g (:) []
+cheapBuild :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]
+{-# INLINE CONLIKE [1] cheapBuild #-}
+-- cheapBuild is just like build, except that it is CONLIKE
+-- See Note [cheapBuild]
+cheapBuild g = g (:) []
+
-- | A list producer that can be fused with 'foldr'.
-- This function is merely
--
@@ -320,6 +326,8 @@ augment g xs = g (:) xs
{-# RULES
""fold/build"" forall k z (g::forall b. (a->b->b) -> b -> b) .
foldr k z (build g) = g k z
+""fold/cheapBuild"" forall k z (g::forall b. (a->b->b) -> b -> b) .
+ foldr k z (cheapBuild g) = g k z
""foldr/augment"" forall k z xs (g::forall b. (a->b->b) -> b -> b) .
foldr k z (augment g xs) = g k (foldr k z xs)
@@ -343,6 +351,12 @@ augment g xs = g (:) xs
""augment/build"" forall (g::forall b. (a->b->b) -> b -> b)
(h::forall b. (a->b->b) -> b -> b) .
augment g (build h) = build (\c n -> g c (h c n))
+
+""augment/cheapBuild"" forall (g::forall b. (a->b->b) -> b -> b)
+ (h::forall b. (a->b->b) -> b -> b) .
+ augment g (cheapBuild h) = build (\c n -> g c (h c n))
+ -- 'augment' doesn't necessarily have a cheap argument, so we revert to 'build'
+
""augment/nil"" forall (g::forall b. (a->b->b) -> b -> b) .
augment g [] = build g
#-}
@@ -351,6 +365,20 @@ augment g xs = g (:) xs
-- augment g (augment h t) = augment (\cn -> g c (h c n)) t
\end{code}
+Note [cheapBuild]
+~~~~~~~~~~~~~~~~~
+cheapBuild is just like build, except that it is CONLIKE
+
+It is used in situations where fusion is more imortant than sharing,
+ie in situation where its argument function 'g' in (cheapBuild g) is
+cheap.
+
+Main example: enumerations of one kind or another:
+ f x = let xs = [x..]
+ go = \y. ....go y'....(map (h y) xs)...
+ in ...
+Here we woud like to fuse the map with the [x..]
+
----------------------------------------------
-- map
@@ -831,7 +859,7 @@ a `iShiftRL#` b | b >=# WORD_SIZE_IN_BITS# = 0#
-- Rules for C strings (the functions themselves are now in GHC.CString)
{-# RULES
-""unpack"" [~1] forall a . unpackCString# a = build (unpackFoldrCString# a)
+""unpack"" [~1] forall a . unpackCString# a = cheapBuild (unpackFoldrCString# a)
""unpack-list"" [1] forall a . unpackFoldrCString# a (:) [] = unpackCString# a
""unpack-append"" forall a n . unpackFoldrCString# a (:) n = unpackAppendCString# a n
diff --git a/GHC/Enum.lhs b/GHC/Enum.lhs
index cea3ced..561a995 100644
--- a/GHC/Enum.lhs
+++ b/GHC/Enum.lhs
@@ -376,9 +376,9 @@ instance Enum Char where
enumFromThenTo (C# x1) (C# x2) (C# y) = efdtChar (ord# x1) (ord# x2) (ord# y)
{-# RULES
-""eftChar"" [~1] forall x y. eftChar x y = build (\c n -> eftCharFB c n x y)
-""efdChar"" [~1] forall x1 x2. efdChar x1 x2 = build (\ c n -> efdCharFB c n x1 x2)
-""efdtChar"" [~1] forall x1 x2 l. efdtChar x1 x2 l = build (\ c n -> efdtCharFB c n x1 x2 l)
+""eftChar"" [~1] forall x y. eftChar x y = cheapBuild (\c n -> eftCharFB c n x y)
+""efdChar"" [~1] forall x1 x2. efdChar x1 x2 = cheapBuild (\ c n -> efdCharFB c n x1 x2)
+""efdtChar"" [~1] forall x1 x2 l. efdtChar x1 x2 l = cheapBuild (\ c n -> efdtCharFB c n x1 x2 l)
""eftCharList"" [1] eftCharFB (:) [] = eftChar
""efdCharList"" [1] efdCharFB (:) [] = efdChar
""efdtCharList"" [1] efdtCharFB (:) [] = efdtChar
@@ -510,7 +510,7 @@ instance Enum Int where
-- In particular, we have rules for deforestation
{-# RULES
-""eftInt"" [~1] forall x y. eftInt x y = build (\ c n -> eftIntFB c n x y)
+""eftInt"" [~1] forall x y. eftInt x y = cheapBuild (\ c n -> eftIntFB c n x y)
""eftIntList"" [1] eftIntFB (:) [] = eftInt
#-}
@@ -539,7 +539,7 @@ eftIntFB c n x0 y | x0 ># y = n
{-# RULES
""efdtInt"" [~1] forall x1 x2 y.
- efdtInt x1 x2 y = build (\ c n -> efdtIntFB c n x1 x2 y)
+ efdtInt x1 x2 y = cheapBuild (\ c n -> efdtIntFB c n x1 x2 y)
""efdtIntUpList"" [1] efdtIntFB (:) [] = efdtInt
#-}
@@ -646,8 +646,8 @@ instance Enum Integer where
enumFromThenTo x y lim = enumDeltaToInteger x (y-x) lim
{-# RULES
-""enumDeltaInteger"" [~1] forall x y. enumDeltaInteger x y = build (\c _ -> enumDeltaIntegerFB c x y)
-""efdtInteger"" [~1] forall x y l.enumDeltaToInteger x y l = build (\c n -> enumDeltaToIntegerFB c n x y l)
+""enumDeltaInteger"" [~1] forall x y. enumDeltaInteger x y = cheapBuild (\c _ -> enumDeltaIntegerFB c x y)
+""efdtInteger"" [~1] forall x y l.enumDeltaToInteger x y l = cheapBuild (\c n -> enumDeltaToIntegerFB c n x y l)
""enumDeltaInteger"" [1] enumDeltaIntegerFB (:) = enumDeltaInteger
""enumDeltaToInteger"" [1] enumDeltaToIntegerFB (:) [] = enumDeltaToInteger
#-}
}}}" simonpj
5757 51 mail@…, dterei, eir@… zero unexpected failures on all tier 1 platforms Test Suite 7.2.1 7.12.1 new normal 2014-12-23T13:34:10Z "We're often sloppy about this, so I'm making a ticket to ensure we can tag a testsuite that has zero unexpected failures on all tier 1 platforms at release time.
That may mean filing more tickets and marking some tests as expected failures.
I'll take {x86_64,x86}/Linux.
" simonmar
8827 104 mail@…, dterei, mazieres-i58umkudjfnfpfdx6jbbn3ymzi@… Inferring Safe mode with GeneralizedNewtypeDeriving is wrong Compiler 7.9 7.12.1 new normal 2015-04-09T07:59:39Z "Consider the following modules:
{{{
module A (List, ints) where
data List a = Nil | Cons a (List a)
infixr 4 `Cons`
ints :: List Int
ints = 1 `Cons` 2 `Cons` 3 `Cons` Nil
}}}
{{{
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module B where
import A
newtype Age = MkAge Int
deriving C
class C a where
cList :: List a
instance C Int where
cList = ints
}}}
{{{
{-# LANGUAGE Safe #-}
module C (ages) where
import A
import B
ages :: List Age
ages = cList
}}}
Module C compiles without a hiccup. But, it shouldn't: the coercion between `ages` and `ints` (performed by !GeneralizedNewtypeDeriving in module B) isn't Safe, as it breaks through `List`'s abstraction. (Note that the constructors of `List` are ''not'' exported from module A!)
If module B includes `{-# LANGUAGE Safe #-}`, it duly doesn't compile, because of the stringent ""constructors-must-be-in-scope"" check done by the `Coercible` mechanism. The problem is that safety can be ''inferred'' without this check taking place.
You may also want to read the commentary on #8745 for related discussion." goldfire
8211 11 mail@… ghc -c recompiles TH every time while --make doesn't Compiler 7.6.3 new normal 2013-09-02T01:32:14Z "https://github.com/nh2/ghc-bug-recompiles-th-on-c
{{{
ghc -c Test.hs # compiles
ghc -c Test.hs # compiles (and loads TH) again
}}}
I would expect ghc to print
{{{
compilation IS NOT requried
}}}
since ghc --make does not recompile either, and the created .hi and .o files are identical." nh2
8662 11 mail@… GHC does not inline cheap inner loop when used in two places Compiler 7.6.3 new normal 2014-01-13T09:45:08Z "When I made a Criterion benchmark of Neil Michell's ""Tight Inner Loop"" blog post (http://neilmitchell.blogspot.co.uk/2014/01/optimising-haskell-for-tight-inner-loop.html), I noticed that GHC 7.6.3 will not inline the performance-critical function when it's called from two different places (inside the same module).
{{{
break0_2pleaseinline :: (Char -> Bool) -> ByteString0 -> (ByteString, ByteString0)
break0_2pleaseinline f (BS0 bs) = (BS.unsafeTake i bs, BS0 $ BS.unsafeDrop i bs)
where
i = Internal.inlinePerformIO $ BS.unsafeUseAsCString bs $ \ptr -> do
let start = castPtr ptr :: Ptr Word8
let end = go start
return $! Ptr end `minusPtr` start
go s@(Ptr a) | c == '\0' || f c = a
| otherwise = go $ inc s
where c = chr s
versionInl1 :: ByteString0 -> (ByteString, ByteString0)
versionInl1 str = break0_2pleaseinline test str
where
test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$')
versionInl2 :: ByteString0 -> (ByteString, ByteString0)
versionInl2 str = break0_2pleaseinline test str
where
test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$')
}}}
Full code here: https://github.com/nh2/inner-loop-benchmarks/blob/6715d1e9946d6b5e6d9bb53203982ed3d2ed32ff/Bench.hs#L166.
{{{break0_2pleaseinline}}} does not get inlined, which makes {{{versionInl1}}} and {{{versionInl2}}} over 4 times slower than when inlined. The inlining doens't happen, not even with {{{-O2}}} and {{{-O3}}}, only an {{{INLINE}}} pragma will move GHC to do it.
If I was a compiler, I would so inline that function!
I am surprised that GHC doesn't decide to do so." nh2
8930 11 mail@… GHC API: List of available Pragmas GHC API 7.6.3 new normal 2014-03-27T11:28:50Z "From https://github.com/kazu-yamamoto/ghc-mod/issues/103#issuecomment-14827257:
It would be useful if the GHC API allowed us to query a list of supported pragmas." nh2
8159 11 mail@… Uses of Binary decode should have a proper error message Compiler 7.6.3 new low 2013-08-23T12:56:20Z "In #8144 I changed the interface file format.
That can happen without you noticing because it just uses the Binary instance.
To deserialize it, we also use Binary. When that fails, the error message is
{{{
Binary.get(Usage): 50
}}}
The error message should at least also mention:
{{{
Reading the interface file failed
}}}
This is not a specific problem with interface files (it is actually a minor problem there since ghc will refrain from reading .hi files created by an older version), but it is in development, and independent from that, all uses of Binary decode should be guarded as it is a very partial function." nh2
3588 11 mail@… ghc -M should emit dependencies on CPP headers Compiler 6.10.4 7.12.1 new low 2014-12-23T13:33:45Z "When using CPP, ghc -M should emit dependencies on header files that are `#included` into Haskell source code. It could do this by running `gcc -M`, perhaps.
" simonmar
8213 49 mail@…, core-libraries-committee@… Bad error message when using lazy IO to read from closed handle Core Libraries 7.6.3 infoneeded normal 2014-11-20T16:45:28Z "Today I accidentally wrote this code:
{{{
import System.IO
import Data.ByteString.Lazy as BSL
filesEqual :: FilePath -> FilePath -> IO Bool
filesEqual f1 f2 = do
equal
withBinaryFile f2 ReadMode $ \h2 -> do
c1 >= print
}}}
The problem is that I should have done the forcing before the files are closed:
{{{
return $! (c1 == c2)
}}}
I got the incredibly unhelpful error message
{{{
test: test.hs: illegal operation
}}}
It took me 2 hours and strace to find out what was going on, especially because around every file open() there are multiple things that map top IllegalOperation (e.g. the ENOTTY from the ioctl that checks whether the device is a TTY).
Can we give a better error message here, at least mentioning that the problem has to do with closed (and GC'd) handles?" nh2
8684 62 mail@…, hvr, ekmett, core-libraries-committee@… hWaitForInput cannot be interrupted by async exceptions on unix Core Libraries 7.6.3 snoyberg patch normal 2015-02-17T14:18:32Z "http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html
claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact that's false (e.g. mentioned in https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4).
{{{
-- import Control.Concurrent
import System.IO
import System.Timeout
main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000)
}}}
will not be killed after 1 second, but instead wait for the full 5 seconds timeout passed to {{{hWaitForInput}}}.
The implementation is {{{ready}}} at http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO-FD.html, where we have two foreign calls: {{{safe fdReady}}} and {{{unsafe unsafe_fdReady}}}.
The actual C implementation is at https://github.com/haskell-suite/base/blob/master/cbits/inputReady.c#L16. It uses {{{select}}} on Unix, and does check for {{{EINTR}}}, so I believe that according to http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi-interruptible both foreign calls can be replaced by a single {{{interruptible}}} one.
Is that true?
If not, it's a documentation bug in {{{timeout}}} at least.
Also, does {{{interruptible}}}, apart from allowing the function to be interrupted, behave more like {{{safe}}} or {{{unsafe}}}?" nh2
9526 35 mail@…, hvr, ekmett, heisenbug Add missing Generic instances in base Core Libraries 7.8.3 7.12.1 dreixel new normal 2014-12-23T13:34:10Z "Most primitive types (`Int`, `Char`, etc.) have a GHC.Generics.Generic instance, but some are missing, such as `Integer` and the various `Word*` data types.
We should consistently have instances for all primitive types offered by base, since they are required if you want to derive a Generic instance for any type that contains them.
I boldly set the milestone to 7.10 because I naively assume this should be straightforward." nh2
8173 30 mail@…, leroux@… GHC uses nub Compiler 7.6.3 leroux new low 2013-10-05T07:35:57Z "nub is O(n²).
I bet all usages have Ord instances.
https://github.com/nh2/haskell-ordnub" nh2
8947 37 mail@…, mail@… Depending on hint/ghc API fixes the binary version I can use GHC API 7.6.3 new normal 2014-11-07T12:25:06Z "When I `build-depend` on hint-0.4.0.0 with GHC 7.6.3, I get
{{{
% cabal configure
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: pointcloudviewer-0.1.0 (user goal)
trying: hint-0.4.0.0/installed-cf3... (dependency of pointcloudviewer-0.1.0)
trying: ghc-7.6.3/installed-494... (dependency of
hint-0.4.0.0/installed-cf3...)
trying: bin-package-db-0.0.0.0/installed-608... (dependency of
ghc-7.6.3/installed-494...)
trying: GLUtil-0.7.4/installed-223... (dependency of pointcloudviewer-0.1.0)
next goal: linear (dependency of GLUtil-0.7.4/installed-223...)
rejecting: linear-1.6/installed-300... (conflict: bin-package-db =>
binary==0.5.1.1/installed-72e..., linear => binary==0.7.1.0/installed-a33...)
}}}
This fails because `linear` uses a `binary > 0.5.1.1`, but through my use of `hint` which depends on `ghc` (`hint` does not directly depend on `binary`), I pull in a constraint `binary == 0.5.1.1`.
I believe this is bad, because depending on the GHC API in any way fixes the binary version I can use, which immediately makes a range of newer libraries unavailable to my program.
Probably GHC should somehow hide the fact that binary is used inside, and let the rest of my program use whatever binary it likes.
----
I am aware that this might not be immediately easy, since the GHC API might expose some `binary` types to my program that I could try use with my newer binary version, which of course would be illegal.
Maybe it is possible to implement such a check into actual typechecking, and let it pass if I don't actually use types from the old version with functions from the new library. I actually believe I have seen compiler errors in the past where two identical types where not unified because one was from a different version, so maybe infrastructure for this is already in place?" nh2
8763 34 mail@…, pivo@…, george forM_ [1..N] does not get fused (10 times slower than go function) Compiler 7.6.3 7.12.1 new normal 2015-06-02T11:12:42Z "Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away.
This can give serious performance problems when unnoticed.
{{{
-- Slow:
forM_ [0.._N-1] $ \i -> do ...
-- Around 10 times faster:
loop _N $ \i -> do ...
{-# INLINE loop #-}
loop :: (Monad m) => Int -> (Int -> m ()) -> m ()
loop bex f = go 0
where
go !n | n == bex = return ()
| otherwise = f n >> go (n+1)
}}}
Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented." nh2
9037 20 mail@…, schyler Add option to make selected warnings errors Compiler 7.8.2 new normal 2014-05-18T12:24:52Z "It would be great if GHC offered a `-ferror-*` flag for every `-fwarn-*` flag, that turns the given type of warning into an error.
For example, I would like to always error on uninitialized record fields, but don't want to go full `-Werror`." nh2
5288 22 malcolm.wallace@… Less noisy version of -fwarn-name-shadowing Compiler 7.0.3 7.12.1 new low 2014-12-23T13:33:45Z "I would like a flag that warns about name-shadowing in more restricted circumstances than the current flag. I.e. I would like examples like these not to produce a warning:
{{{
foo x = ..
where
bar x = ...
}}}
{{{
baz z = do
z Int -> Int
foo !f k =
if k == 0 then 0
else if even k then foo f (k-1)
else case f of
FooPair (FooPair (Foo n) _) _ -> n
data Foo0 a b c = Foo0 !(Foo1 a b) !c
data Foo1 a b = Foo1 !a !b
foo' :: Foo0 Int Int Int -> Int -> Int
foo' !f k =
if k == 0 then 0
else if even k then foo' f (k-1)
else case f of
Foo0 (Foo1 n _) _ -> n
}}}
The core generated by `ghc -ddump-simpl -O2 ww.hs` contains the following functions:
{{{
Foo.foo_$s$wfoo [Occ=LoopBreaker]
:: Foo Int
-> Foo Int
-> Foo.R:Foo(,) Int Int ~R# Foo (Int, Int)
-> Foo Int
-> GHC.Prim.Int#
-> Int
Foo.$wfoo [InlPrag=[0]]
:: Foo (Int, Int) -> Foo Int -> GHC.Prim.Int# -> Int
Foo.$wfoo' [InlPrag=[0], Occ=LoopBreaker]
:: GHC.Prim.Int# -> Int -> Int -> GHC.Prim.Int# -> Int
}}}
The first argument of `Foo.foo_$s$wfoo` could be `Int#`, but it takes a boxed value.
In practice this happens with unboxed vectors from the `vector` package." akio
10235 40 maoe@…, karolis.velicka@… Get profiling info without stopping program Compiler 7.10.1 new normal 2015-05-05T16:49:37Z "I frequently want to know profiling information for web servers in production. Unfortunately there doesn't seem to be a way to trigger this without stopping the program, which might annoy my users.
My ideal would be to able to call ""dumpProfile :: Filename -> IO()"" and then call that from a timer thread." mwotton
2340 19 marco-oweber@… Improve Template Haskell error recovery Template Haskell 6.8.2 7.12.1 new lowest 2014-12-23T13:33:22Z "Marc Weber wants better error recovery in TH's Q monad: http://www.haskell.org/pipermail/template-haskell/2008-May/000666.html
The Quasi monad is defined thus:
{{{
class (Monad m, Functor m) => Quasi m where
-- Fresh names
qNewName :: String -> m Name
-- Error reporting and recovery
qReport :: Bool -> String -> m () -- Report an error (True) or warning (False)
-- ...but carry on; use 'fail' to stop
qRecover :: m a -> m a -> m a -- Recover from the monadic 'fail'
-- The first arg is the error handler
-- Inspect the type-checker's environment
qReify :: Name -> m Info
qLocation :: m Loc
-- Input/output (dangerous)
qRunIO :: IO a -> m a
}}}
A sensible change (but it would be a change) would be to change `qRecover` thus:
{{{
qRecover :: m a -> ([(Bool,String)] -> m a) -> m a
-- (qRecover q f) runs the action `q`, collecting all the messages
-- emitted by `qReport`. If the action `q` calls the monad `fail`,
-- these messages are passed to `f`. If the action `q` does not call
-- `fail`, the messages are retained in the monad, just as if the
-- `qRecover` was not there.
}}}
Comments? This would be quite easy to implement in 6.10.
Simon" simonpj
595 173 marcot@…, ryani.spam@…, benjross@…, carter.schonwald@…, the.dead.shall.rise@…, jkarni@…, michael.b.bassett@… Overhaul GHC's overlapping/non-exhaustive pattern checking Compiler None ⊥ new normal 2014-03-30T12:55:39Z GHC has a module in the desugarer (Check) which checks whether patterns are overlapping and/or exhaustive, to support the flags -fwarn-overlapping-patterns and -fwarn-non-exhaustive-patterns. The code is old and crufty, and has several outstanding bugs. A rewrite is needed. simonmar
926 22 mark@… infinite loop in ShutdownIOManager() Runtime System 6.5 ⊥ new lowest 2009-07-07T08:23:26Z "Hi,
I have found a way to 'hang' a DLL created using ghc-6.5.20061006 under Win32. This occurs when I dynamically load DLL built using GHC, call one of its exported functions that uses file IO and then exit my program without explicitly releasing the DLL first. I have uploaded a test application to http://eeter.fi.tartu.ee/~mark/ghc_hang.zip that demonstrates this issue.
I am not sure if I can call this a bug, as when I unload the DLL, everything works fine. But this does not happen in GHC-6.4.2 or older versions.
Regards,
Mark" guest
1262 21 MartijnVanSteenbergen RecursiveDo in Template Haskell Template Haskell 6.6 ⊥ new normal 2014-11-13T14:21:45Z I really want mdo support in Template Haskell! Thanks! philip.weaver@…
7413 17 me@… runghc (runhaskell) should be able to reload code on editing Compiler 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "Hot code reloading on file edit is an incredibly useful feature for server development.
Right now several Haskell web frameworks are able to reload code on file edits, however there does not seem to be a simple way to use code reloader from one of them without finding yourself up to the neck in the framework.
It seems to me that the best thing what can be done is a flag to runghc / runhaskell:
{{{
runghc --reload MyServer.hs
}}}
It should watch for changes in the main file and all imported modules (or at least imported modules in the current folder).
A nice addition would be an ability to specify more files to watch
{{{
runghc --reload-watch *.some.weird.haskell.js --reload MyServer.hs
}}}
" va1en0k
5051 16 mechvel@… Typechecker behaviour change Compiler (Type checker) 7.0.2 ⊥ new normal 2014-11-28T17:26:15Z "From: http://www.haskell.org/pipermail/glasgow-haskell-users/2011-March/020116.html
The behaviour has changed (7.0.1 accepts it, 7.0.2 doesn't), but I'm not sure which behaviour is right.
I've put a cut-down (but not standalone) version of the offending module below. I believe the relevant steps are then:
{{{
The ct application means we need an instance for:
Cast (ResidueI (Pol (ResidueE (UPol k))))
(Pol (ResidueE (UPol k)))
Need: Cast (ResidueI (Pol (ResidueE (UPol k))))
(Pol (ResidueE (UPol k)))
Have: instance LinSolvRing a => Cast (ResidueI a) a
Now need: LinSolvRing (Pol (ResidueE (UPol k)))
Have: instance EuclideanRing a => LinSolvRing (Pol a)
Now need: EuclideanRing (ResidueE (UPol k))
Have: instance (EuclideanRing a, Ring (ResidueE a) )
=> EuclideanRing (ResidueE a)
Now need: EuclideanRing (UPol k)
Have: instance Field a => EuclideanRing (UPol a)
Now need: LinSolvRing (UPol k) (from the EuclideanRing class constraints)
Have: instance EuclideanRing a => LinSolvRing (UPol a) (Pol2_.hs:95)
And: instance (LinSolvRing (Pol a), CommutativeRing a)
=> LinSolvRing (UPol (Pol a))
A different instance should be used depending on whether or not
k = Pol x
(for some x).
}}}
With flags:
{{{
-XTypeSynonymInstances -XUndecidableInstances -XFlexibleContexts -XFlexibleInstances -XMultiParamTypeClasses -XOverlappingInstances -XRecordWildCards -XNamedFieldPuns -XScopedTypeVariables -fcontext-stack=30
}}}
{{{
module T_cubeext (cubicExt) where
import Prelude (undefined)
import DPrelude (ct)
import Categs (ResidueE)
import SetGroup ()
import RingModule (Field, FactorizationRing)
import VecMatr ()
import Fraction ()
import Pol (Pol, UPol)
import Residue (ResidueI)
import GBasis ()
cubicExt :: forall k . (Field k, FactorizationRing (UPol k))
=> k -> ()
cubicExt _ = undefined
where unE :: ResidueI (Pol (ResidueE (UPol k)))
unE = undefined
kToE :: Pol (ResidueE (UPol k)) -> ResidueI (Pol (ResidueE (UPol k)))
kToE = ct unE
}}}
" igloo
3055 17 merehap@… Int / Word / IntN / WordN are unequally optimized Compiler 6.11 7.12.1 new normal 2015-02-23T14:54:26Z "A lot of thought has been put into optimizing usage of `Int`, but not all of these tweaks have been copied for usage of `Word`, and the specific-size versions of both have even fewer optimizations. The consequence is that switching from signed to unsigned, or from unspecified to specified size, can result in dramatic performance loss.
- builtin rules (`prelude/PrelRules`) cover `Int` and `Word`, but not sized alternatives
- `SPECIALI[SZ]E` pragmas cover `Int`, but little of the others. Try
{{{
find libraries/ -name _darcs -prune -o -name *hs |
xargs grep SPECIAL | grep '\ a -> a
negate :: a -> a
}}}
apart from multiple inheritance, it could work like this:
{{{
import Prelude hiding ((+),negate)
import qualified Prelude ((+),negate)
class Group a where
(+) :: a -> a -> a
negate :: a -> a
instance Num a => Group a where
(+) = (Prelude.+)
negate = Prelude.negate
}}}
- coeus_at_gmx_de" nobody
8761 30 merijn@…, cactus Make pattern synonyms work with Template Haskell Template Haskell 7.12.1 new normal 2014-12-23T13:34:10Z "Template Haskell has no support for pattern synonyms. This should be added.
Specifically:
* Create syntax in `Language.Haskell.TH.Syntax` and corresponding functions in `Language.Haskell.TH.Lib`
* Support in !DsMeta for desugaring pattern synonym quotations. See `rep_bind`.
* Support in Convert for splicing in pattern synonyms.
* Support in !TcSplice for reifying pattern synonyms. See `reifyThing`." goldfire
9520 16 meteficha, edsko Running an action twice uses much more memory than running it once Compiler 7.8.3 new normal 2014-09-04T11:17:43Z "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
_ Int -> Sink a m Int
sink2 state = do
maybeToken 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." snoyberg
8623 32 michael@…, simonmar Strange slowness when using async library with FFI callbacks Runtime System 7.6.3 7.12.1 simonmar new normal 2014-12-23T13:34:10Z "I've attached a Haskell and a C file, when compiled as such:
{{{
ghc -DSPEED_BUG=0 -threaded -O2 -main-is SpeedTest SpeedTest.hs SpeedTestC.c
}}}
You should find that with 7.4.2, 7.6.3 or a recent build of 7.8, building with `SPEED_BUG=0` produces an executable that takes more than a second to run, while building with `SPEED_BUG=1` runs very quickly. I've also attached the Core for both scenarios." JohnWiegley
9347 45 michael@…, AndreasVoellmy, simonmar forkProcess does not acquire global handle locks Runtime System 7.8.2 simonmar new normal 2014-11-14T01:08:42Z "The global I/O handles (`stdout`, `stdin`, `stderr`) all make use an `MVar` wrapping a `Handle__`, and many I/O functions temporarily take this `MVar` (for instance, functions such as `hPutStr` include a call to `wantWritableHandle`, which uses `withHandle_'`, which involves taking the `MVar`, executing some operation, and then putting the `MVar` back).
Suppose we have a program consisting of two threads A and B, where thread A is doing I/O. If thread B does a call to `forkProcess` then it is possible that the `fork()` happens at the point that A has just taken, say, the `MVar` for `stdout`. If this happens, every use of `stdout` in the child process will now forever deadlock.
This is not a theoretical scenario. The example code reported by Michael Snoyman a few years ago
http://www.haskell.org/pipermail/haskell-cafe/2012-October/103922.html
exhibits precisely this behaviour: the child process deadlocks (not all the the time, but very frequently), exactly because of this problem.
In `forkProcess` we avoid this sort of situation for all of the global RTS locks by acquiring the lock just before the call to `fork()`, and then releasing the lock in the parent again and re-initializing the lock in the child. But there are no provisions for Haskell-land locks such as the above `MVar`.
In principle we can work around this problem entirely in user-land. Here is a modified version of Michael's code that does not deadlock (at least, it never has in my tests..), that basically takes the same acquire-release*2 trick that `forkProcess` does for RTS locks in the lines marked `(*)`:
{{{
import System.Posix.Process (forkProcess, getProcessID)
import Control.Concurrent (forkIO, threadDelay)
import System.IO (hFlush, stdout)
import System.Posix.Signals (signalProcess, sigKILL)
import Control.Exception (finally)
import Control.Concurrent
import GHC.IO.Handle.Types
import System.IO
main :: IO ()
main = do
mapM_ spawnChild [1..9]
ioLock IO ()
spawnChild i = do
_ Int -> IO ()
loop msg i = do
pid takeMVar m
unlockIO :: Handle__ -> IO ()
unlockIO hout =
case stdout of
FileHandle _ m -> putMVar m hout
}}}
I guess that _any_ global `MVar` or `TVar` is suspect when using `forkProcess`. " edsko
9314 51 michael@…, chak@…, simonmar Each object file in a static archive file (.a) is loaded into its own mmap()ed page Runtime System 7.8.3 7.12.1 patch high 2015-06-12T23:21:25Z "GHC API 7.8.x uses much more memory than GHC API 7.6.x.
Attached two files demonstrate this:
- A.hs -- Simple program using GHC API (copied from Wiki)
- B.hs -- A target file, just hello world
You can compile A.hs as follows:
{{{
% ghc A.hs -package ghc -package ghc-paths
}}}
A.hs stays in 10 seconds. So, we can investigate its memory usage with the ""top"" command.The following is the result:
{{{
Mac (64bit) Linux (64bit)
GHC 7.6.3: 20MB 4MB
GHC 7.8.3: 106MB 13MB
}}}" kazu-yamamoto
4900 130 michael@…, patrick@…, sol@…, ryant5000@…, idhameed@…, adam@…, simonmar Consider usage files in the GHCi recompilation check Compiler 7.12.1 new normal 2014-12-23T13:34:10Z "Since a seemingly-growing amount of Haskell code is using Template Haskell to read and include data from external sources, it would be nice if GHC recognized a pragma for specifying additional build dependencies for a source file. Such a pragma could be required to appear before the module headers, and look like:
{-# DEPENDS ""file.dat"" #-}
ghc --make would add it to other dependencies when deciding what modules to rebuild. The file would NOT be one that's generated by some other build step, but rather play the role of an additional source file, so it would have no effect on the order of compiling modules. My gut says to just make it an error if the file does not exist.
One example of a place this is called for is Michael Snoyman's Yesod and external hamlet files (e.g., hamletFile in the hamlet package). These are plastered all over the place with warnings that if you use them, GHC will no longer automatically rebuild everything it needs to." cdsmith
5262 30 michal.palka@…, dfeuer Compiling with -O makes some expressions too lazy and causes space leaks Compiler 7.1 7.12.1 new low 2014-12-23T13:33:45Z "Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.
Here are terms that get compiled too lazy with -O only when full strictness is on:
{{{
seq (id (\a -> seq a (\b -> (undefined::Int))) (undefined::Bool))
\a -> seq (seq a (\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\b -> ([]::[] Int)) length
\a -> seq (id (\b -> seq b (\c -> seq)) (length a)) ([]::[] Int)
}}}
Here are terms which are compiled too lazy with -O regardless of full strictness:
{{{
seq (seq (odd (undefined::Int)) (\a -> (undefined::[] (Int -> Bool))))
foldr (\a -> seq) id ((:) True (undefined::[] Bool))
\a -> foldr (\b -> \c -> seq c (\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False
\a -> (\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\b -> (undefined::([] Bool))))
map (seq (seq (seq 0 (undefined::Bool)) (\a -> \b -> (undefined::Bool)) (undefined::Int)))
map (seq (seq (id (\a -> (undefined::Int)) ([]::[] Int)) (\a -> undefined::Bool)))
\a -> (\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\b -> (undefined::Int -> [] Int)))
}}}
To discover the differences, just run the terms (whose types are [Int] -> [Int]) on some partially or fully-defined small lists.
It is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).
All programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.
Is this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug." michal.palka
149 56 michal.terepeta@…, hackage.haskell.org@… missed CSE opportunity Compiler 5.04.2 ⊥ new normal 2014-02-10T13:53:01Z "Don't know if this is a bug, but it was at least
_surprising_ to find that
{{{
playerMostOccur [a] = a
playerMostOccur (x:xs)
| numOccur x (x:xs) > numOccur (playerMostOccur xs) xs = x
| otherwise = playerMostOccur xs
}}}
was exponentially slower when compiled with ghc-5.04.2
-O than:
{{{
playerMostOccur [a] = a
playerMostOccur (x:xs)
| numOccur x (x:xs) > numOccur pmo xs = x
| otherwise = pmo
where pmo = playerMostOccur xs
}}}
Although the student responsible for the code couldn't
spot the
obvious optimisation, I was expecting that GHC's
optimiser would. :)
If it's not a bug, could you explain it to me?
-Greg(gregm.at.cs.uwa.edu.au)
" nobody
1687 44 mihai.maruseac@…, rwbarton@… A faster (^)-function. Prelude 6.6.1 ⊥ new normal 2013-08-27T07:43:00Z "This function performs better for me than the `(^)`-function in GHC. I seem to only be able to test it for the Integer type though and its only tested with ghc 6.6 (and ghc 6.6.1 by byorgey on #haskell).
I'm not sure if you really need this or if it is correct, but after discussion on #haskell i was asked to make a bug report so here it is! Enjoy. :)
{{{
module Pow (pow) where
import Prelude hiding ((^))
pow = (^)
(^) :: (Integral b, Num a) => a -> b -> a
x ^ y | y < 0 = error ""Negative exponent""
| y == 0 = 1
| y == 1 = x
| odd y = x * x^(y - 1)
| otherwise = let x' = x^(y `div` 2)
in x' * x'
}}}
Tests
{{{
-- TestData.hs
module TestData where
e = 10^8
}}}
{{{
-- mytest.hs
import Pow
import TestData
main = print $ (2 `pow` e) `mod` 2
}}}
{{{
-- ghctest.hs
import TestData
main = print $ (2 ^ e) `mod` 2
}}}
Test results (performance)
{{{
$ time ./ghctest
0
real 0m11.744s
user 0m11.449s
sys 0m0.104s
$ time ./mytest
0
real 0m6.794s
user 0m6.696s
sys 0m0.084s
-}
}}}
QuickCheck test
{{{
-- qc.hs
-- $ ./qc
-- OK, passed 100 tests.
import Test.QuickCheck
import Pow
main = quickCheck prop
prop x y = y >= 0 ==> x `pow` y == x^y
}}}" moonlite@…
8457 87 mihaly.barasz@…, tkn.akio@…, bos@…, johan.tibell@… -ffull-laziness does more harm than good Compiler 7.7 7.12.1 new normal 2015-07-21T09:42:14Z "In this bug report I'd like to argue that `-ffull-laziness` shouldn't
be turned on automatically with either `-O` nor `-O2`, because it's
dangerous and can cause serious memory leaks which are hard to debug
or prevent. I'll also try to show that its optimization benefits are
negligible. Actually, my benchmarks show that it's beneficial to turn
it off even in the cases where we don't hit a space leak.
We've met this issue last week, but it had been reported several times
before: e.g. #917 and #5262.
A typical example is the following:
{{{
#!haskell
main :: IO ()
main = task () >> task ()
task :: () -> IO ()
task () = printvalues [1..1000000 :: Int]
printvalues :: [Int] -> IO ()
printvalues (x:xs) = print x >> printvalues xs
printvalues [] = return ()
}}}
We succeed with `-O0`, but fail with `-O`:
{{{
errge@curry:~/tmp $ ~/tmp/ghc/inplace/bin/ghc-stage2 -v0 -O0 -fforce-recomp lazy && ./lazy +RTS -t >/dev/null
<>
errge@curry:~/tmp $ ~/tmp/ghc/inplace/bin/ghc-stage2 -v0 -O -fforce-recomp lazy && ./lazy +RTS -t >/dev/null
<>
}}}
28M? What the leak!? Well, it's `-ffull-laziness`:
{{{
errge@curry:~/tmp $ ~/tmp/ghc/inplace/bin/ghc-stage2 -v0 -O -fno-full-laziness -fforce-recomp lazy && ./lazy +RTS -t >/dev/null
<>
}}}
We get constant space and the fastest run-time too, since we spare
some cycles on GC.
Note, that in this instance we are trying to explicity disable sharing
by using `()` as a fake argument for the function. Also note, that
this function may easily be a utility function in a larger code base
or in a library, therefore it's impractical to say that you shouldn't
use it twice ""too close together"".
Quoting from the GHC user guide:
{{{
-O2:
Means: “Apply every non-dangerous optimisation, even if it means
significantly longer compile times.”
The avoided “dangerous” optimisations are those that can make
runtime or space worse if you're unlucky. They are normally turned
on or off individually.
At the moment, -O2 is unlikely to produce better code than -O.
}}}
This seems to be false at the moment.
We decided to make a broader investigation into this issue and wanted
to know if we can disable this optimization without too much pain.
Came up with this benchmark plan:
- let's benchmark GHC,
- compile all stages with -O, but hack the stage1 compiler to
emit `-t` statistics for every file compiled,
- gather these statistics while compiling the libraries and the
stage2 compiler.
On the second run we compile the stage1 compiler with
`-O -fno-full-laziness`, but leave everything else unchanged in the
environment.
When we have both results of the compilation of ~1600 files, we match
them up and compute the (logarithmic) ratio of CPU and memory
difference between compilations, the final results for our benchmark.
The results and the raw data can be found at
https://github.com/errge/notlazy.
The overall compilation time dropped from 26:20 to 25:12, which is a
4% improvement. Investigating the full matching shows that this
overall result is from small improvements all around the place.
The results plotted:
- https://github.com/errge/notlazy/blob/master/cpu.png
- https://github.com/errge/notlazy/blob/master/mem.png
The graphs show the logarithmic (100*log_10(new/orig)) ratio of change
in cpu and memory consumption. Therefore negative results mean that
the new compilation method is faster.
As can be seen on the CPU graph, in most of the cases the difference
is negligible (actually smaller than what can be measured on small
files, this is why we have the spike at 0). In overall we see a small
improvement in CPU, and there are some outliers in both directions,
but there are more drastic improvement cases than drastic regressions.
On the memory graph the situation is much more close to zero. There
is one big positive memory outlier: `DsListComp.lhs`. It uses 69M
originally and now uses 103M. But compiles in 2 seconds both ways and
there are files in the source tree which requires 400M to compile, so
this is not an issue.
After all this, I'd like to hear other opinions about just disabling
this optimization in `-O` and `-O2` and leaving it as an option that
can be turned on when needed, my reasons once more:
- it's unsafe,
- it's hard to debug when you hit its issues,
- the optimization doesn't seem to be very productive,
- it's always easy to force sharing, but it's not easy to force
copying.
Apparently a Haskell programmer should be lazy, but never fully lazy.
Research done by Gergely Risko and Mihaly Barasz ,
confirmed on two different machines with no other running processes.
" errge
10498 11 MikeIzbicki """if ... then \case -> else ..."" causes a ""missing else clause"" error" Compiler (Parser) 7.10.1 7.10.3 new normal 2015-07-31T14:28:31Z "The following program:
{{{#!hs
{-# LANGUAGE LambdaCase #-}
foo =
if True
then
\case ->
1 -> 2
else id
}}}
Produces this message:
{{{
problem.hs:4:5:
parse error in if statement: missing required else clause
}}}
The problem in the code is that there's a -> after the \case.
I don't know if a better error message can be generated, but this one is really unhelpful." dramforever
3971 48 mikolaj.konarski@…, mle+hs@… FFI callback segfaults on PPC Compiler (FFI) 6.12.3 ⊥ new normal 2011-04-10T23:30:24Z "ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:
{{{
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
Cabal-1.8.0.3
QuickCheck-2.1.0.3
array-0.3.0.0
base-3.0.3.2
base-4.2.0.1
bin-package-db-0.0.0.0
binary-0.5.0.2
bytestring-0.9.1.6
containers-0.3.0.0
directory-1.0.1.1
Segmentation fault
}}}
(Now, trying to install zlib, I also get:
{{{
./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p
Configuring zlib-0.5.2.0...
Setup: failed to parse output of 'ghc-pkg dump'
}}}
although I can see nothing wrong with the output of 'ghc-pkg dump' — reported under [http://hackage.haskell.org/trac/hackage/ticket/599 Bug 559 in the Cabal trac].)
Wolfram" wkahl
2437 17 mjm2002@… More accurate package dependencies Package system 6.8.3 7.12.1 niteria patch lowest 2015-06-20T21:58:55Z "The problem we want to solve here is that there is currently no distinction between compile-time package dependencies and link-time package dependencies. Often a compile-time dependency is also a link-time dependency, but there are two instances in which it might not be:
* Template Haskell: some packages might be required for executing TH code at
compile-time, but the compiled code doesn't require those packages to be
linked in.
* [wiki:Annotations]: we're considering allowing arbitrary attributes to be attached
to declarations, where the attributes are compile-time Haskell expressions.
The same issue as with TH crops up again here.
Currently we figure out which packages to link by looking at the (transitive closure of the) imports. It would be better to look at the external references of the compiled code; some of the packages referred to by imports may not need to be linked.
Similarly, we should figure out the dependencies of a ``package`` by taking the union of the link-time dependencies of its compiled modules. This means a small changes to Cabal.
None of this is particularly hard, and doesn't need any changes to the interface file format or package database: we just record fewer package dependencies than before. The only tricky bit is traversing the code to figure out what the package dependencies should be.
" simonmar
2041 60 mjm2002@…, reiner.pope@…, pho@… Allow splicing in concrete syntax Template Haskell 6.8.2 ⊥ new normal 2015-04-20T15:12:55Z "
Template Haskell tends to lag behind GHC extensions, so it might be nice to allow concrete syntax to be returned, e.g. something like
{{{
f = $( return (RawE ""5 + 6"") )
}}}
There wouldn't be any need to restrict it to the top level, e.g. this would also be allowed:
{{{
f = $( return (InfixE (IntE 5) '(+) (RawE ""6"")) )
}}}
One possible disadvantage is that it might result in TH languishing even further behind, as there is less incentive to fill in the gaps.
Also, if a module splices in a raw expression from a TH library, what extensions should be enabled when parsing the string? Should we use the extensions enabled for the module, or should the `RawE` constructor specify the extensions to be used? We actually have this problem already, as (for example) when instances are spliced in we might need !OverlappingInstances enabled, so just using the extensions enabled for the module would be consistent.
" igloo
4806 16 mmitar@… Make error message more user friendly when module is not found because package is unusable Compiler 7.0.1 7.12.1 lstrano new normal 2015-06-03T15:51:09Z "Make error message more user friendly when module is not found because package is unusable. Currently it just reports that module is missing (the same as it even would not be installed) but then checking with `ghc-pkg find-module` shows package correctly. Chasing '-v' output around can then show you this but it would be easier that you would immediately get a helpful message.
" mitar
4340 16 mmitar@… Add alignment to hsc2hs template Compiler (FFI) 6.12.3 7.12.1 new low 2014-12-23T13:33:45Z "I think [http://www.haskell.org/haskellwiki/FFICookBook#Working_with_structs commonly used]:
{{{
#let alignment t = ""%lu"", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)
}}}
should be added to official hsc2hs template. What are cons to that?" mitar
4316 82 mmitar@…, haskell.vivian.mcphail@…, dterei, gridaphobe, hvr, yokto "Interactive ""do"" notation in GHCi" GHCi 7.0.3 7.12.1 new low 2015-02-26T20:51:56Z "Enable GHCi to run commands under StateT monad based on IO or maybe even any other monad based on IO. So that you could for example exec a state and ""fall"" into this monad.
This could be generalized by supporting interactive ""do"" notation. Currently doing something like:
{{{
(flip execStateT) state $ do
}}}
raises ""Empty 'do' construct"" warning, but GHCi could go into interactive mode where it would be possible to write one command after another and it would execute them." mitar
1530 18 mnislaih@… debugging :steps inside TH spliced code need to be bypassed GHCi 6.7 ⊥ new normal 2013-01-23T00:06:56Z See test dynbrk005 for an example mnislaih
2737 18 mnislaih@… add :tracelocal to ghci debugger to trace only the expressions in a given function GHCi 6.8.3 7.12.1 new lowest 2014-12-23T13:33:22Z "As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within a given function. When an acces to a variable is needed it would be searched first in the selected expression and if not found the search would continue in the expressions from the trace history. If the value used would originate from the trace history it should be indicated so in the output: at the end or beginning of the output there would be the list of identifiers which values were taken from trace history. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the current depth of 50 would be enough).
:tracelocal should take an optional argument which defines the function to trace. Similar options as for a breakpoint specification (:break command) would be fine. It might be usefull to associate the tracelocal trace with breakpoint and having an option to set it on for given breakpoint (in such a case it would be possible to add tracelocal flag for a breakpoint).
Note that the results from the trace history may not be from the expected scope but the same problem is with ""printf debugging"" which is an efficient way to debug Haskell programs now too. The list of identifiers which were taken from trace history (while evaluating an interactively entered expression) should be provided because of the posibility to get values from an unexpected scope.
This should be a cheap way to make ghci debugger better than just plain ""printf debugging"", especially when used together with scriptable breakpoints (where one could script each breakpoint individually - not only all of them at once with :set stop). The best solution from user point of view would be just to provide access to all the variables which are in scope in a given expression (not just the free ones) but it is believed that it would introduce too much overhead.
Here is the url of the thread head where this proposal started to evolve:
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015840.html" phercek
2803 18 mnislaih@… bring full top level of a module in scope when a breakpoint is hit in the module GHCi 6.8.3 7.12.1 new lowest 2014-12-23T13:33:22Z "It should do something like {{{:module + *ModuleWhereBreakpointWasHit}}} and remove the added top level symbols of {{{ModuleWhereBreakpointWasHit}}} when we leave it.
The goal is so that the functions which are in scope when we hit a breakpoint are readily available for investigations of the values stored in the free variables of the selected expression.
This feature request is a consequence of the dicsussion in this ticket http://hackage.haskell.org/trac/ghc/ticket/2740#comment:4
... and a realated thing: When I do something like {{{:module + ModName}}} and later I do {{{:module + *ModName}}} then the non-exported symbols from {{{ModName}}} are not added into the scope." phercek
2950 18 mnislaih@… show breakpoint numbers of breakpoints which were ignored during :force GHCi 6.10.1 7.12.1 new lowest 2014-12-23T13:33:22Z "Extend message ""*** Ignoring breakpoint"" (which is printed during :force evalutation) so that it contains basic information about the breakpoint ignored. Add at least the breakpoint number." phercek
10276 10 mpickering ApiAnnotations : ITopenExpQuote needs SourceText Compiler (Parser) 7.10.1 7.12.1 alanz new normal 2015-04-12T19:59:18Z "In the lexer, `ITopenExpQuote` can be recognised for '[e|' or '[|'.
The token definition needs to capture the original `SourceText`, and pass it through to `ExpBr`, which also needs a `SrcText` field.
" alanz
7621 38 nathan.huesken@…, 0@… Cross-build for QNX ARM smashes stack when using FunPtr wrappers Compiler (FFI) 7.7 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "I have built an unregistered LLVM cross-compiler for arm-unknown-nto-qnx8.0.0eabi, which I finally got to build using the attached patch. Simple programs no longer crash like they do in registered ARM cross-compilers (as reported on mailing list at http://www.haskell.org/pipermail/ghc-devs/2013-January/000005.html and other places), however the following code does crash:
{{{
{-# LANGUAGE ForeignFunctionInterface #-}
module Main (main) where
import Foreign.Ptr
foreign import ccall ""wrapper"" wrap_refresh :: ( IO ()) -> IO (FunPtr ( IO ()))
main :: IO ()
main = do
wrap_refresh (return ())
return ()
}}}
It seems, from experiments, that any code using the ""wrapper"" imports causes this error:
{{{
$ ./Main
*** stack smashing detected ***: Main terminated
Abort (core dumped)
}}}" singpolyma
7459 24 nathanhowell@… deriving Generic does not work with TypeLits Compiler 7.6.1 7.12.1 dreixel new normal 2014-12-23T13:34:10Z "
{{{
{-# LANGUAGE DataKinds, KindSignatures #-}
{-# LANGUAGE DeriveGeneric #-}
import GHC.TypeLits
import GHC.Generics
data F (a :: Symbol)
data X = X (F ""hello"") deriving Generic
}}}
Trying to derive Generics instance for simple datatype with Symbol inside but GHC complains:
{{{
Can't make a derived instance of `Generic X':
X must not have unlifted or polymorphic arguments
In the data declaration for `X'
}}}
I found that this could be fixed by adding single line to isTauTy:
{{{
--- a/compiler/typecheck/TcType.lhs
+++ b/compiler/typecheck/TcType.lhs
@@ -899,6 +899,7 @@ mkTcEqPred ty1 ty2
isTauTy :: Type -> Bool
isTauTy ty | Just ty' Bool
bar x = x == 72
}}}
If I run:
{{{
ghc --make Bar -fforce-recomp
}}}
I get (snipped):
{{{
Bar.bar =
\ (x_afk :: GHC.Types.Int) ->
case x_afk of _ { GHC.Types.I# x1_alo ->
case x1_alo of _ {
__DEFAULT -> GHC.Types.False;
72 -> GHC.Types.True
}
}
}}}
`bar` now looks pretty well optimised. However, if I uncomment the `deriving Eq` I get:
{{{
Bar.bar1 = GHC.Types.I# 72
Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt
Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1
}}}
Now `bar` looks like terrible code, using dictionaries, boxing etc. It seems adding `deriving` in the imported and unused module makes it ignore the optimisation level." NeilMitchell
4861 58 ndmitchell@…, core-libraries-committee@… Documentation for base does not include special items Core Libraries 7.0.1 ⊥ ekmett upstream low 2015-02-24T23:20:45Z "The documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.
For tuples, the documentation for base doesn't include them in either Prelude or Data.Tuple, but the documentation for ghc-prim includes them in GHC.Unit and GHC.Tuple. I think the lack of documentation for tuple types is a bug, since it would be relatively easy for them to be documented, and does make the documentation more complete.
For lists ([], (:)), there is no documentation in either base or ghc-prim. It would be nice if they were documented in Prelude and Data.List, but not if it was too much effort (I can imagine that Haddock can't accept list definitions).
For the arrow type ->, it's unclear if it can reasonably be documented, so it might be worth thinking about but probably not bothering to document.
The reason I'm interested in ensuring complete documentation is that Hoogle currently doesn't know about tuple constructors in the base library, but it does know about them in ghc-prim, which seems wrong." NeilMitchell
3085 305 ndmitchell@…, deduktionstheorem@…, conal@…, id@…, haskell@…, chevalier@…, vogt.adam@…, merehap@…, mmitar@…, shahn, hackage.haskell.org@…, pho@…, asr, wren@… warn about language extensions that are not used Compiler 6.10.1 7.12.1 new normal 2015-06-11T02:06:58Z "When I put
`{-# OPTIONS_GHC -Wall -Werror #-}`
in my source file, I don't get compiler warnings about redundant language extensions that I enabled in that file.
For example if I write
`{-# LANGUAGE GeneralizedNewtypeDeriving #-}`
in the file, but I never do newtype deriving, the compiler could give me a warning.
It would be nice if the compiler gave warnings about this, since after refactoring, some language extensions might not be needed anymore, and hence should be removed since fewer language extensions mean more stable and portable code no?
" PVerswyvelen
989 87 ndmitchell@…, fryguybob@…, dterei, dagitj@…, idhameed@… Build GHC on Windows using Microsoft toolchain Build System ⊥ new low 2014-11-03T01:16:54Z "Create a Windows ""native"" port of GHC, i.e. one that uses the Microsoft toolchain instead of GCC and the GNU binutils. The main tasks are:
* Convert the pretty printer in the i386 NCG to generate MS/Intel syntax
instead of AT&T syntax. We can then generate assembly code that MASM can
grok.
* Make the RTS compile with Microsoft's CL compiler. (this has been done in
the past, so shouldn't be too much work).
* Drop any dependencies on mingw32 functionality in the libraries.
* Make appropriate modifications to the driver, build system etc. We'd still
need Cygwin/MSYS for build tools (dropping dependency on GNU make is another task
entirely...)" simonmar
1498 130 ndmitchell@…, johan.tibell@…, jan.stolarek@…, slyfox@…, mail@…, omeragacan@…, rwbarton Optimisation: eliminate unnecessary heap check in recursive function Compiler 6.6.1 7.12.1 new low 2015-07-24T17:11:46Z "See [http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html]
In a basic block consisting of some primitive cases, in which only some branches require heap, we could push the heap check into the branches as long as the primitive operations are safe to repeat, and the stack has not been modified. This might save a heap check in the common recursive case, which could be a significant win." simonmar
2867 38 ndmitchell@…, lemmih@… "Make a way to tell GHC that a pragma name should be ""recognised""" Compiler 6.10.1 7.12.1 new lowest 2014-12-23T13:33:22Z "GHC warns about unrecognised pragmas, but other impls can add pragmas inbetween GHC releases. If you want to use those pragmas then you can't just use `-Wall -Werror` when compiling. We could make a pragma to tell GHC to not warn about other pragmas, e.g.
{{{
{-# KNOWN_PRAGMA FOO #-}
}}}
would make GHC not warn about `FOO` pragmas.
Suggested in #2847.
" igloo
3231 78 ndmitchell@…, lennart@…, tetra2005@…, hvr, ekmett Permission denied error with runProcess/openFile Core Libraries 6.10.4 7.12.1 simonmar new normal 2014-12-23T13:34:10Z "Given this program:
{{{
module Main() where
import Control.Concurrent
import System.IO
import System.Process
main = do
hSetBuffering stdout NoBuffering
forkIO $ f ""foo1.txt""
forkIO $ f ""foo2.txt""
threadDelay $ 100*1000000
putStrLn ""Finished successfully""
f file = do
h IO a
retryIO act = catchIO act $ \x -> do
threadDelay $ 1 * 1000000 -- 1 second
performGC
act
}}}
Now calling {{{retryIO $ openFile ...}}} works reliably. These problems are occurring sufficiently often that {{{retryIO}}} is about to go in to our standard library :-)
This may be related to #2924, but has the advantage of replicating easily." NeilMitchell
2598 40 ndmitchell@…, rl@… Avoid excessive specialisation in SpecConstr Compiler 6.8.3 7.12.1 new lowest 2014-12-23T13:33:22Z "This ticket captures an email thread so it doesn't get lost.
Consider this (from `haddock/src/Haddock/Backends/Hoogle.hs`):
{{{
dropComment (' ':'-':'-':' ':_) = []
dropComment (x:xs) = x : dropComment xs
dropComment [] = []
}}}
This desugars thus:
{{{
dropComment xs
= case xs of
(C# x1 : xs1) ->
case x1 of
' '# ->
case xs1 of
(C# x2:xs2) ->
case x2 of
'-' -> ....
DEFAULT -> dropComment (C# x2 : xs2)
DEFAULT -> ...
[] -> ...
}}}
I have elided the branches that are less interesting, and I have done a bit of multi-level pattern matching to save space.
The thing to notice is this: at the recursive call, we know that the argument is a cons, with C# at the front. So `SpecConstr` dutifully creates a specialized version. And similarly for ''each subsequent character''! Indeed, if the match fails after matching `(' ': '-' : )` prefix, the recursive call even knows that the first char is `'-'`!
Hence we get as many specializations as we have characters in the input match.
So `SpecConstr` is behaving as expected. Can anyone think of a heuristic to squash this behavior? At the moment we take the first N specializations and then stop. One heuristic might be ""if there are lots of recursive calls, don't specialize"". But that is very close to ""if there are lots of specializations, drop some"". Mind you, perhaps we should be more vigorous still: ""if there are more than N, don't do any"" on the grounds that randomly choosing the first few is unlikely to be useful.
Any thoughts?
" simonpj
5793 40 ndmitchell@…, rwbarton@… make nofib awesome NoFib benchmark suite ⊥ dterei new normal 2014-10-12T09:09:04Z "Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations.
This task is about making nofib useful again.
The breakdown for this is something like:
1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that.
'''Note''' there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using-shake.html
The design discussion of it is mostly lost as it was done on private email sorry.
2. Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful.
E.g., Lots of great discussion and links to papers on this thread
http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html
3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second.
4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....)" dterei
10549 27 ndmitchell@…, scpmw floatExpr tick break<2> Compiler 7.10.2 7.10.3 new high 2015-08-01T14:33:22Z "When running the Shake test suite against GHC HEAD I get:
{{{
ghc: panic! (the 'impossible' happened)
(GHC version 7.11.20150615 for x86_64-unknown-linux):
floatExpr tick break<2>()
}}}
Full log at https://travis-ci.org/ndmitchell/shake/jobs/67636563. The command line that produced it is:
{{{
runhaskell -ignore-package=hashmap -ioutput/docs/ -isrc output/docs/Main.hs
}}}
If this seems like a legitimate bug that you don't already know about and are interested in tracking down, I'll try and grab the output/docs directory (it's on a remote machine I don't have access to on a different OS with a compiler I don't have installed, so it's not trivial to find it, but should be possible)." NeilMitchell
2522 12 NeilMitchell Warning for missing export lists Compiler 6.8.3 7.12.1 new lowest 2014-12-23T13:33:22Z "It occurred to me that it would be nice to have a warning for modules that lack an export list. Obviously not everybody prefers to write export lists for all their modules, but that's why it would be an optional warning. (It would also be handy to use in conjunction with {{{-fwarn-unused-binds}}}.)
If there is already such a flag, then the task is to add it to the users' guide, since I don't see it there :-)" tim
7782 7 nfrisby flag to run the demand analysis a second time Compiler 7.7 7.12.1 new high 2015-07-10T11:43:35Z "There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087, #6070. #10626 ? Others?
The -flate-dmd-anal flag has been committed to HEAD (cf comment:10 below).
The remaining task is to determine if `-O2` should imply `-flate-dmd-anal`. It currently does not: late demand analysis is ''off'' by default.
See LateDmd for more info." nfrisby
7109 7 nfrisby Inlining depends on datatype size, even with INLINE pragmas Compiler 7.5 7.12.1 simonpj infoneeded normal 2014-12-23T13:34:10Z "Consider the following code:
{{{
data Logic = T | F
| Not Logic
instance GEq Logic
testEqLogic = geq (Not T) (Not F)
}}}
With a proper definitions of generic equality `geq` in class `GEq`, and an `instance Generic Logic`, we get the following core code with -O1:
{{{
Rec {
Bug.$fGEqLogic_$cgeq [Occ=LoopBreaker]
:: Bug.Logic -> Bug.Logic -> GHC.Types.Bool
[GblId, Arity=2, Caf=NoCafRefs, Str=DmdType SS]
Bug.$fGEqLogic_$cgeq =
\ (x_ap1 :: Bug.Logic) (y_ap2 :: Bug.Logic) ->
case x_ap1 of _ {
Bug.T ->
case y_ap2 of _ {
Bug.T -> GHC.Types.True;
Bug.F -> GHC.Types.False;
Bug.Not g1_aBc_ayJ -> GHC.Types.False
};
Bug.F ->
case y_ap2 of _ {
Bug.T -> GHC.Types.False;
Bug.F -> GHC.Types.True;
Bug.Not g1_aBc_ayJ -> GHC.Types.False
};
Bug.Not g1_aBc_ayJ ->
case y_ap2 of _ {
__DEFAULT -> GHC.Types.False;
Bug.Not g1_aBc1_XAu -> Bug.$fGEqLogic_$cgeq g1_aBc_ayJ g1_aBc1_XAu
}
}
end Rec }
}}}
Nice and simple, looking just like what we would expect for an equality function for datatype `Logic`.
Now we add one more constructor to datatype `Logic` (and adapt the `Generic` instance accordingly):
{{{
data Logic = T | F
| Not Logic
| And Logic Logic
}}}
GHC (HEAD) now generates 3000 lines of core code for the `Bug.$fGEqLogic_$cgeq` function, instead of something only slightly longer than above.
Why is this? The second version of our `Logic` datatype is as easy to optimise as the first version; only the terms involved will be slightly longer. Attached file `Bug2.hs` is the input which gives the correct behaviour, while `Bug3.hs` is the input with one added constructor. (You might wonder if it has to do with the fact that the added constructor has more than one argument, but this is not the source of the problem.) Both files have `INLINE` pragmas pretty much everywhere (in fact, we're not `deriving Generic` so that we can put `INLINE` pragmas on `to` and `from`)." dreixel
7114 7 nfrisby Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1 Compiler 7.4.1 7.12.1 new normal 2014-12-23T13:34:10Z "(I'm sorry that this test case is so large.)
The attached module `Code3.hs` is a highly simplified version of a generic implementation of enumeration, followed by its instantiation to a datatype of lists of integers. The goal is to drive the simplifier to fully specialise the generic version to an optimised version for lists, without any reference to the generic representation constructors.
With GHC 7.0.2, the (interesting part of the) attached module compiles to the following core code (my renaming):
{{{
enumNil :: [Code2.List]
[GblId, Caf=NoCafRefs]
enumNil =
GHC.Types.: @ Code2.List Code2.Nil (GHC.Types.[] @ Code2.List)
Rec {
lvl1_roO :: GHC.Types.Int -> [Code2.List]
[GblId, Arity=1]
lvl1_roO =
\ (x_XnO :: GHC.Types.Int) ->
GHC.Base.map
@ Code2.List
@ Code2.List
(\ (x1_XnN :: Code2.List) -> Code2.Cons x_XnO x1_XnN)
enumList
lvl2_roR :: [[Code2.List]]
[GblId]
lvl2_roR =
GHC.Base.map
@ GHC.Types.Int @ [Code2.List] lvl1_roO enumInt
enumCons :: [Code2.List]
[GblId]
enumCons = Code2.diag @ Code2.List lvl2_roR
enumList [Occ=LoopBreaker] :: [Code2.List]
[GblId, Str=DmdType]
enumList = Code2.||| @ Code2.List enumNil enumCons
end Rec }
}}}
This is exactly what is intended: no more generic representation stuff. GHC 7.4.1, however, doesn't quite achieve this, instead leaving us with the following:
{{{
enumNil :: [Code2.List]
[GblId, Caf=NoCafRefs]
enumNil =
GHC.Types.: @ Code2.List Code2.Nil (GHC.Types.[] @ Code2.List)
Rec {
a_rme :: [Code2.K1 Code2.List]
[GblId, Str=DmdType]
a_rme =
GHC.Base.map
@ Code2.List
@ (Code2.K1 Code2.List)
(Code2.K1 @ Code2.List)
enumList
lvl1_rmf :: GHC.Types.Int -> [Code2.List]
[GblId, Arity=1]
lvl1_rmf =
\ (x_Xmk :: GHC.Types.Int) ->
GHC.Base.map
@ (Code2.K1 Code2.List)
@ Code2.List
(\ (x1_Xn9 :: Code2.K1 Code2.List) ->
case x1_Xn9 of _ { Code2.K1 b_aaM -> Code2.Cons x_Xmk b_aaM })
a_rme
lvl2_rmg :: [[Code2.List]]
[GblId]
lvl2_rmg =
GHC.Base.map
@ GHC.Types.Int @ [Code2.List] lvl1_rmf enumInt
enumCons :: [Code2.List]
[GblId]
enumCons = Code2.diag @ Code2.List lvl2_rmg
enumList [Occ=LoopBreaker] :: [Code2.List]
[GblId, Str=DmdType]
enumList = Code2.||| @ Code2.List enumNil enumCons
end Rec }
}}}
The strange part is the interaction between the `lvl1_rmf` and `a_rme` functions: basically `a_rme` maps `K1` over a list, and `lvl1_rmf` maps a function that takes this `K1` away.
I have no idea why 7.4.1 leaves this residue around. I have played with different inline pragmas and rewrite rules, but so far have been unable to convince GHC 7.4.1 to just do what 7.0.2 did. Turning `K1` into a `newtype` doesn't help (we're left with a newtype coercion instead)." dreixel
2255 7 nfrisby Improve SpecConstr for free variables Compiler 6.8.2 ⊥ new normal 2013-03-26T16:23:29Z "This ticket records a suggestion for improving `SpecConstr`, so we don't lose it. The original `SpecConstr` transformation is described in ""[http://research.microsoft.com/%7Esimonpj/papers/spec-constr Call pattern specialisation for Haskell]"". Consider this program
{{{
f x = let g y = ...case x of { z:zs -> e1; [] -> e2 } ...
in
...case x of
z:zs -> if ... then g 3 else g 4
[] -> ...
}}}
Here 'x' is free in 'g', but x's value is known at g's call sites. It's not enough just to know ""x is a cons"" inside g; we must also have access to z,zs. So perhaps the thing to do is to imagine lambda-lifting 'g' to become 'gl' thus:
{{{
gl x y = ...case x of { z:zs -> e1; [] -> e2 } ...
f x = ...case x of
z:zs -> if ... then gl x 3 else gl x 4
[] -> ...
}}}
Now the `SpecConstr` transformation will apply nicely. And it's arguably a bad shortcoming that currently the mere act of lambda lifting can affect how effective `SpecConstr` is.
Of course, we only want to lambda-lift wrt the parameters that'll be specialised, so this transformation probably wants to be done at the same time as the rest of `SpecConstr`. I don't have much idea of how hard that'd be, but it's a nice idea.
" simonpj
9615 3 nh2 GHC panic: Loading temp shared object failed Compiler 7.8.3 infoneeded normal 2015-02-19T08:26:54Z "(Seemingly) Randomly happened when building with cabal (before many builds were fine in the same project):
{{{
:
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc6776_0/ghc6776_359.so: undefined symbol: ganetizm2zi12_GanetiziUtils_newUUID1_info
}}}" nh2
10161 3 nh2 GHC does not relink if a library's code changed Compiler 7.8.4 new normal 2015-03-17T16:15:49Z "Test case for reproducing: https://github.com/nh2/ghc-relinking-avoidance-bug/
----
{{{myexe}}} is an executable that depends on {{{mylib}}}, whose {{{myfun = putStrLn ""output 1""}}}.
If we install {{{mylib}}}, compile {{{myexe}}}, then change mylib's code to {{{myfun = putStrLn ""output 2""}}}, re-install it, and then compile {{{myexe}}}, then GHC does not notice that the library code changed.
It avoids re-linking myexe, with the result that the program prints {{{output 1}}} when you told it to compile against code that prints {{{output 2}}}.
----
Note that I had to use {{{NOINLINE myfun}}} to trigger the bug, since otherwise {{{myfun}}}'s code would have ended up in the interface file, thus changing the package ID, which naturally forces GHC to relink (even re-compile).
With the {{{NOINLINE}}}, the package IDs of the two different versions of {{{myfun}}} are completely identical. I think that is correct, since the package ID only hashes the API and ABI, not the actual implementation, right?
How does GHC decide when to relink? I think in the present case, it doesn't notice that the object/archive file of the library changed. Does it check that somehow? Just looking at API and API can't be enough to make a decision for linking." nh2
10310 3 nh2 MakingReleases outdated or build system problems Build System 7.10.1 new normal 2015-04-16T11:39:03Z "Hey, I have some problems following https://ghc.haskell.org/trac/ghc/wiki/MakingReleases with HEAD.
I'll collect them here, maybe we can update the Wiki page together, or fix the corresponding problems in the build system if they are problems.
1) `make sdist` fails with the problem that `ghc-tarballs` doesn't exist. I've heard that's only needed on Windows, and that some people seem to get it by cloning a submodule when they are on Windows. A `mkdir ghc-tarballs` fixed it. Maybe that directory should be created by the build system?
2) When I `make` in the unpacked sdist tarball, I get
{{{
"""" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --ps -o utils/haddock/doc/haddock.ps
"""" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --pdf -o utils/haddock/doc/haddock.pdf
/bin/bash: : command not found
/bin/bash: : command not found
make[1]: *** [utils/haddock/doc/haddock.ps] Error 127
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [utils/haddock/doc/haddock.pdf] Error 127
}}}
Looks like some program was set to the empty string here." nh2
9614 3 nh2 ghc --print-(gcc|ld)-linker-flags broken Compiler 7.8.3 7.12.1 new normal 2014-12-23T13:34:10Z "{{{
rwbarton@morphism:~/ghc$ ghc --print-gcc-linker-flags
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-linux):
Setting not found: ""Gcc Linker flags""
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
rwbarton@morphism:~/ghc$ ghc --print-ld-linker-flags
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-linux):
Setting not found: ""Ld Linker flags""
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
In 2d2650bf65da3aede4e1c1ca4da623092b869dbe and subsequent commits (between 7.6 and 7.8) these settings fields became ""C compiler link flags"" and ""ld flags"". (I think, more or less.)
The real problem is that Cabal still looks for the settings fields ""Gcc Linker flags"" and ""Ld Linker flags"". I guess this should be updated on the Cabal side though. (They are empty on at least Linux x86_64, which I guess is why nobody noticed before.)" rwbarton
9841 3 nh2 Touching a file that uses TH triggers TH recompilation flood Driver 7.8.3 7.12.1 new normal 2015-05-24T18:23:13Z "Check out this test case:
https://github.com/nh2/ghc-th-recomp-touch-test
I have 2 modules, A and B, both using TH (using aeson) with B importing A.
After the first compilation, `touch A.hs && ghc --make B.hs` causes B to be recompiled.
Why should this be the case? If we see that the A.hi file is completely identical with what it was before, why should we recompile B?
This problem actually hits pretty hard when working in projects with > 200 modules.
(This all is under the assumption that TH doesn't do any IO with observably different result; we do already have this assumption if I understand it correctly, since otherwise we would always recompile all TH code, which we don't.)
----
Another problem is that the process is not very repeatable:
If you do `touch A.hs && ghc --make All.hs` and hit `Ctrl-C` before everything is done (e.g. after the 3rd modules), and then run just `ghc --make All.hs`, then GHC will decide to compile nothing at all, even though it had determined just before that everything needs to be recompiled. Is this expected?" nh2
9760 22 nh2, aehlig@… ghc -c 7.8 drops last char of file name if -osuf contains a dot Driver 7.8.3 7.12.1 thomie new normal 2015-03-19T02:13:31Z "I discovered that if I compile with `ghc -c -osuf .something Myfile.hs` where `Myfile.hs` contains TH and thus has to dynamically link in, say, `Other.hs`, I get the error that
{{{
Myfile.hs:1:1:
cannot find normal object file 'Othe.dyn_o`
while linking an interpreted expression
}}}
So `Other` was wrongly made into `Othe`, dropping the last character.
If I don't pass `-osuf .something`, or have it not have a dot, everything's fine.
The trouble is that `-osuf .something` worked fine in GHC <= 7.6.
So I believe this is a regression, or at least a very bad error message." nh2
10229 21 nh2, thomie, simonmar setThreadAffinity assumes a certain CPU virtual core layout Runtime System 7.10.1 simonmar new normal 2015-04-03T17:23:05Z "The {{{RTS -qa}}} option that can set thread affinity was implemented in https://git.haskell.org/ghc.git/commitdiff/31caec794c3978d55d79f715f21fb72948c9f300
{{{
// Schedules the thread to run on CPU n of m. m may be less than the
// number of physical CPUs, in which case, the thread will be allowed
// to run on CPU n, n+m, n+2m etc.
void
setThreadAffinity (nat n, nat m)
}}}
Today I discovered that on some machines, this option helps parallel performance (e.g. {{{+RTS -N4}}}) a lot, while on others it doesn't.
Together with thomie on #ghc, I found out the reason:
Lets assume I have 4 real cores with hyperthreading, so 8 virtual cores.
The mapping of hyperthreading cores to physical cores is different across machines.
On my one machine (Intel i5), the layout is 11223344, meaning that the first two vCPUs (hyperthreads) that the OS announces (visible e.g. in HTOP) map to the first physical core in the system, and so on.
On my other machine (Intel Xeon), the layout is 12341234; here the 1st and the 5th vCPU map to the same physical core.
This layout can be (on Linux) observed by running:
{{{
cat /proc/cpuinfo|egrep ""processor|physical id|core id"" |sed 's/^processor/\nprocessor/g'
}}}
I do not know whether this layout is dictated by the processor, chosen by the OS, or even changing across reboots; what is clear is that the layout can vary across machines.
Now, as explained by thomie:
{{{
-qa will set your 4 capabilities to cores [(1,5), (2,6), (3,7), (4,8)], and then the os randomly chooses out of those tuples
}}}
This strategy is optimal for the 12341234 layout; for example, when running with -N4, it ensures that two threads are not scheduled onto vCPUs that are on the same physical core. The possible {{{+RTS -aq}}} choice {{{1__4_23_}}} is a great assignment in this case, as is {{{1234____}}} ({{{_}}} means the vCPU is not chosen).
But for the 11223344, the choice {{{1234____}}} isn't good, because it uses only 2 of our 4 physical cores; our program now takes twice as long to run.
----
It seems likely to me that {{{setThreadAffinity}}} was written on a machine with 12341234 layout, and with the assumption that all machines have this layout.
It would be great if we could change it to take the actual layout into account." nh2
9279 24 nicolas.frisby@… Local wrapper function remains in final program; result = extra closure allocation Compiler 7.8.2 simonpj new normal 2014-08-20T04:02:53Z "I have a strange problem with a local function binding that is not being inlined. I've attached the repro code, build it like this:
{{{
$ ghc -O2 Haxl/Core/Monad.hs
}}}
There are several modules, but the one with the problem is `Haxl/Core/Monad.hs`. In particular `Haxl.Core.Monad.$fApplicativeGenHaxl2`, which contains this fragment:
{{{
let {
$wa4_s6YQ
$wa4_s6YQ =
\ w_s6YF _ ww1_s6YM _ _ w1_s6YI ->
case GHC.Prim.readMutVar# ipv7_X5Ne w1_s6YI
of _ { (# ipv10_X5QO, ipv11_X5QQ #) ->
case ipv11_X5QQ of _ {
Haxl.Core.Monad.IVarFull a2_a3kK -> case lvl6_r7qi of wild3_00 { };
Haxl.Core.Monad.IVarEmpty dt2_d4Vs ->
case GHC.Prim.writeMutVar#
ipv7_X5Ne (Haxl.Core.Monad.IVarFull w_s6YF) ipv10_X5QO
of s2#_a5OR { __DEFAULT ->
case GHC.Prim.readMutVar# dt2_d4Vs s2#_a5OR
of _ { (# ipv12_X5R0, ipv13_X5R2 #) ->
case GHC.Prim.readMutVar# ww1_s6YM ipv12_X5R0
of _ { (# ipv14_X5SS, ipv15_X5SU #) ->
letrec {
go_a5ti
go_a5ti =
\ ds10_a5tj ->
case ds10_a5tj of _ {
[] -> ipv15_X5SU;
: y_a5to ys_a5tp -> GHC.Types.: (y_a5to w_s6YF) (go_a5ti ys_a5tp)
}; } in
case go_a5ti ipv13_X5R2 of x'_a5P6 { __DEFAULT ->
case GHC.Prim.writeMutVar# ww1_s6YM x'_a5P6 ipv14_X5SS
of s2#1_a5P7 { __DEFAULT ->
(# s2#1_a5P7, Haxl.Core.Monad.cacheRequest6 #)
}
}
}
}
}
}
} } in
let {
a2_s6lH
a2_s6lH =
\ w_s6YF _ w2_s6YH w3_s6YI ->
case w2_s6YH
of _
{ Haxl.Core.Monad.SchedState ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO ->
$wa4_s6YQ w_s6YF ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO w3_s6YI
} } in
}}}
I want `$wa4` to be inlined at its single occurrence in `a2`. I believe the reason it is not being inlined is that `a2` is a wrapper, but the situation seems silly because the wrapper isn't going away either, so we have a redundant closure being built (this is in my inner loop)." simonmar
9374 24 nicolas.frisby@… Investigate Static Argument Transformation Compiler 7.9 new lowest 2014-11-05T13:36:01Z "At the moment the Static Argument Transformation (SAT) optimisation is not run unless explicitly enabled with `-fstatic-argument-transformation`. There was a comment by Max Bolingbroke in DynFlags that said this (that comment is now removed and replaced with a reference to this ticket):
{{{
Max writes: I think it's probably best not to enable SAT with -O2 for the
6.10 release. The version of SAT in HEAD at the moment doesn't incorporate
several improvements to the heuristics, and I'm concerned that without
those changes SAT will interfere with some attempts to write ""high
performance Haskell"", as we saw in some posts on Haskell-Cafe earlier
this year. In particular, the version in HEAD lacks the tail call
criterion, so many things that look like reasonable loops will be
turned into functions with extra (unneccesary) thunk creation.
}}}
6.10 was a long time ago. Has anything changed since then? Does it make sense to enable that optimisation now? What are the mentioned heuristics and were they finally implemented? Does anyone know what Haskell-cafe posts does Max refer to?" jstolarek
2057 27 nicolas.pouillard@… inconsistent .hi file error gets ignored Compiler 6.8.2 ⊥ new normal 2008-09-30T15:51:40Z "{{{
[20 of 20] Compiling Main ( ./Main.hs, dist/build/cabal/cabal-tmp/Main.o )
The interface for `main:Hackage.Config'
Declaration for savedConfigToConfigFlags
Unfolding of Hackage.Config.savedConfigToConfigFlags:
Can't find interface-file declaration for variable Distribution.Simple.Setup.a401
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
Linking dist/build/cabal/cabal ...
dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `sfsu_info':
(.text+0x70cc): undefined reference to `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `rf7U_closure':
(.data+0xf28): undefined reference to `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
collect2: ld returned 1 exit status
}}}
Now, the inconsistent .hi file was entirely my fault. However note that `ghc --make` did not stop at the error! It continued and tried to link.
This is bad because sometimes linker errors are very long and a user might loose the real source of the error.
The error gets raised in `iface/TcIface.lhs` by `importDecl`. The uses of that function look like they are translating the error into failure in other monads ok. It's not immediately obvious at what point in the propagation of this error it gets ignored and linking continues irrespective.
It should not be too hard to reproduce I hope. Generating inconsistent .hi files is fairly easy to do. In this case I just built cabal-install against an existing Cabal. Then rebuilt and re-registered a slightly changed Cabal lib. Then did another build of cabal-install without cleaning first." duncan
4295 163 nicolas.pouillard@…, v.dijk.bas@…, hackage.haskell.org@…, favonia@…, nathanhowell@…, rabeslik@…, ben@… Review higher-rank and impredicative types Compiler (Type checker) 6.12.3 7.12.1 simonpj new normal 2015-03-25T01:08:27Z "The ticket is a placeholder to remind me to work through the test cases for impredicative and higher rank types in the new typechecker. For now, I'm marking many of them as `expect_broken` on this ticket, although I think many of them really should fail.
* tc150
* tc194
* tcfail198
* tcfail174
* tcfail165
* tcfail145
* tcfail104
* tc211
* indexed-types/should_compile/T4120
* simpl017
* Many tests in `boxy/` (see also #1330 for Church2)
* #2193
* #2846
* #4347
* [http://augustss.blogspot.com/2011/07/impredicative-polymorphism-use-case-in.html Lennart's blog post] has an interesting use case of impredicative polymorphism; it worked in 7.0, but alas not in the new typechecker.
" simonpj
9218 36 niklasl, gintas, hamish, RyanGlScott Upgrade the version of MinGW shipped with GHC Build System 7.8.2 7.12.1 gintas patch normal 2015-08-02T12:03:02Z "The Windows binary distribution of GHC incorporates a version of MinGW which has not been updated for several releases and is now out-of-date. It should be upgraded. The previous time this was done appears to correlate with ticket #3390.
" komadori
2595 68 noah.easterly@…, adam.gundry@…, byorgey@… Implement record update for existential and GADT data types Compiler 6.8.3 new normal 2014-06-30T13:37:43Z "Ganesh writes: The most important thing for me is supporting record update for
existentially quantified data records, as in the error below.
In general I also find working with code that involves existential
type variables quite hard work - for example I can't use foo as a
record selector either, even if I immediately do something that seals
the existential type back up again.
I don't understand this stuff well enough to be sure whether it's an
impredicativity issue or not, though.
{{{
Foo.hs:11:8:
Record update for the non-Haskell-98 data type `Foo' is not (yet)
supported
Use pattern-matching instead
In the expression: rec {foo = id}
In the definition of `f': f rec = rec {foo = id}
}}}
Program is:
{{{
{-# LANGUAGE Rank2Types #-}
module Foo where
data Foo = forall a . Foo { foo :: a -> a, bar :: Int }
x :: Foo
x = Foo { foo = id, bar = 3 }
f :: Foo -> Foo
f rec = rec { foo = id }
g :: Foo -> Foo
g rec = rec { bar = 3 }
}}}
Simon says: Ah now I see. The relevant comment, `TcExpr` line 465, says
{{{
-- Doing record updates on
-- GADTs and/or existentials is more than my tiny
-- brain can cope with today
}}}
Should be fixable, even with a tiny brain.
" simonpj
10464 7 nomeata ghc 7.8.4 on arm Build System 7.8.4 new normal 2015-07-24T19:32:52Z "when compiling i get the warning
/usr/bin/d.gold: warning: cannot scan executable section 1 of ..... transformers-04.3.0a... for Cortex-A8 erratum because it has no mapping symbols.
there are some informations on the web on the cortex-a8 erratum, but i cannot see how i could apply them. should the compiler be recompiled? i installed from the debian distribution.
the hardware is a cubietruck.
i observe that compilation, especially the phase of preparing the configuration in cabal takes very long - perhaps this is related to this problem. the resulting code is ok and runs with expected speed.
thank you for producing a full ghc for arm!
andrew" andrewufrank
10724 7 nomeata ghci crashing when using copy/paste in Gnome Terminal on Debian Jessie GHCi 7.10.2 new normal 2015-08-01T19:47:40Z "When I copy/paste text from a ghci instance running in the terminal, quite often it stops responding with the following message:
: hGetChar: hardware fault (Input/output error)
I then have to kill it (Ctrl-C) and restart.
It's
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
but I remember the same was happening in 7.10.1 too." martinvlk
9511 7 nomeata Remove deprecated -fglasgow-exts from NoFib suite NoFib benchmark suite 7.8.3 new low 2015-06-14T08:15:45Z Someone on #ghc noted that replacing -fglasgow-exts with only the necessary options in each case may change compile times, which may be undesirable. I think a reasonable workaround would be to just put all the options on the command line, whether necessary or not. This will increase the time needed to parse the command lines, but presumably by a trivial amount. dfeuer
10245 17 nomeata, simonmar "panic in new integer switch logic with ""out-of-range"" literals" Compiler (CodeGen) 7.11 new high 2015-07-30T23:47:46Z "Compiling this module
{{{
module D (f) where
f :: Int -> String
f n = case n of
0x8000000000000000 -> ""yes""
_ -> ""no""
}}}
crashes with the error
{{{
[1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o )
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.11.20150403 for x86_64-unknown-linux):
Map.findMin: empty map has no minimal element
}}}
The constant does not have to be exactly `0x8000000000000000`, everything I tested from there up to `0xffffffffffffffff` yields the same crash. Also occurs with `Word` and negative literals.
The bug seems to be tied to the target's word size somehow, though: a 64-bit compiler does not panic on `Int32` and `0x80000000`, but a 32-bit compiler does." rwbarton
9719 8 nominolo Improve `mkInteger` interface Compiler 7.12.1 new low 2014-10-29T15:03:31Z "`mkInteger` is the current operation provided by the `Integer` libraries to construct (large) integer values. The current type-signature is
{{{#!hs
mkInteger :: Bool -- sign-bit
-> [Int] -- absolute value in 31 bit chunks, least significant first
-> Integer
}}}
A somewhat pathological example of why this representation is not so nice is the following simple CAF
{{{#!hs
c :: Integer
c = 0xf000000000000000
}}}
that (this is for a 64bit arch!) gets compiled into the following STG:
{{{
==================== STG syntax: ====================
sat_sJQ :: GHC.Types.Int
[LclId, Str=DmdType] =
NO_CCS GHC.Types.I#! [3];
sat_sJR :: [GHC.Types.Int]
[LclId, Str=DmdType] =
NO_CCS :! [sat_sJQ GHC.Types.[]];
sat_sJP :: GHC.Types.Int
[LclId, Str=DmdType] =
NO_CCS GHC.Types.I#! [1610612736];
sat_sJS :: [GHC.Types.Int]
[LclId, Str=DmdType] =
NO_CCS :! [sat_sJP sat_sJR];
sat_sJO :: GHC.Types.Int
[LclId, Str=DmdType] =
NO_CCS GHC.Types.I#! [0];
sat_sJT :: [GHC.Types.Int]
[LclId, Str=DmdType] =
NO_CCS :! [sat_sJO sat_sJS];
Foo.c :: GHC.Integer.Type.Integer
[GblId, Str=DmdType] =
\u srt:SRT:[0Y :-> GHC.Integer.Type.mkInteger, sJT :-> sat_sJT] []
GHC.Integer.Type.mkInteger GHC.Types.True sat_sJT;
}}}
Moreover, determining how much space to allocate for the resulting `Integer` is a bit work as it for one, you need to traverse the list twice, and then you can't simply derive the exact allocation amount by the list-length alone due to the odd 31-bit chunks.
Instead a more ""natural"" `mkInteger` would be desirable, possibly in the style of `unpackCString#`, in terms of a packed/unboxed vector of machine-word-sized chunks. A better `mkInteger` could then take a `ByteArray#` or a `Addr#` + length instead, e.g.
{{{#!hs
mkInteger :: Int# -- signum(n) = sign of encoded Integer
-- abs(n) = number of machine-word sized chunks
-> Addr# -- pointer to start of machine-word sized chunks,
-- least-significant chunk first
-> Integer
}}}" hvr
8914 4 nsch Remove unnecessary constraints from MonadComprehensions and ParallelListComp Compiler (Type checker) new normal 2014-05-27T22:58:49Z "Many parts of MonadComprehensions don't actually require monads instance, the following could do with a `Functor` constraint
{{{
fmapM :: Monad m => (a -> b) -> m a -> m b
fmapM f xs = [ f x | x FunctorZip f where
fzip :: f a -> f b -> f (a,b)
fzip = fzipWith (,)
fzipWith :: (a -> b -> c) -> f a -> f b -> f c
fzipWith f fa fb = fmap (uncurry f) (fzip fa fb)
funzip :: f (a,b) -> (f a, f b)
funzip fab = (fmap fst fab, fmap snd fab)
}}}
with the laws
{{{
fmap (f *** g) (fzip fa fb) = fzip (fmap f fa) (fmap g fb)
fmap (const ()) fa = fmap (const ()) fb
==> funzip (fzip fa fb) = (fa, fb)
}}}
Same with `Applicative` (see ApplicativeDo):
{{{
liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c
liftA2 f a1 a2 = [ f x1 x2 | x1 SUBJ_Obs subj -> IO ()
data ASubj obs = forall subj. (SUBJ subj, SUBJ_Obs subj ~ obs) => ASubj subj
-- data ASubj obs = forall subj. (SUBJ subj) => ASubj subj (obs -> SUBJ_Obs subj)
class OBS obs where
subscribed :: obs -> ASubj obs -> IO ()
withdraw :: obs -> IO ()
-- The implementation of Obs
data Obs = Obs{obs_subjects :: IORef [ASubj Obs]}
instance OBS Obs where
subscribed obs subj = modifyIORef (obs_subjects obs) (subj:)
withdraw obs = do
subjs unsubscribe' subj obs) subjs
-- mapM_ (\ (ASubj subj cast) -> unsubscribe' subj (cast obs)) subjs
}}}
gives a rather obscure type error
{{{
Couldn't match type `b0' with `()'
`b0' is untouchable
inside the constraints (SUBJ subj, SUBJ_Obs subj ~ Obs)
bound at a pattern with constructor
ASubj :: forall obs subj.
(SUBJ subj, SUBJ_Obs subj ~ obs) =>
subj -> ASubj obs,
in a lambda abstraction
In the pattern: ASubj subj
In the first argument of `mapM_', namely
`(\ (ASubj subj) -> unsubscribe' subj obs)'
In a stmt of a 'do' block:
mapM_ (\ (ASubj subj) -> unsubscribe' subj obs) subjs
-}
}}}
It is not even clear what b0 is: the code has no type variable named b.
Incidentally, if I use the explicit cast (as in the commented out
declaration of ASubj) and change the last line of withdraw accordingly (as shown in the commented out line), the code compiles.
It seems that what I am trying to accomplish is reasonable.
Incidentally, why GHC insists on the extension GADTs given that I already specified ExistentialQuantification? It seems when opening amn existential GADTs extension must be present. It seems ExistentialQuantification no longer has any point?" guest
10647 20 omeragacan@… Notice about lack of SIMD support. Compiler 7.8.4 new normal 2015-07-17T02:16:13Z "In some cases, when SIMD primitives are used without the `-fllvm` flag, instead of giving the friendly `SIMD vector instructions require the LLVM back-end.`, GHC crashes with varying messages.
The simplest example is
{{{#!hs
{-# LANGUAGE MagicHash #-}
module Foo where
import GHC.Prim
data V = V Int8X16#
}}}
In 7.8.4 this crashes with
{{{
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.4 for x86_64-unknown-linux):
Size.intSize W128
}}}
According to osa1, in HEAD this still crashes, but with
{{{
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150717 for x86_64-unknown-linux):
Format.intFormat W128
}}}" mniip
3541 20 omeragacan@… Allow local foreign imports Compiler (FFI) 6.12.2 ⊥ DevarshDesai new normal 2015-07-03T00:39:59Z "I have no idea the level of difficulty this would entail, but it would be rather nice to be able to import foreign functions at scopes other than the top level. When writing glue code, especially for C++ where I often want to catch and haskellize exceptions, I find myself using wrappers quite a bit, for example:
{{{
foreign import ccall ""foo.h foo""
raw_foo :: CString -> IO ()
foo :: String -> IO ()
foo s = withCString s raw_foo
}}}
Where I only want ""foo"" exported from the module. It's not that big a deal to list explicit exports, I know, but I would like to be able to say instead:
{{{
foo :: String -> IO ()
foo s = withCString s raw_foo
where
foreign import ccall ""foo.h foo"" raw_foo :: CString -> IO ()
}}}
In addition to reducing clutter in the top level namespace, it makes for less clutter on the left margin of the code, making it easier to scan through function names visually." mokus
10577 33 omeragacan@…, RyanGlScott Use empty cases where appropriate when deriving instances for empty types Compiler 7.11 new normal 2015-07-16T15:03:38Z "In some sense the correct instance for
{{{
data X
deriving instance Eq X
}}}
is not (what GHC currently produces)
{{{
instance Eq X where
(==) = error ""Void ==""
}}}
but rather
{{{
instance Eq X where
a == b = case a of {} -- using the EmptyCase extension
}}}
See comments starting at ticket:7401#comment:28 for justification.
The list of classes that GHC can currently derive is
* Eq, Ord, Enum, Bounded, Show, Read (Haskell 2010 Report)
* Functor, Foldable, Traversable, Typeable, Generic, Data, ""any class"" (`-XDerive*`)
Deriving Enum and Bounded is not currently allowed for empty data types. The `showList` method of Show and the whole Read instance are easy and already implemented correctly. All the remaining methods of Haskell 2010 derivable type classes take at least one argument of the instance head type `a`. I propose that all these methods be defined as an empty case on the first such argument.
Similarly in Functor, Foldable and Traversable, each method has a single argument of the form `t _` where `t :: * -> *` is the instance head type, and the method should be defined as an empty case on that argument.
In all these cases so far, the derived methods for a non-empty type would, at the outermost level, be a (non-empty) case on that first argument, or the equivalent (series of pattern matches, one for each constructor), so the use of an empty case is justified for an empty type.
Typeable does not care about the values or even the kind of the type at all, so it's not relevant here.
Generic and especially Data are above my pay grade, but generally I expect that methods which are normally defined by case analysis on an argument of the instance head type should be defined by an empty case, and methods that (sometimes) produce a value of the instance head type should do whatever they normally do when unable to produce such a value (like `readsPrec` returning an empty list, or `read` calling `error` (if `read` were actually a method of `Read`)).
`DeriveAnyClass` doesn't generate any new code, so like Typeable it's not relevant.
None of this behavior is specified by the Haskell 2010 Report, which disallows deriving any class for a type with no constructors; but see #7401. So, we are entitled to do what we think is best here." rwbarton
7401 33 omeragacan@…, RyanGlScott Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. Compiler 7.6.1 7.12.1 osa1 new normal 2015-07-16T15:03:57Z "On a ""phantom datatype"" D, one gets the message:
{{{
Can't make a derived instance of `Eq D':
`D' must have at least one data constructor
}}}
However there is a trivial, correct instance of Eq D:
{{{
instance Eq D where
(==) = undefined
}}}
" jpbernardy
9968 4 osa1 DeriveAnyClass fails on multi-parameter type classes Compiler 7.10.1-rc1 7.12.1 dreixel new high 2015-07-29T17:58:41Z "When I say
{{{
{-# LANGUAGE DeriveAnyClass, MultiParamTypeClasses #-}
module Bug where
class C a b
data X
deriving (C Int)
}}}
and load that into GHCi, I see this:
{{{
*Main> :load ""/Users/rae/temp/DeriveAny.hs""
[1 of 1] Compiling Bug ( /Users/rae/temp/DeriveAny.hs, interpreted )
Var/Type length mismatch:
[b_a2YW]
[]
Var/Type length mismatch:
[b_a2YW]
[]
Ok, modules loaded: Bug.
*Bug> :info C
class C a b -- Defined at /Users/rae/temp/DeriveAny.hs:5:1
instance C X -- Defined at /Users/rae/temp/DeriveAny.hs:7:13
}}}
It seems my `Int` parameter to `C` is being dropped. I don't believe I have a debug build in this example, so that debugging output is shipping." goldfire
10663 4 osa1 ghci ignores stuff after an import command and a semicolon GHCi 7.10.1 new normal 2015-07-28T21:30:10Z "I can put a semicolon and then an expression or declaration after an import command in ghci, and the expression or declaration is simply ignored.
{{{
rwbarton@morphism:~/ghc$ ghci-7.10.1
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> import Data.List; x
Prelude Data.List>
}}}
The stuff after the semicolon does have to parse, but then is discarded. Pretty confusing.
It's especially confusing when using `ghc -e`
{{{
rwbarton@morphism:~/ghc$ ghc-7.10.1 -e ""import Data.List; sort [2,1]""
rwbarton@morphism:~/ghc$ echo $?
0
}}}
The command is wrong (in general you cannot give multiple commands separated by semicolons, you must use multiple `-e` options), but GHC fails to complain in any way and silently ignores the ""second command""." rwbarton
8673 28 p.k.f.holzenspies@… GHC could generate GADT record selectors in more cases Compiler 7.6.3 new normal 2014-05-17T19:07:18Z "Philip Holzenspies writes (in email to ghc-users): I was playing around with GADT-records again and ran into behaviour that I'm not sure is intentional. Given this program:
{{{
{-#LANGUAGE GADTs #-}
data FooBar x a where
Foo :: { fooBar :: a } -> FooBar Char a
Bar :: { fooBar :: a } -> FooBar Bool a
}}}
GHC tells me this:
{{{
foo.hs:3:1:
Constructors Foo and Bar have a common field `fooBar',
but have different result types
In the data declaration for `FooBar'
Failed, modules loaded: none.
}}}
The user guide does say (section 7.4.7): ""However, for GADTs there is the following additional constraint: every constructor that has a field f must have the same result type (modulo alpha conversion)."" So this behaviour is documented in the user guide. However, it seems reasonable that in the case above, where all the relevant variables are exposed in the result type of both constructors, this should be perfectly typeable.
In other words, shouldn't GHC be able to derive a type that is simply:
{{{
fooBar :: FooBar x a -> a
}}}
?
Is this something that was simply never implemented, but could be, or is this not decidable or prohibitively computationally complex?
" simonpj
8318 20 patrick@… GHC does not infer type of `tagToEnum#` expression Compiler (Type checker) 7.7 new normal 2014-11-19T20:44:06Z "Compiling this program:
{{{
{-# LANGUAGE MagicHash #-}
module TTE where
import GHC.Prim
f = case tagToEnum# 1# of
True -> ""True""
False -> ""False""
}}}
gives a compilation error:
{{{
[1 of 1] Compiling TTE ( tte.hs, tte.o )
tte.hs:6:10:
tagToEnum# must appear applied to one argument
In the expression: tagToEnum# 1#
In the expression:
case tagToEnum# 1# of {
True -> ""True""
False -> ""False"" }
In an equation for ‛f’:
f = case tagToEnum# 1# of {
True -> ""True""
False -> ""False"" }
}}}
To make it work one needs to supply type annotation for `tagToEnum#`: `case tagToEnum# 1# :: Bool of`. I would expect however that type will be inferred from type of patterns in the branches. Although I can imagine that things might get complicated for an ill-typed program:
{{{
f = case tagToEnum# 1# of
True -> ""True""
3 -> ""What now?""
}}}
If it is not possible to infer type of scrutinee based on patterns then I would expect to get more informative error message. Current one - `tagToEnum# must appear applied to one argument` - is very misleading. When I saw it for the first time it took me about 15 minutes to actually figure out what GHC expects me to do." jstolarek
2786 37 patrick@…, me@…, hvr Blackhole loops are not detected and reported in GHCi GHCi 6.8.3 ⊥ new normal 2014-01-08T17:54:28Z "While looking into #2783 I noticed this. It has never worked, and I was vaguely aware of it, but it seems we don't have a ticket.
{{{
let x = x in x
}}}
in GHCi should report `<>`. One issue is that the `interruptTargetThread` global var points to the `ThreadId` running the expression, which will keep it alive and prevent it from being detected as deadlocked. But that's not all: I think the expression itself is being retained by the main thread (perhaps because it is bound to `it`), which will cause the child thread to also stay alive.
" simonmar
6017 27 peter.minten@…, hvr Reading ./.ghci files raises security issues GHCi 7.4.1 7.12.1 new normal 2014-12-23T13:34:10Z "GHCi will execute .ghci files in the current directory, and this can be used to run arbitrary shell commands.
It seems to me that most people would not expect that running ""ghci"" in a directory can cause arbitrary commands to be executed. This could be a security issue, e.g. running ghci in a just downloaded software package with a rouge .ghci file.
Also it affects invocations ""ghc -e"", which conceivably could be used in aliases or scripts for some action unrelated to running a ghci session, as in http://www.joachim-breitner.de/blog/archives/156-Haskell-on-the-Command-Line.html
I just noticed that it will not read files in directories not owned by you and warn you about it (e.g. in /tmp), which is a good start. But this does not help against files in packaged repositories.
Maybe ghci could keep a white-list of files somewhere in ~/.ghci and ask if it should execute a .ghci file that has not been encountered before.
Alternatively (and more work) a safe subset of options (such as inclusion paths) could be identified and only those would be allowed in ./.ghci, while ~/.ghci allows all commands." nomeata
1377 37 phercek@…, mnislaih@… GHCi debugger tasks GHCi 6.7 7.12.1 mnislaih new lowest 2014-12-23T13:33:22Z "I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these.
== easy ==
* Autocompletion for :break only provides names, not modules
== moderate ==
* for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us
show the enclosing binding(s) for each breakpoint in the UI (eg. ""Stopped in M.f (M.hs:40:23-28)"").
* :force should catch exceptions, so [1,2,undefined] would display as `[1,2,< exception >]`
* show variables with unboxed types.
* tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh)
== unknown, or require thinking about ==
* Some kind of ""step over"" or ""next"" command is needed.
* `:break ` only works if the name is exported can/should we relax this?
* perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get
thrown away by :continue)
* We can disable a breakpoint with "":set stop N :continue"", but this still prints out the breakpoint info when we stop.
Should we print the info only if there were no commands?
* Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way.
* Flag to disable breakpoints?
* When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this
be fixed?
* threads and breakpoints.
* if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get
""*** Ignoring breakpoint"").
* It's a bit strange that in ""f = e"" you don't get a breakpoint covering the whole binding, but in ""f x = e"" you do." simonmar
7988 18 pho@… Big integers crashing integer-simple on qnxnto-arm Compiler 7.7 new normal 2013-06-28T08:50:07Z "The following program gives a SIGSEGV when run on qnxnto-arm (my Blackberry Z10 running OS10.1, to be exact) after being compiled by my cross-compiler.
Initial investigation shows that compiling a non-cross-compiler for i486 that uses integer-simple does *not* crash on the same program, so it's not a fundamental issue with integer-simple (unless the bug has been fixed between the version of source my cross-compiler uses and HEAD, which I have not yet tested because I'm not sure how to build HEAD to make a good-style statically-linking-libraries GHC).
{{{
module Main(main) where
main::IO()
main=print 169821641172389640937095636777672117931888945045504182713271897430274187839083732143233634367563316254925040331580602942790529924419031237257992694047545188803054325440702792009735658578224936744314329623399862853427161588994478038000957583036049445212750560294647972107700330648403394932373528288706138101730866129542001812796094504052779945357555018210304989340497464935845180607042646690920787035715174921382511732745931975718868480005317353569848454618331425749699355019762926384123909468814180690222898222556785716853422930906736084397064171894642825018414586574929919999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
}}}" singpolyma
5645 18 pho@… Sharing across functions causing space leak Compiler 7.2.1 7.12.1 Alexander.Pakhomov new normal 2014-12-23T13:34:10Z "I have two test functions in code that both have a lazy list declared like this:
{{{
let elements = [0 .. someBigInt]
}}}
If, from main, I run both of them, the compiler decides to share this list among them. In effect the memory is exhausted.
If only one function is called, the memory used is constant and low.
The workaround is to declare on of them like this:
{{{
let elements = [0] ++ [1 .. someBigInt]
}}}
But this is very ugly.
What worries me most is that this is very non-obvious behaviour: if the list is declared locally inside a function, the compiler shouldn't (?) share it between two functions. It feels wrong.
If one of the functions is declared in different module, this behavior disappears. Seems like CSE is not done across modules boundaries.
Another workaround (tested) is to disable CSE with -fno-cse switch. You can test it works with ""make workaround"". The bug can be tested with ""make bug"".
The compiler behaves this way across the versions. I've tested 6.12.3, 7.0.2, 7.0.3, 7.0.4, 7.2.1, 7.2.2.
My platform should be irrelevant, but for the sake of completeness:
{{{
Linux raptor 3.1.0-4-ARCH #1 SMP PREEMPT Mon Nov 7 22:47:18 CET 2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel GNU/Linux
}}}
The code for reproducing is attached. Again, run it with ""make bug"" or simply ""make"".
I'm experimenting with high-performance FIFO queues. The implementation attached is quite potent, capable of processing 40M messages / second on my machine in one-producer one-consumer case." tener
7373 18 pho@… When building GHC: Failed to load interface for `GHC.Fingerprint' Driver 7.6.1 7.12.1 new normal 2015-02-22T12:28:39Z "when doing a build with THREADS=1, we are getting
things like:
{{{
inplace/bin/ghc-stage1 [...] -c libraries/time/./Data/Time/Calendar/Days.hs [...]
/home/ian/ghc/git/ghc/libraries/base/dist-install/build/Data/Typeable/Internal.dyn_hi
Declaration for mkTyConApp
Unfolding of Data.Typeable.Internal.mkTyConApp:
Failed to load interface for `GHC.Fingerprint'
Perhaps you haven't installed the ""dyn"" libraries for package `base'?
Use -v to see a list of the files searched for.
/home/ian/ghc/git/ghc/libraries/base/dist-install/build/Data/Typeable.dyn_hi
Declaration for mkTyCon
Unfolding of Data.Typeable.mkTyCon:
Can't find interface-file declaration for variable GHC.Fingerprint.fingerprintString
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
}}}
(we only have Fingerprint.dyn_hi-boot). GHC still exits successfully, however.
" igloo
4374 18 pho@… Remove in-tree gmp Build System 7.1 7.12.1 new normal 2014-12-23T13:34:10Z "We already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.
I'm assuming installing GMP on other non-Windows OSes is not painful. We probably want to point to a framework for OS X users to use.
" igloo
2031 18 pho@… relocation overflow Compiler 6.8.2 ⊥ new normal 2009-12-15T08:05:40Z "I've created a statically linked ghc-6.8.2 for PPC Mac OS 10.4 (Tiger).
http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin-static-libs.tar.bz2
When linking our big hets binary after compilation with optimization I get millions (actually 34999 lines) of entries like:
{{{
/usr/bin/ld: PGIP/XMLparsing.o relocation overflow for relocation entry 63 in section (__TEXT,__text) (displacement too large)
...
/usr/bin/ld: SoftFOL/Sign.o relocation overflow for relocation entry 45280 in section (__TEXT,__text) (displacement too large)
collect2: ld returned 1 exit status
make: *** [hets] Error 1
}}}
I had such messages before and got rid of them by rearranging code and imports (just by wild guesses, a strategy would be helpful). It is sort of a known (Apple PPC) deficiency (and I misuse this ticket to document it here).
Linking works fine after compilation without optimization or when linking against GMP and GNUreadline frameworks using my other binary distribution.
" maeder
750 18 pho@… Set -M, -H, -c and other memory-related values based on available virtual/physical memory Runtime System 6.4.1 ⊥ new normal 2013-09-27T13:09:24Z "From John Meacham:
perhaps if `-M` is not otherwise set, {{{getrlimit(RLIMIT_AS,..)}}} could be
called and the maximum heap size set to just under that, since it is the
point that the OS will forcefully kill the program anyway.
Ravi Nanavati would like to be able to set the value to a percentage of physical RAM, e.g. `prog +RTS -H256m -M95% -RTS'.
Bulat Ziganshin would like to be able to do the same with `-c`." simonmar
881 18 pho@… Improve space profiling for references Profiling 6.4.2 ⊥ new normal 2013-02-22T10:19:31Z "GHC's great space profiling tools don't appear to be much help when your
leaked memory is stored in references (IORefs, StablePtrs, etc). I had
a real-life case where the allocation profile showed me where the leaked
data came from, and I could guess that it was being held by some
reference, but I couldn't tell which one. Retainer set profiling showed
a big suspicious entry for ""SYSTEM"", but I couldn't find any way to
pinpoint the problem. (It ended up being a missing freeStablePtr in
hsgnutls, found by code inspection.)
Here's a contrived example that just allocates a bunch of IORefs:
{{{
import Control.Monad
import Data.IORef
main = repeatM (newIORef [1,2,3])
repeatM io = liftM2 (:) io (repeatM io)
}}}
Retainer set profiling shows everything in ""SYSTEM"". None of the other
profiling methods say anything interesting either. What I'd like to
get, I think, is (1) your memory is being held in IORefs (2) allocated
by this cost center and (3) being retained by this cost center. I guess
I'm looking for something like a memory profiler for a traditional
language.
Andrew Pimlott
Simon Marlow comments: ""The relevant predicate ""is retainer"" is pretty much built into the retainer profiler, and it returns true only for thunks if I recall correctly. Being able to tweak this, or maybe just install a better default would be an improvement." simonpj
2708 18 pho@… Error message should suggest UnboxedTuples language extension Compiler (Parser) 6.9 ⊥ new low 2008-11-28T04:14:40Z "If I compile this code:
{{{
module Foo where
import GHC.Integer
foo x y =
case x `quotRemInteger` y of
(# y, z #) -> 42
}}}
I get:
{{{
foo.hs:7:5: Parse error in pattern
}}}
It would be better if the error message suggested using {{{-XUnboxedTuples}}}." tim
2370 18 pho@… num009 fails on OS X 10.5? Compiler 6.9 7.12.1 new lowest 2014-12-23T13:33:22Z "Running on an 8-core system based on Xeon 5400s.
Full error:
{{{
=====> num009(threaded2)
cd . && '/Users/mbolingbroke/Programming/Checkouts/ghc.working/compiler/stage2/ghc-inplace' -fforce-recomp -dcore-lint -dcmm-lint -Di386_apple_darwin -dno-debug-output -o num009 num009.hs -O -threaded >num009.comp.stderr 2>&1
cd . && ./num009 +RTS -N2 -RTS num009.run.stdout 2>num009.run.stderr
Actual stdout output differs from expected:
--- ./num009.stdout.normalised 2008-06-17 09:55:40.000000000 +0100
+++ ./num009.run.stdout.normalised 2008-06-17 09:55:40.000000000 +0100
@@ -1 +1,31 @@
+sind
+-0.6452512852657808
+-0.7469218912594929
+(-5811906895766608,-53)
+(-6727674302302237,-53)
+sinf
+0.6565767
+-0.7710884
+(11015529,-24)
+(-12936717,-24)
+cosd
+0.7639704044417284
+-0.6649117899070088
+(6881233657531710,-53)
+(-5988992978518909,-53)
+cosf
+0.7542593
+0.63672805
+(12654371,-24)
+(10682524,-24)
+tand
+-0.8446024630198841
+1.123339821307656
+(-7607502675465106,-53)
+(5059072800651599,-52)
+tanf
+0.87049204
+-1.2110169
+(14604433,-24)
+(-10158746,-23)
Done
*** unexpected failure for num009(threaded2)
}}}" batterseapower
7651 72 pho@…, andreas.voellmy@…, george.colpitts@… Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD) Build System 7.7 7.12.1 new high 2015-07-03T22:46:27Z "Building GHC with parallel IO manager on Mac freezes when
compiling the dph libraries in the phase 2.
We '''suspect this is due to a bug in the OS X implementation of kqueue''', for the reasons given below. In the meantime, we have added an extra IO manager wakeup that appears to work around the problem; see `GHC/Event/Manager.hs`.
Details:
* This happens only if we specify ""-j"" to ""make"". Note that ""make"" closes stdin of sub-processes if ""-j"" is specified.
* Even if we specify ""-j"" to ""make"", the problem disappears with stdout/stderr redirection. That is, ""make -jN >& LOG &"" works.
* The ""-d"" option of ""make"" does not make any effects.
* Programs compiled with built GHC (with our patches) work well. For test, I compiled a daemon HTTP server which closes stdin/stdout/stderr. It worked well.
An IO manager is polling a kqueue fd. Another Haskell thread on
another native thread registers an event through the same kqueue
fd. In many cases, this works on Mac. In a certain situation,
MacOS does not deliver an event to the IO manager. If the IO
manager gets up and polls the kqueue fd, the event is delivered.
This bug only appears when building GHC on Mac. I cannot find a
simple way to reproduce it. Even if we find a way to reproduce
it, I guess that we will probably reach a conclusion that this is
a bug of kqueue of Mac.
I have some evidences that kqueue of Mac is buggy:
* http://comments.gmane.org/gmane.comp.lib.ev/1871
* http://lists.apple.com/archives/darwin-dev/2011/Jun/msg00016.html
" kazu-yamamoto
5966 56 pho@…, core-libraries-committee@… getAppUserDataDirectory does not respect XDG specification Core Libraries 7.4.1 7.12.1 ekmett upstream normal 2014-12-06T12:12:26Z "getAppUserDataDirectory function from System.Directory module returns path to a dot-dir under home directory. This swamps home with many hidden directories, when there are many applications installed. There is [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html XDG specification] for this situation, which suggests using $XDG_DATA_HOME environment variable.
So, getAppUserDataDirectory should behave approximately like this when $XDG_DATA_HOME is set:
{{{
getAppUserDataDirectory appName = do
path : hPutChar: invalid argument (invalid character)
}}}
unicode.hs:
{{{
module Foo where
δ x = 3
δ x = 4
}}}" akio
6166 53 pho@…, dima@…, bgamari@… Performance regression in mwc-random since 7.0.x Compiler 7.4.2 7.12.1 new normal 2014-12-23T13:34:10Z "I've had a report that the performance of the mwc-random package has regressed seriously after upgrading from GHC 7.0 to 7.4. It turns out that 7.2 also has the regression.
Here's a sample program.
{{{
import qualified Data.Vector.Unboxed as U
import qualified System.Random.MWC as R
import System.Random.MWC.Distributions (standard)
count = 1000 * 1000
fast gen = standard gen
slow gen = standard gen >>= return
-- Edit this to choose fast or slow.
which gen = slow gen
main = do
gen ffi009(ghci)
cd ./ffi/should_run && '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 98633 Illegal instruction '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 132 )
Stdout:
Testing 5 Int arguments...
True
True
True
True
True
True
True
True
True
True
Testing 11 Double arguments...
Stderr:
*** unexpected failure for ffi009(ghci)
}}}
An extract from the so-called crash report indicates a jump into the wild:
{{{
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000002, 0x00000000027ffd04
Crashed Thread: 2
...
Thread 2 Crashed:
0 ??? 0x027ffd04 0 + 41942276
1 ghc 0x012da320 setThreadLocalVar + 16
2 ghc 0x012fa87c ffi_call_DARWIN + 204 (darwin.S:131)
3 ghc 0x012fa3a0 ffi_call + 208 (ffi_darwin.c:457)
4 ghc 0x012cacb8 interpretBCO + 4984
5 ghc 0x012d46d0 schedule + 1024
6 ghc 0x012d4d84 workerStart + 84
7 libSystem.B.dylib 0x9292f658 _pthread_start + 316
}}}
When the test is run with a ghc built with {{{GhcDebugged=YES}}} (see http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking and {{{mk/config.mk}}}), an assertion failure is reported instead:
{{{
=====> ffi009(ghci)
cd . && '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 43988 Abort trap '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 134 )
Stdout:
Stderr:
ffi009: internal error: ASSERTION FAILED: file Linker.c, line 4380
(GHC version 6.11.20081121 for powerpc_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
*** unexpected failure for ffi009(ghci)
}}}
The assertion failure is reported from this context in {{{Linker.c}}}:
{{{
if(reloc->r_pcrel)
{
#ifdef powerpc_HOST_ARCH
// In the .o file, this should be a relative jump to NULL
// and we'll change it to a relative jump to the symbol
ASSERT(word + reloc->r_address == 0);
jumpIsland = (unsigned long)
&makeSymbolExtra(oc,
reloc->r_symbolnum,
(unsigned long) symbolAddress)
-> jumpIsland;
if(jumpIsland != 0)
{
offsetToJumpIsland = word + jumpIsland
- (((long)image) + sect->offset - sect->addr);
}
#endif
word += (unsigned long) symbolAddress
- (((long)image) + sect->offset - sect->addr);
}
}}}
The relocations leading to the assertion failure are required by branch instructions generated by {{{gcc}}} for {{{ffi009_stub.c}}} that contains expressions of the form {{{symbol+constant}}} (where {{{symbol}}} is an external symbol) whose distance to the instruction needs to be packed into a 24-bit field. An example is
{{{
bl saveFP+56 ; save f28-f31
}}}
and there are actually 4 cases like this in the code generated by {{{gcc}}} for {{{ffi009_stub.c}}}.
This problem does not appear particularly easy to solve: The mechanism used when such a branch needs to address code that cannot be addressed using a 24-bit relative address is to create so-called jump islands, which are small, close-by pieces of code that (hopefully, but see #1845) *can* be reached using 24-bit relative addressing. The branch is changed to address the jump island which, in turn, constructs the actual 32-bit address and branches to it. Currently, however, this mechanism, for the PPC Mac OS X architecture, is limited to a single jump island per external symbol and is not capable of handling the addressing of external symbols with constants added to them. Handling the adding of a constant is doable, I believe, but the problem is that the same external symbol may appear multiple times with different constants added. For example, in addition to the above case, the code for {{{ffi009_stub.c}}} also includes
{{{
bl saveFP+28 ; save f21-f31
}}}
which would require creating two jump islands for the single symbol {{{saveFP}}}.
Possible solutions:
1. Make a special case out of the specific symbols concerned here. This would involve creating a limited list of different jump islands for these symbols, to be used when different constants were added.
1. Generalize, somehow, the present jump island mechanism to allow more flexibility. It is undoubtably possible to do this, but it does not seem to be particularly easy to do.
1. The {{{-mlongjump}}} option actually causes {{{gcc}}} to replace the critical relative brach instructions by inline code, at the expense of generating longer and potentially slower code for all calls and possibly other branches as well. And if we try this, we get:
{{{
ffi009: internal error:
unknown relocation 13
(GHC version 6.11.20081121 for powerpc_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
(relocation type 13 is PPC_RELOC_JBSR) so Linker.c needs to be extended to handle this type also.
Any advice on how to proceed in this matter, additional ideas and views, would be most welcome.
Best regards
Thorkil" thorkilnaur
5902 84 pho@…, exbb2@…, idhameed@…, hackage.haskell.org@… Cannot tell from an exception handler whether the exception was asynchronous Compiler 7.4.1 7.12.1 simonmar new normal 2014-12-23T13:34:10Z "Following on from #2558 which was closed (by me) as wontfix, we still don't have a way to reliably tell whether an exception we caught was asynchronous or not. There are some suggestions in #2558, we just need to implement something. The fix for #3997 was defficient due to this, as exposed by the test program in #5866.
" simonmar
5928 103 pho@…, fox@…, hackage.haskell.org@…, tkn.akio@…, ecrockett0@… INLINABLE fails to specialize in presence of simple wrapper Compiler 7.4.1 7.12.1 new normal 2014-12-23T13:34:10Z "If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.)
Here's an example where it fails. First, the simple wrapper module:
{{{
module Repro where
import Data.Hashable
import Data.HashMap.Strict as M
infixl 9 !
(!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b
m ! x = case M.lookup x m of -- lookup is INLINABLE
Just y -> y
Nothing -> error ""Repro.!""
}}}
and then the call site:
{{{
module Test (test) where
import Data.HashMap.Strict as M
import Repro
test :: M.HashMap Int Int -> Int
test m = m ! 42
}}}
To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered-containers is:
{{{
lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v
lookup k0 = go h0 k0 0
where
h0 = hash k0
go !_ !_ !_ Empty = Nothing
go h k _ (Leaf hx (L kx x))
| h == hx && k == kx = Just x
| otherwise = Nothing
go h k s (BitmapIndexed b v)
| b .&. m == 0 = Nothing
| otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m))
where m = mask h s
go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s))
go h k _ (Collision hx v)
| h == hx = lookupInArray k v
| otherwise = Nothing
#if __GLASGOW_HASKELL__ >= 700
{-# INLINABLE lookup #-}
#endif
}}}
If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that.
The core for `Repro` and `Test` is:
{{{
$ ghc -O2 Test.hs -fforce-recomp -ddump-simpl
[1 of 2] Compiling Repro ( Repro.hs, Repro.o )
==================== Tidy Core ====================
Result size = 28
lvl_rNZ :: [GHC.Types.Char]
[GblId]
lvl_rNZ = GHC.CString.unpackCString# ""Repro.!""
Repro.!1 :: forall b_aBU. b_aBU
[GblId, Str=DmdType b]
Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ
Repro.!
:: forall a_atJ b_atK.
(GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) =>
Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK
[GblId,
Arity=4,
Str=DmdType LLLL,
Unf=Unf{Src=, TopLvl=True, Arity=4, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0 0 0 0] 70 0}]
Repro.! =
\ (@ a_aBT)
(@ b_aBU)
($dEq_aBV :: GHC.Classes.Eq a_aBT)
($dHashable_aBW :: Data.Hashable.Hashable a_aBT)
(m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU)
(x_atM :: a_aBT) ->
case Data.HashMap.Base.lookup
@ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL
of _ {
Data.Maybe.Nothing -> Repro.!1 @ b_aBU;
Data.Maybe.Just y_atN -> y_atN
}
[2 of 2] Compiling Test ( Test.hs, Test.o )
==================== Tidy Core ====================
Result size = 20
Test.test2 :: GHC.Types.Int
[GblId,
Caf=NoCafRefs,
Str=DmdType m,
Unf=Unf{Src=, TopLvl=True, Arity=0, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [] 10 110}]
Test.test2 = GHC.Types.I# 42
Test.test1
:: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int
-> Data.Maybe.Maybe GHC.Types.Int
[GblId,
Unf=Unf{Src=, TopLvl=True, Arity=0, Value=False,
ConLike=False, Cheap=False, Expandable=False,
Guidance=IF_ARGS [] 40 0}]
Test.test1 =
Data.HashMap.Base.lookup
@ GHC.Types.Int
@ GHC.Types.Int
GHC.Classes.$fEqInt
Data.Hashable.$fHashableInt
Test.test2
Test.test
:: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int
-> GHC.Types.Int
[GblId,
Arity=1,
Str=DmdType L,
Unf=Unf{Src=, TopLvl=True, Arity=1, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0] 40 0}]
Test.test =
\ (m_aPx
:: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) ->
case Test.test1 m_aPx of _ {
Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int;
Data.Maybe.Just y_atN -> y_atN
}
}}}
" tibbe
7611 49 pho@…, hackage.haskell.org@… Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) Compiler 7.6.2 7.12.1 new normal 2014-12-23T13:34:10Z "I’m moving the discussion from
http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023522.html (with reply at http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023531.html) here, as a reminder for myself to work on it someday:
Short summary: a rule ""map (\x -> x) = id"" will not match ""map id"" because the latter has (in Core) an application of a type variable, despite the matcher looking through the definition of id. Doing beta-reduction (of type applications) in the matcher could fix this.
I’ll attach a test case." nomeata
2648 59 pho@…, hackage.haskell.org@…, hvr, asr Report out of date interface files robustly GHCi 7.6.3 7.12.1 new lowest 2015-06-11T13:16:36Z "Suppose `X.hi` refers to `Y.f77`, but `Y.hi` is out of date and has no `f77`. Then you get a bad crash:
{{{
(GHC version 6.8.3 for i386-unknown-mingw32):
tcIfaceGlobal (local): not found:
Please report this as a GHC bug
}}}
The solution lies within our grasp:
* X.hi already contains a fingerprint for Y.hi
* So, we should simply check Y.hi's fingerprint when we suck it in
(Currently we do this fingerprint checking only for the module we are currently compiling, to see if the bits it depends on have changed.)
Simon" simonpj
7378 80 pho@…, hackage.haskell.org@…, tom.schrijvers@… Identical alts/bad divInt# code Compiler 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "[http://stackoverflow.com/questions/13139875/removing-case-with-duplicate-branches-from-haskells-core This] may be the same as #7360, but it may also be a problem in the code generation for `divInt#`. I've reduced it to the following minimal test case:
When compiling
{{{
fun :: Int -> Int
fun i = i `div` 2
}}}
with `ghc -O2 -funfolding-use-threshold=150`, the generated core becomes
{{{
Div2.fun =
\ (i_aeH :: GHC.Types.Int) ->
case i_aeH of _ { GHC.Types.I# ww_aiV ->
case GHC.Prim.># ww_aiV 0 of _ {
GHC.Types.False ->
case GHC.Prim. GHC.Types.I# (GHC.Prim.quotInt# ww_aiV 2);
GHC.Types.True ->
GHC.Types.I#
(GHC.Prim.-# (GHC.Prim.quotInt# (GHC.Prim.+# ww_aiV 1) 2) 1)
};
GHC.Types.True ->
case GHC.Prim. GHC.Types.I# (GHC.Prim.quotInt# ww_aiV 2);
GHC.Types.True ->
GHC.Types.I#
(GHC.Prim.-# (GHC.Prim.quotInt# (GHC.Prim.+# ww_aiV 1) 2) 1)
}
}
}
}}}
with two identical `case` alternatives, and in the `True` case, the next comparison is guaranteed to return `False`.
The generated core is good if the divisor is negative, though, so that speaks for taking a look at `divInt#`." daniel.is.fischer
7388 23 pho@…, hvr CAPI doesn't work with ghci GHCi 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "{{{
$ ghc -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history T4012 --interactive -ignore-dot-ghci
GHCi, version 7.7.20121101: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 3] Compiling T4012_B ( T4012_B.hs, interpreted )
ByteCodeLink: can't find label
During interactive linking, GHCi couldn't find the following symbol:
ghczuwrapperZC0ZCmainZCT4012zuBZCprintf
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
>
}}}
" igloo
849 199 pho@…, johan.tibell@…, claus, daniel.is.fischer@…, michal.terepeta@…, ikke+ghc@…, buecking@…, hackage.haskell.org@…, jan.stolarek@… Offer control over branch prediction Compiler 6.4.2 7.12.1 new normal 2014-12-23T13:34:10Z "So now that GHC is so good at producing really fast low level code (see
ByteString benchmarks) we start to encounter low level gubbins where to
get the fastest possible code we need slightly more influence over
branch prediction.
In the code for ByteString's 'writeStrUp/Dn' functions we're doing a
tight loop writing bytes to memory.
The first version looks much like this:
{{{
loop fp n off s = case next s of
Done -> return $! PS fp 0 off
Skip s' -> loop fp n off s'
Yield x s' -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
}}}
When we get to the end of a memory block we need to double the size of
the memory block and carry on. So this adds an additional conditional
test into this loop.
{{{
loop fp n off s = case next s of
Done -> trimUp fp n off
Skip s' -> loop fp n off s'
Yield x s'
| n == off -> realloc fp n off s' x
| otherwise -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
}}}
There are dramatic differences between equivalent forms of code. Just by
reversing the order of the (n==off) test one form I can process 50Mb of
data in 0.20 seconds and in the other it takes 0.34 seconds.
That is:
{{{
| n == off -> realloc fp n off s' x
| otherwise -> do ...
}}}
vs
{{{
| n /= off -> do ...
| otherwise -> realloc fp n off s' x
}}}
I think that this is all down to branch prediction and the arrangement
of basic blocks. On a modern CPU correctly predicted branches are nearly
free while mis-predicted branches are very costly due to stalled
pipelines etc.
In gcc they have a branch prediction framework. It annotates
conditionals with prediction information. It then uses that during code
generation to do things like arranging basic blocks so that unlikely
blocks are moved out of line. It gets the prediction information from a
few sources. One is a simple static branch predictor, for example
branches back to to the beginning of a loop are likely to be taken and
branches to error functions are not. gcc even has a profile feedback
system to find the real probabilities of branches from a sample run of
the program. It also has a user annotation {{{__builtin_expect()}}} which many
C projects use in the form of a macro:
{{{
if (unlikely(x==0)) { ...
}}}
The Linux kernel uses this fairly heavily to move error handling code
out of the main 'fast path' code.
Anyway, so what I wish is that I could write something like:
{{{
loop fp n off s = case next s of
Done -> {-# UNLIKELY #-}
trimUp fp n off
Skip s' -> loop fp n off s'
Yield x s'
| n == off -> {-# UNLIKELY #-}
realloc fp n off s' x
| otherwise -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
}}}
The best approximating effect that I can use at the moment is to make
the unlikely realloc branch a local function in a where clause but mark
it with {{{ {-# NOINLINE #-} }}} so that the code for the realloc case doesn't
pollute the tight loop for the normal fast case. Then the other
approximation is fiddling with the logic of the binary test and looking
at the benchmarks. The combination of these two techniques makes a
dramatic difference to the speed.
However I do need more control to do it reliably, while I was able to
make it work for writeStrUp, I could not find a combination to work for
writeStrDn - we loose about 50% performance when we add the realloc
branch. So a slightly more reliable method to hint at the likelihood of
conditionals would make this kind of low level code faster and easier to
write.
Some time ago as a quick hack I did add a branch prediction annotation
to the CMM conditional constructor. I only used it in the C backend to
turn it into uses of gcc's {{{__builtin_expect()}}}. I also didn't connect it
to the front end so I didn't have any high level static branch
prediction (which could be done by looking for branches with recursive
calls or calls to error etc). The only place I did actually use it was
in the heap check and stack check. I assumed that it would be
advantageous to predict heap and stack overflow branches as not taken.
It was only a quick hack - I didn't do any benchmarks to see if it had
any effect.
Anyway, just a thought, and of course not something we should be
thinking about 'til post 6.6.
Duncan" simonpj
2600 44 pho@…, mail@… Bind type variables in RULES Compiler 6.8.3 7.12.1 simonpj new lowest 2014-12-23T13:33:22Z "Roman writes: here's an example I came across while working on the recycling paper
and which I subsequently forgot about. Suppose we have:
{{{
{-# LANGUAGE Rank2Types #-}
module T where
class T t where
to :: [a] -> t a
from :: t a -> [a]
tmap :: (a -> a) -> t a -> t a
{-# RULES
""myrule"" forall f x.
from (tmap f (to x)) = map f (from (to x))
#-}
}}}
Alas, this fails with:
{{{
Ambiguous type variable `t' in the constraint:
`T t' arising from a use of `to' at T.hs:12:40-43
Probable fix: add a type signature that fixes these type variable(s)
}}}
Of course, I'd like the t on the rhs to be the same as on the lhs but
I don't see how to tell this to GHC. Is it actually possible? The only
solution I've found was to add a dummy argument to 'to':
{{{
to' :: t a -> [a] -> t a
to = to' undefined
{-# RULES
""myrule"" forall f t x.
from (tmap f (to' t x)) = map f (from (to' t x))
#-}
}}}
That's ugly, of course. Am I missing something or is this just
impossible to do with the current system?
" simonpj
1600 65 pho@…, mail@…, maoe@…, akio Optimisation: CPR the results of IO Compiler 6.6.1 7.12.1 new lowest 2015-08-02T07:21:25Z "GHC currently cannot unbox the result of a function in the IO monad. For example:
{{{
facIO :: Int -> IO Int
facIO n = if n < 2 then return 1 else do n' Float -- ^ The 'Float' argument
-> IO () -- ^ The return value
}}}
A possible API for reifying comments would be
{{{
reifyDocs :: Name -> (Maybe String, Maybe [String]) -- documentation string; documentation for individual arguments
}}}
Reiner" reinerp
7831 59 pho@…, the.dead.shall.rise@…, simonmar Bad fragmentation when allocating many large objects Runtime System 7.7 ⊥ ezyang new low 2014-07-21T13:15:37Z "Consider our good old friend, the space-leaky list program:
{{{
import Control.Exception
import System.Environment
f n = let xs = [1..n] in sum xs * product xs
main = do
[n] Int -> Int
{-# INLINE idx #-}
idx a (I# i) = case readIntOffAddr# a i realWorld# of (# _, y #) -> I# y
f :: Int -> Int -> Int
{-# INLINE f #-}
f x y = y + x
foo :: Addr# -> Int -> Int
foo a n = n `seq` loop (idx a 0) 1
where
loop x i = case i >= n of
False -> loop (f x (idx a i)) (i+1)
True -> x
}}}
GHC infers the demand `LU(L)` for `loop`, only unboxes the second argument, ultimately generates a loop of type `Int -> Int# -> Int` and always allocates a thunk for the first argument:
{{{
$wloop_si9 [Occ=LoopBreaker] :: Int -> Int# -> Int
[LclId, Arity=2, Str=DmdType LL]
$wloop_si9 =
\ (w1_shU :: Int) (ww1_shX :: Int#) ->
case >=# ww1_shX ww_si5 of _ {
False ->
$wloop_si9
(case readIntOffAddr# @ RealWorld w_si2 ww1_shX realWorld#
of _ { (# _, y_a9S #) ->
case w1_shU of _ { I# y1_ahb -> I# (+# y_a9S y1_ahb) }
})
(+# ww1_shX 1);
True -> w1_shU
}; }
}}}
But if I change the pragma on `f` from `INLINE` to `NOINLINE`, `loop` gets the demand `U(L)U(L)m` and GHC manages to unbox both arguments as well as the result, producing a nice tight loop:
{{{
$wloop_sii [Occ=LoopBreaker] :: Int# -> Int# -> Int#
[LclId, Arity=2, Str=DmdType LL]
$wloop_sii =
\ (ww1_shW :: Int#) (ww2_si0 :: Int#) ->
case >=# ww2_si0 ww_sib of _ {
False ->
case readIntOffAddr# @ RealWorld w_si8 ww2_si0 realWorld#
of _ { (# _, y1_Xac #) ->
case f (I# ww1_shW) (I# y1_Xac) of _ { I# ww3_Xin ->
$wloop_sii ww3_Xin (+# ww2_si0 1)
}
};
True -> ww1_shW
}; }
}}}
It would be nice if this happened in both cases." rl
5289 296 pho@…, v.dijk.bas@…, vandijk.roel@…, ivan.stojic@…, howard_b_golden@…, echo@…, hartmut0407@…, rian@…, wren@…, leather@…, tim@…, hvr, idhameed@…, ryan.gl.scott@… Can't use ghci with a library linked against libstdc++ GHCi 7.0.3 7.12.1 new normal 2014-12-23T13:34:10Z "My `double-conversion` library links to a C++ library. If I build it and try to use it from `ghci`, I get a failure:
{{{
Prelude Data.Double.Conversion.Text Data.Text> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text>
Leaving GHCi.
~ $ ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... can't load .so/.DLL for: stdc++ (libstdc++.so: cannot open shared object file: No such file or directory)
}}}
I can sort of work around this, but then I get a different crash:
{{{
~ $ ln -s /usr/lib64/libstdc++.so.6 libstdc++.so
~ $ LD_LIBRARY_PATH=$(pwd) ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... linking ... done.
""Floating point exception (core dumped)
}}}
Unfortunately, `gdb` doesn't give me a useful stack trace from this :-(" bos
781 108 pho@…, vandijk.roel@…, anton.nik@…, dterei, lewurm@…, jims@… GHCi on x86_64, cannot link to static data in shared libs Compiler 6.5 7.12.1 new high 2015-01-19T14:54:16Z "System.Posix.getEnvironment fails on Linux 2.6.16-1.2108_FC4smp
with a segfault. (x86_64)
{{{
[aleator@thoth HopenCV]$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.5.20060527, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :m +System.Posix.Env
Prelude System.Posix.Env> getEnv ""USER""
Loading package unix-1.0 ... linking ... done.
Just ""aleator""
Prelude System.Posix.Env> getEnvironment
Segmentation fault
}}}" guest
4899 22 ppremont@… "Non-standard compile plus Template Haskell produces spurious ""unknown symbol"" linker error" Compiler 7.0.1 7.12.1 simonmar new low 2014-12-23T13:33:45Z "Programs that use Template Haskell fail to link when doing a ""non-standard"" compile. Specifically, compilations with -prof and -dynamic produce this bug, although other flags may as well; it seems that compilations that require the two-stage -osuf flag produce this bug. The error message is always ""unknown symbol"" but the specific symbol that is allegedly missing varies. Removing the TH block from the code makes the problem go away.
I've provided a minimal example of a program that can reproduce this bug, in the enclosed files Bug1.hs and Main.hs. A typescript demonstrating the error message is also included.
Tested on GHC 7.0.1 and 6.12.1, running under Ubuntu 10.04, both 64-bit and 32-bit. Also tested with 6.12.3 under 32-bit Windows 7." jepst
917 119 prokhorenkov@…, pho@…, mail@…, ezyang@…, rwbarton@…, pivo@… -O introduces space leak Compiler 6.5 ⊥ new lowest 2014-04-27T16:20:37Z "consider the following variant of a popular space problem
{{{
initlast :: (()->[a]) -> ([a], a)
initlast xs = (init (xs ()), last (xs ()))
main = print $ case initlast (\()->[0..1000000000]) of
(init, last) -> (length init, last)
}}}
the long list has been wrapped in abstractions to avoid
sharing, gaining constant space processing rather than
the space leak in the original code - see
http://www.haskell.org/pipermail/haskell-cafe/2006-September/018447.html
http://www.haskell.org/pipermail/haskell-cafe/2006-September/018464.html
this works nicely if compiled without -O, but unfortunately,
-O reintroduces the space leak (apparently lifting and sharing
the common and space-expensive subexpression).
1. I didn't see a ticket for this issue, so I wanted to record the example
2. avoiding sharing isn't always possible, so it would be nice if one could
""bypass"" sharing in such cases. in the old g-machine, that might have
been as simple as introducing a pragma that tells the compiler to omit
the update after the eval in the code for some subexpression (so the
original application node would not be overwritten by the space-expensive
result, trading time for space). is there a chance for a similar trick
in GHC? so one might write code like this (handwaving:-):
{{{
initlast :: [a] -> ([a], a)
initlast xs = (init ({-# COPY #-} xs), last ({-# COPY #-} xs))
main = print $ case initlast [0..1000000000] of
(init, last) -> (length init, last)
}}}" claus.reinke@…
3353 96 proppy@…, barsoap@…, hackage.haskell.org@…, the.dead.shall.rise@… Add CLDouble support Compiler 6.12.1 ⊥ new normal 2013-08-22T22:24:30Z "The FFI spec says that we should support `CLDouble`, but we don't (#2793).
" igloo
10343 62 Ptharien's, Flame, oerjan, shachaf, int-e, dterei, RyanGlScott Make Typeable track kind information better Compiler 7.10.1 7.12.1 goldfire new normal 2015-05-30T21:13:29Z "(EDIT: My long rambling seems to have been confusing, so a summary:
I think that the type inference and runtime representation should support constructing `Typeable (T :: k)`, even when `k` contains kind variables that are only mentioned in other `Typeable` constraints not necessarily involving the type constructor `T`. This will allow simple composition with polymorphic type constructors like `Proxy` and `Typeable` to work more naturally, but also more complicated things.)
With all the apparent exploitable bugs now fixed, #9858 seems to be settling down. Simon P.J. asked me to make a new ticket for some quibbles I still have with limitations of the new design. These started with some examples that I discussed there pre-implementation with Richard Eisenberg, and which he concluded could be supported by a ""sufficently smart solver"".
In the new (current) design, a `TypeRep` ''does'' contain kind information, which as I understand it is a list of `KindRep`s for the explicit kind parameters applied to the type constructor after type inference. This is sufficient to prevent confusing the same type constructor used at different kinds, and also easily supports type application ''provided'' the `TypeRep`s of the parts are known. For this, the internal `Typeable` constraint solver only ever needs to combine `TypeRep`s, never decompose them.
Since no one else complained in #9858, I assume this is enough for what people are currently using `Typeable` for. However:
I think the current `TypeRep` representation for `Typeable (a :: k)` doesn't contain enough information to generally extract the `KindRep` for `k` itself, much less to decompose it, even if the internal `Typeable` solver were to try. This prevents some polykinded code that is intuitively sound, and which ""worked"" in the old system, although if only because it didn't try to track kinds at all.
For example, the following expression, with `PolyKinds` enabled:
{{{#!hs
typeOf :: Typeable a => Proxy a -> TypeRep
}}}
In the old system, this worked simply by combining the `TypeRep` for `Proxy` with the `TypeRep` for `a`. But in the new system, it fails, because the `TypeRep` for `Proxy` needs to know the kind of `a`, which is neither statically known nor available from the `TypeRep` of `a`. You would need to have compile-time information about the type constructor of `a` to even know how to build the `KindRep` from the kind arguments.
This problem with constructing `TypeRep`s would arise whenever a polykinded type constructor is applied to a type whose kind is not a known monomorphic one. The second similar one I can think of is
{{{#!hs
typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep
}}}
In an ideal system, we can also find use cases that require not just extracting the `KindRep` for a type, but also decomposing it. Here is my very hypothetical kitchen sink example from [comment:46:ticket:9858] (this example was made up as a test case before I knew what the new solver would support):
{{{#!hs
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE AutoDeriveTypeable #-}
import Data.Typeable
newtype C a b = C ()
step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *)
step Proxy = Proxy
nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep
nest 0 x = typeRep x
nest n x = nest (n-1) (step x)
main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *))
}}}
Here, to make this compile, the solver would need to derive `Typeable (C a :: [k -> *] -> *]` from `Typeable (a :: [k] -> *)`, which at runtime requires first extracting the `KindRep` of `k` from the `TypeRep` of `a`, and then building the `TypeRep` for the correctly kinded `C`. At least the former part seems essentially impossible with the current `TypeRep` representation, even with a more clever solver.
" oerjan
4308 20 pumpkingod@… LLVM compiles Updates.cmm badly Compiler (LLVM) 6.13 7.12.1 new low 2014-12-23T13:33:45Z "Simon M. reported that compiled rts/Updates.cmm on x86-64 with the LLVM backend produced some pretty bad code. The ncg produces this:
{{{
stg_upd_frame_info:
.Lco:
movq 8(%rbp),%rax
addq $16,%rbp
movq %rbx,8(%rax)
movq $stg_BLACKHOLE_info,0(%rax)
movq %rax,%rcx
andq $-1048576,%rcx
movq %rax,%rdx
andq $1044480,%rdx
shrq $6,%rdx
orq %rcx,%rdx
cmpw $0,52(%rdx)
jne .Lcf
jmp *0(%rbp)
.Lcf:
[...]
}}}
The LLVM backend produces this though:
{{{
stg_upd_frame_info: # @stg_upd_frame_info
# BB#0: # %co
subq $104, %rsp
movq 8(%rbp), %rax
movq %rax, 24(%rsp) # 8-byte Spill
movq %rbx, 8(%rax)
mfence
movq $stg_BLACKHOLE_info, (%rax)
movq %rax, %rcx
andq $-1048576, %rcx # imm = 0xFFFFFFFFFFF00000
andq $1044480, %rax # imm = 0xFF000
shrq $6, %rax
addq %rcx, %rax
addq $16, %rbp
cmpw $0, 52(%rax)
movsd %xmm6, 88(%rsp) # 8-byte Spill
movsd %xmm5, 80(%rsp) # 8-byte Spill
movss %xmm4, 76(%rsp) # 4-byte Spill
movss %xmm3, 72(%rsp) # 4-byte Spill
movss %xmm2, 68(%rsp) # 4-byte Spill
movss %xmm1, 64(%rsp) # 4-byte Spill
movq %r9, 56(%rsp) # 8-byte Spill
movq %r8, 48(%rsp) # 8-byte Spill
movq %rdi, 40(%rsp) # 8-byte Spill
movq %rsi, 32(%rsp) # 8-byte Spill
je .LBB1_4
}}}
This has two main problems:
1. mfence instruction (write barrier) isn't required. (write-write barriers aren't required on x86)
2. LLVM backend is spilling a lot of stuff unnecessarily.
Both these I think are fairly easy fixes. LLVM is handling write barriers quite naively at the moment so 1. is easy. The spilling problem I think is related to a previous fix I made where I need to explicitly kill some of the stg registers if they aren't live across the call, otherwise LLVM rightly thinks they are live since I always pass the stg registers around (so live on entry and exit of every function unless I kill them)." dterei
1965 122 pumpkingod@…, ireney.knapp@…, mokus@…, jake.mcarthur@…, sweirich@…, oerjan Allow unconstrained existential contexts in newtypes Compiler 6.8.1 7.12.1 new normal 2015-02-24T04:02:44Z "Declarations like
{{{
newtype Bar = forall a. Bar (Foo a)
}}}
ought to be allowed so long as no typeclass constraints are added. Right now, this requires data rather than newtype.
" guest
3927 329 pumpkingod@…, ppremont@…, conal@…, sjoerd@…, nathanhowell@…, eir@…, ghartshaw@…, jeroen.weijers@…, wren@…, hackage.haskell.org@…, george.karachalias@…, gergo@…, ulf.norell@…, victor@… Incomplete/overlapped pattern warnings + GADTs = inadequate Compiler 6.12.1 7.12.1 simonpj new normal 2014-12-23T13:34:10Z "Consider these defintions
{{{
data T a where
T1 :: T Int
T2 :: T Bool
-- f1 should be exhaustive
f1 :: T a -> T a -> Bool
f1 T1 T1 = True
f1 T2 T2 = False
-- f2 is exhaustive too, even more obviously
f2 :: T a -> T a -> Bool
f2 T1 (T1 :: T Int) = True
f2 T2 (T2 :: T Bool) = False
-- f3's first equation is unreachable
f3 :: T a -> T a -> Bool
f3 T2 T1 = False
f3 _ _ = True
}}}
With HEAD (GHC 6.13) we get
{{{
G1.hs:11:1:
Warning: Pattern match(es) are non-exhaustive
In the definition of `f1':
Patterns not matched:
T1 T2
T2 T1
}}}
This is wrong.
* `f1` should behave like `f2`, and be accepted without warning.
* `f3` has an inaccessible branch that is not reported.
The type checker accepts just the right programs, but the rather simple-minded approach to overlap warnings isn't doing the right thing.
Note to self: the reason is that `tcPat` does not insert a coercion on the second arg to narrow the type, because there's no ''type'' reason to do so. So for `f1` we get
{{{
f1 a (x:T a) (y:T a)
= case x of { T1 (cox:a~Int) ->
case y of { T1 (coy:a~Int) -> ... }
}}}
In the inner case it's not obvious that T2 is inaccessible. If we refined eagerly we might get
{{{
f1 a (x:T a) (y:T a)
= case x of { T1 (cox:a~Int) ->
case (y |> T cox) of { T1 (coy:Int~Int) -> ... }
}}}
and now the scrutinee of the inner case has type `(T Int)` and the `T2` constructor obviously can't occur.
Fix this with the new inference engine." simonpj
2123 52 redneb@…, core-libraries-committee@… implement waitForProcess using signals Core Libraries 6.8.2 7.12.1 snoyberg new lowest 2015-02-17T14:04:34Z "`waitForProcess` currently calls `waitpid` with a safe FFI call, which means that
* you need to use `-threaded` to call this in a multithreaded program
* one OS thread is needed per `waitProcess`
instead we could implement this using the IO manager: have `waitForProcess` communicate with the IO manager, which wakes up the client when the appropriate `SIGCHLD` is received. Note that this means hooking `SIGCHLD` so we'd interact badly if the program itself wanted to use `SIGCHLD`.
I think it was Duncan Coutts who mentioned this idea to me." simonmar
7670 29 remi.turk@…, simonmar StablePtrs should be organized by generation for efficient minor collections Runtime System 7.7 7.12.1 new normal 2015-06-04T07:29:00Z Currently, stable pointers are all in one giant pointer table (see markStablePtrTable); this results in pretty bad GC behavior when you create a lot of stable pointers (Peaker has a test-case which he thinks is suffering due to repeated traversal of the stable pointers list.) We should partition them up into generations like we do for mutable lists. There might be some trickiness keeping the table up-to-date after GCs. ezyang
5219 2 rl need a version of hs_init that returns an error code for command-line errors Runtime System 7.0.3 7.12.1 new low 2014-12-23T13:33:45Z "This ticket is extracted from Roman's comment in #4464:
`hs_init` simply aborts if it doesn't like the RTS arguments which is quite unhelpful for dynamic libraries. I took me a day to find out that an application crash was caused by a failing hs_init (because of the -rtsopts problem). I would like to add a check for this to our code but there doesn't seem to be a way to do this. It would be much nicer if hs_init returned a failure/success code, at least for dynamic libraries.
To which I responded:
If hs_init needs to return an error condition rather than aborting, then we need to define a new API for that, and fix setupRtsFlags. I don't think we need to do this for every case of stg_exit and certainly not for barf: these are all internal error conditions and we have no sensible way to recover.
" simonmar
3782 18 rl@… "Data Parallel ""Impossible happened"" compiler error" Data Parallel Haskell 6.12.1 7.12.1 benl new low 2014-12-23T13:33:45Z "When I attempted to compile my vectorized code , I got the following message:
{{{
ghc -c -Odph -fcpr-off -fdph-seq newprop.hs
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.1 for i386-apple-darwin):
sumTyCon 11
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
" guest
5470 23 rleshchinskiy@… The DPH library needs to support PData and PRepr instances for more than 15-tuples Data Parallel Haskell 7.3 7.12.1 chak new normal 2014-12-23T13:34:10Z "Currently, `Data.Array.Parallel.PArray.PDataInstances` only generates tuple instances up to 6-tuple. This is not sufficient as these instances are used for environments of closures by the vectoriser — i.e., once a closures has more than 15 free variables, the compiler fails with `VectMonad.lookupFamInst: not found`.
" chak
2401 22 rob@…, simonmar aborting an STM transaction should throw an exception Runtime System 6.8.3 7.12.1 new low 2014-12-23T13:33:45Z The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore. sclv
9846 8 rodlogic GHC --make should also look for .hi, not only for .hs Compiler ⊥ new normal 2014-11-28T18:01:00Z "Currently, `ghc --make` will only consider .hs source files from the include path.
Example (assuming `Library` can't be resolved from the package database):
`A.hs`
{{{#!hs
module A where
import B
import Library
}}}
`B.hs`
{{{#!hs
module B where
}}}
Compiling these files with `ghc --make -Idir A.hs B.hs` will succeed only if GHC finds a `Library.hs` file.
In a thread on [https://www.haskell.org/pipermail/glasgow-haskell-users/2014-November/025476.html glasgow-haskell-users], Simon proposed relaxing this constraint; namely: In `--make` mode, when encountering an import `X`, GHC will try the following in order:
1. resolve the import from a package
2. search the include path for `X.hs` or `X.lhs`
3. search the include path for `X.hi`
It already does 1 and 2, and this proposal would add 3." larsrh
618 8 rodlogic Dependency caching in ghc --make Compiler None ⊥ new normal 2014-12-01T15:42:29Z ghc --make should cache dependencies between runs, somehow. simonmar
7261 16 roma@… ghci's :info and :browse break encapsulation GHCi 7.6.1 ⊥ new normal 2013-04-12T16:09:45Z "In ghci, :info shows representations of abstract data types. I consider this undesirable, since it breaks abstraction and confuses users.
Example:
{{{
Prelude> :m +Data.Unique
Prelude Data.Unique> :i Unique
newtype Unique = Data.Unique.Unique Integer
-- Defined in `Data.Unique'
}}}
I would expect it to behave in the same way as Haddock does, i.e. just show ""data Unique"".
Same about the :browse command." Feuerbach
4879 34 roma@…, ekmett, rodlogic Deprecate exports Compiler 7.0.1 7.12.1 new high 2015-06-19T09:36:35Z "== Motivation ==
During the library submission process there's sometimes the desire to have the ability to deprecate an export from a module.
For example [http://article.gmane.org/gmane.comp.lang.haskell.libraries/14524 during the discussing] about ticket #4422, I would have liked the ability to deprecate the exports of the `String` functions: `lines`, `words`, `unlines` and `unwords` from `Data.List` in favour of importing them from `Data.String`. However I wasn't able to do so, so these exports remain.
Similarly, [http://article.gmane.org/gmane.comp.lang.haskell.libraries/14925 during the discussion] about ticket #4865, Ian also desired to deprecate the export of `catch` from `System.IO.Error` but was unable to do so.
== Syntax ==
To deprecate an export simply place a `DEPRECATE` pragma for the export inside the export list, as in:
{{{
module Data.List
( ...
{-# DEPRECATE lines ""Exported from Data.String instead"" #-}
, lines
...
) where
...
}}}
Another design might be to have a different pragma as in:
{{{
{-# DEPRECATE_EXPORT lines ""Exported from Data.String instead"" #-}
}}}
But I find the former much prettier and more obvious.
== Semantics ==
If the `lines` export from `Data.List` is deprecated the following should raise deprecation warnings:
* Directly importing a deprecated export:
{{{
import Data.List (lines)
}}}
* Referring to a deprecated export:
{{{
import Data.List
foo = lines
}}}
If you import the same symbol from different modules and only some of them are deprecated exports then referring to the symbol won't give a deprecation warning. For example the following should not give deprecation warnings:
{{{
import Data.List
import Data.String
foo = lines
}}}
=== What exports can be deprecated? ===
* Functions.
* Types.
* Classes.
* Constructors. Possible syntax:
{{{
module A
( {-# DEPRECATE T(C1) ""The export of C1 is deprecated"" #-}
T(C1, C2, C3)
) where
}}}
* Modules. Possible syntax:
{{{
module A
( {-# DEPRECATE module B ""The export of module B is deprecated"" #-}
module B
) where
}}}
The semantics of deprecating a module export is that you get deprecation warnings for all symbols from module `B` that you refer to inside a module that imports `A`. (Does that make sense?)" basvandijk
7253 58 roma@…, patrick@…, rwbarton@… Top-level bindings in ghci GHCi 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z "ghci now supports most of the declarations. However, it doesn't support the most basic and common type of declaraion — pattern and function bindings!
E.g.
{{{
Prelude> a = 1
:2:3: parse error on input `='
}}}
I realise that, if implemented, they would have somewhat different semantics than in Haskell modules — e.g. with respect to recursion.
But even if they behaved in the same way as top-level monadic let-bindings, they would still be very useful for two reasons:
1. If you're doing quick experiments in ghci, ""let a=1"" is more than twice as long as ""a=1"", and that makes a difference.
2. Novices are often confused when they are told that they have to use one syntax for definitions in modules and another in ghci.
" Feuerbach
8779 72 roma@…, yom@…, cactus, merijn@…, dfranke Exhaustiveness checks for pattern synonyms Compiler (Type checker) 7.6.3 new normal 2015-03-30T13:07:43Z "Pattern synonyms are great, as they decouple interface from implementation. Especially if #8581 is also implemented, it should be possible to change a type completely while retaining the existing interface. Exciting!
Another missing piece is exhaustiveness checks. Given this pattern
{{{
initLast [] = Nothing
initLast xs = Just (init xs, last xs)
pattern xs ::: x Just (xs,x))
}}}
we want the compiler to tell the programmer that
{{{
f [] = ...
f (xs ::: x) = ...
}}}
is complete, while
{{{
g (xs ::: x) = ...
}}}
is not.
With view pattern directly, this is impossible. But the programmer did not write view patterns!
So here is what I think might work well, inspired by the new `MINIMAL` pragma:
We add a new pragma `COMPLETE_PATTERNS` (any ideas for a shorter name). The syntax is essentially the same as for `MINIMAL`, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case.
{{{
{-# COMPLETE_PATTERNS [] && (:::) #-}
}}}
Multiple pragmas are obviously combined with `||`, and there is an implicit `{-# COMPLETE_PATTERNS [] && (:) #-}` listing all real data constructors.
When checking for exhaustiveness, this would be done before unfolding view patterns, and for `g` above we get a warning that `[]` is not matched. Again, the implementation is very much analogous to `MINIMAL`.
Clearly, a library author can mess up and give wrong `COMPLETE_PATTERNS` pragmas. I think that is ok (like with `MINIMAL`), and generally an improvement." nomeata
9985 4 ross GHC panic with ViewPatterns and GADTs in a proc pattern Compiler 7.8.4 new normal 2015-01-14T15:32:09Z "The following code causes a ghc panic with versions 7.8.4 and 7.9.
{{{#!hs
module A where
{-# LANGUAGE GADTs, ViewPatterns, PatternSynonyms, DataKinds, Arrows, TypeOperators, TypeFamilies, UndecidableInstances #-}
import Control.Arrow
data Nat = Z | S Nat
data Vec n a where
VNil :: Vec Z a
VCons :: a -> Vec n a -> Vec (S n) a
viewVNil :: Vec Z a -> ()
viewVNil VNil = ()
viewVCons :: Vec (S n) a -> (a, Vec n a)
viewVCons (VCons a as) = (a, as)
pattern (:>) :: a -> Vec n a -> Vec (S n) a
pattern a :> as (a, as))
pattern VNil' ())
type family n + m where
n + Z = n
n + S m = S (n + m)
type family P2 n where
P2 Z = S Z
P2 (S n) = P2 n + P2 n
class A n where
a :: Arrow b => b (Vec (P2 n) a) a
instance A Z where
a = proc (a :> VNil) -> returnA -< a
}}}
If the pattern (a :> VNil) is changed to (a :> _) or (a :> VNil'), the code compiles.
GADTs pattern are not allowed to appear in proc patterns, but view patterns seems to be able to bypass this restriction, #9953, and the check on subpatterns." Rafbill
5777 84 ross, ben@…, benjamin.moseley@…, abcz2.uprola@… core lint error with arrow notation and GADTs Compiler (Type checker) 7.4.2 7.12.1 ross new normal 2014-12-23T13:34:10Z "The following code panics GHC (with 7.0.3, 7.2 and 7.4.0.20111219):
{{{
{-# LANGUAGE Arrows, GADTs #-}
import Control.Arrow
data Value a where BoolVal :: Value Bool
class ArrowInit f where
arrif :: f b -> ()
instance ArrowInit Value where
arrif = proc BoolVal -> returnA -< ()
-- arrif = arr (\BoolVal -> ())
}}}
I am attaching the -dcore-lint from 7.4.
" benmos
344 43 ross@…, abcz2.uprola@… arrow notation: incorrect scope of existential dictionaries Compiler (Type checker) 6.4 7.12.1 ross new lowest 2014-12-23T13:33:22Z "{{{
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
cgPanic
deref{v a1yz}
static binds for:
local binds for:
SRT labelghc-6.4: panic! (the `impossible'
happened, GHC version 6.4):
initC: srt
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
I've attached a test driver that can reproduce the problem.
-- Esa Pulkkinen
}}}" nobody
6024 59 ross@…, bgamari@…, diatchki@… Allow defining kinds alone, without a datatype Compiler (Type checker) 7.5 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "Sometimes we want to define a kind alone, and we are not interested in the datatype. In principle having an extra datatype around is not a big problem, but the constructor names will be taken, so they cannot be used somewhere else. A contrived example:
{{{
data Code = Unit | Prod Code Code
data family Interprt (c :: Code) :: *
data instance Interprt Unit = Unit1
data instance Interprt (Prod a b) = Prod1 (Interprt a) (Interprt b)
}}}
We're only interested in the constructors of the data family `Interprt`, but we cannot use the names `Unit` and `Prod` because they are constructors of `Code`.
The suggestion is to allow defining:
{{{
data kind Code = Unit | Prod Code Code
}}}
Such that `Code` is a kind, and not a type, and `Unit` and `Prod` are types, and not constructors.
Note that using ""data kind"" instead of just ""kind"" means the word ""kind"" does not have to be a reserved keyword.
You could also think you would want to have datatypes that should not be promoted:
{{{
data K
data type T = K
}}}
But I don't see a need for this, as the fact that the `K` constructor is promoted to a type does not prevent you from having a datatype named `K`." dreixel
7828 43 ross@…, jan.stolarek@… RebindableSyntax and Arrow Compiler (Type checker) 7.6.2 7.12.1 new normal 2015-03-02T09:01:40Z "When trying to add constraints to the types of the arrow primitives I get a type error. I think that doing such a thing should be possible and I've attached the code I used to test this. The errors I get when using the arrow notation for the function test are as follows:
{{{
test :: Typeable a => R a a
test = proc n -> returnA -< n
}}}
{{{
bug-arrow.hs:15:8:
Could not deduce (Typeable c) arising from a use of `arr'
from the context (Typeable a)
bound by the type signature for test :: Typeable a => R a a
at bug-arrow.hs:14:9-27
Possible fix:
add (Typeable c) to the context of
a type expected by the context: (b -> c) -> R b c
or the type signature for test :: Typeable a => R a a
In the expression: arr
When checking that `arr' (needed by a syntactic construct)
has the required type: forall b1 c1. (b1 -> c1) -> R b1 c1
arising from a proc expression at bug-arrow.hs:15:8-29
In the expression: proc n -> returnA -< n
bug-arrow.hs:15:8:
Could not deduce (Typeable c) arising from a use of `>>>'
from the context (Typeable a)
bound by the type signature for test :: Typeable a => R a a
at bug-arrow.hs:14:9-27
Possible fix:
add (Typeable c) to the context of
a type expected by the context: R a1 b -> R b c -> R a1 c
or the type signature for test :: Typeable a => R a a
In the expression: (>>>)
When checking that `(>>>)' (needed by a syntactic construct)
has the required type: forall a2 b1 c1.
R a2 b1 -> R b1 c1 -> R a2 c1
arising from a proc expression at bug-arrow.hs:15:8-29
In the expression: proc n -> returnA -< n
bug-arrow.hs:15:8:
Could not deduce (Typeable d) arising from a use of `first'
from the context (Typeable a)
bound by the type signature for test :: Typeable a => R a a
at bug-arrow.hs:14:9-27
Possible fix:
add (Typeable d) to the context of
a type expected by the context: R b c -> R (b, d) (c, d)
or the type signature for test :: Typeable a => R a a
In the expression: first
When checking that `first' (needed by a syntactic construct)
has the required type: forall b1 c1 d1.
R b1 c1 -> R (b1, d1) (c1, d1)
arising from a proc expression at bug-arrow.hs:15:8-29
In the expression: proc n -> returnA -< n
}}}
When I replace the definition with the translated core code (minus type applications and scoped type variables) the code compiles:
{{{
test :: Typeable a => R a a
test =
(>>>)
(arr (\ (n_apd) -> n_apd))
((>>>)
(arr (\ (ds_dst) -> ds_dst))
(returnA)
)
}}}
" AlessandroVermeulen
5267 26 ross@…, peteg Missing type checks for arrow command combinators Compiler (Type checker) 7.0.3 7.12.1 ross new low 2014-12-23T13:33:45Z "Is this expected to work?
{{{
{-# LANGUAGE Arrows #-}
module T where
import Prelude
import Control.Arrow
t = proc () ->
do rec x
do x
do x arr id <<< (| (arr id) (returnA -< 3) |)
}}}
I get:
{{{
/tmp/T.hs:8:18:
The type of the first argument of a command form has the wrong shape
Argument type: t_tX
In the command: (arr id) <<< ((|(arr id) ((returnA -< x))|))
In a stmt of a 'do' expression:
x do { x do { x (arr id) <<< ((|(arr id) ((returnA -< 3))|))
In an equation for `t'''':
t''' = proc x -> (arr id) <<< ((|(arr id) ((returnA -< 3))|))
}}}
" peteg
3215 18 rrnewton@… Valgrind support Runtime System 6.10.3 ⊥ new normal 2012-03-26T19:29:21Z "This is based on code in gtk2hs.
{{{
$ valgrind -q ./finalizer_queue
finalizer_queue: internal error: stg_ap_v_ret
(GHC version 6.10.3 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Killed
}}}
Unfortunately this test doesn't crash without Valgrind.
My guess is that this bit is the problem:
{{{
finalizer mkThunk $ do
freeHaskellFunPtr callback
freeHaskellFunPtr dPtr
}}}
Perhaps the documentation should say not to do this?" cmcq
8224 104 rrnewton@…, andreas.voellmy@…, alpmestan@…, kazu@…, simonmar, nh2, gidyn Excessive system time -- new IO manager problem? Runtime System 7.7 7.12.1 new high 2015-05-06T12:34:10Z "This is an issue that came to light when testing the patches on #910. You can see some of the numbers there. Basically, recent GHC HEAD builds, running a large number of threads blocked on MVars will result in burning a lot of system time.
The attached file provides a mediocre reproducer. With it, you can see that building with HEAD as of Aug 31st and running with `-RTS -N32` will result in around 200ms system time, whereas GHC 7.6.3 spends about 30ms in system time. This shows the disparity, but the result is not that egregious.
A more noticeable example is on ticket #910, where when running on 31 threads, there is an 8 minutes of system time for 17 minutes of user time, and yet at one thread that system time drops to under two seconds!
{{{
1 thread: real 1m20.028s user 1m17.921s sys 0m1.768s
31 threads: real 1m27.445s user 17m0.314s sys 8m0.175s
}}}
It needs to be determined whether this system time is a result of the parallel compilation patches on #910, or whether it is a new problem with the runtime system, and in particular with the parallel IO manager. I am inclined to believe that compiling in parallel involves extra IO (repeatedly reading interface files?), but not eight minutes of it!!
" rrnewton
9421 13 rwbarton, nh2 Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine Compiler 7.8.3 MikolajKonarski new normal 2015-07-31T11:53:37Z "I'm compiling i386 binaries on amd64 linux and reporting problems and workarounds in this meta ticket.
The very first problem I encounter is a magic number mismatch message.
This is basically the same problem as reported here:
https://www.mail-archive.com/ghc-devs@haskell.org/msg04439.html
I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS (12.04.4) so I was able to install ia32-libs and a few other libs
I've downloaded
http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux-deb7.tar.xz
configured, and make install says:
{{{
Installing library in
/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3
""utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist"" copy libraries/haskell2010 dist-install ""strip"" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p dyn'
Installing library in
/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0
""/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg"" --force --global-package-db ""/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d"" update rts/dist/package.conf.install
Reading package info from ""rts/dist/package.conf.install"" ... done.
""utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist"" register libraries/ghc-prim dist-install ""/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc"" ""/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg"" ""/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3"" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO
ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi
magic number mismatch: old/corrupt interface file? (wanted 33214052, got
129742)
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2
}}}
" MikolajKonarski
10246 18 rwbarton, simonmar Literal Pattern match loses order Compiler 7.10.1 nomeata patch normal 2015-04-06T08:54:25Z "I found this long-standing bug while investigating #10245:
Consider this code:
{{{
f1 :: Int -> String
f1 n = case n of
0 -> ""bar""
0x10000000000000000 -> ""foo""
_ -> ""c""
{-# NOINLINE f1 #-}
g1 :: Int -> String
g1 n = if n == 0 then ""bar"" else
if n == 0x10000000000000000 then ""foo"" else
""c""
{-# NOINLINE g1 #-}
f2 :: Int -> String
f2 n = case n of
0x10000000000000000 -> ""foo""
0 -> ""bar""
_ -> ""c""
{-# NOINLINE f2 #-}
g2 :: Int -> String
g2 n = if n == 0x10000000000000000 then ""foo"" else
if n == 0 then ""bar"" else
""c""
{-# NOINLINE g2 #-}
main = do
let i = read ""0"" :: Int
print (f1 i)
print (g1 i)
print (f2 i)
print (g2 i)
}}}
According to the report, `f1` should behave like `g1` and `f2` should behave like `g2`. But that is not the case: I get
{{{
""foo""
""bar""
""foo""
""foo""
}}}
The reason is that the branches are sorted, to create fancy code for it, but this does not take into account that `0x10000000000000000 = 0`, at least for `Int`.
This bug is present also in 7.8.4, and not (directly) related to my CmmSwitch code: It can also be observed with interpreted code, so the fix must happen earlier." nomeata
10692 16 rwbarton, slyfox Replace (SourceText,FastString) with WithSourceText data type Compiler 7.11 alanz new normal 2015-08-02T08:25:45Z "Phab:D907 introduced `SourceText` for a number of data types, by replacing `FastString` with `(SourceText,FastString)`. Since this has an `Outputable` instance, no warnings are generated when `ppr` is called on it, but unexpected output is generated. See Phab:D1096 for an example of this.
Replace the `(SourceText,FastString)` tuples with a new data type
{{{#!hs
data WithSourceText = WithSourceText SourceText FastString
}}}
" alanz
8288 18 rwbarton@… add idris style EDSL support for deep embedding lambdas Compiler 7.6.3 7.12.1 new normal 2014-12-23T13:34:10Z "I could be wrong, but I think this would actually make it much easier to write interesting EDSLs and have a native haskelly syntax.
This would sort of be in the same vein as the recently requested applicative brackets idea, albeit a tad more going on . " carter
3351 18 rwbarton@… Generated ghc man page missing xrefs Documentation 6.10.3 7.12.1 new lowest 2014-12-23T13:33:22Z "The man page for ghc is generated from xml files. Currently, this ignores xrefs, turning, for example
{{{
enable almost all warnings (details in )
}}}
to
enable almost all warnings (details in )
This leads to stunted sentences as well as missing information." kaol
9813 23 ryan.gl.scott@… Error when reifying type constructor Compiler 7.8.3 new normal 2014-12-06T19:58:26Z "The following code works under ghc-7.6.3 and template-haskell-2.8.0.0:
{{{#!hs
{-# LANGUAGE TemplateHaskell #-}
data Huh = ThisDefinitely
| UsedToWork
constructorNames :: String
constructorNames = $(do
ty map showCon cons
showCon (NormalC n _) = nameBase n
return . LitE . StringL $ concat strs)
main = putStrLn constructorNames
}}}
Printing the following at compile time:
{{{
[1 of 1] Compiling Main ( Main.hs, Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Linking Main ...
}}}
and then successfully executing:
{{{
$ ./Main
ThisDefinitelyUsedToWork
}}}
However, using ghc 7.8.3/template-haskell-2.9.0.0 I get the following compile error:
{{{
[1 of 1] Compiling Main ( Main.hs, Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Main.hs:8:22:
‘Huh’ is not in the type environment at a reify
In the splice:
$(do { ty FD -> Ptr Word8 -> Int -> CSize -> IO CInt
readRawBufferPtr loc !fd buf off len
| threaded = blockingReadRawBufferPtr loc fd buf off len
| otherwise = asyncReadRawBufferPtr loc fd buf off len
...
blockingReadRawBufferPtr :: String -> FD -> Ptr Word8 -> Int -> CSize -> IO CInt
blockingReadRawBufferPtr loc fd buf off len
= fmap fromIntegral $ throwErrnoIfMinus1Retry loc $
if fdIsSocket fd
then c_safe_recv (fdFD fd) (buf `plusPtr` off) len 0
else c_safe_read (fdFD fd) (buf `plusPtr` off) len
...
-- NOTE: ""safe"" versions of the read/write calls for use by the threaded RTS.
-- These calls may block, but that's ok.
foreign import stdcall safe ""recv""
c_safe_recv :: CInt -> Ptr Word8 -> CSize -> CInt{-flags-} -> IO CSsize
foreign import stdcall safe ""send""
c_safe_send :: CInt -> Ptr Word8 -> CSize -> CInt{-flags-} -> IO CSsize
}}}
If I understand correctly, safe foreign calls cannot be interrupted by asynchronous exceptions.
Is this a bug in readRawBufferPtr, or a bug in the network package? Can a caller expect readRawBufferPtr to be interruptible by an exception?" joeyadams
10056 11 RyanGlScott Inconsistent precedence of ~ Compiler (Parser) 7.8.4 new normal 2015-07-29T15:30:13Z "The following compiles as expected:
{{{#!hs
{-# LANGUAGE TypeFamilies #-}
type family Foo a b
f :: (Foo a b ~ Int) => a -> b -> b
f = error """"
}}}
but this fails:
{{{#!hs
{-# LANGUAGE TypeFamilies #-}
type family a \\ b
f :: (a \\ b ~ Int) => a -> b -> b
f = error """"
}}}
with the error
> ""The second argument of `(\\)` should have kind `*`, but `b ~ Int` has kind `Constraint`.""
Thus the first example is being parsed as `(Foo a b) ~ Int`, while the second is parsed as `a \\ (b ~ Int)`. I believe the second example should compile, i.e. `(\\)` and `Foo` should have the same precedence, both of which are higher than `(~)`." crockeea
2101 20 ryani.spam@… Allow some form of type-level lemma Compiler 6.8.2 ⊥ new normal 2008-09-30T15:51:41Z See http://www.haskell.org/pipermail/haskell/2008-February/020230.html guest
1147 4 SamB Quadratic behaviour in the compacting GC Runtime System 6.6 ⊥ new normal 2013-01-22T16:54:16Z "Run the following program under GHCi with `+RTS -c -RTS`:
{{{
module Main where
break2 p (x:xs) = if p x then
([],x:xs)
else
let (b1,b2) = break2 p xs
in (x : b1, b2)
break2 p [] = ([],[])
surprise xs = b1 ++ ""\n surprise "" ++ b2
where
(b1,b2) = break2 (=='\n') xs
test n = length $ surprise $ [head (show i) | i '[]
GHC.Base.[]
Prelude> 'True
GHC.Base.True
Prelude> '(*)
GHC.Num.*
Prelude Data.Array.Unboxed> ''UArray
Data.Array.Base.UArray
}}}
It would be nice if Template Haskell could instead use public names, where available, so that Derive and similar tools would be able to use qualified names (and the quoting syntax without fear of their ending up pointing into the middle of no-mans-land, or even GHC-only land.
This would also mean that users of Derive via TH splicing wouldn't need to import so many modules that the derivings depend on." SamB
2215 4 SamB :disable command to disable breakpoints GHCi 6.9 7.12.1 new lowest 2014-12-23T13:33:22Z "Okay, I've finally gotten around to trying the debugger, and I noticed that there don't seem to be any commands to disable or reenable breakpoints. These would be really nice, and probably not too difficult. The names should be {{{:disable}}}and {{{:enable}}}. (That's what I expected them to be.)
Man, I wish there was a severity between ""normal"" and ""major""..." SamB
932 12 samb simonpj Improve inlining Compiler 6.4.2 ⊥ simonpj new normal 2008-09-30T15:51:08Z "Currently the contruct
{{{
case (x# ># 0#) of ...
}}}
attracts no argument discount for x#, which is silly.
The comment in CoreUnfold says:
{{{
PrimOpId op -> primOpSize op (valArgCount args)
-- foldr addSize (primOpSize op) (map arg_discount args)
-- At one time I tried giving an arg-discount if a primop
-- is applied to one of the function's arguments, but it's
-- not good. At the moment, any unlifted-type arg gets a
-- 'True' for 'yes I'm evald', so we collect the discount even
-- if we know nothing about it. And just having it in a primop
-- doesn't help at all if we don't know something more.
}}}
But the right thing to do seems to be to fix interestingArg in SimplUtils so that it only thinks a primitive-typed thing is interesting if it knows its value (or some structure).
Here's the program that triggered this thought:
{{{
import GHC.Word
import GHC.Base
import GHC.Prim
a `shiftRLT` b | b >=# 32# = int2Word# 0#
| otherwise = a `uncheckedShiftRL#` b
(W32# x#) `shift` (I# i#) =
{- we do an actual case analysis on i# to try to give us a discount -}
case i# of
{- For some bizzare reason removing the `shiftRLT` 0# makes the
inlining fail again -}
0# -> W32# (x# `shiftRLT` 0#)
_ ->
if i# >=# 0# then W32# (narrow32Word# (x# `shiftL#` i#))
else W32# (x# `shiftRLT` negateInt# i#)
x `shiftR` y = x `shift` (-y)
shift7 x = x `shiftR` 7
}}}
roconnor@theorem.ca initiated the thread" simonpj
3024 53 SamB, anton.nik@…, claudiusmaximus@… Rewrite hp2ps in Haskell Profiling 6.10.1 ⊥ new normal 2012-10-21T15:52:46Z Right now, hp2ps is written in rather difficult to modify C, and is quite inflexible. We should rewrite it in Haskell and make it, among other things, more tolerant to incomplete records. SamB
2200 42 SamB, core-libraries-committee@… big static random access arrays Core Libraries 6.8.2 ⊥ ekmett new normal 2014-11-02T10:11:41Z "
These would be unlike `StorableArray`s because they would be available at compile time, and would be pure values. They would amount to arrays of bytes, of course, but it'd be nice if they could be `(Storable a) => StaticArray a` and we could walk down them or randomly access them to get the `a` values out of them. They should be capable of storing hundreds of thousands of `Int`s.
What are some functions that work on these arrays? We need just one:
{{{
indexInto :: (Storable a) => StaticArray a -> Word -> a
}}}
Then we can make a `Monad` to walk up and down the array. It will be some `State` hybrid. No `IO`. A bright person could implement static `Trie`s, `RoseTree`s and other things using this `Monad` -- storing the offsets mixed in with the data in an unholy mess and skipping forward or backward, leveraging ""the world’s most beautiful imperative language.""
It's been suggested (SamB) that this should be implemented in Template Haskell.
Important features of this array relative to other arrays and lists in Haskell:
Specificity of Index::
A machine `Word` since that contains the finest grained pointer. When indexing into a `Storable a`, the index is multiplied by `sizeOf (undefined :: a)`.
Static Nature::
Exists to facilitate large static constants. The array does not support any append or delete operations, there is no way to change any of its values and it can not be copied." jsnx
3021 17 SamB, hvr@… A way to programmatically insert marks into heap profiling output Profiling 6.10.1 ⊥ new normal 2012-10-02T22:58:14Z "This would be useful for e.g. marking compiler phases.
Hmm, this would be more useful if the ""MARK"" record type had a string field..." SamB
5416 19 sanzhiyan@… Local modules and Template Haskell declaration splices Template Haskell 7.2.1 ⊥ new normal 2014-11-27T23:25:26Z "Sometimes you want a Template Haskell splice to expand to a bunch of declarations, ''some of which are not visible to the context''. A trivial example might be
{{{
module M where
$(f 4)
====> expands to
module M where
helper = ...blah...
real_fun = ...helper....
}}}
But `helper` is only a helper function for `real_fun` and should not be exported by M, nor should it conflict with other definitions in M.
See #5398 for a more concrete example, and (at the end) a speculative suggestion for ""local modules"" that might be a good design.
Another thing you might want is for a splice to expand into some import declarations that bring some new stuff into scope. That too might be possible using this design.
Prioity uncertain, details very uncertain. I'm just making the ticket to keep track of the idea." simonpj
8272 7 schyler testing if SpLim=$rbp and Sp=$rsp changed performance at all Compiler 7.7 7.12.1 carter new normal 2014-12-23T13:34:10Z "testing if SpLim=$rbp and Sp=$rsp changed performance at all
would need a stack check but then push could be used to spill to the stack
Idea via Nathan Howell.
At the very least, the x86 PUSH instruction has a more succinct encoding than MOV.
worth hacking out to see if this can measurable shift ghc perf on nofib or not.
this would be part of a larger effort to explore ways to improve GHC's calling convention for modern hardware
" carter
10506 5 scpmw SourceNotes are not applied to all identifiers Compiler 7.10.1 7.10.3 new normal 2015-07-27T00:58:43Z "Compiling
{{{
module Foo where
foo x = x + 1
bar y = foo y
}}}
with `-g` produces
{{{
$ ghc -g -ddump-ticked test.hs
[1 of 1] Compiling Foo ( test.hs, test.o )
AbsBinds [a_avC] [$dNum_avD]
{Exports: [foo <= foo_amB
<>]
Exported types: foo :: forall a_avC. Num a_avC => a_avC -> a_avC
[LclId, Str=DmdType]
Binds: -- ticks = [src]
foo_amB x_alA
= src (+)
src x_alA src 1}
AbsBinds [a_avV] [$dNum_avW]
{Exports: [bar <= bar_avN
<>]
Exported types: bar :: forall a_avV. Num a_avV => a_avV -> a_avV
[LclId, Str=DmdType]
Binds: -- ticks = [src]
bar_avN y_amz = src foo (src y_amz)}
}}}
Note that neither the occurrence of `(+)` in `foo`, nor the occurrence of `foo` in `bar` have their own Ticks. Instead they are only covered by the Tick for the entire application `x + 1` (resp. `foo y`).
I'm trying to use the new SourceNote infrastructure to map CoreExprs back to their original source location, but unfortunately I need these locations for each identifier in the source.
Would it be reasonable to add a SourceNote to each occurrence of an identifier?" gridaphobe
10667 5 scpmw '-g' option generates invalid assembly when '*/*' operator is used Compiler (CodeGen) 7.10.2-rc2 new normal 2015-07-25T16:51:43Z "Bug is observed when building cpphs-1.19
{{{#!hs
module A where
x */* y = 42
}}}
{{{
$ ghc -fforce-recomp A -g
[1 of 1] Compiling A ( A.hs, A.o )
/tmp/ghc23923_0/ghc_2.s: Assembler messages:
/tmp/ghc23923_0/ghc_2.s:17:0: Error: bad expression
/tmp/ghc23923_0/ghc_2.s:17:0:
Warning: missing operand; zero assumed
...
}}}
The problem here is the following assembly snippet:
{{{
.text
.align 8
.loc 1 3 1 /* */* */
.quad 12884901911
.quad 0
.quad 15
}}}
Would it be worthwile using ';' as a comment instead?
Don't know if it's universally portable." slyfox
9952 15 scpmw, Tarrasch Add -g Compiler 7.8.4 new normal 2015-01-02T23:02:27Z "We should add debug info levels, just like GCC and LLVM has. In particular, I'd like to have -g1 which has (from https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html)
> minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables.
This should let us have -g1 turned on even in production code, as it should grow binary sizes by much. This in turn should be a boon for debugability of programs. It should also allow us to offer some for of stack traces without any runtime cost (except when an exception with a stack trace is actually raised.)" tibbe
10001 22 sean.leather@… GHC crash trying to build a project within Nix-shell Compiler 7.8.4 infoneeded normal 2015-07-27T11:25:49Z "
{{{
:
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.4 for x86_64-unknown-linux):
Loading temp shared object failed: /run/user/1000/ghc19915_0/ghc19915_20.so: failed to map segment from shared object
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[20 of 99] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, dist/build/Settings/StaticFiles.o )
:
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.4 for x86_64-unknown-linux):
Loading temp shared object failed: /run/user/1000/ghc19915_0/ghc19915_21.so: failed to map segment from shared object
}}}" wolftune
4222 18 sergueyz@… Template Haskell lets you reify supposedly-abstract data types Template Haskell 6.12.3 7.12.1 new low 2014-12-23T13:33:45Z "Serguey Zefirov writes ([http://www.haskell.org/pipermail/haskell-cafe/2010-July/079802.html on Haskell cafe]) ""Data.Map.Map and Data.Set.Set are exported abstractly, without exposing knowledge about their internal structure.
I cannot directly create my own class instances for them because of that. But I found that I can write Template Haskell code that could do that - those data types could be reified just fine.""
Good point. It's not quite clear what a better design should be. Haskell controls data abstraction by whether or not the constructors of the data type are exported. But they might be exported by the module that ''defined'' them, but ''not'' to ""clients"" of the data type. So the data type is abstract to some importers but concrete to others.
So when should TH let you reify the representation of a data type? Maybe it should let you do so iff
* The data constructors of the data type are in scope (somehow) at the reification site
So, to take an example:
{{{
module Conc( T(..), Blah(..) ) where
data T = T1 | T2 Blah
data Blah = A | B
module Abs( T, Blah ) where
import Conc
module ReifyA where
import Abs
foo = reify ''T
module ReifyC where
import Conc
foo = reify ''T
}}}
So the `reify` in `ReifyC.foo` would ""see"" the data constructors of `T`, but not the one in `ReifyA`.
But this approach raises related questions.
* What if some, but not all, of `T`'s data constructors are in scope?
* What if the data constructors are all in scope, but some mention a type that is not in scope? For example, suppose type `Blah` is not in scope, but you reify `T`?
* At the moment, when you reify a data type you get its `Dec`. But if `T` is abstract, what `Dec` can we give it? Just giving it an empty constructor list seems wrong; after all, it might really ''be'' a zero-constructor data type. I suspect we may want a richer data type for `Info` (ie what `reify` returns).
All these require design thinking. Does anyone want to lead that debate? Otherwise things will probably stay as they are.
I've labelled this as a feature request, although it is a kind of bug, because of this design component.
" simonpj
7741 28 shelarcy@…, simonmar Add SIMD support to x86/x86_64 NCG Compiler (NCG) 7.7 7.12.1 new normal 2014-12-23T13:34:10Z ghc-7.7.20130301 has SIMD support. But only LLVM backend supports SIMD currently. If we want to use SIMD, we should use LLVM backend. I request to add SIMD support to x86/x86_64 NCG. shelarcy
10155 8 simonmar [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64 Runtime System 7.8.1 7.12.1 thoughtpolice patch high 2015-03-27T14:49:06Z "The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants where the ABI doesn't impose a mandatory red zone for the stack, like on Windows or Xen/HaLVM. The current implementation restores the stack pointer first, which effectively marks the area with the saved registers as reusable. Later, the CPU registers are restored from this ""free"" area. This ordering happens to work by accident on operating systems that strictly adhere to the System V ABI, because any interrupt/signal delivery is guaranteed to leave the first 128 bytes past the stack pointer untouched (red zone). On other systems this might result in corrupted CPU registers if an interruption happens just after restoring the stack pointer. The red zone is usually only used by small leaf functions to avoid updates to the stack pointer and exploiting it doesn't give us any advantage in this case.
The attached patch reorders the register access, so that the stack pointer is restored last. It's also shorter by one instruction." stengel
10433 8 simonmar Fix load/store barriers in pre-ARMv7 builds Runtime System 7.12.1 new high 2015-06-04T22:38:31Z "As pointed out in #10244 and Phab:D894, the fix we committed for this problem isn't 100% correct - from 753b156dc6b0c38b106c390952750fb800bf27e7:
{{{
#elif arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv7)
// TODO FIXME: This case probably isn't totally correct - just because we
// use a pre-ARMv7 toolchain (e.g. to target an old Android device), doesn't
// mean the binary won't run on a newer ARMv7 system - in which case it
// needs a proper barrier. So we should rethink this
// - Reid
__asm__ __volatile__ ("""" : : : ""memory"");
}}}
This is a reminder to fix this." thoughtpolice
10712 8 simonmar Regression: make TEST=exceptionsrun001 WAY=optasm is failing Compiler 7.11 7.12.1 new high 2015-07-31T12:35:52Z "The following program, extracted from the test exceptionsrun001, should exit with exitcode 100. Instead, when compiled with `-O1`, it never gets past the ioTest and somehow manages to exit with exitcode 0.
{{{
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import Control.Exception
import System.IO.Error
import System.Exit
main = do
ioTest
exitWith (ExitFailure 100)
ioTest :: IO ()
ioTest = (catch (ioError (userError ""wibble""))
(\(e::IOException) -> return ())
}}}
I think this will require a git bisect:
* last known good commit: 34bb4605d4ec5b131df57ca4c91d6840b7539194
* first known bad commit: f83aab95f59ae9b29f22fc7924e050512229cb9c." thomie
8327 8 simonmar Cmm sinking does not eliminate dead code in loops Compiler (CodeGen) 7.7 new normal 2015-07-25T07:16:20Z "Cmm code shown in #8326 is suboptimal. For this Haskell code:
{{{
isTrue# :: Int# -> Bool
isTrue# 1# = True
isTrue# _ = False
f :: Int# -> Int
f x | isTrue# (x ># 0#) = I# x
| otherwise = -(I# x)
}}}
we get Cmm that contains dead code in a loop:
{{{
cFg: // False branch
Hp = Hp + 16;
if (Hp > HpLim) goto cFy; else goto cFx;
cFy: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFf;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8;
cFf: // re-do the False branch
_sEU::I64 = I64[Sp + 8];
Sp = Sp + 16;
_sEV::I64 = R1;
goto cFg;
cFx: // RHS of False branch
I64[Hp - 8] = GHC.Types.I#_con_info;
I64[Hp] = -_sEU::I64;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}}}
Notice that `_sEV` is dead - we should optimize it away. This is a known deficiency in the Cmm sinking pass (i.e. it does not work for loops). I'm putting this on Trac so we have this documented." jstolarek
8336 8 simonmar Sinking pass could optimize some assignments better Compiler (CodeGen) 7.7 new normal 2014-11-19T19:43:41Z "Compiling this program:
{{{
{-# LANGUAGE BangPatterns, MagicHash, CPP #-}
{-# OPTIONS_GHC -O2 -funbox-strict-fields #-}
module HashStr where
import Foreign.C
import GHC.Exts
import Data.Word
#define hASH_TBL_SIZE 4091
hashStr :: Ptr Word8 -> Int -> Int
-- use the Addr to produce a hash value between 0 & m (inclusive)
hashStr (Ptr a#) (I# len#) = loop 0# 0#
where
loop h n | n GHC.Exts.==# len# = I# h
| otherwise = loop h2 (n GHC.Exts.+# 1#)
where !c = ord# (indexCharOffAddr# a# n)
!h2 = (c GHC.Exts.+# (h GHC.Exts.*# 128#)) `remInt#`
hASH_TBL_SIZE#
}}}
produces following Cmm code for `hashStr` function:
{{{
{offset
cut:
goto cux;
cux:
_stC::I64 = R3;
_stB::I64 = R2;
_stF::I64 = 0;
_stE::I64 = 0;
goto stD;
stD:
if (_stF::I64 == _stC::I64) goto cuH; else goto cuI;
cuH:
R1 = _stE::I64;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
cuI:
_stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7),
4091);
_stF::I64 = _stF::I64 + 1;
_stE::I64 = _stM::I64;
goto stD;
}
}}}
The problem here is that three last assignments:
{{{
_stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091);
_stF::I64 = _stF::I64 + 1;
_stE::I64 = _stM::I64;
}}}
could be optimized as:
{{{
_stE::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091);
_stF::I64 = _stF::I64 + 1;
}}}
We should improve sinking pass so that it can optimize such cases. See Note [dependent assignments] in !CmmSink." jstolarek
8573 8 simonmar """evacuate: strange closure type 0"" when creating large array" Runtime System 7.6.3 rwbarton new normal 2014-11-18T04:17:51Z "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 : can't load .so/.DLL for: libHStext-1.0.0.0.so (libHStext-1.0.0.0.so: cannot open shared object file: No such file or directory)
cabal: Error: some packages failed to install:
uniplate-1.6.12 failed during the building phase. The exception was:
ExitFailure 1
}}}
I have shared: False in cabal.config, so it's not surprising that libHStext-1.0.0.0.so is not found. What is surprising is that it's needed. uniplate doesn't use TemplateHaskell, from what I can tell.
This is GHC 7.7.20131217." Feuerbach
8665 8 simonmar RELEASE_LOCK: I do not own this lock Runtime System 7.6.3 infoneeded normal 2014-11-17T02:23:39Z "Got this error running the latest version of Yesod:
{{{
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
devel.hs: internal error: RELEASE_LOCK: I do not own this lock: rts/Capability.c 431
(GHC version 7.6.3 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Exit code: ExitFailure 6
}}}
" guest
8847 8 simonmar Int64 ^ Int64 broken by optimization on SPARC Compiler (NCG) new normal 2014-03-04T19:45:02Z "The T7507 test is broken on SPARC NCG, I've more simplified it to
{{{
module Main where
import Data.Int
main = print ( ( 2 :: Int64 ) ^ ( 6 :: Int64 ) )
}}}
it does not matter if it's run with two Int64 or just with one:
{{{
main = print ( 2 ^ 6 :: Int64 )
}}}
the result with -O is still 0. The result without -O is correct." kgardas
8862 8 simonmar forkProcess does not play well with heap or time profiling Runtime System 7.6.3 simonmar new normal 2014-03-08T18:14:01Z "This is similar to #4512. When doing heap or time profiling, the forked process and the parent process both write to the same `.hp` or `.prof` file. I think this also applies to program coverage using hpc (didn't test this).
I was able to reproduce the bug with the attached source code, but some other people were not. Just run `space-profiling +RTS -h` and try to convert the generated heap profile using `hp2ps`, I get the following error message:
{{{
hp2ps: space-profiling.hp, line 186: integer must follow identifier
}}}
I attached the generated hp file. " bennofs
8887 8 simonmar Double double assignment in optimized Cmm on SPARC Compiler (CodeGen) 7.9 new normal 2014-11-07T12:43:36Z "Hello,
while reading ffi003 asm/opt-cmm for fixing this on SPARC I've noticed this code, this is optimized Cmm dump:
{{{
112 c1or:
113 _s1nw::F64 = F64[_s1nv::P32 + 3];
114 _c1oj::I32 = sin;
115 _c1ok::F64 = _s1nw::F64;
}}}
this assignment to _s1nw::F64 looks useless as we may assign directly to _c1ok::F64, may we not?
Both optimized and non-optimized Cmms attached." kgardas
8905 8 simonmar Function arguments are always spilled/reloaded if scrutinee is already in WHNF Compiler (CodeGen) 7.9 new normal 2014-11-07T13:57:37Z "The code generator unnecessarily spills and reloads function arguments if the scrutinee turns out to be already evaluated (i.e. has non-zero tag bits).
Here's the beginning of a function body, taken from the `insert` function at https://github.com/tibbe/unordered-containers/blob/master/Data/HashMap/Base.hs#L303:
{{{
c2wQ: // stack check
if ((Sp + -72) < SpLim) goto c2wR; else goto c2wS;
c2wR: // stack check failure
R1 = PicBaseReg + $wpoly_go_closure;
I64[Sp - 40] = R2;
I64[Sp - 32] = R3;
P64[Sp - 24] = R4;
I64[Sp - 16] = R5;
P64[Sp - 8] = R6;
Sp = Sp - 40;
call (I64[BaseReg - 8])(R1) args: 48, res: 0, upd: 8;
c2wS: // stack check success
I64[Sp - 40] = PicBaseReg + block_c2my_info; // return addr for eval
R1 = R6; // t
I64[Sp - 32] = R2; // spill: s
I64[Sp - 24] = R3; // spill: x
P64[Sp - 16] = R4; // spill: k
I64[Sp - 8] = R5; // spill: h
Sp = Sp - 40;
if (R1 & 7 != 0) goto c2my; else goto c2mz; // eval check of t
c2mz: // eval check failed
call (I64[R1])(R1) returns to c2my, args: 8, res: 8, upd: 8; // eval
c2my: // eval check succeeded
_s2b1::I64 = I64[Sp + 8]; // reload: h
_s2b2::I64 = I64[Sp + 16]; // reload: k
_s2b3::P64 = P64[Sp + 24]; // reload: x
_s2b4::I64 = I64[Sp + 32]; // reload: s
switch [0 .. 4] (R1 & 7 - 1) {
case 0 : goto c2wK;
case 1 : goto c2wL;
case 2 : goto c2wM;
case 3 : goto c2wN;
case 4 : goto c2wO;
}
}}}
It seems to me that all the spills/reloads could be pushed into the `c2mz` block.
The `c2my` block, in its current form, is reused for a heap check failure case, so the heap check most likely will have to do its own spilling/reloading. However, since the scrutinee not having tags bit or the eval checking failing is not the common case, they should be out of the common path.
If it matters the data type is spine strict so GHC should have enough information to know that the common case (e.g. self-recursive calls) already have an evaluated argument (although there might be an indirection in some cases)." tibbe
8949 8 simonmar switch -msse2 to be on by default Compiler (CodeGen) 7.9 new normal 2014-11-07T12:27:19Z "I propose msse2 to be on by default. I guess the default was chosen way back, when Pentium III support was still relevant.
Nowadays we don't really win on the CPU support, because e.g. https://github.com/tibbe/hashable/blob/master/hashable.cabal is built by default with sse2 on the injected C code level. And hashable has a lot of reverse depends, therefore on an end user system (RedHat or Debian) the user is most probably unlucky with a Pentium III CPU anyways.
Flipping this default would also fix the excess precision problem for most users of GHC on the i686 platform.
GHC should provide a -mno-sse2 flag for the cases when this needs to be disabled." errge
8982 8 simonmar Cost center heap profile restricted by biography of GHC segfaults Profiling 7.8.1 new normal 2014-04-10T11:04:17Z "Steps to reproduce:
1. Build GHC with profiling on 64-bit Linux
2. Run T1969 with RTS options -hc -hbvoid
{{{
[ezyang@hs01 compiler]$ '/home/hs01/ezyang/ghc-compalloc/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine-readable -RTS -dcore-lint -static +RTS -hc -hbvoid
Segmentation fault
}}}
Interestingly enough, I don't see the problem with other types of profiling, e.g. '-hd'. I tried a few simpler, nontrivial Haskell programs but I couldn't reproduce the segfault, so this is some sort of bug that only shows up in complex setting (maybe multithreading is the issue?) It reproduces quite reliably for me.
When I build the runtime system with debugging, I get a useful assert failure:
{{{
ghc-stage2: internal error: ASSERTION FAILED: file rts/ProfHeap.c, line 201
(GHC version 7.8.0.20140408 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
This assert is complaining that the cost center (CCS_SYSTEM) never made it into the hash table for era 149.
I'll try looking for a simpler test-case later, but maybe someone can figure out what this bug is by sight." ezyang
9105 8 simonmar Profiling binary consumes CPU even when idle on Linux. Runtime System 7.8.2 simonmar new normal 2014-11-16T04:04:03Z "The program is
main = forever $ threadDelay 1000000 >> return () .
Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1 on Ubuntu (not VM).
The non-profiling binary doesn't consume CPU, the profiling does ~10% (of a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc.
When strace-ing, the profiling one seems to receive a constant flow of SIGVTALRM, while the normal receives one burst each second.
I see I can switch off ""master tick interval"" with -V0, and then CPU is not used, but the consequences of this are not very well documented (apart from context switching becoming deterministic).
Interestingly, if I compile using profiling on Windows (latest haskell-platform, 64bit), it doesn't use more CPU than the non-profiling.
So, the question is, why does this happen on Linux, and if it can be avoided somehow." robinp
9253 8 simonmar """internal error: evacuate(static): strange closure type 0"" when running in QEMU" Runtime System 7.8.2 simonmar new normal 2014-07-01T17:31:40Z "We're trying to use NixOS to automatically run our acceptance tests in a VM on commit, in order to guarantee system stability. However, we're periodically seeing our web server component, compiled with GHC 7.8.2 is failing to start up. When it fails, the error message is always:
{{{
internal error: evacuate(static): strange closure type 0
(GHC version 7.8.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
Happy to do more debugging on this, but I'll need to be pointed in the right direction.
" ocharles
9315 8 simonmar Weird change in allocation numbers of T9203 Runtime System 7.9 simonmar new normal 2014-07-21T13:23:45Z "While trying to improve our handle on allocation numbers, I’m stuck with the test case T9203. On some machines, it allocates roughly 95747304 bytes (this includes travis and my laptop), on others 42946176 bytes (e.g. on the machine where I monitor benchmark performance). All machines are 64 bit Linux machines.
The output of `-ddump-simpl`, `-ddump-stg` and `-ddump-cmm` is identical (up to variable names). Even `-ddump-asm` looks the same, besides some jump target reordering. The binary runs too small to get a heap profile.
I’m a bit stuck here: What can be the cause for these differences?
(BTW, if have an up-to-date GHC tree, can you report the number you get? Run `make -C testsuite VERBOSE=4 TEST=T9203` for that.)" nomeata
9481 8 simonmar Linker does not correctly resolve symbols in previously loaded objects Compiler 7.8.2 new normal 2014-09-03T10:12:38Z "'''Summary''': Given two object files (created from C files) A and B, where B refers to symbols defined in A, if we load B before A, calling `resolveObjs` after each object file, symbol resolution goes wrong. Full test case attached.
'''Detailed description''': Consider
{{{#!c
// a.c
#include
void defined_in_A() {
printf(""In A\n"");
}
}}}
{{{#!c
// b.c
#include
void defined_in_A();
void defined_in_B() {
printf(""In B\n"");
defined_in_A();
printf(""In B\n"");
}
}}}
and
{{{#!hs
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import System.IO
foreign import ccall ""defined_in_B"" defined_in_B :: IO ()
main :: IO ()
main = defined_in_B
}}}
and we use the GHC API to load the object files `a.o` and `b.o` (corresponding to `a.c` and `b.c`), calling `resolveObjs` after loading each object, and then load `Main` and call `Main.main`, everything works fine (the attached test case contains both `a.c`, `b.c` and `Main.hs` as well as the test program that calls into the GHC API).
However, if we load `b.o` ''before'' `a.o`, things go wrong. When we load `b.o` and call `resolveObjs` then `resolveObjs` (quite reasonably) complains that
{{{
lookupSymbol failed in relocateSection (relocate external)
b.o: unknown symbol `_defined_in_A'
}}}
since we haven't loaded `a.o` yet. But when we then load `a.o` and call `resolveObjs` again, `resolveObjs` reports okay, but something goes wrong because the program subsequently segfaults.
'''A successful run'''
I took a closer look at what happens exactly. First, let's consider the test run where we load A before B, and everything works fine, and let's look at the precise code that we actually execute when `Main.main` does the foreign call to `defined_in_B`:
{{{
# lldb Linkerbug
Current executable set to 'Linkerbug' (x86_64).
(lldb) breakpoint set -n ffi_call
Breakpoint 1: where = Linkerbug`ffi_call + 29 at ffi64.c:421, address = 0x0000000102be2eed
(lldb) run
Process 92361 launched: 'Linkerbug' (x86_64)
Loading object ""a.o""
symbol resolution ok
Loading object ""b.o""
symbol resolution ok
Loading Haskell module ""Main.hs""
ok
Running ""Main.main""
Process 92361 stopped
* thread #1: tid = 0x32048b, 0x0000000102be2eed Linkerbug`ffi_call(cif=0x000000010cc68500, fn=0x0000000104c6c210, rvalue=0x00007fff5fbff920, avalue=0x00007fff5fbff8c0) + 29 at ffi64.c:421, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000102be2eed Linkerbug`ffi_call(cif=0x000000010cc68500, fn=0x0000000104c6c210, rvalue=0x00007fff5fbff920, avalue=0x00007fff5fbff8c0) + 29 at ffi64.c:421
(lldb) disassemble -c 14 -s fn
0x104c6c210: pushq %rbp
0x104c6c211: movq %rsp, %rbp
0x104c6c214: pushq %rbx
0x104c6c215: pushq %rax
0x104c6c216: leaq 0x1d(%rip), %rbx
0x104c6c21d: movq %rbx, %rdi
0x104c6c220: callq 0x104c6c3c8
0x104c6c225: xorl %eax, %eax
0x104c6c227: callq 0x104c6b210
0x104c6c22c: movq %rbx, %rdi
0x104c6c22f: addq $0x8, %rsp
0x104c6c233: popq %rbx
0x104c6c234: popq %rbp
0x104c6c235: jmpq 0x104c6c3c8
}}}
This disassembly is the compiled code for B which, in order, does a call to `printf`, then to `defined_in_A`, and then back to `printf` (the last call is `jmpq` rather than `callq`: the C compiler did a tail call optimization). Let's make sure that this is actually true; the first call is a call to
{{{
(lldb) disassemble -c 2 -s 0x104c6c3c8
0x104c6c3c8: jmpq *-0xe(%rip)
0x104c6c3ce: addb %al, (%rax)
}}}
which is an indirect jump to
{{{
(lldb) memory read -f A -c 1 ""0x104c6c3ce - 0xe""
0x104c6c3c0: 0x00007fff84fd5b9b libsystem_c.dylib`puts
}}}
to `puts`, okay, good. Seems an unnecessary level of indirection, but that's okay. The next call is to
{{{
(lldb) disassemble -c 5 -s 0x104c6b210
0x104c6b210: pushq %rbp
0x104c6b211: movq %rsp, %rbp
0x104c6b214: leaq 0x6(%rip), %rdi
0x104c6b21b: popq %rbp
0x104c6b21c: jmpq 0x104c6b370
}}}
which is the compiled code for `defined_in_A`, which should be just a call to `printf`. Let's confirm:
{{{
(lldb) disassemble -c 2 -s 0x104c6b370
0x104c6b370: jmpq *-0xe(%rip)
0x104c6b376: addb %al, (%rax)
(lldb) memory read -f A -c 1 ""0x104c6b376 - 0xe""
0x104c6b368: 0x00007fff84fd5b9b libsystem_c.dylib`puts
}}}
Ok, all good.
'''A failed run'''
Now let's check what happens when we load the objects in the opposite order. The code that we execute is
{{{
(lldb) disassemble -c 14 -s fn
0x104c6b210: pushq %rbp
0x104c6b211: movq %rsp, %rbp
0x104c6b214: pushq %rbx
0x104c6b215: pushq %rax
0x104c6b216: leaq 0x1d(%rip), %rbx
0x104c6b21d: movq %rbx, %rdi
0x104c6b220: callq 0x104c6b3c8
0x104c6b225: xorl %eax, %eax
0x104c6b227: callq 0x104c6c210
0x104c6b22c: movq %rbx, %rdi
0x104c6b22f: addq $0x8, %rsp
0x104c6b233: popq %rbx
0x104c6b234: popq %rbp
0x104c6b235: jmpq 0x104c6b556
}}}
This immediately looks suspicious: the address of the `jmpq` (the second -- tail -- call to `printf`) is different from the first. The first `callq` is okay:
{{{
(lldb) disassemble -c 2 -s 0x104c6b3c8
0x104c6b3c8: jmpq *-0xe(%rip)
0x104c6b3ce: addb %al, (%rax)
(lldb) memory read -f A -c 1 ""0x104c6b3ce - 0xe""
0x104c6b3c0: 0x00007fff84fd5b9b libsystem_c.dylib`puts
}}}
and the call to `defined_in_A`, as well as the code ''for'' `defined_in_A`, are both ok:
{{{
(lldb) disassemble -c 5 -s 0x104c6c210
0x104c6c210: pushq %rbp
0x104c6c211: movq %rsp, %rbp
0x104c6c214: leaq 0x6(%rip), %rdi
0x104c6c21b: popq %rbp
0x104c6c21c: jmpq 0x104c6c370
(lldb) disassemble -c 2 -s 0x104c6c370
0x104c6c370: jmpq *-0xe(%rip)
0x104c6c376: addb %al, (%rax)
(lldb) memory read -f A -c 1 ""0x104c6c376 - 0xe""
0x104c6c368: 0x00007fff84fd5b9b libsystem_c.dylib`puts
}}}
However, that second call to `printf` (the `jmpq`) in `defined_in_B` is indeed wrong: it's jumping into nowhere:
{{{
(lldb) memory read -c 8 0x104c6b556
0x104c6b556: 00 00 00 00 00 00 00 00 ........
}}}
Note that somewhat surprisingly is it ''not'' the resolution of the symbol from `a.o` that is wrong; that ''does'' get resolved okay once we load `a.o`; rather, it is the jump to `puts` which is wrong (and then only the one of them)." edsko
9512 8 simonmar T9329 fails test on unregisterised i386, amd64 Compiler 7.8.3 new normal 2014-09-02T08:57:57Z "ghc-HEAD '''./configure --enable-unregistersied''' on i386-linux fails as:
{{{
=====> T9329(normal) 118 of 4091 [0, 0, 0]
cd ./codeGen/should_compile && '/root/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -optc-fno-builtin -fno-ghci-history -c T9329.cmm -no-hs-main >T9329.comp.stderr 2>&1
Compile failed (status 256) errors were:
/tmp/ghc23160_0/ghc23160_2.hc: In function ‘foo’:
/tmp/ghc23160_0/ghc23160_2.hc:10:12:
error: ‘c0_info’ undeclared (first use in this function)
*Sp = (W_)&c0_info;
^
/tmp/ghc23160_0/ghc23160_2.hc:10:12:
note: each undeclared identifier is reported only once for each function it appears in
}}}
The generated C code is:
{{{
/* GHC_PACKAGES
*/
#include ""Stg.h""
FN_(foo) {
FB_
_c0:
if ((W_)(((W_)Sp-4) < (W_)SpLim)) goto _c2; else goto _c3;
_c2:
*Sp = (W_)&c0_info;
JMP_((W_)&stg_gc_noregs);
_c3:
R1.w = 0x0;
JMP_(*((P_)(*Sp)));
FE_
}
}}}
while on UNREG x86_64 test does not fail and generates the following C:
{{{
/* GHC_PACKAGES
*/
#include ""Stg.h""
FN_(foo) {
FB_
_c0:
goto _c3;
_c3:
R1.w = 0x0;
JMP_(*((P_)(*Sp)));
FE_
}
}}}
Looks like there is no stack check at all." slyfox
9862 8 simonmar defined but not used errors on Solaris/SPARC Compiler (NCG) 7.8.2 new normal 2014-12-04T20:44:00Z "I recently tried building GHC on Solaris and I got a ton of these files when compiling the bootstrapping copy of Cabal:
{{{
""/afs/sipb/user/ezyang/ghc-7.8.2/usr/bin//ghc"" -H32m -O -Werror -Wall -H64m -O0 \
-optc-Werror -optc-Wall -optc-fno-stack-protector \
\
--make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \
-no-user-package-db \
-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
-DCABAL_VERSION=1,21,1,0 \
-DBOOTSTRAPPING \
-odir bootstrapping \
-hidir bootstrapping \
-ilibraries/Cabal/Cabal \
-ilibraries/binary/src -DGENERICS \
-ilibraries/filepath \
-ilibraries/hpc \
-w
""rm"" -f compiler/stage1/build/Config.hs
Creating compiler/stage1/build/Config.hs ...
""rm"" -f utils/ghc-pkg/dist/build/Version.hs
echo ""module Version where"" >> utils/ghc-pkg/dist/build/Version.hs
echo ""version, targetOS, targetARCH :: String"" >> utils/ghc-pkg/dist/build/Version.hs
echo ""version = \""7.9.20141204\"""" >> utils/ghc-pkg/dist/build/Version.hs
echo ""targetOS = \""solaris2\"""" >> utils/ghc-pkg/dist/build/Version.hs
echo ""targetARCH = \""sparc\"""" >> utils/ghc-pkg/dist/build/Version.hs
done.
[ 1 of 86] Compiling Distribution.Compat.CreatePipe ( libraries/Cabal/Cabal/Distribution/Compat/CreatePipe.hs, bootstrapping/Distribution/Compat/CreatePipe.o )
cc1: warnings being treated as errors
/tmp/ghc322370_0/ghc322370_21.hc: In function ‘s1xM_entry’:
/tmp/ghc322370_0/ghc322370_21.hc:21:0:
error: label ‘_c312’ defined but not used
/tmp/ghc322370_0/ghc322370_21.hc: In function ‘s1xK_entry’:
/tmp/ghc322370_0/ghc322370_21.hc:63:0:
error: label ‘_c31b’ defined but not used
}}}
Maybe the 7.8.2 codegen which I bootstrapped from is buggy in some way? It makes it mildly difficult to actually validate." ezyang
10241 8 simonmar BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely Runtime System 7.8.3 simonmar new normal 2015-04-04T11:23:09Z "BlockedIndefinatelyOnMVar exception is thrown to the main thread in below source code although the thread is not blocked indefinitely.
{{{#!hs
module Main where
import qualified Control.Concurrent.MVar as MV
import qualified Control.Concurrent as CC
import qualified Control.Exception as E
main :: IO ()
main = do
-- call this thread ""threadA""
mvar1 IO ()
errorHandler1 e = putStrLn $ ""errorHandler1 : "" ++ show e
errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO ()
errorHandler2 e = putStrLn $ ""errorHandler2 : "" ++ show e
}}}
Save above as ""mvar.hs"" and run by ghc as below.
{{{
> runhaskell mvar.hs
errorHandler1 : thread blocked indefinitely in an MVar operation
errorHandler2 : thread blocked indefinitely in an MVar operation
after error catch
after readMVar
after putMVar
}}}
BlockedIndefinitelyOnMVar thrown for mvar1 is correct. It will be caught by errorHandler1 and ""threadB"" can continue to put the value to mvar2. It means that ""threadA"" can wait for the value of mvar2 and it is not blocked indefinately.
However, BlockedIndefinitelyOnMVar is thrown for mvar2 on ""threadA"" before ""threadB"" puts value to the mvar2. I think it is incorrect.
----
I tested another case that adding ""CC.threadDelay 10000000"" before ""readMVar"" as below.
{{{#!hs
module Main where
import qualified Control.Concurrent.MVar as MV
import qualified Control.Concurrent as CC
import qualified Control.Exception as E
main :: IO ()
main = do
-- call this thread ""threadA""
mvar1 IO ()
errorHandler1 e = putStrLn $ ""errorHandler1 : "" ++ show e
errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO ()
errorHandler2 e = putStrLn $ ""errorHandler2 : "" ++ show e
}}}
And it will run correctly (BlockedIndefinitelyOnMVar is not thrown for mvar2).
{{{
> runhaskell mvar.hs
errorHandler1 : thread blocked indefinitely in an MVar operation
after error catch
after putMVar
after readMVar
}}}
----
I found this behavior is same on STM / BlockedIndefinitelyOnSTM.
{{{#!hs
module Main where
import qualified Control.Concurrent.STM as STM
import qualified Control.Concurrent as CC
import qualified Control.Exception as E
main :: IO ()
main = do
tmv1 IO ()
errorHandler1 e = putStrLn $ ""errorHandler1 : "" ++ show e
errorHandler2 :: E.BlockedIndefinitelyOnSTM -> IO ()
errorHandler2 e = putStrLn $ ""errorHandler2 : "" ++ show e
}}}
{{{
> runhaskell stm.hs
errorHandler1 : thread blocked indefinitely in an STM transaction
errorHandler2 : thread blocked indefinitely in an STM transaction
after error catch
after readTMVar
after putTMVar
}}}
----
I tested this in below versions/OSs and got same result (exception thrown for mvar2/tmv2).
ghc7.8.3 on Windows7
ghc7.8.3 on lubuntu14.04 on VirtualBox on Windows7
ghc7.8.4 on lubuntu14.04 on VirtualBox on Windows7
ghc7.10.1 on lubuntu14.04 on VirtualBox on Windows7
Similar report https://ghc.haskell.org/trac/ghc/ticket/8804 found but not the same.
(In this case, the reference to the MVar is not weak)
" asukamirai
10350 8 simonmar Should be able to specify path for eventlog output. Runtime System 7.10.1 simonmar new normal 2015-04-24T10:46:35Z Currently it is a fixed path, but the binary might run in an env where write access is restricted. literon
7952 8 simonmar Can cost-centre annotations be included in -ddump-simpl? Compiler 7.6.3 new normal 2013-06-17T19:00:47Z "I'm trying to diagnose an allocation problem. I'm using both explicit cost-centre annotations and {{{-fprof -fprof-auto}}}. I'm running with {{{+RTS -pa -hc}}}. To understand what I'm seeing in the profiles, I'm looking at the output from the {{{ghc-core}}} tool, which I think include {{{-ddump-simpl}}}.
If I understand the semantics correctly, allocations are indicated by {{{let}}} bindings in the Core. It would be ''hugely'' helpful if each of these {{{let}}} bindings were annotated with the cost centre to which the allocation is charged. A great aid to debugging!
If we can help with this idea, please let me know." nr
8404 8 simonmar Default to turning on architecture specific optimizations in the codegen Compiler (NCG) 7.6.3 new normal 2014-11-18T22:51:55Z "LLVM defaults to turning on whatever architecture specific optimizations are supported on the user's machine (e.g. `-msse4.2`). This makes programs run faster during testing and generally gives users a better perception of the compiler. If the user wants to compile for some more portable subset (e.g. when cross-compiling) he/she adds `-march`, `-mcpu`, etc flags on the command line.
To implement this we'd have to detect what CPU type is used etc and initialize our `DynFlags` based on that." tibbe
8996 8 simonmar mark more things as const in C codegen Compiler (CodeGen) 7.8.2 new normal 2014-05-01T21:37:33Z "Recently i've tried to build ghc-7.8.2 on ia64 and
it overflows so called ""short data"" section.
(it's where global 'static' variables live).
I've looked at low-hanging fruits of squashing such global ""variables"".
One source of them seems to be a string literal.
Consider one-line module:
{{{
module B (v) where v = ""hello""
}}}
in '''-fvia-C''' (or unreg) mode it generates code like
{{{
static char gibberish_str[] = ""hello"";
}}}
It uselessly eats data section.
The patch switches generator to emit:
{{{
static const char gibberish_str[] = ""hello"";
}}}
Some notes:
1. as far as I see native codegens already put ot to .rodata,
thus it should be safe.
2. I likely didn't cover more cases, like
- RelocatableReadOnlyData
- and mysterious '''pprTop (CmmData _section (Statics lbl [CmmUninitialised size]))'''
Size of unreg-stage2 on amd64 before and after the patch:
{{{
$ size inplace/lib/bin/ghc-stage2 (unpatched)
text data bss dec hex filename
81986382 20776344 44096 102806822 620b526 inplace/lib/bin/ghc-stage2
$ size inplace/lib/bin/ghc-stage2 (patched)
text data bss dec hex filename
83648494 19062936 44096 102755526 61fecc6 inplace/lib/bin/ghc-stage2
}}}
Text section increased for 1.6MBs (consts moved here, likely .rodata actually),
data section decreased for 1.7MBs.
I think with minor fiddling with linker flags we can merge equal constants later on.
Thanks!" slyfox
9143 8 simonmar feature request: way to set actual program argv Runtime System 7.8.2 new normal 2014-11-16T20:07:52Z "It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps.
An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, ""sshd: joey [priv]""
I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps:
/usr/local/propellor/docker/android-git-annex-builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex-builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux-gnu:/usr/local/propellor/docker/android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu:/usr/local/propellor/docker/android-git-annex-builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker/android-git-annex-builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker/android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/audit:/usr/local/propellor/docker/android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor
That's enough motivation for me to dig into this. :)
In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv.
So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv.
The haskell interface I'm considering would be:
displayArgv :: [String] -> IO ()
It would need to truncate strings to fit within the available argv space.
(This would not affect the argv used by System.Environment, which is a copy of argv.)" joeyhess
9321 8 simonmar Support for waiting on multiple MVars Runtime System 7.8.3 simonmar new normal 2014-07-19T02:08:49Z "A lot of code in servers uses MVars because they seem to have more desirable scalability characteristics than STM. Unfortunately, unlike STM which is composable (i.e. `readTChan chan1 readTChan chan2`), `MVar`s often require extra inefficient intermediate steps to funnel many-to-one.
A common thing for people to do when they need to funnel N `MVar`s into one is to create 1 `MVar` and N forks where each fork attempts to read from its associated `MVar` and then writes it into the one `MVar` where another fork is waiting to process the data.
This is such a waste; it produces more forks and another `MVar` where contention can occur.
In some ways it would be better if the internal representation of an `MVar` had a pointer to the ""next `MVar`"" so that we could use a function like `eitherMVar` to merge two (or more) `MVar`s together into one which can be waited on and yield values from any of the containing `MVar`s.
(I believe) the runtime would need to provide appropriate support in the scheduler so that the list is traversed instead of only the single `MVar` checked. The overhead for code which does not use this feature would probably be only 1 branch, which is acceptable.
" schyler
9350 8 simonmar Consider using xchg instead of mfence for CS stores Compiler (NCG) 7.9 new normal 2014-11-14T00:50:28Z To get sequential consistency for `atomicWriteIntArray#` we use an `mfence` instruction. An alternative is to use an `xchg` instruction (which has an implicit `lock` prefix), which might have lower latency. We should check what other compilers do. tibbe
9923 8 simonmar Offer copy-on-GC sliced arrays Runtime System 7.11 simonmar new normal 2015-01-06T22:02:39Z "It's sometimes useful to split an array and send each part on to a different computation. Slicing works very well for this sort of thing, as long as both computations run to completion or become garbage at about the same time. It can work badly, however, if one computation is completed or abandoned and the other is retained—it may only hold a tiny slice, but that's enough to keep the entire array alive.
The alternative, currently, is to copy the array to form two new arrays. This gets rid of the retention problem, but introduces a performance problem.
One way to solve these problems might be to offer sliced arrays supported by the RTS. On collection, the garbage collector would copy each slice separately, turning it into an independent (and independently collectible) array." dfeuer
10606 8 simonmar avoid redundant stores to the stack when examining already-tagged data Compiler (CodeGen) 7.11 new normal 2015-07-09T08:10:27Z "GHC compiles a function that performs case analysis on a value of an ADT like
{{{
bool :: a -> a -> Bool -> a
bool f t b = case b of
False -> f
True -> t
}}}
to Cmm of the form
{{{
{offset
cwV:
if ((Sp + -24) < SpLim) goto cwW; else goto cwX;
cwW:
R4 = R4;
R3 = R3;
R2 = R2;
R1 = Bool.bool_closure;
call (stg_gc_fun)(R4, R3, R2, R1) args: 8, res: 0, upd: 8;
cwX:
I64[Sp - 24] = cwL; -- (*)
R1 = R4;
P64[Sp - 16] = R2; -- (†1)
P64[Sp - 8] = R3; -- (†2)
Sp = Sp - 24; -- (‡)
if (R1 & 7 != 0) goto cwL; else goto cwM;
cwM:
call (I64[R1])(R1) returns to cwL, args: 8, res: 8, upd: 8;
cwL:
if (R1 & 7 >= 2) goto cwT; else goto cwU;
cwT:
R1 = P64[Sp + 16];
Sp = Sp + 24;
call stg_ap_0_fast(R1) args: 8, res: 0, upd: 8;
cwU:
R1 = P64[Sp + 8];
Sp = Sp + 24;
call stg_ap_0_fast(R1) args: 8, res: 0, upd: 8;
}
}}}
Statement (*) stores a return address for the evaluation of `b` to return to, and statements (†1), (†2) save local variables that are live in case alternatives, since they cannot be held in registers across the evaluation of `b`. But in the event that `b` is already evaluated and represented by a tagged pointer, all these stores are unnecessary: the return address written by (*) is simply dead, and the values saved in (†1), (†2) are still available in whatever locations they were copied to the stack from.
In many cases the data we examine is mostly tagged, and while the active part of the stack is likely to be in L1 cache, the cost of these stores and reads is probably still positive (barring secondary effects from changes to pipelining, branch prediction, and so on).
In this case we could certainly move the return address store (*) into block `cwM`, and possibly move the local variable stores (†1), (†2) into `cwM` as well, though it's then not clear to me how to recover the values in the alternatives (does Cmm have something like phi nodes?) I don't propose to move the statement (‡), as arithmetic on registers is essentially free anyways.
I tried implementing the part of this pertaining to the return address (*) and ran into two complications.
* For some reason, when I moved the return address store (*) into the ""data is not tagged"" branch in the Stg->Cmm translation, this also resulted in both the local variable stores (†1), (†2) and the update to Sp (‡) being sunk into both branches of the ""is the data tagged"" conditional at some point in the Cmm optimization pipeline. This was useless since they couldn't be pushed further past the branch on the returned tag value, so the result was enlarged code size that outweighed the savings of avoiding a single store. I didn't investigate exactly why this sinking was dependent on the location of the store (*), but this should be fixable.
* There may be heap checks in the alternatives. In that case, the code generator currently cleverly reuses the stack frame and info table set up for the evaluation of `b` in the heap failure branches. If we move some of the stores (*), (†1), (†2) into the evaluation branch `cwM`, then we either have to duplicate them in heap failure branches, or set up a new stack frame and info table, or do some other clever thing. Or in the worst case, only do this optimization when performing the heap check before the case (which may then become slightly more attractive).
I'm attaching the current version of my patch mainly for my own future reference; it seems to produce correct, but larger and marginally slower code, I believe for the reasons described above." rwbarton
8290 8 simonmar lookupSymbol API is unsafe Runtime System 7.9 new normal 2014-09-24T15:45:20Z "lookupSymbol is one of those functions that looks nice and innocuous on the tin, until you realize actually it doesn't actually do what you want, and seduces you into writing code that doesn't work on Mac OS X. Case in point, this recent test suite commit:
{{{
commit 02d4958903e967b78fc3bbceddc2ce8ce33901c0
Author: Edward Z. Yang
Date: Fri Sep 13 20:52:57 2013 -0700
Properly provide leading underscore when necessary.
Signed-off-by: Edward Z. Yang
}}}
Yes, the API is ""correct"" in some sense, but from a portability sense, we really want the function to add the underscore itself.
If we change this particular function, we will probably break most dynamic loading code (including GHC's). We could also add a safe variant of the function. We just need to decide something to do." ezyang
8578 8 simonmar Improvements to SpinLock implementation Runtime System 7.7 new normal 2015-07-01T17:31:07Z The SpinLock implementation has a number of deficiencies. Here is a pair of patches that improves its implementation. Let me know what you think. parcs
10303 8 simonmar Make it easier to print stack traces when debugging GHC itself Compiler 7.10.1 goldfire new normal 2015-04-19T11:51:23Z "As suggested in [http://mail.haskell.org/pipermail/ghc-devs/2015-February/008271.html the mailing list], GHC should have better support for printing its own stack trace when profiling is enabled.
This ticket is to track progress toward this goal.
There are a few moving parts:
* Just having `pprTrace` use `traceStack` is a bad idea, because a profiled compiler will spew lots and lots and lots of output. Instead, I propose a new `pprTraceStack :: String -> SDoc -> a -> a`.
* Currently, `ASSERT` will print a stack trace, but it's sometimes the wrong one. `ASSERT` throws an error; if this error is caught and re-thrown, the stack trace is at the re-throw. Instead, it should be at the origin.
* Is it worth adding a new mode in `build.mk` that enables profiling, `DEBUG`, and `-fprof-auto`, just to get good stack traces?" goldfire
7198 8 simonmar New codegen more than doubles compile time of T3294 Compiler (CodeGen) 7.4.2 7.12.1 simonmar new normal 2015-03-23T03:30:31Z "I did some preliminary investigation, and there seem to be a couple of things going on.
First, the stack allocator generates lots of unnecessary reloads at a continuation, for variables that are not used. These would be cleaned up by the sinking pass (if we were running the sinking pass), but generating them in the first place costs compile time.
Second, there is a large nested `let` expression of the form
{{{
let x = let y = let z = ...
in f z
in f y
}}}
where each let binding has a lot of free variables. So the body of each let ends up copying a ton of variables out of its closure to build the inner let binding's closure. These sequences look like:
{{{
x1 = [R1+8]
x2 = [R1+16]
...
[Hp-32] = x1
[Hp-24] = x2
...
}}}
now `CmmSink` can't currently inline all the locals because knowing that `[R1+8]` doesn't alias `[Hp-32]` is tricky (see comments in `CmmSink`). However, again, we're not even running the sinking pass because this is `-O0`. The fact that we generate all this code in the first place is a problem. The old code generator generated
{{{
[Hp-32] = [R1+8]
[Hp-24] = [R1+16]
...
}}}
which amounts to a lot less `Cmm`, and a lot less trouble for the register allocator later.
One thing we could do is flatten out the `let`s, on the grounds that the inner let binding has a lot of free variables that need to be copied when the `let` is nested. This could be based on a heuristic about the number of free variables and the amount of extra allocation that would be entailed if the `let` is never entered.
" simonmar
7723 8 simonmar iOS patch no 12: Itimer.c doesn't work on iOS Runtime System 7.7 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "As it stands, rts/posix/Itimer.c dies at runtime on iOS.
I am in the process of tidying up a solution for this." StephenBlackheath
8014 8 simonmar Assertion failure when using multithreading in debug mode. Runtime System 7.6.2 7.12.1 infoneeded normal 2014-12-23T13:34:10Z "Using the -debug compiler option in search of a (hopefully unrelated) bug, I've begun to receive the following error message a few seconds after starting my program;
{{{
Multi: internal error: ASSERTION FAILED: file rts/Schedule.c, line 1311
(GHC version 7.6.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
}}}
When I have time and if this site allows, I'll try to find what precisely in my code is generating the error and add that to this ticket. Until then, what information I can give:
- Running the same executable in non-threaded mode (executing with ""+RTS N1"" rather than ""+RTS N2"" or greater) produces no error.
- The program calls into C using the FFI interface, and there is also a callback from C back into Haskell. This would be happening around when the error occurs.
- For reasons I presume to have to do with the C++ code, the program segfaults after extended execution; this is the hopefully unrelated bug I was after when I found this." Maxander
8198 8 simonmar One-shot mode is buggy w.r.t. hs-boot files Driver 7.7 7.12.1 parcs new normal 2014-12-23T13:34:10Z "Consider
=== A.hs-boot
{{{
#!haskell
module A where
}}}
=== B.hs
{{{
#!haskell
module B where
import {-# SOURCE #-} A
}}}
=== Command Line
{{{
$ ghc -c A.hs-boot B.hs
B.hs:3:1:
Bad interface file: A.hi-boot-boot
A.hi-boot-boot: openBinaryFile: does not exist (No such file or directory)
}}}
I expect the modules to get compiled cleanly. Instead I get an error.
" parcs
8281 8 simonmar The impossible happened: primRepToFFIType Compiler 7.6.2 7.12.1 new normal 2014-12-23T13:34:10Z "I ran into this error while trying to use GHCi on the hashable package:
{{{
$ cabal repl
Preprocessing library hashable-1.2.0.10...
GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading object (static) dist/build/cbits/fnv.o ... done
Loading object (static) dist/build/cbits/getRandomBytes.o ... done
final link ... done
[1 of 4] Compiling Data.Hashable.RandomSource ( Data/Hashable/RandomSource.hs, interpreted ) [flags changed]
[2 of 4] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, interpreted ) [flags changed]
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for x86_64-apple-darwin):
primRepToFFIType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
" tibbe
8657 8 simonmar -fregs-graph still has a limit on spill slots Compiler (NCG) 7.7 7.12.1 archblob new normal 2014-12-23T13:34:10Z "The limit on spill slots was removed for the linear register allocator in 7.8, but not for `-fregs-graph`.
SHA-1 fails to compile with `-fregs-graph` in 7.8.
Related: #7679 (`-fregs-graph` generates poor code with the new codegen).
" simonmar
8971 8 simonmar Native Code Generator for 7.8 is not as optimized as 7.6.3... Compiler (NCG) 7.8.1-rc2 7.12.1 new normal 2015-05-04T07:28:19Z "The output assembly code is not as optimized for the Windows 32-bit version 7.8.1 RC2 compiler as the Windows 7.6.3 compiler (32-bit) when the option switches are exactly the same although it may not be limited to only the Windows platform; this has a negative impact on execution time for tight loops of about a factor of two times slower.
The following code will reproduce the problem:
{{{#!haskell
-- GHC_NCG_OptimizationBug.hs
-- it seems the Haskell GHC 7.8.1 NCG Native Code Generator (NCG) doesn't
-- optimize as well for (at least) the x86 target as version 7.6.3
{-# OPTIONS_GHC -O3 -rtsopts -v -dcore-lint -ddump-asm -ddump-to-file -dumpdir . #-} -- or O2
import Data.Bits
import Control.Monad.ST (runST,ST(..))
import Data.Array.Base
-- Uses a very simple Sieve of Eratosthenes to 2 ^ 18 to prove it.
accNumPrimes :: Int -> Int
accNumPrimes acc = acc `seq` runST $ do
let bfSz = (256 * 1024 - 3) `div` 2
bfLmtWrds = (bfSz + 1) `div` 32
bufw ST s (STUArray s Int Bool)) bufw
let cullp i =
let p = i + i + 3 in
let s = (p * p - 3) `div` 2 in
if s > bfSz then
let count i sm = do
sm `seq` if i > bfLmtWrds then return (acc + sm) else do
wd bfSz then cullp (i + 1) else do
unsafeWrite bufb j False
cull (j + p) in
cull s
else cullp (i + 1)
cullp 0
main =
-- run the program a number of times to get a reasonable time...
let numloops = 2000 in
let loop n acc =
acc `seq` if n <= 0 then acc else
loop (n - 1) (accNumPrimes acc) in
print $ loop numloops 0
}}}
The above code takes almost twice as long to run when compiled under 7.8.1 RC2 for Windows (32-bit) as it does for the version 7.6.3 compiler (both 32-bit compilers).
The -ddump-simpl Core dump is almost identical between the two, which is also evidenced by that using the -fllvm LLVM compiler back end switch for each results in code that runs at about the same speed for each compiler run (which would use the same Core output as used for NCG, right?).
Under Windows, the compilation and run for 7.8.1 RC2 goes like this:
{{{
*Main> :! E:\ghc-7.8.0.20140228_32\bin\ghc --make -pgmlo ""E:\llvm32\build\Release\bin\opt"" -pgmlc ""E:\llvm32\build\Release\bin\llc"" ""GHC_NCG_OptimizationBug.hs""
compile: input file WindowsVsLinuxNCG.hs
Created temporary directory: C:\Users\Gordon\AppData\Local\Temp\ghc15460_0
*** Checking old interface for main:Main:
*** Parser:
*** Renamer/typechecker:
[1 of 1] Compiling Main ( GHC_NCG_OptimizationBug.hs, GHC_NCG_OptimizationBug.o )
*** Desugar:
Result size of Desugar (after optimization)
= {terms: 260, types: 212, coercions: 0}
*** Core Linted result of Desugar (after optimization):
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 213, types: 136, coercions: 52}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 215, types: 148, coercions: 67}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=3
= {terms: 209, types: 135, coercions: 51}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 209, types: 135, coercions: 42}
*** Core Linted result of Simplifier:
*** Specialise:
Result size of Specialise = {terms: 209, types: 135, coercions: 42}
*** Core Linted result of Specialise:
*** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}):
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
PAPs = False})
= {terms: 286, types: 185, coercions: 42}
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}):
*** Float inwards:
Result size of Float inwards
= {terms: 286, types: 185, coercions: 42}
*** Core Linted result of Float inwards:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 502, types: 393, coercions: 103}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 428, types: 326, coercions: 29}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=3
= {terms: 420, types: 321, coercions: 29}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 420, types: 321, coercions: 29}
*** Core Linted result of Simplifier:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 418, types: 318, coercions: 29}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 418, types: 318, coercions: 29}
*** Core Linted result of Simplifier:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 475, types: 383, coercions: 32}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 444, types: 336, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 444, types: 336, coercions: 9}
*** Core Linted result of Simplifier:
*** Demand analysis:
Result size of Demand analysis
= {terms: 444, types: 336, coercions: 9}
*** Core Linted result of Demand analysis:
*** Worker Wrapper binds:
Result size of Worker Wrapper binds
= {terms: 579, types: 457, coercions: 9}
*** Core Linted result of Worker Wrapper binds:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 510, types: 415, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 420, types: 322, coercions: 9}
*** Core Linted result of Simplifier:
*** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}):
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
PAPs = True})
= {terms: 426, types: 326, coercions: 9}
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}):
*** Common sub-expression:
Result size of Common sub-expression
= {terms: 424, types: 326, coercions: 9}
*** Core Linted result of Common sub-expression:
*** Float inwards:
Result size of Float inwards
= {terms: 424, types: 326, coercions: 9}
*** Core Linted result of Float inwards:
*** Liberate case:
Result size of Liberate case
= {terms: 1,824, types: 1,259, coercions: 9}
*** Core Linted result of Liberate case:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 608, types: 422, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 604, types: 413, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=3
= {terms: 604, types: 413, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 604, types: 413, coercions: 9}
*** Core Linted result of Simplifier:
*** SpecConstr:
Result size of SpecConstr = {terms: 708, types: 505, coercions: 9}
*** Core Linted result of SpecConstr:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 702, types: 499, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 608, types: 405, coercions: 9}
*** Core Linted result of Simplifier:
*** Tidy Core:
Result size of Tidy Core = {terms: 608, types: 405, coercions: 9}
*** Core Linted result of Tidy Core:
*** CorePrep:
Result size of CorePrep = {terms: 825, types: 489, coercions: 9}
*** Core Linted result of CorePrep:
*** Stg2Stg:
*** CodeOutput:
*** New CodeGen:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** CPSZ:
*** Assembler:
""E:\ghc-7.8.0.20140228_32\lib/../mingw/bin/gcc.exe"" ""-U__i686"" ""-fno-stack-protector"" ""-DTABLES_NEXT_TO_CODE"" ""-I."" ""-x"" ""assembler-with-cpp"" ""-c"" ""C:\Users\Gordon\AppData\Local\Temp\ghc15460_0\ghc15460_2.s"" ""-o"" ""GHC_NCG_OptimizationBug.o""
Linking GHC_NCG_OptimizationBug.exe ...
*Main> :! GHC_NCG_OptimizationBug +RTS -s
46000000
32,965,096 bytes allocated in the heap
7,032 bytes copied during GC
41,756 bytes maximum residency (2 sample(s))
19,684 bytes maximum slop
2 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 61 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s
Gen 1 2 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s
INIT time 0.00s ( 0.00s elapsed)
MUT time 1.73s ( 1.73s elapsed)
GC time 0.00s ( 0.00s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 1.73s ( 1.73s elapsed)
%GC time 0.0% (0.0% elapsed)
Alloc rate 19,006,902 bytes per MUT second
Productivity 100.0% of total user, 100.2% of total elapsed
}}}
whereas under version 7.6.3 goes like this:
{{{
*Main> :! E:\ghc-7.6.3_32\bin\ghc --make -pgmlo ""E:\llvm32\build\Release\bin\opt"" -pgmlc ""E:\llvm32\build\Release\bin\llc"" ""GHC_NCG_OptimizationBug.hs""
compile: input file GHC_NCG_OptimizationBug.hs
Created temporary directory: C:\Users\Gordon\AppData\Local\Temp\ghc28200_0
*** Checking old interface for main:Main:
*** Parser:
*** Renamer/typechecker:
[1 of 1] Compiling Main ( GHC_NCG_OptimizationBug.hs, GHC_NCG_OptimizationBug.o )
*** Desugar:
Result size of Desugar (after optimization)
= {terms: 247, types: 212, coercions: 0}
*** Core Linted result of Desugar (after optimization):
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 198, types: 132, coercions: 35}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 200, types: 144, coercions: 43}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=3
= {terms: 194, types: 131, coercions: 57}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 194, types: 131, coercions: 39}
*** Core Linted result of Simplifier:
*** Specialise:
Result size of Specialise = {terms: 194, types: 131, coercions: 39}
*** Core Linted result of Specialise:
*** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}):
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
PAPs = False})
= {terms: 277, types: 191, coercions: 39}
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}):
*** Float inwards:
Result size of Float inwards
= {terms: 277, types: 191, coercions: 39}
*** Core Linted result of Float inwards:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 514, types: 403, coercions: 103}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 420, types: 317, coercions: 29}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=3
= {terms: 412, types: 312, coercions: 29}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 412, types: 312, coercions: 29}
*** Core Linted result of Simplifier:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 410, types: 309, coercions: 29}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 410, types: 309, coercions: 29}
*** Core Linted result of Simplifier:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 455, types: 364, coercions: 32}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 422, types: 317, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 422, types: 317, coercions: 9}
*** Core Linted result of Simplifier:
*** Demand analysis:
Result size of Demand analysis
= {terms: 422, types: 317, coercions: 9}
*** Core Linted result of Demand analysis:
*** Worker Wrapper binds:
Result size of Worker Wrapper binds
= {terms: 536, types: 427, coercions: 9}
*** Core Linted result of Worker Wrapper binds:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 480, types: 391, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 400, types: 306, coercions: 9}
*** Core Linted result of Simplifier:
*** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}):
Result size of Float out(FOS {Lam = Just 0,
Consts = True,
PAPs = True})
= {terms: 408, types: 311, coercions: 9}
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}):
*** Common sub-expression:
Result size of Common sub-expression
= {terms: 406, types: 311, coercions: 9}
*** Core Linted result of Common sub-expression:
*** Float inwards:
Result size of Float inwards
= {terms: 406, types: 311, coercions: 9}
*** Core Linted result of Float inwards:
*** Liberate case:
Result size of Liberate case
= {terms: 1,186, types: 824, coercions: 9}
*** Core Linted result of Liberate case:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 585, types: 411, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 569, types: 392, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=3
= {terms: 569, types: 392, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 569, types: 392, coercions: 9}
*** Core Linted result of Simplifier:
*** SpecConstr:
Result size of SpecConstr = {terms: 746, types: 566, coercions: 9}
*** Core Linted result of SpecConstr:
*** Simplifier:
Result size of Simplifier iteration=1
= {terms: 739, types: 560, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier iteration=2
= {terms: 762, types: 546, coercions: 9}
*** Core Linted result of Simplifier:
Result size of Simplifier = {terms: 642, types: 402, coercions: 9}
*** Core Linted result of Simplifier:
*** Tidy Core:
Result size of Tidy Core = {terms: 642, types: 402, coercions: 9}
*** Core Linted result of Tidy Core:
writeBinIface: 10 Names
writeBinIface: 34 dict entries
*** CorePrep:
Result size of CorePrep = {terms: 779, types: 483, coercions: 9}
*** Core Linted result of CorePrep:
*** Stg2Stg:
*** CodeOutput:
*** CodeGen:
*** Assembler:
""E:\ghc-7.6.3_32\lib/../mingw/bin/gcc.exe"" ""-fno-stack-protector"" ""-Wl,--hash-size=31"" ""-Wl,--reduce-memory-overheads"" ""-I."" ""-c"" ""C:\Users\Gordon\AppData\Local\Temp\ghc28200_0\ghc28200_0.s"" ""-o"" ""GHC_NCG_OptimizationBug.o""
Linking GHC_NCG_OptimizationBug.exe ...
*Main> :! GHC_NCG_OptimizationBug +RTS -s
46000000
32,989,396 bytes allocated in the heap
4,976 bytes copied during GC
41,860 bytes maximum residency (2 sample(s))
19,580 bytes maximum slop
2 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 61 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s
Gen 1 2 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s
INIT time 0.00s ( 0.00s elapsed)
MUT time 0.64s ( 0.64s elapsed)
GC time 0.00s ( 0.00s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 0.66s ( 0.64s elapsed)
%GC time 0.0% (0.1% elapsed)
Alloc rate 51,495,642 bytes per MUT second
Productivity 100.0% of total user, 102.3% of total elapsed
}}}
Looking at the ASM dump for the innermost tight culling loop reveals the problem, with 7.8.1 RC2 outputting as follow:
{{{
_n3nx:
movl 76(%esp),%ecx
_c3gf:
cmpl %ecx,%eax
jg _c3jB
_c3jC:
movl %eax,%edx
sarl $5,%edx
movl %ecx,76(%esp)
movl $1,%ecx
movl %ecx,280(%esp)
movl %eax,%ecx
andl $31,%ecx
movl %eax,292(%esp)
movl 280(%esp),%eax
shll %cl,%eax
xorl $-1,%eax
movl 64(%esp),%ecx
addl $8,%ecx
movl (%ecx,%edx,4),%ecx
andl %eax,%ecx
movl 64(%esp),%eax
addl $8,%eax
movl %ecx,(%eax,%edx,4)
movl 292(%esp),%eax
addl $3,%eax
jmp _n3nx
}}}
and 7.6.3 outputting as follows:
{{{
.text
.align 4,0x90
.long 1894
.long 32
s1GZ_info:
_c1YB:
cmpl 16(%ebp),%esi
jg _c1YE
movl %esi,%edx
sarl $5,%edx
movl $1,%eax
movl %esi,%ecx
andl $31,%ecx
shll %cl,%eax
xorl $-1,%eax
movl 12(%ebp),%ecx
movl 8(%ecx,%edx,4),%ecx
andl %eax,%ecx
movl 12(%ebp),%eax
movl %ecx,8(%eax,%edx,4)
addl 4(%ebp),%esi
jmp s1GZ_info
_c1YE:
movl 8(%ebp),%esi
addl $8,%ebp
jmp s1GB_info
}}}
The second code is clearly much more efficient, with the only memory access reading/writing the sieve buffer array and one register reload of the prime value to add to the current position index, whereas the first (7.8.1 RC2) code has three register spills and five register re-loads, almost as if debugging were still turned on.
This bug was tested under Windows, but likely applies to other platforms, at least for 32-bit versions but also possibly to others." GordonBGood
10445 8 simonmar Wrong stack space size when using -Ksize Compiler 7.10.1 7.12.1 archblob patch normal 2015-06-12T16:45:39Z "After compiling the first example in https://wiki.haskell.org/Performance/Accumulating_parameter:
{{{
$ cat Test.hs
len :: [a] -> Int
len [] = 0
len (x:xs) = len xs + 1
main :: IO ()
main = print $ len [1..1000000]
}}}
{{{
$ ghc Test.hs -rtsopts
}}}
and running
{{{
./Test +RTS -K10K
}}}
GHC 7.6.3 reports
{{{
Stack space overflow: current size 10240 bytes.
}}}
GHC 7.8.4 reports
{{{
Stack space overflow: current size 33632 bytes.
}}}
and GHC 7.10.1 reports
{{{
Stack space overflow: current size 99136 bytes.
}}}
GHC 7.8.3 and 7.10.1 report an incorrect stack space size.
" asr
7337 8 simonmar GHC does not generate great code for bit-level rotation Compiler (NCG) 7.6.1 7.12.1 new normal 2014-12-23T13:34:10Z I'm working on some hashing functions at the moment, and I notice that GHC generates an {{{or}}} and a pair of shifts for a rotate. The LLVM back end is smart enough to recover the code's intent via strength reduction and emit a single {{{rot}}} instruction, but the regular code generator emits three instructions. bos
8199 8 simonmar Get rid of HEAP_ALLOCED Compiler 7.7 7.12.1 ezyang new normal 2015-07-29T15:25:35Z "This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC (especially for large/scattered heaps), as long as we can keep the cost of indirections down.
The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. Version 2 of the patchset is probably correct.
Blocking problems:
* Properly handle the Windows DLL case (e.g. SRTs). We will probably have to reorganize how the indirections are laid out.
* ~~Make it work for GHCi linking of static objects.~~ Blocked on #2841, I have it working for ELF, and can make it work for other platforms as soon as I get relevant machines.
* Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead)
* Does not work with unloadObj (see comments below)
Performance improvements possible:
* ~~This patch introduces a lot of new symbols; ensure we are not unduly polluting the symbol tables. (In particular, I think _static_closure symbols can be made hidden).~~ ~~I've eliminated all of these except for the init symbols, which cross the stub object and assembly file boundary, and so would need to be made invisible by the linker.~~ I needed to make local info tables public.
* Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working.
* The old HEAP_ALLOCED is supposed to be pessimal on very large heaps. Do some performance tests under those workloads.
* Make sure the extra indirection is not causing any C-- optimizations to stop firing (it might be, because I put it in as a literal CmmLoad)
* Once an static thunk is updated, we can tag the indirection to let other code segments to know about the good news. One way to do this is have the update frame for a static indirection should have a reference to the *indirection*, not the closure itself. However, this scheme will not affect other static closures which have references to the thunk.
* Closure tables should have their indirections short-circuited by the initialization code. But maybe it is not worth the cost of telling the RTS about the closure tables (also, they would need to be made writeable).
* We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun.
* ~~Save tags inside the indirection tables, so that we don't spend instructions retagging after the following the indirection.~~ Done.
* ~~Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs.~~ After discussing this with some folks, it seems that there isn't really a portable way to do this when we are using the system dynamic linker to load libraries at startup. The problem is that we need to somehow get a list of all the GHC-compiled libraries which got loaded, and really the easiest way to get that is to just build it ourselves.
* ~~Need to implement a new megablock tracking structure so we can free/check for lost blocks~~. Now that efficient lookup is not necessary, perhaps we can write-optimize the megablock tracking structures.
Speculative improvements:
* Now that static lives in a block, can we GC them like we GC normal data? This would be beneficial for static thunks, which now can have their indirections completely removed; reverting CAFs may be somewhat tricky, however.
* Now that HEAP_ALLOCED is greatly simplified, can we further simply some aspects of the GC? At the very least, we ought to be able to make megablock allocation cheaper, by figuring out how to remove the spinlocks, etc.
* Another possibility is to adopt a hybrid approach, where we manually lay out closures when compiling statically, and indirect when compiling dynamically. In some sense, this gets the best of both worlds, since we expect to not pay any extra cost for indirection due to PIC." ezyang
9342 8 simonmar Branchless arithmetic operations Compiler (CodeGen) 7.8.3 7.12.1 new normal 2014-12-23T13:34:10Z "While working on #9281 I noticed sub-optimal code generation for common arithmetic operations on `Int`. Below are some examples of code generation, where the branchless versions may be desirable on modern CPUs:
= `abs`
{{{#!hs
-- base version
absI# :: Int# -> Int#
absI# i# = i'#
where
!(I# i'#) = abs (I# i#)
-- optimized version
optAbsI# :: Int# -> Int#
optAbsI# i# = (i# `xorI#` nsign) -# nsign
where
-- nsign = i# Int#
sgnI# i# = i'#
where
!(I# i'#) = signum (I# i#)
optSgnI# :: Int# -> Int#
optSgnI# x# = (x# ># 0#) -# (x# Int# -> Int#
cmpI# x# y# = dataToTag# (compare (I# x#) (I# y#))
-- returns 0, 1 or 2, can be fed to tagToEnum# :: Ordering
optCmpI# :: Int# -> Int# -> Int#
optCmpI# x# y# = 1# +# (x# ># y#) -# (x# IO a -> IO a -> IO a
catchHeapOverflow limitBytes handler action = ...
}}}
It sets a memory usage limit for the current thread (and any child threads, ideally). If this limit is surpassed while performing the action, it invokes the handler (with the usage limit lifted).
Granted, the notion of a thread using too much memory makes less sense when objects are shared between threads. Should a thread be blamed for pointing to a lot of memory that another thread gave it? I don't know. Should a thread be blamed for consuming a lot of memory while evaluating a thunk? Absolutely. In my opinion, handling the edge cases perfectly is not as important as being able to do this at all. As long as the user performs all the necessary calculations in one thread and does not export unforced thunks to other threads, s/he should be fine." joeyadams
7934 8 simonmar usleep hangs, no threads Runtime System 7.4.2 new normal 2015-03-14T21:47:08Z "import System.Posix.Unistd
main = flip mapM_ [0..] $ \i -> do
usleep 100000
print i
===
The above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to print).
The documentation for usleep warns about bad interactions with threads, but the above program doesn't use any.
The problem also occurs with nanosleep, but not with threadDelay.
#1156 sounds related, but this time the problem also occurs without -threaded.
===
workaround: use threadDelay.
" gelisam
9232 8 simonmar Stats file has wrong numbers Runtime System 7.8.2 simonmar new low 2014-06-24T10:33:25Z "The summary numbers in the file generated with the -S flag cannot be right. Here's an example:
{{{
1,943,795,468 bytes allocated in the heap
17,587,189,232 bytes copied during GC
}}}
The corresponding numbers with ghc 7.2 are
{{{
193,859,474,520 bytes allocated in the heap
17,766,908,288 bytes copied during GC
}}}
While it's theoretically possible that allocation has improved that much, I don't believe it." augustss
9525 8 simonmar +RTS -xc stack trace sometimes reported twice Runtime System 7.8.3 osa1 new low 2014-08-30T10:57:18Z "Not sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance.
Stack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected:
{{{#!haskell
f :: Int -> Int
f = error ""hello""
main = print (f 20)
}}}
{{{
➜ ghc_patch ./error +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
Main.f,
called from Main.CAF
--> evaluated by: Main.main,
called from Main.CAF
error: hello
}}}
But if I change it to this:
{{{#!haskell
f :: Int -> Int
f x =
let x = x + 20
in x
main = print (f 20)
}}}
Stack trace is reported twice:
{{{
➜ ghc_patch ./error +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.f.x,
called from Main.f,
called from Main.main,
called from Main.CAF
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.f.x,
called from Main.f,
called from Main.main,
called from Main.CAF
error: <>
}}}
Can anyone confirm that this is really a bug?" osa1
9577 8 simonmar String literals are wasting space Compiler (NCG) 7.8.2 xnyhps new low 2014-09-25T08:54:30Z "For [https://phabricator.haskell.org/D199 D199] I looked into how string literals are compiled down by GHC.
On 64-bit OS X, a simple string `""AAA""` turns into assembly:
{{{
.const
.align 3
.align 0
c38E_str:
.byte 65
.byte 65
.byte 65
.byte 0
}}}
(And also something that invokes `unpackCString#`, but that isn't relevant here.)
(`MkCore.mkStringExprFS` -> `CmmUtils.mkByteStringCLit` -> `compiler/nativeGen/X86/Ppr.pprSectionHeader`.)
Note how this:
* Is 8 byte aligned.
* Is a `.const` section.
I can't find any reason why string literals would need to be 8-byte aligned on OS X. There might be a small benefit in performance to read data starting 8-byte aligned, but I doubt doing that for string literals would be a meaningful difference. Assembly from both clang and gcc does not align string literals.
The trivial program:
{{{#!hs
main :: IO ()
main = return ()
}}}
has almost 5kB of wasted space of padding between all strings the Prelude brings in, built with GHC HEAD.
The fact that it is a `.const` section, instead of `.cstring` (https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html#//apple_ref/doc/uid/TP30000823-TPXREF127) means duplicate strings aren't shared by the assembler. GHC floats out string literals to the top-level and uses CSE to eliminate duplicates, but that only works in a single modules. Strings shared between different modules end up as duplicate strings in an executable.
The same program as above also has ~4kB of wasted space due to duplicate Prelude strings (`""base""` occurs 16 times!). Compared to the total binary size (4MB after stripping), removing this redundant data wouldn't be a big improvement (0.2%), but I still think it can be a worthwile optimization.
I think this can be solved quite easily by creating a new section header for literal strings, which is unaligned and of type `.cstring`." xnyhps
9666 8 simonmar runtime crashing with +RTS -w -h Runtime System 7.8.3 simonmar new low 2014-11-10T16:51:14Z "A combination of the RTS flags -w and -h makes executables generated with ghc crash at runtime. Does not happen always; my current guess is that a gc run triggers the bug.
Reproducible with the following input:
'''Main.hs'''
{{{#!hs
module Main where
import qualified Data.Map.Strict as M
main = print $ M.lookup 10 $ M.fromList [ (i,i)
| i ghc -rtsopts Main.hs && ./Main +RTS -w -h
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
Main: internal error: heapCensus, unknown object: 4093
(GHC version 7.8.3 for x86_64_unknown_linux)
}}}
optimization level did not change the outcome.
I am aware that -w is marked experimental, and I don't need it. Just noticed the crashing.
@simon: you get added to Cc (one more time) every time I press ""preview"", it seems. Doubt that is intentional.. I'll leave you in Cc just so you get this message. (hmm.. where is the bug-tracker bug-tracker..)" lspitzner
10199 8 simonmar Sending SIGINT to a program that uses forkOS may crash with various errors Runtime System 7.10.1 simonmar new low 2015-04-06T07:52:19Z "This is the program:
{{{#!hs
module Main ( main ) where
import Control.Concurrent
import Control.Monad
main :: IO ()
main = recursive 0
where
recursive n = do
tid IO ()
boot path = do
r do
r' print v
LoadFailure msg -> print msg
MakeFailure es -> putStrLn (""Failed: "" ++ intercalate "" "" es)
main = do
boot ""Foo.hs""
}}}
where Foo.hs is
{{{
module Foo where
result = 2 :: Int
}}}
Here are the things that, as far as I can tell, need to be handled:
* We should ensure consistency between the host and the object file being uploaded. For example, if you load an un-profiled object file into a profiled binary, GHC will eat all your puppies. A simple way to do this is look for a symbol (e.g. CC_LIST) which is only ever exported when something is profiled and barf it is encountered.
* This current code fails with {{{test: Foo.o: unknown symbol `CC_LIST'}}}, much the same way GHCi used to fail. This particular problem is (I think) that we don’t store CC_LIST and other externsymbols in our global hash table, so the linker thinks that they don’t exist, when they do. CC_LIST and friends should be special-cased or added to the table. I have a patch for that; it's pretty easy.
* We don’t run ctors which setup CC_LIST with all of the cost-centres from the loaded module; we need to teach the linker to do that. The relevant bug is #5435.
* We need to come up with some sensible way of unloading cost-centres from CC_LIST and friends; we could make CC_LIST doubly-linked and then just excise the cost-centre in a destructor, but freeing the actual allocated CostCentre is more difficult. For now, we might just live with the memory leak, but see wiki:""Commentary/ResourceLimits#Memoryleaks"" for a possible better implementation strategy. Whatever cleanup is done here should be registered as a destructor for the library. Maybe #8039 solves this problem.
* Tests!
But that’s it; everything else should work normally. Something similar should apply to ticky builds. Sans destructors, there is a good chance this shindig may already work for dynamically linked apps." ezyang
8504 8 simonmar Provide minor GC residency estimates Runtime System 7.7 simonmar new lowest 2013-11-06T09:52:39Z "Currently, the residency statistics (e.g. max residency and current residency) are only updated when a major garbage collection occurs. While this is the only way to ensure an accurate residency count, there are times when a residency estimate would be desirable, since only taking the sample on major GC can be somewhat low resolution. We already collect and report this information on verbose GC stats, so all that needs to be done is to expose it via GHC.Stats. Should be an easy patch, good for someone who wants to play around in the RTS.
Here is a simple patch that switches residency to the inaccurate version:
{{{
diff --git a/rts/Stats.c b/rts/Stats.c
index c19f23c..c71d0fb 100644
--- a/rts/Stats.c
+++ b/rts/Stats.c
@@ -449,7 +449,6 @@ stat_endGC (Capability *cap, gc_thread *gct,
CAPSET_HEAP_DEFAULT,
mblocks_allocated * MBLOCK_SIZE_W * sizeof(W_));
- if (gen == RtsFlags.GcFlags.generations-1) { /* major GC? */
if (live > max_residency) {
max_residency = live;
}
@@ -459,7 +458,6 @@ stat_endGC (Capability *cap, gc_thread *gct,
traceEventHeapLive(cap,
CAPSET_HEAP_DEFAULT,
live * sizeof(W_));
- }
if (slop > max_slop) max_slop = slop;
}
}}}" ezyang
3251 8 simonmar split rts headers into public and private Runtime System 6.10.2 7.12.1 new lowest 2014-12-23T13:33:22Z "C code calling into the rts, eg to initialise it, uses header files like `HsFFI.h` or `RtsAPI.h`. However these header files that describe the public API of the rts are installed in `$libdir/ghc-x.y/include` where as the standard location for public header files should be `$prefix/include/ghc-x.y`.
The private header files that are only used by `.hc` files when compiling `-fvia-C` should remain where they are. So this would involve identifying which headers are public and which are private.
Once we have a set of public header files it might be nice to provide a `pkg-config` .pc file to make it easy for C programs to locate the header files and libraries. Eg it should be possible to compile and link a C program that uses the RTS public API with just:
{{{
gcc -o main main.c `pkg-config --cflags --libs ghc-rts-6.12.1`
}}}
and this would supply the flags like
{{{
-I/usr/include/ghc-6.12.1 -lHSrts -L/usr/lib/ghc-6.12.1
}}}
Note that `pkg-config` supports both shared and static libs (ie allows specifying the extra private deps of a static lib, eg `-lm -ldl` etc)." duncan
8964 8 simonmar split_marker_entry assert breaks -split-objs and -ddump-opt-cmm Compiler 7.9 ⊥ new lowest 2014-04-07T11:13:29Z ...since the pretty-printer attempts to force the blocks list of the split_marker_entry proc. I'm not really sure what the right way to fix this is: just provide an empty block list, or hack the pretty-printer to treat split markers specially. But should be easy to fix. ezyang
9809 32 simonmar, AndreasVoellmy, davean Overwhelming the TimerManager Runtime System 7.10.1 simonmar new normal 2015-04-17T18:30:57Z "I was talking on IRC with davean about an issue that potentially could have been related to STM (I don't think it is at all after investigating) and I reduced the issue to the following program:
{{{#!hs
-- Main.hs
module Main where
import Control.Monad
import Control.Concurrent
import Control.Concurrent.STM
import System.Environment
main :: IO ()
main = do
as replicateM_ 100000 . void . forkIO . void $ registerDelay 10
_ -> replicateM_ 100000 . void $ registerDelay 10
threadDelay 1000
}}}
This ends up registering a lot of events with the TimerManager. With the ""-f"" flag it does so from many threads and when run that way it appears to eventually overwhelm the TimerManager and causing over 350 MB total memory in use.
{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.9.20141115
$ ghc -O2 -threaded -debug Main.hs -o Main-head
...
$ ./Main-head -f +RTS -s
3,566,966,936 bytes allocated in the heap
4,200,021,784 bytes copied during GC
118,273,720 bytes maximum residency (96 sample(s))
12,649,480 bytes maximum slop
354 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 6350 colls, 0 par 2.430s 2.434s 0.0004s 0.0073s
Gen 1 96 colls, 0 par 7.438s 7.441s 0.0775s 0.2526s
TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.002s ( 0.002s elapsed)
MUT time 0.461s ( 0.460s elapsed)
GC time 9.869s ( 9.875s elapsed)
EXIT time 0.003s ( 0.003s elapsed)
Total time 10.336s ( 10.340s elapsed)
Alloc rate 7,741,472,461 bytes per MUT second
Productivity 4.5% of total user, 4.5% of total elapsed
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0
}}}
Running without forking many threads and the total memory in use stays low (3 MB).
{{{
154,305,648 bytes allocated in the heap
16,922,272 bytes copied during GC
1,378,608 bytes maximum residency (3 sample(s))
28,520 bytes maximum slop
3 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 298 colls, 0 par 0.056s 0.056s 0.0002s 0.0015s
Gen 1 3 colls, 0 par 0.005s 0.005s 0.0017s 0.0047s
TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.001s ( 0.001s elapsed)
MUT time 0.148s ( 0.148s elapsed)
GC time 0.061s ( 0.061s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 0.211s ( 0.210s elapsed)
Alloc rate 1,042,557,595 bytes per MUT second
Productivity 70.8% of total user, 71.2% of total elapsed
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0
}}}
Using 7.6.3, things don't get out of hand, also with 3 MB total memory use.
{{{
$ ./Main-7.6.3 -f +RTS -s
213,519,392 bytes allocated in the heap
116,111,712 bytes copied during GC
505,080 bytes maximum residency (11 sample(s))
113,032 bytes maximum slop
3 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 403 colls, 0 par 0.33s 0.33s 0.0008s 0.0028s
Gen 1 11 colls, 0 par 0.01s 0.01s 0.0011s 0.0019s
TASKS: 3 (1 bound, 2 peak workers (2 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.00s ( 0.00s elapsed)
MUT time 1.99s ( 1.50s elapsed)
GC time 0.34s ( 0.34s elapsed)
EXIT time 0.00s ( 0.00s elapsed)
Total time 2.33s ( 1.84s elapsed)
Alloc rate 107,426,859 bytes per MUT second
Productivity 85.5% of total user, 108.1% of total elapsed
gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0
}}}
I looked for causes and eliminated any `STM` interactions causing problems (`STM` shows up in the `Unique` values and in creating a `TVar` for the registered delay) but did discover that the `emTimeouts` queue gets very large at some point when executing with ""-f"". If I print the size of `expired` on this line:
https://github.com/ghc/ghc/blob/021b7978d14799bae779907faf7490cfd21b3f46/libraries/base/GHC/Event/TimerManager.hs#L226
I end up seeing somewhere from 4 to 20 events for a while then eventually it jumps up to 80000 or so. Perhaps davean can chime in about the particular use case that he has that I reduced to this simple program for a more real world use." fryguybob
8311 36 simonmar, carter.schonwald@… suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) Compiler (NCG) 7.7 new normal 2014-11-19T21:11:10Z "This appears to be the x86 assembly for a specialization for `even :: Int -> Bool` that's produced by a SPECIALISE pragma for `(^) :: Int -> Int -> Int` in GHC.Real. The relevant bit is offsets `0x2c` through `0x3b`.
{{{
0000000c :
c: 8b 45 00 mov 0x0(%ebp),%eax
f: c7 45 00 2c 00 00 00 movl $0x2c,0x0(%ebp)
12: R_386_32 .text
16: 89 c6 mov %eax,%esi
18: f7 c6 03 00 00 00 test $0x3,%esi
1e: 75 0c jne 2c
20: ff 26 jmp *(%esi)
22: 66 90 xchg %ax,%ax
24: 00 00 add %al,(%eax)
26: 00 00 add %al,(%eax)
28: 20 00 and %al,(%eax)
...
0000002c :
2c: b8 02 00 00 00 mov $0x2,%eax
31: 89 c1 mov %eax,%ecx
33: 8b 46 03 mov 0x3(%esi),%eax
36: 99 cltd
37: f7 f9 idiv %ecx
39: 85 d2 test %edx,%edx
3b: 75 0b jne 48
3d: be 02 00 00 00 mov $0x2,%esi
3e: R_386_32 ghczmprim_GHCziTypes_True_closure
42: 83 c5 04 add $0x4,%ebp
45: ff 65 00 jmp *0x0(%ebp)
48: be 01 00 00 00 mov $0x1,%esi
49: R_386_32 ghczmprim_GHCziTypes_False_closure
4d: 83 c5 04 add $0x4,%ebp
50: ff 65 00 jmp *0x0(%ebp)
}}}
It would be much better to do a simple `testb $0x1,0x3(%esi)` in place of the first six instructions of `c8gO_info`.
The NCG generates similar code on x86_64." rwbarton
9660 16 simonmar, dfeuer unnecessary indirect jump when returning a case scrutinee Compiler (CodeGen) 7.8.3 new normal 2014-10-22T14:57:42Z "I happened to be looking at the Cmm for this code (ghc 7.8.3, -O2)
{{{#!hs
f :: Int -> Int
f x = if x < 0 then x else x+1
}}}
and I noticed something a bit funny about it:
{{{
c12e:
if ((Sp + -8) < SpLim) goto c12z; else goto c12A;
c12z:
R2 = R2;
R1 = Test.f_closure;
call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8;
c12A:
I64[Sp - 8] = c12b;
R1 = R2;
Sp = Sp - 8;
if (R1 & 7 != 0) goto c12b; else goto c12c;
c12c:
call (I64[R1])(R1) returns to c12b, args: 8, res: 8, upd: 8;
c12b:
Hp = Hp + 16;
if (Hp > HpLim) goto c12y; else goto c12x;
c12y:
HpAlloc = 16;
R1 = R1;
call stg_gc_unpt_r1(R1) returns to c12b, args: 8, res: 8, upd: 8;
c12x:
_s11Q::I64 = I64[R1 + 7];
if (%MO_S_Lt_W64(_s11Q::I64, 0)) goto c12u; else goto c12v;
c12u:
Hp = Hp - 16;
R1 = R1 & (-8); /* :set -package array
# in a different terminal:
pidstat -t -p $(pidof ghc) | grep ghc_worker
kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc)
# SIGCONT doesn't really resume it, you have to run fg in the terminal where it runs
pidstat -t -p $(pidof ghc) | grep ghc_worker
kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc)
pidstat -t -p $(pidof ghc) | grep ghc_worker
kill -SIGSTOP $(pidof ghc); kill -SIGCONT $(pidof ghc)
pidstat -t -p $(pidof ghc) | grep ghc_worker
}}}
You get:
{{{
$ pidstat -t -p $(pidof ghc) | grep ghc_worker
06:40:55 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker
06:40:55 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker
06:40:55 AM - 2848955 0.00 0.00 0.00 0.00 21 |__ghc_worker
06:40:55 AM - 2848957 0.00 0.00 0.00 0.00 21 |__ghc_worker
06:40:55 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker
06:40:55 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker
06:40:55 AM - 2848960 0.00 0.00 0.00 0.00 3 |__ghc_worker
06:40:55 AM - 2848961 0.00 0.00 0.00 0.00 2 |__ghc_worker
06:40:55 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker
06:40:55 AM - 2848963 0.00 0.00 0.00 0.00 21 |__ghc_worker
06:40:55 AM - 2848964 0.00 0.00 0.00 0.00 31 |__ghc_worker
06:40:55 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker
06:40:55 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker
06:40:55 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker
06:40:55 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker
06:40:55 AM - 2848969 0.00 0.00 0.00 0.00 22 |__ghc_worker
06:40:55 AM - 2848970 0.00 0.00 0.00 0.00 31 |__ghc_worker
}}}
{{{
$ pidstat -t -p $(pidof ghc) | grep ghc_worker
06:41:37 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker
06:41:37 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker
06:41:37 AM - 2848955 0.00 0.00 0.00 0.00 3 |__ghc_worker
06:41:37 AM - 2848957 0.00 0.00 0.00 0.00 3 |__ghc_worker
06:41:37 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker
06:41:37 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker
06:41:37 AM - 2848960 0.00 0.00 0.00 0.00 5 |__ghc_worker
06:41:37 AM - 2848961 0.00 0.00 0.00 0.00 5 |__ghc_worker
06:41:37 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker
06:41:37 AM - 2848963 0.00 0.00 0.00 0.00 7 |__ghc_worker
06:41:37 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker
06:41:37 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker
06:41:37 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker
06:41:37 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker
06:41:37 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker
06:41:37 AM - 2848969 0.00 0.00 0.00 0.00 8 |__ghc_worker
06:41:37 AM - 2848970 0.00 0.00 0.00 0.00 14 |__ghc_worker
06:41:37 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker
06:41:37 AM - 2850194 0.00 0.00 0.00 0.00 33 |__ghc_worker
06:41:37 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker
06:41:37 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker
06:41:37 AM - 2850198 0.00 0.00 0.00 0.00 10 |__ghc_worker
06:41:37 AM - 2850199 0.00 0.00 0.00 0.00 17 |__ghc_worker
06:41:37 AM - 2850294 0.00 0.00 0.00 0.00 21 |__ghc_worker
06:41:37 AM - 2850295 0.00 0.00 0.00 0.00 31 |__ghc_worker
}}}
{{{
$ pidstat -t -p $(pidof ghc) | grep ghc_worker
06:42:43 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker
06:42:43 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker
06:42:43 AM - 2848955 0.00 0.00 0.00 0.00 3 |__ghc_worker
06:42:43 AM - 2848957 0.00 0.00 0.00 0.00 7 |__ghc_worker
06:42:43 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker
06:42:43 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker
06:42:43 AM - 2848960 0.00 0.00 0.00 0.00 9 |__ghc_worker
06:42:43 AM - 2848961 0.00 0.00 0.00 0.00 0 |__ghc_worker
06:42:43 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker
06:42:43 AM - 2848963 0.00 0.00 0.00 0.00 4 |__ghc_worker
06:42:43 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker
06:42:43 AM - 2848965 0.00 0.00 0.00 0.00 11 |__ghc_worker
06:42:43 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker
06:42:43 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker
06:42:43 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker
06:42:43 AM - 2848969 0.00 0.00 0.00 0.00 29 |__ghc_worker
06:42:43 AM - 2848970 0.00 0.00 0.00 0.00 14 |__ghc_worker
06:42:43 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker
06:42:43 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker
06:42:43 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker
06:42:43 AM - 2850198 0.00 0.00 0.00 0.00 10 |__ghc_worker
06:42:43 AM - 2850199 0.00 0.00 0.00 0.00 19 |__ghc_worker
06:42:43 AM - 2850295 0.00 0.00 0.00 0.00 13 |__ghc_worker
06:42:43 AM - 2861009 0.00 0.00 0.00 0.00 34 |__ghc_worker
06:42:43 AM - 2861010 0.00 0.00 0.00 0.00 35 |__ghc_worker
}}}
{{{
$ pidstat -t -p $(pidof ghc) | grep ghc_worker
06:43:37 AM - 2848953 0.00 0.00 0.00 0.00 21 |__ghc_worker
06:43:37 AM - 2848954 0.00 0.00 0.00 0.00 31 |__ghc_worker
06:43:37 AM - 2848955 0.00 0.00 0.00 0.00 9 |__ghc_worker
06:43:37 AM - 2848957 0.00 0.00 0.00 0.00 9 |__ghc_worker
06:43:37 AM - 2848958 0.00 0.00 0.00 0.00 22 |__ghc_worker
06:43:37 AM - 2848959 0.00 0.00 0.00 0.00 37 |__ghc_worker
06:43:37 AM - 2848960 0.00 0.00 0.00 0.00 29 |__ghc_worker
06:43:37 AM - 2848961 0.00 0.00 0.00 0.00 20 |__ghc_worker
06:43:37 AM - 2848962 0.00 0.00 0.00 0.00 36 |__ghc_worker
06:43:37 AM - 2848963 0.00 0.00 0.00 0.00 3 |__ghc_worker
06:43:37 AM - 2848964 0.00 0.00 0.00 0.00 12 |__ghc_worker
06:43:37 AM - 2848965 0.00 0.00 0.00 0.00 15 |__ghc_worker
06:43:37 AM - 2848966 0.00 0.00 0.00 0.00 24 |__ghc_worker
06:43:37 AM - 2848967 0.00 0.00 0.00 0.00 38 |__ghc_worker
06:43:37 AM - 2848968 0.00 0.00 0.00 0.00 23 |__ghc_worker
06:43:37 AM - 2848969 0.00 0.00 0.00 0.00 1 |__ghc_worker
06:43:37 AM - 2848970 0.00 0.00 0.00 0.00 19 |__ghc_worker
06:43:37 AM - 2850193 0.00 0.00 0.00 0.00 32 |__ghc_worker
06:43:37 AM - 2850196 0.00 0.00 0.00 0.00 34 |__ghc_worker
06:43:37 AM - 2850197 0.00 0.00 0.00 0.00 35 |__ghc_worker
06:43:37 AM - 2850198 0.00 0.00 0.00 0.00 30 |__ghc_worker
06:43:37 AM - 2861009 0.00 0.00 0.00 0.00 17 |__ghc_worker
06:43:37 AM - 2861010 0.00 0.00 0.00 0.00 19 |__ghc_worker
06:43:37 AM - 2862954 0.00 0.00 0.00 0.00 2 |__ghc_worker
06:43:37 AM - 2862956 0.00 0.00 0.00 0.00 26 |__ghc_worker
}}}
The sets of threads are changing on every suspend, unsuspend combination.
This is really visible when running in gdb with -j40, gdb just spews threads getting spawned and killed:
{{{
[Thread 0x7f0b767fc700 (LWP 2881933) exited]
[New Thread 0x7f0b767fc700 (LWP 2881940)]
[New Thread 0x7f0cc2cfd700 (LWP 2881941)]
[Thread 0x7f0b76ffd700 (LWP 2881928) exited]
[New Thread 0x7f0b7dffb700 (LWP 2881942)]
[New Thread 0x7f0b76ffd700 (LWP 2881943)]
[New Thread 0x7f0b7ffff700 (LWP 2881944)]
[Thread 0x7f0b777fe700 (LWP 2881932) exited]
[Thread 0x7f0b77fff700 (LWP 2881931) exited]
[Thread 0x7f0b7d7fa700 (LWP 2881927) exited]
[Thread 0x7f0b7f7fe700 (LWP 2881926) exited]
[New Thread 0x7f0b7f7fe700 (LWP 2881945)]
[New Thread 0x7f0b7d7fa700 (LWP 2881948)]
[Thread 0x7f0cc2cfd700 (LWP 2881941) exited]
[Thread 0x7f0b75ffb700 (LWP 2881938) exited]
[New Thread 0x7f0cc2cfd700 (LWP 2881949)]
[Thread 0x7f0b767fc700 (LWP 2881940) exited]
[New Thread 0x7f0b767fc700 (LWP 2881950)]
[New Thread 0x7f0b75ffb700 (LWP 2881951)]
[New Thread 0x7f0b77fff700 (LWP 2881952)]
[Thread 0x7f0b757fa700 (LWP 2881939) exited]
[Thread 0x7f0b7d7fa700 (LWP 2881948) exited]
[New Thread 0x7f0b757fa700 (LWP 2881953)]
[Thread 0x7f0b7effd700 (LWP 2881936) exited]
[Thread 0x7f0cc3cff700 (LWP 2881937) exited]
[New Thread 0x7f0cc3cff700 (LWP 2881954)]
[New Thread 0x7f0b7effd700 (LWP 2881955)]
[New Thread 0x7f0b7d7fa700 (LWP 2881956)]
[Thread 0x7f0b7dffb700 (LWP 2881942) exited]
[New Thread 0x7f0b777fe700 (LWP 2881957)]
[New Thread 0x7f0b7dffb700 (LWP 2881958)]
[Thread 0x7f0b76ffd700 (LWP 2881943) exited]
[New Thread 0x7f0b76ffd700 (LWP 2881959)]
[Thread 0x7f0b7e7fc700 (LWP 2881935) exited]
[Thread 0x7f0b7effd700 (LWP 2881955) exited]
[New Thread 0x7f0b7effd700 (LWP 2881962)]
[New Thread 0x7f0b7e7fc700 (LWP 2881963)]
[Thread 0x7f0b7f7fe700 (LWP 2881945) exited]
[New Thread 0x7f0b7f7fe700 (LWP 2881964)]
[New Thread 0x7f0b7cff9700 (LWP 2881965)]
[Thread 0x7f0b75ffb700 (LWP 2881951) exited]
[Thread 0x7f0b7dffb700 (LWP 2881958) exited]
[Thread 0x7f0cc3cff700 (LWP 2881954) exited]
[New Thread 0x7f0cc3cff700 (LWP 2881967)]
[New Thread 0x7f0b7dffb700 (LWP 2881968)]
[Thread 0x7f0b777fe700 (LWP 2881957) exited]
[Thread 0x7f0b757fa700 (LWP 2881953) exited]
[Thread 0x7f0cc2cfd700 (LWP 2881949) exited]
[Thread 0x7f0b7ffff700 (LWP 2881944) exited]
[New Thread 0x7f0cc2cfd700 (LWP 2881969)]
[Thread 0x7f0b7e7fc700 (LWP 2881963) exited]
[Thread 0x7f0b767fc700 (LWP 2881950) exited]
[New Thread 0x7f0b767fc700 (LWP 2881970)]
[New Thread 0x7f0b7e7fc700 (LWP 2881971)]
[Thread 0x7f0b77fff700 (LWP 2881952) exited]
[New Thread 0x7f0b7ffff700 (LWP 2881972)]
[New Thread 0x7f0b77fff700 (LWP 2881973)]
[New Thread 0x7f0b757fa700 (LWP 2881974)]
[Thread 0x7f0b7dffb700 (LWP 2881968) exited]
[New Thread 0x7f0b7dffb700 (LWP 2881975)]
[Thread 0x7f0cc2cfd700 (LWP 2881969) exited]
[New Thread 0x7f0cc2cfd700 (LWP 2881976)]
[Thread 0x7f0b76ffd700 (LWP 2881959) exited]
[Thread 0x7f0b757fa700 (LWP 2881974) exited]
[New Thread 0x7f0b76ffd700 (LWP 2881977)]
[New Thread 0x7f0b757fa700 (LWP 2881978)]
[New Thread 0x7f0b777fe700 (LWP 2881979)]
[Thread 0x7f0b7effd700 (LWP 2881962) exited]
[New Thread 0x7f0b7effd700 (LWP 2881980)]
[Thread 0x7f0b7ffff700 (LWP 2881972) exited]
[Thread 0x7f0b7e7fc700 (LWP 2881971) exited]
[Thread 0x7f0b77fff700 (LWP 2881973) exited]
[New Thread 0x7f0b77fff700 (LWP 2881981)]
[Thread 0x7f0b7d7fa700 (LWP 2881956) exited]
[New Thread 0x7f0b7d7fa700 (LWP 2881982)]
[New Thread 0x7f0b7e7fc700 (LWP 2881983)]
[Thread 0x7f0cc2cfd700 (LWP 2881976) exited]
[New Thread 0x7f0cc2cfd700 (LWP 2881984)]
[New Thread 0x7f0b7ffff700 (LWP 2881985)]
[New Thread 0x7f0b75ffb700 (LWP 2881986)]
[Thread 0x7f0b7dffb700 (LWP 2881975) exited]
[New Thread 0x7f0b7dffb700 (LWP 2881987)]
[New Thread 0x7f0b74ff9700 (LWP 2881988)]
[Thread 0x7f0b777fe700 (LWP 2881979) exited]
[Thread 0x7f0b7effd700 (LWP 2881980) exited]
[Thread 0x7f0b76ffd700 (LWP 2881977) exited]
}}}" niteria
10046 50 simonmar, Jinhui_Chen, hvr, mmikolajczyk, rwbarton Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales Runtime System 7.8.4 7.12.1 simonmar new normal 2015-01-30T18:17:59Z "Please see ticket:2615#comment:40 and replies.
This error only occurs on systems where linker scripts are used. The linker script patch (as it has evolved) assumes that the error messages it will receive are in English. This would be true if the locale (LC_MESSAGES) is C or en (or one of the en variants). However, in other locales, the message will be in a different language. Unfortunately, the semantics of POSIX dlerror() specify that the error is returned as a pointer to a human-readable text string, rather than an error code. The string returned depends on the locale.
The code could be made more robust by momentarily changing the locale (LC_MESSAGES) to C before calling dlerror() and reverting it to its previous value immediately after. This has been tested on a zh_CN.utf-8 (see ticket:2615#comment:42) and works. The only concern I have is in the case of multithreaded code that _might_ be affected if it is running while the locale is changed. I don't know enough to know if this is a real issue or not, nor do I know how to deal with it if necessary.
Also see ticket:9237 for another corner case in the linker script code that should be dealt with at the same time." hgolden
8429 26 simonmar, jkarni@… GHC.Base.{breakpoint, breakpointCond} do nothing Compiler 7.6.3 7.12.1 iand675 new normal 2014-12-23T13:34:10Z "The `GHC.Exts` module exports functions [[http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC-Exts.html#g:6|breakpoint and breakpointCond]]. Right now they are no-ops, but apparently at some point in the past could be used to set breakpoints programmatically. From my reading of the source code, this feature was removed (either accidentally or on purpose) when the implementation of breakpoints [[changeset:cdce647711c0f46f5799b24de087622cb77e647f/ghc|was reworked]].
Relevant commits:
* 31751ccacc24ebe5d15a0af84b10dc612d455440
* 3a99fa889bdff0c86df20cb18c71d30e30a79b43
* cdce647711c0f46f5799b24de087622cb77e647f
Initially reported [http://stackoverflow.com/questions/19283911/how-do-i-use-ghc-exts-breakpoint here]." refold
9088 56 simonmar, rrnewton@…, carter.schonwald@… Per-thread Haskell thread list/numbering (remove global lock from thread allocation) Runtime System 7.9 simonmar new low 2014-05-13T02:43:04Z "Currently, we take out the scheduler lock when a thread is allocated, in order to make sure we allocate a fresh thread ID and can attach it to the global thread list in the nursery. If we partition the thread ID space per originating capability and maintain thread lists per OS thread, we can remove this lock.
Marking low priority because no one seems to be running into this as their particular scaling problem (and there may be other reasons why high thread churn doesn't scale across cores)." ezyang
10062 39 simonmar, shumovichy@…, bgamari Codegen on sequential FFI calls is not very good Compiler (CodeGen) 7.8.3 new normal 2015-02-23T20:14:59Z "I'm writing a library for efficiently building up a byte buffer. The fastest approach I've found is via FFI, with restricted effects like ST. It's over twice as fast as ByteString Builder.
Consider this example API usage: https://github.com/chadaustin/buffer-builder/blob/6bd0a39c56f63ab751faf29f9784ac87d52638be/bench/Bench.hs#L46
It compiles into an instruction sequence containing direct, sequenced FFI calls. For example, the last three calls work out to:
addq $8,%rsp
movq %rbx,%rdi
movq 72(%rsp),%rax
movq %rax,%rsi
subq $8,%rsp
movl $0,%eax
call bw_append_bsz
addq $8,%rsp
movq %rbx,%rdi
movl $35,%esi
subq $8,%rsp
movl $0,%eax
call bw_append_byte
addq $8,%rsp
movq %rbx,%rdi
movq 64(%rsp),%rax
movq %rax,%rsi
subq $8,%rsp
movl $0,%eax
call bw_append_bsz
I don't know why rsp is being changed so much. I also can't explain the assignment to eax before the call. (It should also be xorl eax,eax, I would think.)
To my reading, the above instruction sequence could be reduced to:
movq %rbx,%rdi
movq 64(%rsp),%rsi
call bw_append_bsz
movq %rbx,%rdi
movl $35,%esi
call bw_append_byte
movq %rbx,%rdi
movq 56(%rsp),%rsi
call bw_append_bsz
To reproduce, check out git@github.com:chadaustin/buffer-builder.git at revision 6bd0a39c56f63ab751faf29f9784ac87d52638be
cabal configure --enable-benchmarks
cabal bench
And then look at the ./dist/build/bench/bench-tmp/bench/Bench.dump-asm file.
This is specifically on OS X 64-bit with GHC 7.8.3, but I saw similar code generation on GHC 7.6 on Linux 64-bit.
" chadaustin
10613 17 simonmar, simonpj Mechanism for checking that we only enter single-entry thunks once Compiler 7.10.1 new normal 2015-07-21T03:35:48Z "During this week's GHC call it came up that it would be nice to have a linting mechanism for verifying that we only enter single-entry thunks once, as currently this invariant appears to be completely unchecked.
Currently we do not record whether a thunk is intended to be single-entry when we emit its code. Moreover, I don't believe there is any room for this left in the info table to record this fact. There are two ways I can think of accomodating this,
* stealing a bit from the thunk type field
* add a flags field to `StgDebugInfo` such that the lint requires the `debug` way
As far as implementing the check itself, I think it should be rather straightforward. When we enter a thunk we simply want to check whether it is single-entry. If it is then we replace it with a special type of `BLACKHOLE`-like thunk which crashes the program (or merely emits a warning) on entry." bgamari
9352 17 simonmar, simonpj Allow `State# s` argument/result types in `ccall` FFI imports Compiler (Type checker) 7.8.2 7.12.1 new normal 2014-12-23T13:34:10Z "This ticket is to allowing code like
{{{#!hs
{-# LANGUAGE UnliftedFFITypes #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE UnboxedTuples #-}
module M where
import GHC.Exts
foreign import ccall unsafe ""foo"" c_foo :: Int# -> State# s -> State# s
foreign import ccall unsafe ""bar"" c_foo :: Int# -> State# s -> (# State# s, Int# #)
}}}
See also discussion in #9281" hvr
9007 16 simonmar, slyfox fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) Compiler 7.9 7.12.1 nomeata infoneeded high 2015-07-03T07:44:42Z "Building HEAD on Debian wheezy with the Debian packaging setup fails:
{{{
configure: Building in-tree ghc-pwd
/usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC
utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
configure: error: Building ghc-pwd failed
}}}
http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.build
This is possibly related to the Hardening flags added by Debian:
{{{
~ $ dpkg-buildflags --get LDFLAGS
-Wl,-z,relro
~ $ dpkg-buildflags --get CFLAGS
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
}}}
Other related bug might be #3668 and https://bugs.debian.org/712228
I’ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27." nomeata
8648 18 simonmar, snoyberg Initialization of C statics broken in threaded runtime Runtime System 7.7 simonmar new normal 2015-06-16T14:29:26Z "Consider a tiny package `static-value`, consisting of one Haskell file
{{{
foreign import ccall unsafe ""returnStaticValue"" c_returnStaticValue :: IO CInt
printStaticValue :: IO ()
printStaticValue = print =<< c_returnStaticValue
}}}
and one corresponding C file
{{{
static int theStaticValue = 0;
int returnStaticValue() {
// Modify the static so the C compiler doesn't optimize it away
return theStaticValue++;
}
}}}
(test case is attached). If we call `printStaticValue` using the GHC API:
{{{
runGhc (Just libdir) $ do
flags0 ghci -package haskeline
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package Win32-2.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package haskeline-0.7.1.2 ... linking ... ghc.exe: warning: SetConsoleCursorPosition from kernel32 is linked instead of __imp_SetConsoleCursorPosition
ghc.exe: warning: FillConsoleOutputCharacterA from kernel32 is linked instead of __imp_FillConsoleOutputCharacterA
ghc.exe: warning: FillConsoleOutputAttribute from kernel32 is linked instead of __imp_FillConsoleOutputAttribute
done.
Prelude>
}}}
Besides {{{haskeline}}}, other packages with similar problems include {{{unix-compat}}}, {{{network}}}, and {{{regex-posix}}}. To see them all at once, you can run the [{{{hermit-web}}} https://github.com/ku-fpg/hermit-web] executable:
{{{
> hermit-web Last.hs
[starting HERMIT-Web v0.1.0.0 on Last.hs]
[starting HERMIT v0.5.0.0 on Last.hs]
% ghc Last.hs -fforce-recomp -O2 -dcore-lint -fsimple-list-literals -fexpose-all-unfoldings -fplugin=HERMIT.Web -fplugin-opt=HERMIT.Web:*:
[1 of 1] Compiling Main ( Last.hs, Last.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package Win32-2.3.0.2 ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package process-1.2.0.0 ... linking ... done.
Loading package Cabal-1.18.1.3 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package bin-package-db-0.0.0.0 ... linking ... done.
Loading package hoopl-3.10.0.1 ... linking ... done.
Loading package hpc-0.6.0.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package ghc-7.8.3 ... linking ... done.
Loading package haskeline-0.7.1.2 ... linking ... ghc: warning: SetConsoleCursorPosition from kernel32 is linked instead of __imp_SetConsoleCursorPosition
ghc: warning: FillConsoleOutputCharacterA from kernel32 is linked instead of __imp_FillConsoleOutputCharacterA
ghc: warning: FillConsoleOutputAttribute from kernel32 is linked instead of __imp_FillConsoleOutputAttribute
done.
Loading package text-1.1.1.3 ... linking ... done.
Loading package hashable-1.2.2.0 ... linking ... done.
Loading package scientific-0.3.2.2 ... linking ... done.
Loading package attoparsec-0.12.1.0 ... linking ... done.
Loading package dlist-0.7.1 ... linking ... done.
Loading package mtl-2.1.3.1 ... linking ... done.
Loading package syb-0.4.2 ... linking ... done.
Loading package unordered-containers-0.2.5.0 ... linking ... done.
Loading package primitive-0.5.3.0 ... linking ... done.
Loading package vector-0.10.11.0 ... linking ... done.
Loading package aeson-0.7.0.6 ... linking ... done.
Loading package blaze-builder-0.3.3.2 ... linking ... done.
Loading package data-default-class-0.0.1 ... linking ... done.
Loading package data-default-instances-base-0.0.1 ... linking ... done.
Loading package data-default-instances-containers-0.0.1 ... linking ... done.
Loading package data-default-instances-dlist-0.0.1 ... linking ... done.
Loading package