}}}
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
8927 19 vxanicauk@… Multiple case match at once Compiler (Parser) 7.8.1-rc2 new normal 2014-06-06T11:42:21Z "In F# we can do
{{{
#!div style=""font-size: 120%""
{{{#!haskell
match x with
| 1 | 2 | 3 -> ""123""
| 4 | 5 | 6 -> ""456""
}}}
}}}
It will be nice if we have an extension which allows us to do
{{{
#!div style=""font-size: 120%""
{{{#!haskell
case x of
1 | 2 | 3 -> ""123""
4 | 5 | 6 -> ""456""
}}}
}}}
" vxanica
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
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
2551 19 vogt.adam@… Allow multiple modules per source file Compiler 6.9 ⊥ new normal 2014-12-05T17:12:16Z "This is helpful because the module system is the only way to achieve encapsulation in Haskell, so the system needs to be as lightweight and flexible as possible. It also makes it easier to share and distribute Haskell programs when it is most convenient to do so as a single file, such as literate Haskell via email.
To use this feature, one would specify files to be compiled explicitly.
When GHC searches on its own for modules, it needs the path of the
file to indicate the name of the module it contains, so multiple modules
are not possible in that case.
See #2550, and the thread in:
http://www.haskell.org/pipermail/haskell-cafe/2008-August/046494.html" YitzGale
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
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
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
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
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 data-default-instances-old-locale-0.0.1 ... linking ... done.
Loading package data-default-0.5.3 ... linking ... done.
Loading package ansi-terminal-0.6.1.1 ... linking ... done.
Loading package kure-2.16.2 ... linking ... done.
Loading package marked-pretty-0.1 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package operational-0.2.3.2 ... linking ... done.
Loading package stm-2.4.3 ... linking ... done.
Loading package exceptions-0.6.1 ... linking ... done.
Loading package temporary-1.2.0.3 ... linking ... done.
Loading package hermit-0.5.0.0 ... linking ... done.
Loading package case-insensitive-1.2.0.0 ... linking ... done.
Loading package http-types-0.8.5 ... linking ... done.
Loading package transformers-base-0.4.2 ... linking ... done.
Loading package monad-control-0.3.3.0 ... linking ... done.
Loading package lifted-base-0.2.3.0 ... linking ... done.
Loading package mmorph-1.0.3 ... linking ... done.
Loading package resourcet-1.1.2.2 ... linking ... done.
Loading package nats-0.2 ... linking ... done.
Loading package semigroups-0.15.1 ... linking ... done.
Loading package void-0.6.1 ... linking ... done.
Loading package conduit-1.1.6 ... linking ... done.
Loading package regex-base-0.93.2 ... linking ... done.
Loading package regex-posix-0.95.2 ... linking ... ghc: warning: isupper from msvcrt is linked instead of __imp_isupper
ghc: warning: toupper from msvcrt is linked instead of __imp_toupper
ghc: warning: tolower from msvcrt is linked instead of __imp_tolower
ghc: warning: isalpha from msvcrt is linked instead of __imp_isalpha
ghc: warning: isalpha from msvcrt is linked instead of __imp_isalpha
ghc: warning: isalpha from msvcrt is linked instead of __imp_isalpha
ghc: warning: iscntrl from msvcrt is linked instead of __imp_iscntrl
ghc: warning: isupper from msvcrt is linked instead of __imp_isupper
ghc: warning: isgraph from msvcrt is linked instead of __imp_isgraph
ghc: warning: isprint from msvcrt is linked instead of __imp_isprint
ghc: warning: ispunct from msvcrt is linked instead of __imp_ispunct
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalpha from msvcrt is linked instead of __imp_isalpha
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
ghc: warning: isalnum from msvcrt is linked instead of __imp_isalnum
done.
Loading package regex-compat-0.95.1 ... linking ... done.
Loading package parsec-3.1.5 ... linking ... done.
Loading package network-2.5.0.0 ... linking ... ghc: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
ghc: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup
ghc: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
ghc: warning: accept from ws2_32 is linked instead of __imp_accept
ghc: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa
ghc: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo
ghc: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo
ghc: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo
done.
Loading package vault-0.3.0.3 ... linking ... done.
Loading package wai-3.0.0.2 ... linking ... done.
Loading package base64-bytestring-1.0.0.1 ... linking ... done.
Loading package fast-logger-2.1.5 ... linking ... done.
Loading package zlib-0.5.4.1 ... linking ... done.
Loading package streaming-commons-0.1.3.1 ... linking ... done.
Loading package stringsearch-0.3.6.5 ... linking ... done.
Loading package byteorder-1.0.4 ... linking ... done.
Loading package wai-logger-2.1.1 ... linking ... done.
Loading package word8-0.0.4 ... linking ... done.
Loading package wai-extra-3.0.1 ... linking ... done.
Loading package conduit-extra-1.1.1 ... linking ... done.
Loading package simple-sendfile-0.2.15 ... linking ... done.
Loading package unix-compat-0.4.1.3 ... linking ... ghc: warning: GetVersionExA from kernel32 is linked instead of __imp_GetVersionExA
ghc: warning: GetModuleHandleA from kernel32 is linked instead of __imp_GetModuleHandleA
ghc: warning: GetProcAddress from kernel32 is linked instead of __imp_GetProcAddress
ghc: warning: _snprintf from msvcrt is linked instead of __imp__snprintf
ghc: warning: GetSystemInfo from kernel32 is linked instead of __imp_GetSystemInfo
ghc: warning: GetSystemMetrics from user32 is linked instead of __imp_GetSystemMetrics
ghc: warning: GetVersionExA from kernel32 is linked instead of __imp_GetVersionExA
ghc: warning: _snprintf from msvcrt is linked instead of __imp__snprintf
ghc: warning: GetSystemInfo from kernel32 is linked instead of __imp_GetSystemInfo
ghc: warning: GetComputerNameA from kernel32 is linked instead of __imp_GetComputerNameA
ghc: warning: CryptAcquireContextA from advapi32 is linked instead of __imp_CryptAcquireContextA
ghc: warning: CryptGenRandom from advapi32 is linked instead of __imp_CryptGenRandom
ghc: warning: _stat64 from msvcrt is linked instead of __imp__stat64
ghc: warning: _open from msvcrt is linked instead of __imp__open
ghc: warning: _stat64 from msvcrt is linked instead of __imp__stat64
done.
Loading package warp-3.0.0.4 ... linking ... done.
Loading package scotty-0.8.1 ... linking ... done.
Loading package hermit-web-0.1.0.0 ... linking ... done.
Setting phasers to stun... (port 3000) (ctrl-c to quit)
}}}
These warnings seem to be related to Windows-specific {{{.dll}}} files, including {{{kernel32.dll}}}, {{{user32.dll}}}, {{{msvcrt.dll}}}, {{{advapi32.dll}}}, and {{{ws2_32.dll}}}. As far as I can tell, there are no problems other than the warnings themselves, but I can't be sure." RyanGlScott
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
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
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
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 a -> m a
f = return
g :: Monoid w => a -> Writer w a
g = return
{-# RULES ""f->g"" f = g #-}
{-# SPECIALISE f :: Monoid w => a -> Writer w a #-}
}}}
Here, the SPECIALISE pragma is accepted, but the RULE is rejected thus:
{{{
Could not deduce (Monoid w) arising from a use of `g'
from the context (Monad (WriterT w Identity))
bound by the RULE ""f->g"" at Foo.hs:14:3-14
Possible fix: add (Monoid w) to the context of the RULE ""f->g""
In the expression: g
When checking the transformation rule ""f->g""
}}}
Rejecting the RULE is quite right. On the LHS you have an application
{{{
f (WriterT w Identity) d
where d :: Monad (WriterT w Identity)
}}}
Recall that `Writer w = WriterT w Identity`. For the rewrite to work you have to rewrite this to
{{{
g w d'
where
d' :: Monoid w
}}}
Well, how can you get a `Monoid w` dictionary from a `Monad (WriterT w Identity)`?
I was surprised that the SPECIALISE pragma worked, but here's what it does (you can see with -ddump-rules):
{{{
==================== Tidy Core rules ==================== ""SPEC Foo.f"" [ALWAYS]
forall (@ a) (@ w) ($dMonoid :: Data.Monoid.Monoid w).
Foo.f @ a
@ (Control.Monad.Trans.Writer.Strict.WriterT
w Data.Functor.Identity.Identity)
(Control.Monad.Trans.Writer.Strict.$fMonadWriterT
@ w
@ Data.Functor.Identity.Identity
$dMonoid
Data.Functor.Identity.$fMonadIdentity)
= Foo.f_f @ a @ w $dMonoid
}}}
Ah! This rule will only match if the LHS is exactly
{{{
f (WriterT w Identity) ($fMonadWriterT w Identity dm $fMonadIdentity)
}}}
So it's a nested pattern match. That makes the LHS match less often; namely only when the dictionary argument to `f` is an application of `$fMonadWriterT`, the function that arises from the instance decl
{{{
instance (Monoid w, Monad m) => Monad (WriterT w m) where
}}}
In exchange for matching less often, we now do get access to the `(Monoid w)` argument.
It is odd that this is inconsistent. Here is why. For a RULE, we must have a way to rewrite the LHS to an arbitrarily complicated RHS. For a SPECIALISE pragma
{{{
SPECIALISE f :: spec_ty
where f's type is
f :: poly_ty
}}}
we simply ask whether `poly_ty` is more polymorphic than `spec_ty`; that is, whether `f` can appear in a context requiring a value of type `spec_ty`. If so, we see what arguments `f` would need to do that, and that's the LHS pattern.
But
* It's odd that the behaviour is inconsistent
* The SPECIALISE rule is pretty fragile, beause it'll only match if the argument dictionary is constructed exactly as shown.
It's not clear to me what, if anything, to do about this, but this ticket records the issue.
" simonpj
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
472 17 merehap@… Supertyping of classes Compiler (Type checker) None ⊥ new normal 2012-07-01T06:50:19Z "see
[http://repetae.net/john/recent/out/supertyping.html Supertyping Suggestion for Haskell]
example:
{{{
class Num a <= Group a where
(+) :: a -> 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
1791 17 iampure@… heap overflow should generate an exception Runtime System 6.8 ⊥ new normal 2013-01-26T22:48:33Z "I want to use the -M option for the goals that are stated in the manual.
{{{
./TestProgram +RTS -M5m -RTS
}}}
Expected output:
{{{
Something like ""out of heap space""
}}}
Actual result:
{{{
Machine going into a state where it swaps memory
}}}
This is the code for TestProgram:
{{{
import Control.Monad.ST
import Data.Array.ST
import Data.Array.MArray
import Data.Array.Base(unsafeNewArray_)
main = print (runST (do make_empty_table >> 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
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
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
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
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
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
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
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
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
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); /* :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
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
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
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 : 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
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
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
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
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
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
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
2180 16 svein.ove@… Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock Runtime System 6.9 ⊥ Baughn new normal 2009-07-24T17:44:02Z "The runtime system's deadlock detection, being a debugging feature, rightly doesn't break a deadlock if there's any chance a signal will do so later. However, if the only installed signal is XCPU - cpu time-limit exceeded - then that will almost never happen in practice; any program that does want to wait for it will be waiting quite literally years.
As such, it seems best if XCPU is left out of the signal-detection logic. The attached patch does this." Baughn
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
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
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
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
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
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
8922 15 tibbe, simonmar GHC unnecessarily sign/zero-extends C call arguments Compiler (NCG) 7.6.3 7.12.1 new normal 2014-12-23T13:34:10Z "Ticket created following discussion in [https://ghc.haskell.org/trac/ghc/ticket/7684#comment:58]
It seems the zero/sign-extension that we're doing in the NCG for arguments less than a word in size is unnecessary, since the ABI doesn't specify any extension. There's some clarification of the spec in this thread: [http://gcc.gnu.org/ml/gcc/2013-01/msg00448.html]
" simonmar
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
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
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
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
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
9625 14 ezyang, slyfox ghc: panic using --enable-executable-dynamic Package system 7.8.3 new normal 2015-05-23T16:17:26Z "(from: https://github.com/haskell/cabal/issues/2039)
Using --enable-executable-dynamic leads to a ghc panic.
Reproduction steps:
{{{
1. git clone https://github.com/coreyoconnor/executable-dynamic-issue
2. cabal configure --enable-tests --enable-executable-dynamic
3. cabal test
}}}
Expected results: Test executes and passes.
Actual results:
{{{
ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Don't understand library name verify-foo
}}}
Actual results varies based on the name of ""verify-foo"" test suite. Other names tried: ""verifyFoo"", ""VerifyFoo"". All of which also fail.
Removing ""--enable-executable-dynamic"" results in a pass regardless of test suite name.
Reproduced on GHC 7.8.2, GHC 7.8.3, Cabal 1.18, Cabal 1.20. Ubuntu." CoreyOConnor
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
7849 14 oleg@… Error on pattern matching of an existential whose context includes a type function Compiler (Type checker) 7.4.2 7.12.1 new normal 2014-12-23T13:34:10Z "The following code
{{{
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE GADTs #-}
module Ex where
import Data.IORef
class SUBJ subj where
type SUBJ_Obs subj :: *
unsubscribe' :: subj -> 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
624 14 ezyang@… Program location for thread error messages Compiler None ⊥ new normal 2010-09-18T01:49:14Z "In programs with a substantial number of threads, the error messages like ""indefinitely blocked"" are not very helpful, because there is no indication as to which thread blocked. Having the source location of the 'fork' or so, would be much more helpful." chak
10665 14 simonpj, scpmw INLINE breaks rewrite rules when '-g' is used Compiler (CodeGen) 7.10.2-rc2 new normal 2015-07-24T10:15:34Z "The bug is found when building conduit-1.2.4.2 package with '-O2 -g' options. The distilled sample looks like that:
{{{#!hs
{-# LANGUAGE BangPatterns #-}
module RewriteBug (bug) where
bug :: () -> ()
bug () = bug ()
{-# NOINLINE bug #-}
a2 :: ()
a2 = ()
{-# INLINE[1] a2 #-}
{-# RULES ""bug a2"" [0] bug a2 = () #-}
{-
Crashes as:
$ inplace/bin/ghc-stage2 -c -O1 -fforce-recomp RewriteBug.hs -g
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.11.20150721 for x86_64-unknown-linux):
Tick in rule ()
-}
}}}
My theory of sequence of actions is the following:
- rewrite rule gets read as-is by GHC (gentle phase)
- a2 INLINE changes LHS of rewrite rule (phase 1)
- when time comes to apply 'bug a2' rule GHC detects INLINE problem (phase 0)
In real code it happened across multiple files.
The bug is reproducible in both ghc-7.10.2-rc2 and today's HEAD." slyfox
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
2273 14 ezyang@… inlining defeats seq Compiler 6.9 7.12.1 new lowest 2014-12-23T13:33:22Z "Consider this module:
{{{
module Q (tcExtendIdEnv2) where
-- Interesting code:
tcExtendIdEnv2 :: M a
tcExtendIdEnv2 = do env 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
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
10482 13 maoe@… Not enough unboxing happens on data-family function argument Compiler 7.10.1 new normal 2015-06-30T07:34:35Z "In the following code, `foo` and `foo'` have isomorphic types, but the worker-wrapper pass does less unboxing for `foo`:
{{{#!hs
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE TypeFamilies #-}
module Foo where
data family Foo a
data instance Foo (a, b) = FooPair !(Foo a) !(Foo b)
newtype instance Foo Int = Foo Int
foo :: Foo ((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
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
9052 13 simonmar, hvr "Support a ""stable heap"" which doesn't get garbage collected" Runtime System 7.9 simonmar new normal 2014-06-02T22:43:30Z "Simon Marlow was explaining the concept on IRC. The problem we're trying to solve is you might have some very long-lived pointer data-structures, and you don't want to waste time traversing this structure on a major GC when you know that it is still going to be alive. Here's the basic idea:
1. We have a new generation on the heap called the 'stable heap' (along-side the nursery, gen0, gen1, etc). By default, no objects are automatically promoted from the old gen to the stable heap.
2. A user can request an object be moved to the stable heap, creating a stable pointer which points to the object.
3. During garbage collection, all blocks in the stable heap are always considered reachable. We don't include the stable pointers in the root set (so we don't trace the stable heap), however, write barriers are processed as usual, and we promote any objects pointed to by the stable heap to the stable heap.
4. Users manually request the stable heap to be garbage-collected, usually after deallocating stable pointers.
In short, the stable heap is just another generation, but one which (1) is only collected by user request, and (2) never receives objects from automatic promotion.
This project fits in very nicely with the existing GC infrastructure, so if you understand how everything is laid out this should be reasonably easy to implement. Could be a good ticket for someone who wants to get their hands dirty with the GC." ezyang
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
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
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
9543 13 thoughtpolice "Testsuite driver: replace ""extra_clean"" by ""git clean -X""" Test Suite thomie new normal 2015-06-11T21:38:28Z "When adding a new test that creates extra files, one also has to do some bookkeeping:
1. Supply an `extra_clean` argument to the test function in `all.T`.
2. Add an entry in `testsuite/.gitignore`
Step number 1 is often forgotten. Currently there are over 200 uncleaned files and directories left behind in the `testsuite`, after running `validate` and then `make clean` (checked with `git clean -X -d -n | wc -l`).
I propose to replace the functionality that `extra_clean` provides, namely to remove these extra files when one calls `make clean`, by doing the equivalent of `git clean -X -d`:
{{{
-X
Remove only files ignored by Git.
-d
Remove untracked directories in addition to untracked files. ...
}}}
That is: use the information from the `.ignore` files to figure out which files to delete on `make clean`.
The advantages of making this change are:
1. Less manual bookkeeping, less work, less code
2. A more thorough `make clean`
Implementation detail: we can not just call `git clean` directly, since this should also work when we are not in a git directory (for example a build directory created with [wiki:Building/Using lndir])." thomie
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
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
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
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
10073 12 hvr, bgamari Idris REPL is pretty and we can too GHCi 7.8.4 new normal 2015-02-23T20:15:42Z "Manual for configuring colors in the Idris REPL: https://github.com/idris-lang/Idris-dev/wiki/Manual#colours
Screenshot: http://i.imgur.com/rYHCI4T.png
Particularly, I'd like to make type errors and warnings more visually distinct. I think little touches like this can go a long way to making it nice to work with Haskell code." bitemyapp
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
9215 8 snoyberg GHC 7.8.2 mingw-w64: symbol not found in link Compiler 7.8.2 new normal 2014-11-14T21:20:26Z "This includes calls such as strdup, stat, , and snprintf. These calls are not available in the 64 bit libraries (though 64 bit versions are such as _strdup, _snprintf)
These problems have occurred in building yaml and unix-compat. They also occurred in system-fileio but jmilikin generated a patch for that library" stuartallenmills
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
9894 8 Tarrasch Presence of DWARF debug symbols doesn't result in working backtraces in GDB Compiler 7.9 scpmw new normal 2014-12-17T14:18:00Z "Now when GHC can output DWARF debug symbols we need to take the remaining steps needed to get downstream tool like GDB to do something useful with it. As of today GDB cannot produce a valid stack trace for this code:
{{{#!hs
module Main where
import System.IO
f name = print $ ""Hello, "" ++ name
{-# NOINLINE f #-}
g name = f name
{-# NOINLINE g #-}
main = do
name 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
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
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
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
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
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
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
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
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
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
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 * -> * 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
4520 8 simonmar "startup code on Windows should use SetDllDirectory("""")" Runtime System 7.0.1 7.12.1 new low 2014-12-23T13:33:45Z "See [http://blogs.msdn.com/b/oldnewthing/archive/2010/11/10/10088566.aspx Raymond's blog] about (un)safe dll loading. He points to a [http://support.microsoft.com/kb/2389418 support article] which recommends that new programs use `SetDllDirectory("""")` to prevent the problem (it's not the default because that'd break old programs).
In the GHC context, this could go in the startup code for standalone executables. It is a process-scope property so changing it is not appropriate for DLL startup." duncan
3462 8 simonmar New codegen: allocate large objects using allocateLocal() Runtime System 6.11 7.12.1 simonmar new low 2014-12-23T13:33:45Z "See #3424.
In the new code generator, we should allocate large objects (larger than F * block size, for some suitable fraction F) using the RTS `allocateLocal()` API rather than from the nursery. It works to allocate them from the nursery -- this is what GHC 6.12 does after the fix in #3424 -- but then they will not be treated as large objects and will be copied during GC. Also, the allocation is likely to fail, requiring a trip through the RTS to put a large enough block in the nursery to satisfy the allocation.
" simonmar
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
7746 8 simonmar Support loading/unloading profiled objects from a profiled executable Runtime System 7.7 ⊥ ezyang new low 2015-06-03T19:08:46Z "This is closely related to #3360, but it is a bit less ambitious and should be possible to implement without too many extra changes to the byte code compiler and interpreter (e.g. we just have to teach the linker how to handle things). Here is a simple test program off of 'plugins' to get working:
{{{
{-# LANGUAGE ScopedTypeVariables #-}
import System.Plugins.Make
import System.Plugins.Load
import Data.List
boot :: FilePath -> 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
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
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
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
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
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
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
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
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
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
9805 7 simonpj Use TrieMaps to speed up type class instance lookup Compiler (Type checker) 7.9 ezyang new normal 2015-02-12T12:34:42Z "Currently, type class instance resolution is performed by doing a map lookup by type class, and then linearly matching against every instance. This is not great, and for a while, simonpj has been keen on using the TrieMap data structure in GHC, which has been previously used to implement a map from CoreExprs to various things (e.g. for CSE). What makes this a little tricky is that instance lookup isn't intended to be an exact match: we should unify so-called template variables and provide a substitution; furthermore, there may be multiple matches.
After some prototyping, I think we should be able to make this work. The primary refactoring we have to do is *maintain the key associated with an entry in a TrieMap*. Unlike the current uses of TrieMaps, where it's acceptable to lose the underlying key associated with an entry in the TrieMap, we need to know the key when doing unification, because it may be reported in the substitution. There are a few knock-on effects of this:
* We should add a method `foldWithKeyTM :: (Key m -> a -> b -> b) -> m a -> b -> b` to the `TrieMap` type class.
* We need a variant of `UniqFM` which tracks the original key that was used. I propose we name it `UniqKM` (unique key map). A number of implementations of `TrieMap` need to be adjusted to use this instead of `UniqFM`.
* Why can't we just represent keyed TrieMaps as `TypeMap (Type, a)`? It might be possible. An insurmountable difficulty would be if we need to know the partial key PRIOR to having finished traversing the TrieMap; however, for the parts of the unification algorithm I've implemented, this does not seem to be the case. The primary actual difficulty is that `Type` uses a named representation, whereas `TypeMap` keys are on-the-fly deBruijn numbered. There would at least be some annoying fiddliness.
* Reversing the deBruijn numbered key into a `Type` is a bit goofy. Essentially, you need the reverse of the current `CmEnv`: a mapping from de Bruijn levels to the `Var` you've decided to allocate. (I've called this `CfEnv` in my prototype)
* When we represent a TrieMap binder, we have to put the binder map on the OUTSIDE, as opposed to the inside as it is currently. Otherwise, we can't update the `CfEnv` with the new mapping before making the recursive call to fold-with-key.
I'll attach the standalone Haskell file I used to prototype this, wherein I copy-pasted a lot of Haskell from GHC's source and implemented fuzzy map on a simplified version of `Type`." ezyang
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
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
9780 7 simonpj dep_orphs in Dependencies redundantly records type family orphans Compiler 7.9 7.12.1 new normal 2015-03-27T07:57:48Z "Currently, there is a comment on `dep_orphs` claiming this:
{{{
, dep_orphs :: [Module]
-- ^ Orphan modules (whether home or external pkg),
-- *not* including family instance orphans as they
-- are anyway included in 'dep_finsts'
}}}
However, it is not difficult to discover that this is not true:
{{{
[ezyang@hs01 ghc-quick]$ cat A.hs
{-# LANGUAGE TypeFamilies #-}
module A where
type family F a :: *
[ezyang@hs01 ghc-quick]$ cat B.hs
{-# LANGUAGE TypeFamilies #-}
module B where
import A
type instance F Int = Bool
[ezyang@hs01 ghc-quick]$ cat C.hs
module C where
import B
[ezyang@hs01 ghc-quick]$ inplace/bin/ghc-stage2 --show-iface C.hi | grep orphans
orphans: GHC.Base GHC.Float B
}}}
I'm not sure if the comment or the implementation is wrong. Certainly `TcRnDriver` would not work if we removed type family orphans from the list, because we only currently load `imp_orphans` and not `imp_finsts`. This change occured in this commit:
{{{
commit 8f212ab5307434edf92c7d10fe0df88ccb5cd6ca
Author: Simon Peyton Jones
Date: Thu May 26 14:30:15 2011 +0100
Rejig the way in which generic default method signatures are checked
- Check GenericSig in tcClassSigs, along with TypeSig
- Add the generic default methods to the type envt
- Look them up via tcLookupId in TcClassDcl.tcDefMeth
Much nicer!
diff --git a/compiler/typecheck/TcRnDriver.lhs b/compiler/typecheck/TcRnDriver.lhs
index 2542ad3..5aa6959 100644
--- a/compiler/typecheck/TcRnDriver.lhs
+++ b/compiler/typecheck/TcRnDriver.lhs
@@ -245,7 +245,6 @@ tcRnImports hsc_env this_mod import_decls
-- interfaces, so that their rules and instance decls will be
-- found.
; loadOrphanModules (imp_orphs imports) False
- ; loadOrphanModules (imp_finsts imports) True
-- Check type-familily consistency
; traceRn (text ""rn1: checking family instance consistency"")
}}}
When did we start adding type family orphans to the list? This commit is to blame (it states that modules with type family orphans are orphans, which means that it will get added to orphan module list in `RnNames` when we import the interface:
{{{
commit 98a642cf29781ebd33994a4ecbea6ef07f89bbed
Author: Simon Peyton Jones
Date: Tue Jan 3 10:35:08 2012 +0000
Major refactoring of CoAxioms
@@ -619,7 +620,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls
mi_exp_hash = export_hash,
mi_orphan_hash = orphan_hash,
mi_flag_hash = flag_hash,
- mi_orphan = not (null orph_rules && null orph_insts
+ mi_orphan = not ( null orph_rules
+ && null orph_insts
+ && null orph_fis
&& null (ifaceVectInfoVar (mi_vect_info iface0))),
mi_finsts = not . null $ mi_fam_insts iface0,
mi_decls = sorted_decls,
@@ -631,12 +634,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls
this_mod = mi_module iface0
dflags = hsc_dflags hsc_env
this_pkg = thisPackage dflags
- (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0)
- (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0)
- -- See Note [Orphans] in IfaceSyn
- -- ToDo: shouldn't we be splitting fam_insts into orphans and
- -- non-orphans?
- fam_insts = mi_fam_insts iface0
+ (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0)
+ (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0)
+ (non_orph_fis, orph_fis) = mkOrphMap ifFamInstOrph (mi_fam_insts iface0)
fix_fn = mi_fix_fn iface0
}}}
I think this is probably a legitimate optimization (keeps interface file smaller), and we try to put it back into effect. The only downside is we'll try to load in the entire `mi_fam_insts` list (mostly harmless sense redundant requests on that front will hit the cache); also, it's more elegant if mi_orph describes orphanness over all orphans." ezyang
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
10664 7 simonpj T8131 times out on master Compiler 7.11 7.12.1 new normal 2015-07-22T19:29:40Z The testsuite test `codeGen/should_fail/T8131` appears to time out on the `master` branch as of today. This isn't counted as a testsuite failure as it is a should-fail test, but nevertheless something is not right as it doesn't terminate despite being allowed to run for several minutes. bgamari
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
10061 7 simonpj Remove fun_infix from Funbind, as it is now in Match Compiler 7.10.1-rc2 7.12.1 alanz new normal 2015-02-02T22:01:39Z "One of the changes Phab:D538 introduced is to add m_fun_id_infix to Match
{{{#!hs
data Match id body
= Match {
m_fun_id_infix :: (Maybe (Located id,Bool)),
-- fun_id and fun_infix for functions with multiple equations
-- only present for a RdrName. See note [fun_id in Match]
m_pats :: [LPat id], -- The patterns
m_type :: (Maybe (LHsType id)),
-- A type signature for the result of the match
-- Nothing after typechecking
m_grhss :: (GRHSs id body)
} deriving (Typeable)
}}}
This was done to track the individual locations and fixity of the fun_id for each of the defining equations for a function when there are more than one.
For example, the function (&&&) is defined with some prefix and some infix equations below.
{{{#!hs
(&&& ) [] [] = []
xs &&& [] = xs
( &&& ) [] ys = ys
}}}
This means that the fun_infix is now superfluous in the FunBind. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after.
This ticket captures that task, which includes processing these fields through the renamer and beyond.
Ticket #9988 introduced these fields into Match through renaming, this ticket it to continue through type checking and then remove it from FunBind completely.
The split happened so that #9988 could land in 7.10
" alanz
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
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
10681 7 skilpat Teach GHC to interpret all hs files as two levels of hs-boot files (abstract types only/full types + values) Compiler 7.11 ezyang new normal 2015-07-31T00:59:01Z "This is a new proposal for solving #1409. The big addition here is that we create **two** hs-boot files for each hs file: one that is a full hs-boot file to be imported by hs files to break loops, and a second which only includes abstract types for hs-boot files to import. C.f. #10679
**Discussion.** Here is a slightly goofy `hs-boot` file I've excerpted from GHC:
{{{
module Packages where
import {-# SOURCE #-} Module (PackageKey)
import {-# SOURCE #-} DynFlags (DynFlags)
packageKeyPackageIdString :: DynFlags -> PackageKey -> Maybe String
}}}
The `hs-boot` file must itself import `hs-boot` files, because this boot file is used by `Module` and `DynFlags`; without `{-# SOURCE #-}`, the boot file itself will participate in a cycle!
But notice that there is something very interesting: a boot file is ONLY ever interested in importing other modules to get types. Never to import constructors or functions!
We can use this observation to give us a mechanical transformation of an `hs` file to an `hs-boot` file, ASSUMING we can define a ""second level"" of `hs-boot` file to record our abstract types.
**Example.** In this example, we have chosen to break the loop from `A`s import to `B`.
{{{
module A where
import {-# SOURCE #-} B
data A = A B
f :: A -> Bool
f (A (B (A b))) = g b
f _ = True
module B where
import A
data B = B A
g :: B -> Bool
g (B (A (B b))) = f b
g _ = False
}}}
The first-level `hs-boot`s are:
{{{
module A where -- not actually used
import {-# SOURCE 2 #-} B
data A = A B
f :: A -> Bool
module B where
import {-# SOURCE 2 #-} A
data B = B A
g :: B -> Bool
}}}
The second-level `hs-boot`s are:
{{{
module A where
data A
module B where -- not actually used
data B
}}}
**Commentary.** Here are some remarks:
1. Because we have to lift the transitive dependencies of anything we `{-# SOURCE #-}` import, it doesn't make sense to have a pragma which explicitly says what to put in the `hs-boot` file; instead, we just put in everything that we *can* handle in an `hs-boot` file (so exclude anything with missing type signatures, type families, etc.) Ideally, these automatic hs-boot files are generated lazily, but they should be reused as necessary.
2. This facility actually makes `{-# SOURCE #-}` a lot more attractive for increasing separate compilation: you can mark an import `{-# SOURCE #-}` to ensure that if its implementation changes, you don't have to recompile this module / you can build the module in parallel with that module. The downside is that when the imported file is modified, we have to regenerate the `hs-boot` stub before we conclude that the types have not changed (as opposed to with separate `hs-boot` files, where a modification to `hs` would not bump the timestamp on `hs-boot`.
3. With Haskell98, you should never need more than two levels of hs-boot nesting. However, with data kind promotion, you may need arbitrarily many levels of nesting. You could simply exclude promoted data kinds ala **Handling unsupported boot features**; however an alternate thing to do is generalize hs-boot to arbitrarily many levels. However, this might be annoying to implement because dependency analysis needs to know how to determine universe stratification so it can tell how many levels of hs-boot are necessary.
4. We can't force the first level of `hs-boot` files to be abstract types, for two reasons: (1) a source file importing the hs-boot file may really need the selector/constructor, and (2) the `hs-boot` files will reflect any cycles from the source files, that's no good! Rolling out to the second level breaks the cycle because abstract types never need any imports.
5. What about type class instances? I propose that instances be lifted to the `hs-boot` level (so hs file usages of the instance continue to work), but not the `hs-boot2` level (so that we can still ""bottom out""). This can result in some slightly unintuitive behavior, however:
{{{
module A where
instance Eq (a -> b) where ...
module B where
import A
module C where
import {-# SOURCE #-} B
}}}
In this case, `C` would NOT see the `Eq` instance for functions defined in `A`.
**Handling unsupported boot features.** Some type-level features in Haskell are not supported at the boot-level (type families, etc), so the automatic generation of `hs-boot` needs a way of transitively(!) excluding these definitions from `hs-boot` files. We can exclude things from the boot file in the following way:
1. If a declaration is not liftable to the `hs-boot` file, we replace it with a ""not bootable"" declaration, which specifies that there is something with this `Name`, but we don't have any information about it. (This is a sort of generalized version of an abstract type).
2. If we are type-checking a declaration and make reference to a not bootable declaration, the full declaration itself is considered not bootable.
Alternately, we can just make sure all language features are supported in boot files." ezyang
10680 7 skilpat Make Backpack order-independent (again) Package system 7.11 ezyang new normal 2015-07-31T04:21:08Z "When we moved to the new `bkp` file format, we also went back to the a format which is order-dependent: that is to say, the order in which you put the declarations matters. So if you write:
{{{
unit p where
module A where
import B
module B where
...
}}}
this fails to type-check, GHC complaining that `B` is not in scope. I did this, in part because it's what the Backpack paper described, and because it was ""simpler"" to implement.
I think we should move back to an order-independent scheme, for the following reasons:
1. Haskell users are used to not needing pay particularly close attention to the ordering of their modules, and forcing people to linearize their module descriptions would be spectacularly disruptive with large amounts of modules. So un-ordered modules are ""more natural for a traditional Haskell user.
2. Order-independence imposes some constraints on how expressive programs are (with order-dependent Backpack, you can do some pretty tricky things by ordering things certain ways); this could simplify some aspects of compiler implementation and make Backpack easier to explain.
3. A particular case of (2): it seems a lot simpler UX-wise to let a user assume that if you import a module `M` in a unit, it doesn't matter where you import it: you always get the same set of identifiers brought into scope. Thus, the incremental results of signatures should not be visible, c.f. #10679
The main idea is that only the surface-syntax is un-ordered: the internal representation of units is a DAG which we work out in an elaboration phase, not altogether unsimilar from what `GhcMake` computes. An important auxiliary idea is that `import A` where `A` is backed by some signatures depends on EVERY signature in scope.
Here are the details:
**The intermediate representation.** We translate into an intermediate representation which consists of a directed graph of:
• Each source-level module, signature and include, and
• Each unfilled requirement (called a “signature merge” node).
The edges of the directed graph signify a “depends on” relation, and are defined as follows:
• An include p depends on include q if, for some module name m, p requires m and q provides m.
• An include p depends on a module m if p requires a module named m.
• A module/signature m depends on include p if m imports a module provided by p.
• A module/signature m depends on a module n if m imports n.
• A module/signature m depends on a signature merge n if m imports n.
• A module/signature m depends on a signature n if m {-# SOURCE #-} imports n.
• A signature merge m depends on a local signature m (if it exists).
• A signature merge m depends on a include p, if the (renamed) include requires m.
**Elaboration.** Take a Backpack file, construct this graph, and topsort it into a DAG of SCCs. SCCs with a single node are compileable as before. SCCs with multiple nodes will have to be managed with some mutual recursion mechanism; see refinements for more thoughts on this.
**Refinements:**
1. **Can a signature depend on a (home) module?** Imports of this kind require a retypecheck loop. Consider this situation:
{{{
unit p where
signature H where
data T
module M where
import H
data S = S T
unit q where
include p
module Q where
import M
signature H where
import Q
data T = T S
}}}
Here, signature H in q depends on Q. When we typecheck `Q`, we bring `M.S` into the type environment with a `TyThing` that describes the constructor as accepting an abstract type `T`. However, when we subsequently typecheck the local signature `H`, we must refine all `TyThing`s of `T` with the true description (e.g. constructor information). So you'll need to retypecheck `Q` (and `M`) in order to make sure the `TyThing` is correct.
2. **Can an include depend on a (home) module?** If the module has no (transitive) dependency on signatures, this is fine. However, it's easy to have a circular dependency. Consider:
{{{
unit p where
signature A -- imports nothing
signature B -- imports nothing
module M
unit q where
include p
module B where
import A
...
}}}
`B` depends on `p` for `p/A.hsig`; however, `p` depends on `B` because this module is filling a requirement. However, if we were to include the internal graph of `p` into `q`, the resulting graph would not have an cycles; so this is one possibility of how to untangle this situation. However, if there's still a cycle (e.g. `A` imports `B`), then you will need at least a retypecheck loop, and maybe `hs-boot` style compilation. We're not going to implement this for now.
3. **Can we deal with include-include dependency cycles?** Yes! Just use the Backpack paper's strategy for creating a recursive unit key and compile the two packages `hs-boot` style. But I'm not planning on implementing this yet.
4. **Can we deal with signature-signature dependency cycles?** Ordered Backpack would have supported this:
{{{
unit a-sig where
signature A where
data T
unit ab-sig where
include a-sig
signature B where
import A
data S = S T
signature A where
import B
data T = T S
}}}
In our model, `ab-sig` has a cycle. However, I believe any such cycle can be broken by creating sufficiently many units:
{{{
unit a-sig where
signature B where
data T
signature A where
data S = S T
unit b-sig where
signature A where
data S
signature B where
data T = T S
unit ab-sig where
include a-sig
include b-sig
}}}
In principle, GHC could automatically break import cycles by replacing an import with an import of a reduced signature that simply has abstract type definitions. See #10681. (I'm not sure this is possible for all language features.) This technique would also work for normal modules, assuming that every function is explicitly annotated with a type." ezyang
8516 7 dreixel Add (->) 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
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
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
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
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
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
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
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
9438 6 carter panic: loading archives not supported Compiler 7.8.3 new normal 2014-11-13T02:07:46Z "Running
{{{
ghci -L/opt/local/lib -latlas
}}}
eventually leads to
{{{
Loading object (static archive) /opt/local/lib/libatlas.a ... ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
Loading archives not supported
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
This looks similar to 8164 and 4828, which are marked closed.
Mac OSX 10.9.4
Xcode 5.1.1" egl
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
9555 6 slyfox internal error: ARR_WORDS object entered! Compiler (LLVM) 7.8.3 new normal 2014-11-11T19:56:42Z "In ghci,
:m Data.Complex.Cyclotomic
goldenRatio
produces the error.
: internal error: ARR_WORDS object entered!
(GHC version 7.8.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
" walck
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
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
10296 6 slyfox Segfaults when using dynamic wrappers and concurrency Compiler 7.11 new normal 2015-05-27T17:16:10Z "I had a largish program that sometimes segfaulted, the segfault seemingly coming from the code that gets a C pointer from an Haskell function.
After much sweat I've managed to produce a self-contained program that exhibits the same behavior:
{{{
bitonic@clay /tmp/ptr-crash % uname -a
Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
bitonic@clay /tmp/ptr-crash % cabal configure --disable-library-profiling -w ghc-7.11.20150411
Resolving dependencies...
Configuring ptr-crash-0...
bitonic@clay /tmp/ptr-crash % cabal build
Building ptr-crash-0...
Preprocessing executable 'ptr-crash' for ptr-crash-0...
[1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr-crash-tmp/Main.o )
Linking dist/build/ptr-crash/ptr-crash ...
bitonic@clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS
[1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS
}}}
I'm running GHC HEAD on a Linux 64bit machine. In the larger program, I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I can reproduce it only on 7.10 and later.
More details (thanks to Sergei Trofimovich on #ghc for helping me in investigating this):
* The segfault only happens when using `-N2` or more.
* Curiously, the segfault seems to happen much more often when compiling the program with `-g`.
* The segfault doesn't happen every time, I get it roughly half of the times on my machine.
* `strace`ing the program when segfaulting shows that all the threads crash together right after some calls to `mremap`. I've attached the end of the output of `strace`.
* `gdb`ing the program and breaking on `mremap` shows that all the calls to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` that shows this pattern.
* The segfault only happens with repeated calls to the dynamic wrapper and with certain timings, which explains the weird nature of the example (I kind of mimicked the behaviour of a C function we were calling from a proprietary C library). Note that the call to `sum_arr` is not really important and it's there just so that some time is spent in the callback -- the example works equally well if we convert the pointer to an Haskell vector and sum it from Haskell.
Sergei had a hunch that this had to do with thread-unsafe calls to `stgReallocBytes` in `enlargeStablePtrTable`." bitonic
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 |] ) 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
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
9699 6 spinda TH function to list names in scope Template Haskell 7.8.3 new normal 2015-06-22T16:03:57Z "I [asked about this on stackoverflow](http://stackoverflow.com/questions/26394199/using-templatehaskell-to-list-all-names-in-a-namespace), and apparently it doesn't exist yet.
I want a TemplateHaskell function `variablesInScope :: Q [Name]` that returns a list of the `Name`'s of all the variables in scope. TemplateHaskell obviously has this information available in order to implement functions like `reify :: Name -> Q Info` and `lookupValueName :: String -> Q (Maybe Name)`. So it seems like this might be a pretty simple function to add." MikeIzbicki
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
10181 6 thomie Lint check: arity invariant Compiler 7.11 new normal 2015-07-18T18:56:17Z The Arity of an ID should not exceed the arity of its type, nor the arity of its strictness signature, if it is a bottoming signatures. This should be checked by a lint check (suggested by SPJ in https://phabricator.haskell.org/D747?id=2498#inline-6058) nomeata
7297 6 slyfox LLVM incorrectly hoisting loads Compiler (LLVM) 7.7 7.12.1 dterei new normal 2014-12-23T13:34:10Z "test 367_letnoescape fails under LLVM as a load of the !HpLim register is hoisted out of the loop. So yielding is never done.
What I am not sure about right now is the best way to fix. Loads in LLVM can be annotated in a few different ways to fix this and not sure which one is the most 'correct'.
All the following work:
* mark the load as volatile. (seems to give nicest code as well)
* mark the load as atomic with either monotonic or seq_cst ordering.
* mark the load as both volatile and atomic.
This bug while only affecting a single test case seems very serious and potentially indicative of a large problem. How well are we communicating the load/store threaded semantics to LLVM?
And what semantics do we need to communicate? I think we are fine other than the STG registers...
So making a bug for now as I don't know yet the best way to proceed without dedicating some time to reading LLVM docs and probably talking to the LLVM devs as the docs on the memory model are fairly confusing.
e.g., Code in question:
Bad version (LBB0_1 loops forever as load hoisted out):
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
movq 144(%r13), %rax
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
}}}
Code when marked with atomic (either monatonic or seq_cst) or both atomic and volatile:
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
movq 144(%r13), %rax
testq %rax, %rax
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
}}}
Code when marked volatile:
{{{
r1Uf_info: # @r1Uf_info
# BB#0: # %c1Vy
decq %r14
.align 16, 0x90
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
incq %r14
cmpq $0, 144(%r13)
jne .LBB0_1
# BB#2: # %c1VD
movq -8(%r13), %rax
movl $r1Uf_closure, %ebx
jmpq *%rax # TAILCALL
}}}" dterei
10047 6 slyfox inconsistency in name binding between splice and quasiquotation Template Haskell 7.8.4 7.12.1 new normal 2015-08-01T02:33:11Z "Let me preface this by saying that this may not be a bug. If not then it would be nice if the documentation for Template Haskell could clarify what's going on here.
My understanding of quasiquotation is that a quasiquote `[n|foo|]` is equivalent to a splice `$(quoteExp n ""foo"")`. However, that is not the case in all contexts.
{{{
module Q where
import Language.Haskell.TH
import Language.Haskell.TH.Quote
n = QuasiQuoter { quoteExp = dyn }
}}}
{{{
rwbarton@morphism:/tmp$ ghci -XTemplateHaskell -XQuasiQuotes Q
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 1] Compiling Q ( Q.hs, interpreted )
Q.hs:6:5: Warning:
Fields of ‘QuasiQuoter’ not initialised: quotePat, quoteType,
quoteDec
In the expression: QuasiQuoter {quoteExp = dyn}
In an equation for ‘n’: n = QuasiQuoter {quoteExp = dyn}
Ok, modules loaded: Q.
*Q> :t [| $(dyn ""foo"") |]
[| $(dyn ""foo"") |] :: ExpQ
*Q> :t [| [n|foo|] |]
Loading package pretty-1.1.1.1 ... 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 template-haskell ... linking ... done.
:1:7:
Not in scope: ‘foo’
In the Template Haskell quotation [| [n|foo|] |]
}}}
Why do these behave differently?
(Lastly, the link to the paper ""Why It's Nice to be Quoted: Quasiquoting for Haskell"" in the User's Guide at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/template-haskell.html#th-quasiquotation is broken. Does this paper have a permanent home? In any case, I only skimmed it but it didn't seem to answer my question.)" rwbarton
10279 6 ezyang panic on haskell-src-exts Template Haskell 7.10.1 7.12.1 ezyang new normal 2015-06-26T16:16:07Z "Compiling `Bug.hs`:
{{{
{-# LANGUAGE QuasiQuotes #-}
import Language.Haskell.Exts.QQ (dec)
main :: IO ()
main = return ()
where
foo = [dec| bar = 3 |]
}}}
by `ghc --make -v -dcore-lint Bug.hs` gives
{{{
ghc --make -v -dcore-lint Bug.hs
Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.8.4
Using binary package database: /usr/lib/ghc-7.10.1/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67
wired-in package base mapped to base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b
wired-in package ghc mapped to ghc-7.10.1-325809317787a897b7a97d646ceaa3a3
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67
wired-in package base mapped to base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b
wired-in package ghc mapped to ghc-7.10.1-325809317787a897b7a97d646ceaa3a3
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *Bug.hs
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2015-04-09 10:01:43.312180074 UTC
ms_mod = Main,
ms_textual_imps = [import (implicit) Prelude,
import Language.Haskell.Exts.QQ ( dec )]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file Bug.hs
Created temporary directory: /tmp/ghc7356_0
*** Checking old interface for Main:
[1 of 1] Compiling Main ( Bug.hs, Bug.o )
*** Parser:
*** Renamer/typechecker:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
Loading package ghc-prim-0.4.0.0 ... linking ... done.
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/integ_2aU3IZNMF9a7mQ0OzsZ0dS --print-file-name libgmp.so
Loading package integer-gmp-1.0.0.0 ... linking ... done.
Loading package base-4.8.0.0 ... linking ... done.
Loading package array-0.5.1.0 ... linking ... done.
Loading package filepath-1.4.0.0 ... linking ... done.
Loading package deepseq-1.4.1.1 ... linking ... done.
Loading package time-1.5.0.1 ... linking ... done.
Loading package bytestring-0.10.6.0 ... linking ... done.
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name librt.so
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libutil.so
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libdl.so
*** gcc:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libpthread.so
Loading package unix-2.7.1.0 ... linking ... done.
Loading package directory-1.2.2.0 ... linking ... done.
Loading package old-locale-1.0.0.7 ... linking ... done.
Loading package old-time-1.1.0.3 ... linking ... done.
Loading package text-1.2.0.4 ... linking ... done.
Loading package polyparse-1.11 ... linking ... done.
Loading package cpphs-1.19 ... linking ... done.
Loading package pretty-1.1.2.0 ... linking ... done.
Loading package haskell-src-exts-1.16.0.1 ... linking ... done.
Loading package syb-0.4.4 ... linking ... done.
Loading package template-haskell-2.10.0.0 ... linking ... done.
Loading package transformers-0.4.2.0 ... linking ... done.
Loading package mtl-2.2.1 ... linking ... done.
Loading package nats-1 ... linking ... done.
Loading package th-lift-0.7.2 ... linking ... done.
Loading package containers-0.5.6.2 ... linking ... done.
Loading package safe-0.3.8 ... linking ... done.
Loading package th-expand-syns-0.3.0.6 ... linking ... done.
Loading package th-reify-many-0.1.3 ... linking ... done.
Loading package th-orphans-0.11.1 ... linking ... done.
Loading package haskell-src-meta-0.6.0.9 ... linking ... done.
Loading package haskell-src-exts-qq-0.6.1 ... linking ... done.
Bug.hs:8:16:*** Deleting temp files:
Deleting: /tmp/ghc7356_0/ghc7356_1.s
Warning: deleting non-existent /tmp/ghc7356_0/ghc7356_1.s
*** Deleting temp dirs:
Deleting: /tmp/ghc7356_0
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
qual_pkg haskell-src-exts-1.16.0.1
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
on my machine:
{{{
$ uname -a
Linux io 3.19.3-1-ARCH #1 SMP PREEMPT Thu Mar 26 14:56:16 CET 2015 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 20150304 (prerelease) (GCC)
$ ghc-pkg list
/usr/lib/ghc-7.10.1/package.conf.d
Cabal-1.22.2.0
array-0.5.1.0
async-2.0.2
base-4.8.0.0
bin-package-db-0.0.0.0
binary-0.7.3.0
bytestring-0.10.6.0
containers-0.5.6.2
cpphs-1.19
deepseq-1.4.1.1
directory-1.2.2.0
filepath-1.4.0.0
ghc-7.10.1
ghc-paths-0.1.0.9
ghc-prim-0.4.0.0
haddock-api-2.16.0
haddock-library-1.2.0
haskeline-0.7.2.1
haskell-src-exts-1.16.0.1
haskell-src-exts-qq-0.6.1
haskell-src-meta-0.6.0.9
hoopl-3.10.0.2
hpc-0.6.0.2
integer-gmp-1.0.0.0
minisat-0.1.1
mtl-2.2.1
nats-1
old-locale-1.0.0.7
old-time-1.1.0.3
polyparse-1.11
pretty-1.1.2.0
process-1.2.3.0
rts-1.0
safe-0.3.8
satchmo-core-0.8.0
stm-2.4.4
syb-0.4.4
template-haskell-2.10.0.0
terminfo-0.4.0.1
text-1.2.0.4
th-expand-syns-0.3.0.6
th-lift-0.7.2
th-orphans-0.11.1
th-reify-many-0.1.3
time-1.5.0.1
transformers-0.4.2.0
unix-2.7.1.0
xhtml-3000.2.1
}}}" throwaway123
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
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
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
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
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
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
Relev