__color__	ticket	summary	component	version	priority	severity	milestone	owner	status	created	_changetime	_description	_reporter
2	7712	"""make install"" fails on Windows"	Build System	7.7	high		7.8.1	igloo	new	2013-02-22T08:55:07-0800	2013-03-24T15:34:03-0700	"Running the 'make install' command under Windows 8/MinGW produces an error. The full output of 'make install':

{{{
$ make install
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for `phase_1_builds'.
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final install
/bin/install -c -m 755 -d ""/usr/local/lib""
/bin/install -c -m 755  driver/split/dist/ghc-split ""/usr/local/lib""
driver/ghci/ghc.mk:56: *** removeFiles: Got leading slash: /usr/local/bin/ghcii.sh.  Stop.
make: *** [install] Error 2
}}}

It seems that the removeFiles function specifically disallows paths that start with a ""/"". Looking around at other places where removeFiles was being called with a rooted path, the path was also quoted. I added quotes to the path in the line mentioned in the error above (and one other place) and thereafter the 'make install' command proceeded without errors."	dpratt71
3	7768	"""untracked content"" in fresh clone of haskeline"	Build System	7.7	normal		7.8.1	igloo	new	2013-03-13T08:02:27-0700	2013-04-13T06:26:22-0700	"This sequence of events happened today:

{{{
~> git clone http://darcs.haskell.org/ghc.git; cd ghc; ./sync-all --testsuite get
...
~/ghc> git status
# On branch master
# Changes not staged for commit:
#   (use ""git add <file>..."" to update what will be committed)
#   (use ""git checkout -- <file>..."" to discard changes in working directory)
#   (commit or discard the untracked or modified content in submodules)
#
#	modified:   libraries/haskeline (untracked content)
#
no changes added to commit (use ""git add"" and/or ""git commit -a"")
~/ghc> cd libraries/haskeline
~/ghc/libraries/haskeline> git status
# Not currently on any branch.
# Untracked files:
#   (use ""git add <file>..."" to include in what will be committed)
#
#	""tests/dummy-I\314\202\302\274I\314\202\302\261I\314\210\302\203/""
nothing added to commit but untracked files present (use ""git add"" to track)
}}}

It seems harmless, but I can't seem to make the problem go away. I'm on a Mac."	goldfire
2	314	#line pragmas not respected inside nested comments	Compiler (Parser)	6.4	high	normal	7.8.1		new	2005-02-28T10:09:41-0800	2012-08-29T01:18:47-0700	"{{{
If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong. 

Minimal file exhibiting the error:

---
{-
/*
 * Copyright (c) 2005 Jesper Louis Andersen
<jlouis@mongers.org>
 *
 * Permission to use, copy, modify, and distribute this
software for any
 * purpose with or without fee is hereby granted,
provided that the above
 * copyright notice and this permission notice appear
in all copies.
 *
 * THE SOFTWARE IS PROVIDED ""AS IS"" AND THE AUTHOR
DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
 */
-}

c = 3 * ""string""

main = putStrLn $ show c
----

; ghc -cpp tmp.hs                              

tmp.hs:6:
    No instance for (Num [Char])
      arising from use of `*' at tmp.hs:6
    In the definition of `c': c = 3 * ""string""

Which is clearly wrong, since ``c'' is not defined on
line 6. 

Note I am not sure wether it is in the parser, or it is
rather in compilation
chain where cpp gets invoked one has to look for the
error. I have filed
it as a parser-bug nonetheless.

Fix: cpp(1) seems to output comments in the style
# xx ""filename""

where ``xx'' is a number stating the linenumber in the
original file.
Keeping track of this probably fixes the bug.

CPP version: GNU CPP from GCC 3.3.5
Operating System: OpenBSD 3.6-current (GENERIC) #1: Sun
Feb 20 10:23:54 CET 2005

Submitter: Jesper Louis Andersen <jlouis@mongers.org>

}}}"	nobody
4	4413	(^^) is not correct for Double and Float	libraries/base	7.1	low		7.6.2	tcsavage	new	2010-10-18T07:48:21-0700	2012-09-12T04:12:31-0700	"Consider
{{{
Prelude> 2 ^^ (-1024)
0.0
Prelude> 0.5 ^^ 1024
5.562684646268003e-309
}}}
The cause is
{{{
x ^^ n          =  if n >= 0 then x^n else recip (x^(negate n))
}}}
If we change it to
{{{
x ^^ n          =  if n >= 0 then x^n else ((recip x)^(negate n))
}}}
it'll do the right thing for Double and Float, and I don't know of any type where it would produce incorrect results.

Does it need a library proposal or can the change be made without?"	daniel.is.fischer
2	5780	-faggressive-primops change caused a failure in perf/compiler/parsing001	Compiler	7.2.2	high		7.8.1		new	2012-01-16T05:26:57-0800	2012-11-17T08:03:00-0800	"The commit 601c983dd0bada6b49bdadd8f172fd4eacac4b0c apparently caused a regression in perf/compiler/parsing001, so I'm reverting it pending investigation.  The patch should have made no changes to performance, because the new functionality was only enabled by a new flag.
"	simonmar
5	3543	-fext-core doesn't force recompilation when .hcr file doesn't exist	Driver	6.10.4	lowest	minor	7.6.2		new	2009-09-25T16:12:21-0700	2012-09-12T04:14:12-0700	"If I do:
ghc -o foo foo.hs
and then immediately afterward:
ghc -fext-core -c foo.hs

and foo.hcr doesn't exist, ghc still says ""Compilation is not required"" and doesn't create the External Core file. It should generate the .hcr given the -fext-core flag, even if the .hi file is up to date.

Sorry if this is a duplicate bug (I know that making the compilation manager pay attention to flags is an ongoing issue)."	tim
3	7735	-fext-core doesn't generate .hcr when .o and .hi files are present	External Core	7.6.2	normal		7.8.1		new	2013-03-03T13:35:59-0800	2013-04-13T05:38:07-0700	"Create a file inside a directory and compile it using -fext-core:

{{{ 
cd /tmp/
mkdir dir
echo ""module Main where main = return ()"" > dir/Main.hs
ghc --make -fext-core dir/Main.hs 
[1 of 1] Compiling Main             ( dir/Main.hs, dir/Main.o )
Linking dir/Main ...
kmels@kmels-workstelle /tmp $ ls dir/
Main  Main.hcr  Main.hi  Main.hs  Main.o
}}}

If the .hcr file is deleted and our program is compiled again with -fext-core, no .hcr file will be generated:

{{{ 
rm dir/Main.hcr 
ghc --make -fext-core dir/Main.hs 
ls dir/
Main  Main.hi  Main.hs  Main.o
}}} 

The file is generated if you 1. cd to dir/ and 2. ghc --make -fext-core Main.hs"	kmels
5	3321	-fhpc assumes original sources relative to the current directory	Compiler	6.10.1	lowest	minor	7.6.2		new	2009-06-22T11:24:01-0700	2012-09-12T04:14:10-0700	"For the most part, ghc can be invoked in a manner that is independent of the current directory by suitable use of `-i` options.

With `-fhpc` it appears that the hpc bits always look in the current directory to find original source files.

Consider the following file layout:
{{{
Codec/Compression/Zlib/Stream.hsc
dist/build/Codec/Compression/Zlib/Stream.hs
examples/gunzip.hs
}}}

Now if we `cd` to `examples` and run:
{{{
ghc --make gunzip.hs -lz -i../ -i../dist/build
}}}
then it works fine. It finds `Codec/Compression/Zlib/Stream.hs` in `../dist/build` and it never bothers to look for the original source of course.

Now in `-fhpc` mode it has to also find the original sources so that it can match things back to them. However just adding -fhpc to the above command fails:
{{{
ghc --make gunzip.hs -lz -i../ -i../dist/build -fhpc
[1 of 4] Compiling Codec.Compression.Zlib.Stream ( ../dist/build/Codec/Compression/Zlib/Stream.hs, ../dist/build/Codec/Compression/Zlib/Stream.o )
Codec/Compression/Zlib/Stream.hsc: getModificationTime: does not exist (No such file or directory)
}}}

So it's clearly not looking in the directory given by `-i..` for the original sources. Also, the failure mode is a bit unfriendly.

Cabal sometimes takes advantage of the fact that ghc can be invoked in a manner that is independent of the current directory, and we would like to add hpc support into Cabal."	duncan
5	2224	-fhpc inteferes/prevents rewrite rules from firing	Code Coverage	6.8.2	lowest	normal	7.6.2	andy@…	new	2008-04-16T17:54:56-0700	2012-09-12T04:13:56-0700	"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-simpl-stats A.hs -c

    1 ByteString pack/packAddress
}}}

Now with -fhpc:

{{{
2 RuleFired
    1 unpack
    1 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
3	5889	-fno-prof-count-entries leads to linking errors	Compiler	7.4.1	normal		7.6.2		new	2012-02-21T06:26:28-0800	2012-09-12T04:12:11-0700	"When I compile the attached program with a certain set of flags, I get a linking error.

{{{
% ghc -O -prof -fprof-auto -fno-prof-count-entries -fforce-recomp main.hs                           
[1 of 2] Compiling Foo              ( Foo.hs, Foo.o )
[2 of 2] Compiling Main             ( main.hs, main.o )
Linking main ...
main.o: In function `s1uR_info':
(.text+0xcc): undefined reference to `Foo_makePairzitotal_C0_cc'
collect2: ld returned 1 exit status
}}}"	akio
3	1526	-fobject-code doesn't apply to expressions typed at the prompt	Compiler	6.7	normal	normal	_|_		new	2007-07-12T00:32:40-0700	2013-01-22T15:29:18-0800	"While looking to see if I could easily fix #1525 myself, I saw a suspicious modification to the unboxed tuples error; examining more closely:

{{{
stefan@stefans:~/qhc/qhc-desugar/Qhc/TypeCheck$ ghci
Loading package base ... linking ... done.
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |    GHC Interactive, version 6.7.20070612, for Haskell 98.
/ /_\\/ __  / /___| |    http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|    Type :? for help.

Prelude> :set -fglasgow-exts 
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
  Possibly due to foreign import/export decls in source.
  Workaround: use -fobject-code, or compile this module to .o separately.
Prelude> :set -fobject-code
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
  Possibly due to foreign import/export decls in source.
  Workaround: use -fobject-code, or compile this module to .o separately.
Prelude> 
}}}

so the suggested workaround doesn't actually work.  I can certainly imagine a model of GHC compilation where the NCG doesn't support anonymous modules; in which case the easiest fix would be to tweak the error message.  But interactive, optimizing, native compilation *does* sound like a cool and relatively cheap-to-implement feature :)"	sorear
5	2710	-main-is flag in {-# OPTIONS #-} pragma not fully supported	Compiler	6.8.3	lowest	normal	7.6.2		new	2008-10-19T07:30:09-0700	2012-09-12T04:14:03-0700	"The `-main-is` flag is dynamic an may therefore be placed inside the `{-# OPTIONS #-}` pragma. Version 6.8.3 of ''runghc'' respects this flag (that is, ''runghc'' works as expected), but this cannot be said of ''ghc''.

=== Example file ''T.hs'' ===

{{{
{-# OPTIONS -main-is T.main #-}

module T where

main :: IO ()
main = putStrLn ""Hello world""
}}}

=== Example execution ===

{{{
$ ghc --make -o t T.hs
[1 of 1] Compiling T                ( T.hs, T.o )
Warning: output was redirected with -o, but no output will be generated
because there is no Main module.
}}}

=== Additional notes ===

This bug is related to ticket #1312, but the difference is that ticket #1312 only addressed ''runghc'', not ''ghc''."	Stephan202
5	917	-O introduces space leak	Compiler	6.5	lowest	normal	_|_		new	2006-09-28T16:38:21-0700	2012-09-26T00:19:41-0700	"consider the following variant of a popular space problem
{{{
initlast :: (()->[a]) -> ([a], a)
initlast xs = (init (xs ()), last (xs ()))

main = print $ case initlast (\()->[0..1000000000]) of
                 (init, last) -> (length init, last)
}}}

the long list has been wrapped in abstractions to avoid
sharing, gaining constant space processing rather than
the space leak in the original code - see

http://www.haskell.org/pipermail/haskell-cafe/2006-September/018447.html

http://www.haskell.org/pipermail/haskell-cafe/2006-September/018464.html

this works nicely if compiled without -O, but unfortunately,
-O reintroduces the space leak (apparently lifting and sharing
the common and space-expensive subexpression).

1. I didn't see a ticket for this issue, so I wanted to record the example

2. avoiding sharing isn't always possible, so it would be nice if one could 
""bypass"" sharing in such cases. in the old g-machine, that might have 
been as simple as introducing a pragma that tells the compiler to omit
the update after the eval in the code for some subexpression (so the
original application node would not be overwritten by the space-expensive
result, trading time for space). is there a chance for a similar trick
in GHC? so one might write code like this (handwaving:-):
{{{
initlast :: [a] -> ([a], a)
initlast xs = (init ({-# COPY #-} xs), last ({-# COPY #-} xs))

main = print $ case initlast [0..1000000000] of
                 (init, last) -> (length init, last)
}}}"	claus.reinke@…
5	2991	.mix files generation broken with -fhpc and --make flags with lhs modules	Code Coverage	6.10.1	lowest	normal	7.6.2	andy@…	new	2009-01-30T12:21:25-0800	2012-09-12T04:14:07-0700	"assume the project consisting of two files: !Main.lhs and !MyModule.hs. Main.lhs imports !MyModule via standard import. Build the project with

ghc --make -fhpc -o main Main.lhs

The generated .mix file contains relevant information and hpc markup correctly shows the coverage for !MyModule.

Now rename !MyModule.hs to !MyModule.lhs and enclose the code there in \begin{code} / \end{code}. Build again. The compilation still succeeds and the executable works fine. But !MyModule.mix now seems wrong and no hpc coverage information is available for !MyModule"	ppavel
3	5827	/usr/local hard-coded in cabal	libraries (other)	7.4.1-rc2	normal		7.6.2	duncan	new	2012-01-29T09:48:02-0800	2012-09-12T04:12:10-0700	"libraries/Cabal/Cabal/Distribution/Simple/InstallDirs.hs:defaultInstallDirs returns ""/usr/local""

(and in same directory, Hugs.hs packageDbPaths includes ""/usr/local/lib/hugs/packages"", and cabal-install/bootstrap.sh forces PREFIX=/usr/local/.)

""/usr/local"" ordinarily does not exist on the platform I'm building for (Haiku), so it isn't a convenient default for cabal.  The `prefix' value from ghc build configure would work for this case."	donn
2	7043	32-bit GHC ceiling of negative float SEGFAULT: 11	Compiler	7.4.1	high		7.6.2	igloo	new	2012-07-02T10:56:30-0700	2013-05-13T02:15:39-0700	When taking the ceiling of a negative float (like -0.8) with GHCi installed by the 32-bit .dmg provided on haskell.org there is a Segmentation Fault: 11 that occurs.  This does not happen in the 64-bit version, which works properly.	DrGodCarl
2	7011	32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8	libraries (other)	7.5	high		7.8.1		new	2012-06-18T23:52:45-0700	2012-10-11T11:27:09-0700	"If I use the 32bit version of GHC 7.4.2 (OS X installer from the GHC downloads page) on OS X 10.8 DP4 with Xcode 4.5 DP, the compilation of package integer-gmp (from the Git repo) fails. Specifically, the GMP files seem to be compiled for the wrong architecture and hence the linker complains — log file attached.

This problem may well also present on earlier version of OS X as well. (I haven't used the 32bit version for a while.)"	chak
3	7655	7.6.2 Segmentation Fault/Bus Error in large exponentation	GHCi	7.6.2	normal		7.8.1	igloo	new	2013-02-03T11:01:40-0800	2013-04-13T03:48:16-0700	"Mac OS X 10.8.2. Haskell Platform 2012.4, 64-bit. GHCI 7.4.2.

Large exponentations cause bus errors or segmentation faults.

Examples:

{{{
~/src/haskell$ ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 12345678901234567890 ^ 12345
Bus error: 10

~/src/haskell$ ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 2384729837498237^23455
Segmentation fault: 11
}}}"	Doug310
3	7730	:info and polykinds	Compiler (Type checker)	7.6.2	normal		7.8.1		new	2013-03-01T15:30:33-0800	2013-04-13T04:58:48-0700	"{{{
ghci -XPolyKinds

Prelude> data A x y
Prelude> :i A
data A k k x y 	-- Defined at <interactive>:3:6
}}}

The two `k` might be different. It should be either {{{A k l x y}}} or - without kind variables - {{{A x y}}}."	monoidal
3	7685	:script command does not resolve ~	GHCi	7.6.2	normal		7.8.1		new	2013-02-12T01:01:12-0800	2013-04-13T04:50:48-0700	"Although the tab completion after "":script ~/..."" would work, the command itself does not resolve ~ to the value of $HOME. This is counter-intuitive, and it would be nicer if ~ would work in parameters to :script."	nomeata
3	1400	:set +r doesn't work for interpreted modules	GHCi	6.7	normal	normal	_|_	simonmar	new	2007-05-31T07:58:51-0700	2013-01-22T08:32:23-0800	"I expect 

{{{
a = trace ""a"" 1 
}}}

and then evaluating a repeatedly to show:
""a""
1

as a result. ghci seems to do this, but with larger programs this doesn't appear to happen. 

I guess it's an implementation detail in that expressions don't ""need"" to be evaluated twice, but for debugging purposes it's vital that it does. 

I want that the first run of an algorithm produces the same trace as any subsequent one. Especially when one uses the 6.7 debugger this is an issue. Essentially, I need to load another module first and then the module I am interested in and then set the breakpoints again. This is a UI nightmare. 

The option +r ""revert top-level expressions after each evaluation"" seems to indicate that should do what I want, but it doesn't."	iampure@…
2	7452	[GNU gold] ld: error: cannot find [...]/Types__1.o	Build System	7.6.1	high		7.8.1		new	2012-11-26T05:45:41-0800	2013-04-12T13:20:22-0700	"`/usr/bin/ld` is gold linker and I am trying to compile GHC 7.6.1 using it. I grabbed GHC 7.6.1 from haskell.org/ghc and edited `settings`; i.e. removing `--hash-size=31` and `--reduce-memory-overheads`.

While running `make` the linker cannot find some object files:

{{{
$ make
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for `phase_1_builds'.
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all
/usr/bin/xsltproc  docs/man/flags.xsl docs/man/flags.xml > docs/man/ghc.1
  HC [stage 0] utils/hp2ps/dist/build/tmp/hp2ps
Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
    Call hs_init_ghc() from your main() function to set these options.
""cp"" -p utils/hp2ps/dist/build/tmp/hp2ps inplace/bin/hp2ps
  HC [stage 0] utils/genapply/dist/build/tmp/genapply
""cp"" -p utils/genapply/dist/build/tmp/genapply inplace/bin/genapply
  HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Types.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__1.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__2.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__3.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__4.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__5.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__6.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__7.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__8.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__9.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__10.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__11.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__12.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__13.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__14.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__15.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__16.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__17.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__18.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__19.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__20.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__21.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__22.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/Types_o_split/Types__23.o
collect2: error: ld returned 1 exit status
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
make: *** [all] Error 2
}}}

All object files that cannot be found are present and switching `/usr/bin/ld` to the bfd linker solves the problem."	mrothe
3	7463	[PATCH] When -keep-hc-files is enabled, foreign stubs *_stub.c should also be kept.	Compiler	7.6.1	normal		7.8.1	igloo	new	2012-11-29T20:24:42-0800	2013-04-14T23:20:47-0700	"GHC used to put `*_stub.c` into `stubdir` along with `*_stub.h` but now `*_stub.c` files are temporarily created and then removed, which means we have no stubs available when we are bootstrapping a compiler via C sources.

My [https://github.com/phonohawk/ghc/commit/680f44a4d325075cd26e9dd4c2fca1ee837847fe patch] is to keep `*_stub.c` as before, when `-keep-hc-files` is enabled:
{{{
% git fetch git://github.com/phonohawk/ghc.git c-sources-in-stubdir
}}}

Please also note that [http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#foreign-export-ghc the documentation about foreign stubs] is slightly outdated."	PHO
4	5209	^C doesn't correctly reset the prompt from within multiline commands in ghci	GHCi	7.0.3	low		7.6.2		new	2011-05-22T17:00:17-0700	2012-09-12T04:13:29-0700	"Steps to reproduce:

1. Open ghci.[[BR]]
2. Start a multiline command with "":{"".[[BR]]
3. Decide multiline commands are overrated, and hit Ctrl-C to cancel.[[BR]]

Observed output:
{{{
Prelude> :{
Prelude| 
Prelude| 
}}}

Expected output:
{{{
Prelude> :{
Prelude| 
Prelude> 
}}}"	dmwit
3	1687	A faster (^)-function.	Prelude	6.6.1	normal	normal	_|_		new	2007-09-12T09:10:47-0700	2013-01-26T14:29:30-0800	"This function performs better for me than the `(^)`-function in GHC. I seem to only be able to test it for the Integer type though and its only tested with ghc 6.6 (and ghc 6.6.1 by byorgey on #haskell).
I'm not sure if you really need this or if it is correct, but after discussion on #haskell i was asked to make a bug report so here it is! Enjoy. :)

{{{
module Pow (pow) where
import Prelude hiding ((^))
pow = (^)

(^) :: (Integral b, Num a) => a -> b -> a
x ^ y | y < 0     = error ""Negative exponent""
      | y == 0    = 1
      | y == 1    = x
      | odd y     = x * x^(y - 1)
      | otherwise = let x' = x^(y `div` 2) 
                    in x' * x'
}}}

Tests

{{{
-- TestData.hs
module TestData where
e = 10^8
}}}
{{{
-- mytest.hs
import Pow
import TestData
main = print $ (2 `pow` e) `mod` 2
}}}
{{{
-- ghctest.hs
import TestData
main = print $ (2 ^ e) `mod` 2
}}}

Test results (performance)
{{{
$ time ./ghctest
0

real    0m11.744s
user    0m11.449s
sys     0m0.104s

$ time ./mytest
0

real    0m6.794s
user    0m6.696s
sys     0m0.084s

-}
}}}

QuickCheck test
{{{
-- qc.hs
-- $ ./qc 
-- OK, passed 100 tests.

import Test.QuickCheck
import Pow

main = quickCheck prop 
prop x y = y >= 0 ==> x `pow` y == x^y
}}}"	moonlite@…
4	2401	aborting an STM transaction should throw an exception	Runtime System	6.8.3	low	normal	7.6.2		new	2008-06-28T15:44:52-0700	2012-09-12T04:12:15-0700	The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted  (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore.	sclv
4	5073	Add blockST for nested ST scopes	Compiler	7.0.3	low		7.6.2		new	2011-04-01T08:00:23-0700	2012-09-12T04:13:27-0700	"GHC lacks the `blockST` and `importVar` primitives introduced by Launchbury/Sabry:
 * http://www.cs.indiana.edu/~sabry/papers/monadic-state-ax.pdf (section 10).  
 * See also Fluet & Morrisset http://www.cs.rit.edu/~mtf/research/rgn-monad/JFP06/jfp06.pdf (page 7ff)

The two new combinators have these types:
{{{
blockST :: (forall r. ST (s,r) a) -> ST s a
importVar :: STRef s a -> STRef (s,r) a
}}}
They are useful, and have no runtime cost; I don't think it'd be hard to provide them.  We need these primitives, I think:
{{{
promoteState# :: State# s -> State# (s,r) a
demoteState#  :: State# (s,r) -> State# s
promoteVar# :: MutVar# s a -> MutVar# (s,r) a
}}}
All three are implemented as no-ops.  (Compare with `newMutVar#` etc in http://darcs.haskell.org/ghc/compiler/prelude/primops.txt.pp.)

Now the implementations look (something) like this. (For background see the current impementations of `ST` and `STRef` in http://darcs.haskell.org/packages/base/GHC (`ST.lhs` and `STRef.lhs` resp.)
{{{
blockST (ST thing) = ST (\s -> case thing (promoteState# s) of
                                 (s', r) -> (demoteState# s', r) )
promoteVar (STRef r) = STRef (promoteVar# r)
}}}
Things to think about:
 * Can we use coercions instead of primops?   (I think yes for `promote/demoteState` but it's unsound to demote variables.)
 * I'm hazy about what type safety guarantees we still have in Core, where the representation of the state monad is exposed.
 * Nomenclature. I'm not attached to these particular names.
 * Is there other relevant background material?"	simonpj
3	3353	Add CLDouble support	Compiler	6.12.1	normal	normal	_|_		new	2009-07-05T09:02:21-0700	2012-08-01T20:59:54-0700	"The FFI spec says that we should support `CLDouble`, but we don't (#2793).
"	igloo
2	7152	Add flag to configure that skips overwriting of symlinks on install	Build System	7.4.2	high		7.8.1		new	2012-08-15T13:47:48-0700	2013-03-25T18:31:26-0700	Sometimes when I'm installing a GHC release candidates I'd like to install the RC without overwriting the `ghc` etc symlinks in `/usr/local/bin`. It would be convenient to have a configure flag that told the install step to only install the versioned binaries (e.g. `ghc-6.2.1`) in `/usr/local/bin`, without the symlinks.	tibbe
3	6040	Adding a type signature changes heap allocation into stack allocation without changing the actual type	Compiler	7.4.1	normal		7.8.1	simonpj	new	2012-04-24T13:15:22-0700	2012-12-06T05:59:53-0800	"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
3	2917	alloca and allocaArray do not respect alignment	Compiler (FFI)	6.12.3	normal	normal	_|_		new	2009-01-06T12:16:57-0800	2011-05-04T18:28:50-0700	"When allocating memory with alloca or allocaArray the alignment of the Storable is not respected, alignment seems to be on 8 byte boundary. malloc and mallocArray seem to have the same problem.  And because of this functions like withArray etc also break the alignment restriction of the array element.

Run this and look at the pointer.
{{{
import Foreign.Ptr
import Foreign.Storable
import Foreign.Marshal.Array
import Foreign.Marshal

data Foo = Foo

instance Storable Foo where
    sizeOf _ = 8
    alignment _ = 256

main =
    allocaArray 5 $ \ p -> do
    let _ = p :: Ptr Foo
    print p
    q <- mallocArray 5
    let _ = q :: Ptr Foo
    print q
}}}
"	guest
2	7534	allocateRegsAndSpill: Cannot read from uninitialized register	Compiler	7.7	high		7.8.1		new	2012-12-27T01:46:57-0800	2013-04-12T15:01:10-0700	"Building git HEAD on linux-powerpc64 and I get:

{{{
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20121227 for powerpc-unknown-linux):
        allocateRegsAndSpill: Cannot read from uninitialized register
    %vI_na5b
}}}
"	erikd
5	3458	Allocation where none should happen	Compiler	6.10.4	lowest	normal	7.6.2		new	2009-08-24T02:36:46-0700	2012-09-12T04:14:11-0700	"These two functions, according to profiling, do a lot of allocation:
{{{
gen d r n m s p
    | r == ll   = do
        pokeElemOff p n 0x0a
        gen d 0     (n+1) (m+1) s p
    | n == m    = do
        pokeElemOff p n 0x0a
        return (s, if r == 0 then m else m+1)
    | otherwise = do
        let t = next s
        pokeElemOff p n (pick d t)
        gen d (r+1) (n+1) m     t p

------------------------------------------------------------------------

pick (c, p) r = loop 0 where
    loop i = if r < unsafeAt p i
              then fromIntegral $ unsafeAt c i :: Word8
              else loop (i+1)
}}}
------------------------------------------------------------------------

Core for pick:
{{{
[GlobalId]
[Arity 3
 NoCafRefs
 Str: DmdType LLL]
$w$spick_r3kC =
  \ (ww_s33o :: GHC.Prim.ByteArray#)
    (ww1_s33v :: GHC.Prim.ByteArray#)
    (ww2_s33A :: GHC.Prim.Word#) ->
    letrec {
      $wloop_s38I :: GHC.Prim.Int# -> GHC.Prim.Word#
      [Arity 1
       Str: DmdType L]
      $wloop_s38I =
        \ (ww3_s339 :: GHC.Prim.Int#) ->
          __scc {pick main:Main !}
          case GHC.Prim.ltWord#
                 ww2_s33A (GHC.Prim.indexWord32Array# ww1_s33v ww3_s339)
          of wild_X3O {
            GHC.Bool.False -> $wloop_s38I (GHC.Prim.+# ww3_s339 1);
            GHC.Bool.True ->
              GHC.Prim.narrow8Word# (GHC.Prim.indexWord32Array# ww_s33o ww3_s339)
          }; } in
    case __scc {pick main:Main}
         case $wloop_s38I 0 of ww3_s33d { __DEFAULT ->
         GHC.Word.W8# ww3_s33d
         }
    of ww3_s33D { GHC.Word.W8# ww4_s33E ->
    ww4_s33E
    }
}}}
------------------------------------------------------------------------

Core for gen (long):
{{{
Rec {
$s$wa_r3mi :: GHC.Prim.State# GHC.Prim.RealWorld
              -> GHC.Prim.Addr#
              -> GHC.Prim.Word#
              -> GHC.Prim.Int#
              -> GHC.Prim.Int#
              -> GHC.Prim.Int#
              -> GHC.Prim.ByteArray#
              -> GHC.Types.Int
              -> GHC.Types.Int
              -> GHC.Types.Int
              -> GHC.Prim.ByteArray#
              -> GHC.Types.Int
              -> GHC.Types.Int
              -> GHC.Types.Int
              -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                    (GHC.Word.Word32, GHC.Types.Int) #)
[GlobalId]
[Arity 14
 NoCafRefs]
$s$wa_r3mi =
  \ (sc_s3es :: GHC.Prim.State# GHC.Prim.RealWorld)
    (sc1_s3et :: GHC.Prim.Addr#)
    (sc2_s3eu :: GHC.Prim.Word#)
    (sc3_s3ev :: GHC.Prim.Int#)
    (sc4_s3ew :: GHC.Prim.Int#)
    (sc5_s3ex :: GHC.Prim.Int#)
    (sc6_s3ey :: GHC.Prim.ByteArray#)
    (sc7_s3ez :: GHC.Types.Int)
    (sc8_s3eA :: GHC.Types.Int)
    (sc9_s3eB :: GHC.Types.Int)
    (sc10_s3eC :: GHC.Prim.ByteArray#)
    (sc11_s3eD :: GHC.Types.Int)
    (sc12_s3eE :: GHC.Types.Int)
    (sc13_s3eF :: GHC.Types.Int) ->
    let {
      m_s39b :: GHC.Types.Int
      []
      m_s39b = GHC.Types.I# sc3_s3ev } in
    ((__scc {gen main:Main !}
      case sc5_s3ex of wild_B1 {
        __DEFAULT ->
          case GHC.Prim.==# sc4_s3ew sc3_s3ev of wild1_X3F {
            GHC.Bool.False ->
              (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
                 let {
                   ww_s33e :: GHC.Prim.Word#
                   []
                   ww_s33e =
                     GHC.Prim.remWord#
                       (GHC.Prim.narrow32Word#
                          (GHC.Prim.plusWord#
                             (GHC.Prim.narrow32Word# (GHC.Prim.timesWord# __word 3877 sc2_s3eu))
                             __word 29573))
                       __word 139968 } in
                 case $w$spick_r3k8 sc10_s3eC sc6_s3ey ww_s33e
                 of ww1_s33i { __DEFAULT ->
                 case GHC.Prim.writeWord8OffAddr#
                        @ GHC.Prim.RealWorld sc1_s3et sc4_s3ew ww1_s33i eta_a2vm
                 of s21_a2wV { __DEFAULT ->
                 $s$wa_r3mi
                   s21_a2wV
                   sc1_s3et
                   ww_s33e
                   sc3_s3ev
                   (GHC.Prim.+# sc4_s3ew 1)
                   (GHC.Prim.+# wild_B1 1)
                   sc6_s3ey
                   sc7_s3ez
                   sc8_s3eA
                   sc9_s3eB
                   sc10_s3eC
                   sc11_s3eD
                   sc12_s3eE
                   sc13_s3eF
                 }
                 })
              `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                      :: GHC.Prim.State# GHC.Prim.RealWorld
                         -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                               (GHC.Word.Word32, GHC.Types.Int) #)
                           ~
                         GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int));
            GHC.Bool.True ->
              (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
                 case GHC.Prim.writeWord8OffAddr#
                        @ GHC.Prim.RealWorld sc1_s3et sc4_s3ew __word 10 eta_a2vm
                 of s21_a2wV { __DEFAULT ->
                 (# s21_a2wV,
                    (GHC.Word.W32# sc2_s3eu,
                     case wild_B1 of wild2_X4o {
                       __DEFAULT -> GHC.Types.I# (GHC.Prim.+# sc3_s3ev 1); 0 -> m_s39b
                     }) #)
                 })
              `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                      :: GHC.Prim.State# GHC.Prim.RealWorld
                         -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                               (GHC.Word.Word32, GHC.Types.Int) #)
                           ~
                         GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int))
          };
        60 ->
          (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
             case GHC.Prim.writeWord8OffAddr#
                    @ GHC.Prim.RealWorld sc1_s3et sc4_s3ew __word 10 eta_a2vm
             of s21_a2wV { __DEFAULT ->
             $s$wa1_r3mk
               s21_a2wV
               sc1_s3et
               sc2_s3eu
               (GHC.Prim.+# sc3_s3ev 1)
               (GHC.Prim.+# sc4_s3ew 1)
               sc6_s3ey
               sc7_s3ez
               sc8_s3eA
               sc9_s3eB
               sc10_s3eC
               sc11_s3eD
               sc12_s3eE
               sc13_s3eF
             })
          `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                  :: GHC.Prim.State# GHC.Prim.RealWorld
                     -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                           (GHC.Word.Word32, GHC.Types.Int) #)
                       ~
                     GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int))
      })
     `cast` ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)
             :: GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)
                  ~
                GHC.Prim.State# GHC.Prim.RealWorld
                -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                      (GHC.Word.Word32, GHC.Types.Int) #)))
      sc_s3es
$s$wa1_r3mk :: GHC.Prim.State# GHC.Prim.RealWorld
               -> GHC.Prim.Addr#
               -> GHC.Prim.Word#
               -> GHC.Prim.Int#
               -> GHC.Prim.Int#
               -> GHC.Prim.ByteArray#
               -> GHC.Types.Int
               -> GHC.Types.Int
               -> GHC.Types.Int
               -> GHC.Prim.ByteArray#
               -> GHC.Types.Int
               -> GHC.Types.Int
               -> GHC.Types.Int
               -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                     (GHC.Word.Word32, GHC.Types.Int) #)
[GlobalId]
[Arity 13
 NoCafRefs]
$s$wa1_r3mk =
  \ (sc_s3fH :: GHC.Prim.State# GHC.Prim.RealWorld)
    (sc1_s3fI :: GHC.Prim.Addr#)
    (sc2_s3fJ :: GHC.Prim.Word#)
    (sc3_s3fK :: GHC.Prim.Int#)
    (sc4_s3fL :: GHC.Prim.Int#)
    (sc5_s3fM :: GHC.Prim.ByteArray#)
    (sc6_s3fN :: GHC.Types.Int)
    (sc7_s3fO :: GHC.Types.Int)
    (sc8_s3fP :: GHC.Types.Int)
    (sc9_s3fQ :: GHC.Prim.ByteArray#)
    (sc10_s3fR :: GHC.Types.Int)
    (sc11_s3fS :: GHC.Types.Int)
    (sc12_s3fT :: GHC.Types.Int) ->
    let {
      m_s39b :: GHC.Types.Int
      []
      m_s39b = GHC.Types.I# sc3_s3fK } in
    ((__scc {gen main:Main !}
      case GHC.Prim.==# sc4_s3fL sc3_s3fK of wild_X3F {
        GHC.Bool.False ->
          (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
             let {
               ww_s33e :: GHC.Prim.Word#
               []
               ww_s33e =
                 GHC.Prim.remWord#
                   (GHC.Prim.narrow32Word#
                      (GHC.Prim.plusWord#
                         (GHC.Prim.narrow32Word# (GHC.Prim.timesWord# __word 3877 sc2_s3fJ))
                         __word 29573))
                   __word 139968 } in
             case $w$spick_r3k8 sc9_s3fQ sc5_s3fM ww_s33e
             of ww1_s33i { __DEFAULT ->
             case GHC.Prim.writeWord8OffAddr#
                    @ GHC.Prim.RealWorld sc1_s3fI sc4_s3fL ww1_s33i eta_a2vm
             of s21_a2wV { __DEFAULT ->
             $s$wa_r3mi
               s21_a2wV
               sc1_s3fI
               ww_s33e
               sc3_s3fK
               (GHC.Prim.+# sc4_s3fL 1)
               1
               sc5_s3fM
               sc6_s3fN
               sc7_s3fO
               sc8_s3fP
               sc9_s3fQ
               sc10_s3fR
               sc11_s3fS
               sc12_s3fT
             }
             })
          `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                  :: GHC.Prim.State# GHC.Prim.RealWorld
                     -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                           (GHC.Word.Word32, GHC.Types.Int) #)
                       ~
                     GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int));
        GHC.Bool.True ->
          (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
             case GHC.Prim.writeWord8OffAddr#
                    @ GHC.Prim.RealWorld sc1_s3fI sc4_s3fL __word 10 eta_a2vm
             of s21_a2wV { __DEFAULT ->
             (# s21_a2wV, (GHC.Word.W32# sc2_s3fJ, m_s39b) #)
             })
          `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                  :: GHC.Prim.State# GHC.Prim.RealWorld
                     -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                           (GHC.Word.Word32, GHC.Types.Int) #)
                       ~
                     GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int))
      })
     `cast` ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)
             :: GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)
                  ~
                GHC.Prim.State# GHC.Prim.RealWorld
                -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                      (GHC.Word.Word32, GHC.Types.Int) #)))
      sc_s3fH
end Rec }

$s$wa2_r3mm :: GHC.Prim.State# GHC.Prim.RealWorld
               -> GHC.Prim.Addr#
               -> GHC.Word.Word32
               -> GHC.Prim.Int#
               -> GHC.Prim.Int#
               -> (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32,
                   Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32)
               -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                     (GHC.Word.Word32, GHC.Types.Int) #)
[GlobalId]
[Arity 6
 NoCafRefs]
$s$wa2_r3mm =
  \ (sc_s3eH :: GHC.Prim.State# GHC.Prim.RealWorld)
    (sc1_s3eI :: GHC.Prim.Addr#)
    (sc2_s3eJ :: GHC.Word.Word32)
    (sc3_s3eK :: GHC.Prim.Int#)
    (sc4_s3eL :: GHC.Prim.Int#)
    (sc5_s3eM :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32,
                  Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32)) ->
    let {
      m_s39b :: GHC.Types.Int
      []
      m_s39b = GHC.Types.I# sc3_s3eK } in
    ((__scc {gen main:Main !}
      case GHC.Prim.==# sc4_s3eL sc3_s3eK of wild_X3F {
        GHC.Bool.False ->
          (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
             case sc5_s3eM of w_X34x { (ww_s32X, ww1_s334) ->
             case ww_s32X
             of ww2_X34F
             { Data.Array.Base.UArray ww3_s32Z ww4_s330 ww5_s331 ww6_s332 ->
             case ww1_s334
             of ww7_X34X
             { Data.Array.Base.UArray ww8_s336 ww9_s337 ww10_s338 ww11_s339 ->
             case __scc {next main:Main}
                  case sc2_s3eJ of wild1_a2Bw { GHC.Word.W32# y#_a2By ->
                  GHC.Word.W32#
                    (GHC.Prim.remWord#
                       (GHC.Prim.narrow32Word#
                          (GHC.Prim.plusWord#
                             (GHC.Prim.narrow32Word# (GHC.Prim.timesWord# __word 3877 y#_a2By))
                             __word 29573))
                       __word 139968)
                  }
             of w1_X35g { GHC.Word.W32# ww12_s33e ->
             case $w$spick_r3k8 ww6_s332 ww11_s339 ww12_s33e
             of ww13_s33i { __DEFAULT ->
             case GHC.Prim.writeWord8OffAddr#
                    @ GHC.Prim.RealWorld sc1_s3eI sc4_s3eL ww13_s33i eta_a2vm
             of s21_a2wV { __DEFAULT ->
             $s$wa_r3mi
               s21_a2wV
               sc1_s3eI
               ww12_s33e
               sc3_s3eK
               (GHC.Prim.+# sc4_s3eL 1)
               1
               ww11_s339
               ww10_s338
               ww9_s337
               ww8_s336
               ww6_s332
               ww5_s331
               ww4_s330
               ww3_s32Z
             }
             }
             }
             }
             }
             })
          `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                  :: GHC.Prim.State# GHC.Prim.RealWorld
                     -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                           (GHC.Word.Word32, GHC.Types.Int) #)
                       ~
                     GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int));
        GHC.Bool.True ->
          (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
             case GHC.Prim.writeWord8OffAddr#
                    @ GHC.Prim.RealWorld sc1_s3eI sc4_s3eL __word 10 eta_a2vm
             of s21_a2wV { __DEFAULT ->
             (# s21_a2wV, (sc2_s3eJ, m_s39b) #)
             })
          `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                  :: GHC.Prim.State# GHC.Prim.RealWorld
                     -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                           (GHC.Word.Word32, GHC.Types.Int) #)
                       ~
                     GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int))
      })
     `cast` ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)
             :: GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)
                  ~
                GHC.Prim.State# GHC.Prim.RealWorld
                -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                      (GHC.Word.Word32, GHC.Types.Int) #)))
      sc_s3eH

$wa1_r3mo :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32,
              Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32)
             -> GHC.Prim.Int#
             -> GHC.Prim.Int#
             -> GHC.Prim.Int#
             -> GHC.Word.Word32
             -> GHC.Prim.Addr#
             -> GHC.Prim.State# GHC.Prim.RealWorld
             -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                   (GHC.Word.Word32, GHC.Types.Int) #)
[GlobalId]
[Arity 7
 NoCafRefs
 Str: DmdType LLLLLLL]
$wa1_r3mo =
  \ (w_s33r :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32,
                Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32))
    (ww_s33u :: GHC.Prim.Int#)
    (ww1_s33y :: GHC.Prim.Int#)
    (ww2_s33C :: GHC.Prim.Int#)
    (w1_s33E :: GHC.Word.Word32)
    (ww3_s33H :: GHC.Prim.Addr#)
    (w2_s33J :: GHC.Prim.State# GHC.Prim.RealWorld) ->
    let {
      m_s39b :: GHC.Types.Int
      []
      m_s39b = GHC.Types.I# ww2_s33C } in
    ((__scc {gen main:Main !}
      case ww_s33u of wild_B1 {
        __DEFAULT ->
          case GHC.Prim.==# ww1_s33y ww2_s33C of wild1_X3F {
            GHC.Bool.False ->
              (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
                 case w_s33r of w3_X34x { (ww4_s32X, ww5_s334) ->
                 case ww4_s32X
                 of ww6_X34F
                 { Data.Array.Base.UArray ww7_s32Z ww8_s330 ww9_s331 ww10_s332 ->
                 case ww5_s334
                 of ww11_X34X
                 { Data.Array.Base.UArray ww12_s336 ww13_s337 ww14_s338 ww15_s339 ->
                 case __scc {next main:Main}
                      case w1_s33E of wild11_a2Bw { GHC.Word.W32# y#_a2By ->
                      GHC.Word.W32#
                        (GHC.Prim.remWord#
                           (GHC.Prim.narrow32Word#
                              (GHC.Prim.plusWord#
                                 (GHC.Prim.narrow32Word# (GHC.Prim.timesWord# __word 3877 y#_a2By))
                                 __word 29573))
                           __word 139968)
                      }
                 of w4_X35g { GHC.Word.W32# ww16_s33e ->
                 case $w$spick_r3k8 ww10_s332 ww15_s339 ww16_s33e
                 of ww17_s33i { __DEFAULT ->
                 case GHC.Prim.writeWord8OffAddr#
                        @ GHC.Prim.RealWorld ww3_s33H ww1_s33y ww17_s33i eta_a2vm
                 of s21_a2wV { __DEFAULT ->
                 $s$wa_r3mi
                   s21_a2wV
                   ww3_s33H
                   ww16_s33e
                   ww2_s33C
                   (GHC.Prim.+# ww1_s33y 1)
                   (GHC.Prim.+# wild_B1 1)
                   ww15_s339
                   ww14_s338
                   ww13_s337
                   ww12_s336
                   ww10_s332
                   ww9_s331
                   ww8_s330
                   ww7_s32Z
                 }
                 }
                 }
                 }
                 }
                 })
              `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                      :: GHC.Prim.State# GHC.Prim.RealWorld
                         -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                               (GHC.Word.Word32, GHC.Types.Int) #)
                           ~
                         GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int));
            GHC.Bool.True ->
              (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
                 case GHC.Prim.writeWord8OffAddr#
                        @ GHC.Prim.RealWorld ww3_s33H ww1_s33y __word 10 eta_a2vm
                 of s21_a2wV { __DEFAULT ->
                 (# s21_a2wV,
                    (w1_s33E,
                     case wild_B1 of wild2_X4o {
                       __DEFAULT -> GHC.Types.I# (GHC.Prim.+# ww2_s33C 1); 0 -> m_s39b
                     }) #)
                 })
              `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                      :: GHC.Prim.State# GHC.Prim.RealWorld
                         -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                               (GHC.Word.Word32, GHC.Types.Int) #)
                           ~
                         GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int))
          };
        60 ->
          (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) ->
             case GHC.Prim.writeWord8OffAddr#
                    @ GHC.Prim.RealWorld ww3_s33H ww1_s33y __word 10 eta_a2vm
             of s21_a2wV { __DEFAULT ->
             $s$wa2_r3mm
               s21_a2wV
               ww3_s33H
               w1_s33E
               (GHC.Prim.+# ww2_s33C 1)
               (GHC.Prim.+# ww1_s33y 1)
               w_s33r
             })
          `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int))
                  :: GHC.Prim.State# GHC.Prim.RealWorld
                     -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                           (GHC.Word.Word32, GHC.Types.Int) #)
                       ~
                     GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int))
      })
     `cast` ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)
             :: GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)
                  ~
                GHC.Prim.State# GHC.Prim.RealWorld
                -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                      (GHC.Word.Word32, GHC.Types.Int) #)))
      w2_s33J

a2_r3mq :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32,
            Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32)
           -> GHC.Types.Int
           -> GHC.Types.Int
           -> GHC.Types.Int
           -> GHC.Word.Word32
           -> GHC.Ptr.Ptr GHC.Word.Word8
           -> GHC.Prim.State# GHC.Prim.RealWorld
           -> (# GHC.Prim.State# GHC.Prim.RealWorld,
                 (GHC.Word.Word32, GHC.Types.Int) #)
[GlobalId]
[Arity 7
 NoCafRefs
 Str: DmdType LU(L)U(L)U(L)LU(L)L]
a2_r3mq =
  __inline_me (\ (w_s33r :: (Data.Array.Base.UArray
                               GHC.Types.Int GHC.Word.Word32,
                             Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32))
                 (w1_s33s :: GHC.Types.Int)
                 (w2_s33w :: GHC.Types.Int)
                 (w3_s33A :: GHC.Types.Int)
                 (w4_s33E :: GHC.Word.Word32)
                 (w5_s33F :: GHC.Ptr.Ptr GHC.Word.Word8)
                 (w6_s33J :: GHC.Prim.State# GHC.Prim.RealWorld) ->
                 case w1_s33s of w7_X35h { GHC.Types.I# ww_s33u ->
                 case w2_s33w of w8_X35q { GHC.Types.I# ww1_s33y ->
                 case w3_s33A of w9_X35z { GHC.Types.I# ww2_s33C ->
                 case w5_s33F of w10_X35J { GHC.Ptr.Ptr ww3_s33H ->
                 $wa1_r3mo w_s33r ww_s33u ww1_s33y ww2_s33C w4_s33E ww3_s33H w6_s33J
                 }
                 }
                 }
                 })
}}}
"	guest
3	4268	Annotation extension needs a flag	Compiler	7.0.4	normal		7.6.2		new	2010-08-23T02:57:25-0700	2012-12-05T20:19:47-0800	There's no flag to enable the annotations extension, as far as I can tell.	simonmar
5	3725	Annotations not written to interface files	Compiler	6.13	lowest		7.6.2		new	2009-12-03T17:57:10-0800	2012-09-12T04:14:13-0700	"Small example:
{{{
module C where

data T a = T a
}}}
Compile it:
{{{
newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs
newbie:tests rl$ ls -l C.hi
-rw-r--r--  1 rl  rl  485  4 Dec 12:53 C.hi
}}}
Add an annotation: `{-# ANN type T () #-}`. Compile:
{{{
newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
newbie:tests rl$ ls -l C.hi
-rw-r--r--  1 rl  rl  485  4 Dec 12:53 C.hi
}}}
Note that the interface file hasn't been updated. Remove `C.hi` and recompile:
{{{
newbie:tests rl$ rm C.hi
newbie:tests rl$ ~/projects/ndp/ghc/inplace/bin/ghc-stage2 -O2 -c C.hs
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
newbie:tests rl$ ls -l C.hi
-rw-r--r--  1 rl  rl  507  4 Dec 12:54 C.hi
}}}
Only now has the annotation been written to `C.hi`."	rl
5	2823	Another arity expansion bug	Compiler	6.10.1	lowest	normal	7.6.2		new	2008-11-28T02:02:01-0800	2012-09-12T04:14:05-0700	"Roman reports: I've finally tracked down one big optimisation problem (at least, I
think it is big). Here is a small example:
{{{
foo :: Eq a => a -> a
{-# NOINLINE foo #-}
foo x = x

bar :: Eq a => a -> a
{-# INLINE [1] bar #-}
bar x = let p = foo (x,x)
             q = foo (p,p) in fst (fst q)
}}}
For some reason, bar's arity is 1 which is wrong. If we replace `(fst (fst q))` by `(fst p)`, it gets the correct arity of 2.

The problem is that because of the arity, `(bar $dEq)` is then floated
out as far as possible which breaks fusion if we have RULES for bar.
In case you are interested, this affects `splitSD` in `dph-prim-par/Data/
Array/Parallel/Unlifted/Distributed/Arrays.hs`. I haven't noticed this
previously because we didn't use segmented arrays as much.

"	simonpj
3	7913	Argument order not preserved by nubBy	Prelude	7.6.3	normal				new	2013-05-15T10:49:27-0700	2013-05-15T10:49:27-0700	"Hello.

I recently wanted to know how the element 4 in [2,4] is ruled out by:

{{{
nubBy (\x y -> x `mod` y == 0) [2,4]
}}}

and discussing this on #haskell we discovered that the documentation or the code is buggy.

The [http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/Data-List.html#nubBy numBy source] states that ''we keep the call to `eq` with arguments in the same order as in the reference implementation'', which, comparing the following two lines, is not true:

{{{
nubBy eq (x:xs)         =  x : nubBy eq (filter (\ y -> not (eq x y)) xs)

elem_by eq y (x:xs)     =  y `eq` x || elem_by eq y xs
}}}

Also this is easily proved by defining:

{{{
nubBy' eq [] = []
nubBy' eq (x:xs) = x : nubBy' eq (filter (\ y -> not (eq x y)) xs)
}}}

Then running:

{{{
nubBy (\x y -> x `mod` y == 0) [2,4]
}}}

which yields [2] because of '''eq y x''' and 

{{{
nubBy' (\x y -> x `mod` y == 0) [2,4]
}}}

which yields [2,4] because of '''eq x y'''."	paullik
3	5809	Arity analysis could be better	Compiler	7.5	normal		7.6.2	simonpj	new	2012-01-23T02:39:35-0800	2012-09-12T04:12:09-0700	"Here's an example I tripped over while optimising Hoopl.  Given the following source code:

{{{
-- | if the graph being analyzed is open at the entry, there must
--   be no other entry point, or all goes horribly wrong...
analyzeFwd
   :: forall n f e .  NonLocal n =>
      FwdPass FuelUniqSM n f
   -> MaybeC e [Label]
   -> Graph n e C -> Fact e f
   -> FactBase f
analyzeFwd FwdPass { fp_lattice = lattice,
                     fp_transfer = FwdTransfer3 (ftr, mtr, ltr) }
  entries g in_fact = graph g in_fact
  where
    graph :: Graph n e C -> Fact e f -> FactBase f
    graph (GMany entry blockmap NothingO)
      = case (entries, entry) of
         (NothingC, JustO entry)   -> block entry `cat` body (successors entry)
         (JustC entries, NothingO) -> body entries
         _ -> error ""bogus GADT pattern match failure""
     where
       body  :: [Label] -> Fact C f -> Fact C f
       body entries f
         = fixpoint_anal Fwd lattice do_block entries blockmap f
         where
           do_block :: forall x . Block n C x -> FactBase f -> Fact x f
           do_block b fb = block b entryFact
             where entryFact = getFact lattice (entryLabel b) fb

    block :: forall e x . Block n e x -> f -> Fact x f
    block BNil            = id
    block (BlockCO n b)   = ftr n `cat` block b
    block (BlockCC l b n) = ftr l `cat` block b `cat` ltr n
    block (BlockOC   b n) =             block b `cat` ltr n

    block (BMiddle n)     = mtr n
    block (BCat b1 b2)    = block b1 `cat` block b2
    block (BHead h n)     = block h  `cat` mtr n
    block (BTail n t)     = mtr  n   `cat` block t

    {-# INLINE cat #-}
    cat ft1 ft2 = \f -> ft2 (ft1 f)
}}}

GHC does not eta-expand `block`, resulting in terrible code.  

{{{
      block_s2bB [Occ=LoopBreaker]
        :: forall e1_aPa x_aPb.
           Compiler.Hoopl.Graph.Block n_aGr e1_aPa x_aPb
           -> f_aGs -> Compiler.Hoopl.Dataflow.Fact x_aPb f_aGs
      [LclId, Arity=1, Str=DmdType S]
      block_s2bB =
        \ (@ e1_a1g7)
          (@ x_a1g8)
          (ds1_d1Le :: Compiler.Hoopl.Graph.Block n_aGr e1_a1g7 x_a1g8) ->
          case ds1_d1Le of _ {
            Compiler.Hoopl.Graph.BlockCO rb1_d1QD rb2_d1QE n_aPo b_aPp ->
              let {
                a4_s2ri [Dmd=Just L]
                  :: f_aGs
                     -> Compiler.Hoopl.Dataflow.Fact Compiler.Hoopl.Graph.O f_aGs
                [LclId, Str=DmdType]
                a4_s2ri =
                  block_s2bB
                    @ Compiler.Hoopl.Graph.O @ Compiler.Hoopl.Graph.O b_aPp } in
              let {
                ft1_aPC [Dmd=Just L] :: f_aGs -> f_aGs
                [LclId, Str=DmdType]
                ft1_aPC = ww2_s2Dc n_aPo } in
              (\ (f_aPE :: f_aGs) -> a4_s2ri (ft1_aPC f_aPE))
              `cast` (<f_aGs>
                      -> Compiler.Hoopl.Dataflow.TFCo:R:FactOf
                           (Sym
                              (Compiler.Hoopl.Dataflow.TFCo:R:FactOf
                                 <f_aGs>) ; Compiler.Hoopl.Dataflow.Fact (Sym rb2_d1QE) <f_aGs>)
                      :: (f_aGs
                          -> Compiler.Hoopl.Dataflow.Fact
                               Compiler.Hoopl.Graph.O (Compiler.Hoopl.Dataflow.R:FactOf f_aGs))
                           ~#
                         (f_aGs
                          -> Compiler.Hoopl.Dataflow.R:FactOf
                               (Compiler.Hoopl.Dataflow.Fact x_a1g8 f_aGs)));
}}}

In order to eta-expand `block`, GHC would have to realise that `graph` is always called with 2 arguments, which means that `block` is always called with 2 arguments (even though it calls itself recursively with only one argument).
"	simonmar
5	2915	Arity is smaller than need be	Compiler	6.10.1	lowest	normal	7.6.2	simonpj	new	2009-01-06T08:51:58-0800	2012-09-12T04:14:05-0700	"Consider 
{{{
h x = let f = case x of { True -> t1; False -> t2 }
          in (f,f)
}}}
where `t1` and `t2` have arity 1. You'd think that `f` should have arity 1, but it doesn't.  (Reason: `exprArity`, used in `Simplify.addNonRecWithUnf`, doesn't look through the case.)

Fix this as part of the upcoming arity cleanup.

Simon"	simonpj
4	5333	Arrow command combinators and infixr cause the desugarer to fail	Compiler (Parser)	7.0.3	low		7.6.2	ross	new	2011-07-19T18:46:52-0700	2013-03-04T01:50:00-0800	"The following code exhibits the bug:

{{{
{-# LANGUAGE Arrows, NoMonomorphismRestriction #-}
module T where

import Prelude hiding ( id, (.) )
import Control.Arrow

cc1 :: Arrow a => a e b -> a e b -> a e b
cc1 = undefined

-- 'g' fails to compile.
-- g = proc (x, y, z) ->
--   ((returnA -< x) &&& (returnA -< y) &&& (returnA -< z))

-- 'f' compiles:
--   - without an infix declaration
--   - with the infixl declaration
-- and fails with the infixr declaration
infixr 6 `cc1`
-- infixl 6 `cc1`

f = proc (x, y, z) ->
  ((returnA -< x) `cc1` (returnA -< y) `cc1` (returnA -< z))

}}}

GHC says:

{{{
ghc: panic! (the 'impossible' happened)
  (GHC version 7.0.3 for i386-apple-darwin):
	dsSyntaxTable Not found: base:GHC.Desugar.>>>{v 01W}
}}}
"	peteg
5	344	arrow notation: incorrect scope of existential dictionaries	Compiler (Type checker)	6.4	lowest	normal	7.6.2	ross	new	2005-04-07T13:39:35-0700	2013-03-04T01:43:32-0800	"{{{
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
        cgPanic
    deref{v a1yz}
    static binds for:
    local binds for:
    SRT labelghc-6.4: panic! (the `impossible'
happened, GHC version 6.4):
        initC: srt

Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.

I've attached a test driver that can reproduce the problem.

-- Esa Pulkkinen <esa.pulkkinen@kotiposti.net>

}}}"	nobody
2	7799	Assembly error while building GHC 7.7	Compiler (FFI)	7.7	high		7.8.1	igloo	new	2013-03-28T12:31:21-0700	2013-04-13T07:24:28-0700	"While building GHC 7.7 (after running `make') I got this error message:

{{{
$ ""inplace/bin/ghc-stage1"" -keep-tmp-files -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc -fPIC -dynamic  -H64m -O0 -fasm    -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build   -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist-install/build/System/Posix/Internals.dyn_o 
<braries/base/dist-install/build/System/Posix/Internals.dyn_o 
ghc23405_0.c: Assembler messages:

ghc23405_0.c:127:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:153:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:181:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:207:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:235:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:261:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:285:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:311:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:339:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:367:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:393:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:421:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:449:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:477:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:505:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:525:0:
     Error: junk at end of line, first unrecognized character is `1'

ghc23405_0.c:526:0:
     Error: junk at end of line, first unrecognized character is `1'

ghc23405_0.c:527:0:  Error: Missing symbol name in directive

ghc23405_0.c:527:0:
     Error: junk at end of line, first unrecognized character is `1'

ghc23405_0.c:528:0:  Error: Missing symbol name in directive
[1] baldur@baldur-lappi:~/ghc> ""inplace/bin/ghc-stage1"" -keep-tmp-files -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc -fPIC -dynamic  -H64m -O0 -fasm    -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build   -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist-install/build/System/Posix/Internals.dyn_o 
<braries/base/dist-install/build/System/Posix/Internals.dyn_o 
ghc23405_0.c: Assembler messages:

ghc23405_0.c:127:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:153:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:181:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:207:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:235:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:261:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:285:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:311:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:339:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:367:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:393:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:421:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:449:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:477:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:505:0:
     Error: junk `.get_pc_thunk.bx' after expression

ghc23405_0.c:525:0:
     Error: junk at end of line, first unrecognized character is `1'

ghc23405_0.c:526:0:
     Error: junk at end of line, first unrecognized character is `1'

ghc23405_0.c:527:0:  Error: Missing symbol name in directive

ghc23405_0.c:527:0:
     Error: junk at end of line, first unrecognized character is `1'

ghc23405_0.c:528:0:  Error: Missing symbol name in directive

ghc23405_0.c:528:0:
     Error: junk at end of line, first unrecognized character is `.'

ghc23405_0.c:529:0:
     Error: junk at end of line, first unrecognized character is `1'

ghc23405_0.c:528:0:
     Error: junk at end of line, first unrecognized character is `.'

ghc23405_0.c:529:0:
     Error: junk at end of line, first unrecognized character is `1'
}}}"	Iceland_jack
5	3073	Avoid reconstructing dictionaries in recursive instance methods	Compiler	6.10.1	lowest	normal	7.6.2		new	2009-03-05T02:46:44-0800	2012-09-12T04:14:08-0700	"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
5	2731	Avoid unnecessary evaluation when unpacking constructors	Compiler	6.8.3	lowest	normal	7.6.2		new	2008-10-30T02:06:29-0700	2012-09-12T04:14:04-0700	"
Consider 
{{{
data T a = MkT !a

foo :: T (a,b) -> a
foo (MkT (x,y)) = x
}}}
GHC will extract the first component of the `MkT`, ''evaluate it'', and then extract the first component of the pair.  The evaluation step isn't needed, since the component is known to be already-evaluated.  `UNPACK` directives won't work here, because the component is polymorphic.

In the email thread, Tyson posted an example where this extra eval made a significant difference to his inner loop:
[http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015796.html]

Simon


"	simonpj
3	4005	Bad behaviour in the generational GC with paraffins -O2	Runtime System	6.12.1 RC1	normal		_|_		new	2010-04-23T06:15:42-0700	2012-01-06T07:25:59-0800	"paraffinsL.hs seems to give a slowdown of almost a factor of
2 when using -O2 during compilation (also with -O)..
I noticed that when tinkering with parallel variants, but
happens even just for seq compilation.
pL.hs is a cleaned-up, stand-alone version that triggers this
behaviour.

I checked this with ghc-6.13 (HEAD as of 1.4.2010) and with
ghc-6.12.2rc2 (as of 20.4.2010), with the commands below.

This is on a i386-unknown-linux machine
"	hwloidl
3	5924	Bad Cmm generated for updating one element in Array#	Compiler	7.4.1	normal		7.6.2		new	2012-03-09T15:56:39-0800	2012-09-12T04:12:12-0700	"I've attached a small standalone program that implements the following function:

{{{
-- | /O(n)/ Update the element at the given position in this array.
update16 :: Array e -> Int -> e -> Array e
}}}

which update one element (by copying the whole array) of an array of size 16. The attachment includes the optimized Cmm for a call to this function, together with a bunch of comments (inline with the Cmm) by me, pointing out inefficiencies in the generated Cmm.

My overall goal is to make this particular function fast. This might involve fixes to the code generator and/or adding primitives whether that makes sense. In any case this code might be a good source of ideas for improvements to the code generator.

To follow my annotations, start at `Update.test_info` in `Update.cmm`."	tibbe
4	3698	Bad code generated for zip/filter/filter loop	Compiler	6.13	low		7.6.2		new	2009-11-26T20:36:35-0800	2012-09-12T04:12:19-0700	"Here is the program:
{{{
zip_filter :: (Num a, Ord a) => a -> [a] -> [a] -> [a]
zip_filter x as bs = zipWith (+) (filter (<x) as) (filter (<x) bs)
}}}
GHC generates this:
{{{
poly_z_smp = \ (@ a_aiz) _ -> GHC.Types.[] @ a_aiz

T.zip_filter =
  \ (@ a_aiz) $dNum_ajm $dOrd_ajn eta_B3 eta_B2 eta_B1 ->
    letrec {
      go_smr :: [a_aiz] -> [a_aiz] -> [a_aiz]
      go_smr =
        \ (ds_ak5 :: [a_aiz]) ->
          case ds_ak5 of _ {
            [] -> poly_z_smp @ a_aiz;
            : y_aka ys_akb ->
              let {
                r_smt :: [a_aiz] -> [a_aiz]
                r_smt = go_smr ys_akb } in
              case GHC.Classes.< @ a_aiz $dOrd_ajn y_aka eta_B3 of _ {
                GHC.Bool.False -> r_smt;
                GHC.Bool.True ->
                  \ (ds_alR :: [a_aiz]) ->
                    case ds_alR of _ {
                      [] -> GHC.Types.[] @ a_aiz;
                      : y_alW ys_alX ->
                        GHC.Types.:
                          @ a_aiz (GHC.Num.+ @ a_aiz $dNum_ajm y_aka y_alW) (r_smt ys_alX)
                    }
              }
          }; } in
    go_smr
      eta_B2
      (GHC.List.filter
         @ a_aiz
         (\ (ds_djz :: a_aiz) ->
            GHC.Classes.< @ a_aiz $dOrd_ajn ds_djz eta_B3)
         eta_B1)
}}}

Eta-expanding `go_smr` would result in much better code."	rl
3	7901	Bad error message when using UnicodeSyntax ∀ without ExplicitForall	Compiler	7.6.2	normal				new	2013-05-09T14:47:52-0700	2013-05-09T14:47:52-0700	"This code
{{{
{-# LANGUAGE UnicodeSyntax #-}

id' :: ∀ a. a → a
id' a = a
}}}
produces following error
{{{
/tmp/id.hs:4:8: parse error on input `∀'
}}}
However, equivalent code without unicode syntax gives a much better error message:
{{{
id' :: forall a. a → a
id' a = a
}}}
{{{
/tmp/id.hs:4:16:
    Illegal symbol '.' in type
    Perhaps you intended -XRankNTypes or similar flag
    to enable explicit-forall syntax: forall <tvs>. <type>
}}}"	exbb2
5	3711	Bad error reporting when calling a function in a module which depends on a DLL on Windows	Runtime System	6.10.4	lowest		7.6.2		new	2009-12-02T02:30:23-0800	2012-09-12T04:14:13-0700	"When you try to call a function which depends on a DLL, after the module has been loaded in ghci, you get: 

Loading package Codec-Image-DevIL-0.1 ... can't load .so/.DLL for: ILU (addDLL: could not load DLL)

This error message is almost completely useless. It should call GetLastError() and present this information to the user. 

I don't know whether the error message for GetLastError is actually useful, but otherwise it should derive a real problem with the library, e.g. ""we searched for it in the PATH, but we couldn't find it, or the library format is wrong(use Dependency walker to verify that this is a valid Windows DLL), etc."".

In general every error message should state what it tried and why it failed. In the same sense that type-error messages do (assuming no bugs in the type-inferencer ;) ).   "	fasta
3	7831	Bad fragmentation when allocating many large objects	Runtime System	7.7	normal		7.8.1	ezyang	new	2013-04-13T02:17:23-0700	2013-05-13T01:35:12-0700	"Consider our good old friend, the space-leaky list program:

{{{
import Control.Exception
import System.Environment

f n = let xs = [1..n] in sum xs * product xs

main = do
    [n] <- getArgs
    evaluate (f (read n :: Integer))
}}}

It is not surprising that this program is quite the memory guzzler; what is surprising is how much GHC *wastes* when evaluating this program:

{{{
Fragmentation, wanted 95 blocks,  105 MB free
}}}

(For reference, a block is 4k, so 95 blocks is a measly 380k!)  The magnitude of the problem can be seen in this graphic:

[[Image(http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png)]]

(The x-axis takes advantage of the fact that the number of requested blocks increases ~linearly over time, since we keep multiplying the integer which adds a constant number of extra bytes to the representation; unused free memory corresponds to blocks of free memory in GHC's free list, which it is holding onto from the OS but not using to store user data.)

When the requested allocations are *just* large enough (just slightly over half a megablock, or 128 blocks), we start allocating a megablock per allocation and waste half of the megablock, since none of the leftovers are ever large enough to store any of the later allocations.

Can we do anything about this? One possibility is to occasionally check how much space we're losing to fragmentation, and everyone once in a while pay the cost of copying tenured large objects and pack them together in a megablock group (obviously one wants to avoid doing this too often, since copying large objects is expensive!) I'm open to better suggestions though! (Apologies if this is a duplicate; I didn't see any open tickets with the word ""fragmentation"" in them)."	ezyang
3	1062	Bad output from Text.PrettyPrint.HughesPJ	libraries/pretty	6.6	normal	normal	_|_		new	2006-12-19T15:13:53-0800	2011-11-19T15:02:39-0800	"This program:

{{{
import Text.PrettyPrint.HughesPJ

ncat x y = nest 4 $ cat [ x, y ]

d1 = foldl1 ncat $ take 50 $ repeat $ char 'a'
d2 = parens $  sep [ d1, text ""+"" , d1 ]

main = print d2
}}}

generates the output below. I haven't worked out what is expected, but this certainly doesn't look right to me (in particular, the space before the `a` on the third line of the output).

{{{
% runghc pp1.hs | tr ' ' _
(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+___________________________________________________________________________________________________________________________________________________________________________________________________a
_a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a)
}}}

The pp1 test goes on to say:

{{{
This code used to print an infinite string, by calling 'spaces'
with a negative argument.  There's a patch in the library now,
which makes 'spaces' do somehthing sensible when called with a negative
argument, but it really should not happen at all.

This output is not what is expected, becuase the
test ""works"" now, by virtue of a hack in HughesPJ.spaces.
I'm leaving this strange output here to remind us to look
at the root cause of the problem.  Sometime.
}}}"	igloo
3	2697	bad testsuite results with ghc-6.10.0.20081007	Compiler	6.9	normal	normal	_|_		new	2008-10-15T00:59:14-0700	2009-02-17T08:38:08-0800	"As I've mailed

{{{
My testsuite results can be found under:

http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.10.0.20081007-tests.log.bz2
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/pc-solaris/ghcs/ghc-6.10.0.20081007-tests.log.bz2

371 unexpected failures resp. 195 unexpected failures
}}}

These are far too many failures, I think.
I've only called ""make"" in ghc-regress. The results do not only depend on the build-tree but at least on the user's package.conf file.

Would someone care to look through the logs?"	maeder
3	1087	bang patterns with infix ops	Compiler (Parser)	6.6	normal	normal	_|_		new	2007-01-05T17:41:07-0800	2013-01-20T17:51:43-0800	"{{{
    $ ghci -fbang-patterns

-- Ok

    Prelude> let at a !b = False in at 1 2
    False

    Prelude> let (.!.) a !b = False in 1 .!. 2
    False

-- ~ patterns are ok

    Prelude> let a `at` ~b = False in at 1 2
    False

    Prelude> let a .!. ~b = False in 1 .!. 2
    False

    Prelude> let ~a .!. b = False in 1 .!. 2
    False

-- Parse error if we combine bang patterns with infix decls:

    Prelude> let a .!. !b = False in 1 .!. 2
    <interactive>:1:10: parse error on input `!'

    Prelude> let a `at` !b = False in at 1 2
    <interactive>:1:11: parse error on input `!'

    Prelude> let !a .!. b = False in 1 .!. 2
    <interactive>:1:5: Parse error in pattern

}}}

So looks like ops and infix declarations are missing a case for bang patterns.

-- Don"	dons
2	7914	base library's MD5 symbols clash with others	libraries/base	7.6.3	high		7.8.1	simonmar	new	2013-05-15T20:22:33-0700	2013-05-17T23:31:28-0700	"We have a large C++ application into which we are linking the GHC runtime. Being large, this app has many components, among which is one that defines a bunch of MD5 functions that have overlapping names with those defined in base, but different ABIs.

Depending on the order in which the linker runs across the object files, we end up with a crash during application startup as a result of one component picking up the other component's MD5 symbols.

The offending source file is libraries/base/cbits/md5.c.

A simple fix for this would be to prefix the function names with e.g. _ghc_ or something similar, so that the names would not clash.

There are perhaps other functions in base (probably many others) that could benefit from a similar treatment, but we're not crashing on those yet."	bos
4	4960	Better inlining test in CoreUnfold	Compiler	7.0.1	low		7.6.2		new	2011-02-15T05:15:36-0800	2012-09-12T04:13:25-0700	"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
3	3354	binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger)	Build System	6.10.1	normal	minor	_|_		new	2009-07-05T12:10:01-0700	2009-09-17T17:28:18-0700	"It seems that binaries (at least those linked with the threaded runtime) built with GHC on Mac OS X 10.5 do not work on Mac OS X 10.4. The error message in my case is

{{{
dyld: lazy symbol binding failed: Symbol not found: _pthread_cond_init$UNIX2003
  Referenced from: <the executable>
  Expected in: /usr/lib/libSystem.B.dylib
}}}

I believe that the primary reasons for this is that the runtime system is linked against the 10.5 system libraries, which are not ABI compatible with the 10.4 system libraries.

Apple provides both 10.4 and 10.5 SDKs with 10.5, along with compiler and linker options for those who want to build backward-compatible binaries. I tried to pass these options to the linker, which results in the error message

{{{
Undefined symbols:
  ""_strerror$UNIX2003"", referenced from:
      _newThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o)
      _setThreadLocalVar in libHSrts_thr.a(OSThreads.thr_o)
      _freeThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o)
      _my_mmap in libHSrts_thr.a(OSMem.thr_o)
      _rtsSysErrorMsgFn in libHSrts_thr.a(RtsMessages.thr_o)
  ""_fputs$UNIX2003"", referenced from:
      _heapCensus in libHSrts_thr.a(ProfHeap.thr_o)
  ""_read$UNIX2003"", referenced from:
      ___hscore_PrelHandle_read in libHSbase-4.0.0.0.a(PrelIOUtils.o)
  ""_fcntl$UNIX2003"", referenced from:
      _resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
      _resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
      _setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
      _setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o)
  ""_pthread_cond_init$UNIX2003"", referenced from:
      _initCondition in libHSrts_thr.a(OSThreads.thr_o)
  ""_open$UNIX2003"", referenced from:
      ___hscore_open in libHSbase-4.0.0.0.a(PrelIOUtils.o)
  ""_kill$UNIX2003"", referenced from:
      _shutdownHaskellAndSignal in libHSrts_thr.a(RtsStartup.thr_o)
  ""_select$UNIX2003"", referenced from:
      _fdReady in libHSbase-4.0.0.0.a(inputReady.o)
  ""_write$UNIX2003"", referenced from:
      _ioManagerWakeup in libHSrts_thr.a(Signals.thr_o)
      _ioManagerDie in libHSrts_thr.a(Signals.thr_o)
      _generic_handler in libHSrts_thr.a(Signals.thr_o)
      ___hscore_PrelHandle_write in libHSbase-4.0.0.0.a(PrelIOUtils.o)
ld: symbol(s) not found
}}}

It would be nice if GHC on OS X shipped with two version of the runtime (and the base library?), and had compiler flags to build compatible binaries. This could be also a problem in the future, with the next OS X versions.

See also this thread: http://lists.apple.com/archives/Darwin-dev/2007/Nov/msg00109.html
"	bkomuves
2	7273	Binary size increase in nofib/grep between 7.6.1 and HEAD	Compiler	7.6.1	high		7.8.1		new	2012-09-28T02:16:05-0700	2012-09-28T02:16:05-0700	"While browsing the nofib results comparing 7.6.1 and HEAD today, I noticed that binary sizes for `grep` are significantly larger in HEAD:

{{{
grep
           Main                34706          +31.3%
        Parsers                 5791           +3.2%
    StringMatch                28227          +36.9%
}}}

The increase seems to be happening in the simplifier, going by the code-size stats generated by `-v`.  This probably warrants investigation before 7.8.1.

Binary sizes are slightly larger across the board (1-2%), which is at least partly due to the new code generator, however performance is slightly better (2-3%), if these numbers are to be believed.
"	simonmar
5	3571	Bizzarely bloated binaries	Compiler	6.10.4	lowest	normal	7.6.2		new	2009-10-09T07:40:53-0700	2012-09-12T04:14:12-0700	"Compiling a trivial test program:

{{{
module Main where

main = print ""Hello World""
}}}

Using GHC 6.10.4 produces a VERY suspicious PE file. (NB: this applies to DLL as well as EXE output).

The two problems that I have observed are:

 1) The PE always contains a .stab and .stabstr section totalling 0x2A00 of debug data. Looking at the contents of stabstr, this appears to originate from a libffi object file. Perhaps we could disable stabs when building libffi to remove this bloat from output binaries.

 2) The PE contains *A LOT* of trailing junk. My hello world program is 691K, and the PE contains 0x4FAFC = 318K of data which doesn't live in any section! Trimming this data appears to have no effect on the correctness of the program! The amount of junk grows proportionally to the amount of real code and data - I have observed e.g. 18Mb DLLs of which 9Mb are trailing junk.

To repeat: we could potentially *halve* GHC binary sizes by fixing this linker behaviour.

I'm not sure where exactly the fault lies - whether it is a GHC problem or some bug in Ld.

To test trimming your executables and DLLs, you can use this utility I whipped up. Usage is ""trimpe <file1> ... <fileN>"". It will trim useless data from the end of the files in place:

{{{
{-# LANGUAGE ScopedTypeVariables #-}
module Main (main) where

import Control.Monad

import Data.Binary
import Data.Binary.Get

import qualified Data.ByteString.Lazy as ByteString
import Data.Word

import System.Environment

import Debug.Trace


assertM :: Monad m => Bool -> m ()
assertM True  = return ()
assertM False = fail ""assertM""

newtype PEImageLength = PEImageLength Word32

-- http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
instance Binary PEImageLength where
    get = do
        -- Skip the MS DOS stub
        skip 0x3c
        pe_sig_offset <- getWord32le
        -- Skip to the PE signature
        skip (fromIntegral pe_sig_offset - (0x4 + 0x3c))
        -- Read the PE signature itself
        -- NB: this will always be the string ""PE\0\0""
        _sig <- getWord32le
        assertM (_sig == 0x00004550)
        -- Read COFF file header
        _machine <- getWord16le
        _no_of_sects <- getWord16le
        _time_date_stamp <- getWord32le
        _ptr_to_sym_tab <- getWord32le
        _no_of_syms <- getWord32le
        _size_of_opt_header <- getWord16le
        assertM (_size_of_opt_header /= 0)
        _characteristics <- getWord16le
        -- Read the ""optional"" header
        magic <- getWord16le
        let pe32plus = magic == 0x20B
        _maj_link_ver :: Word8 <- get
        _min_link_ver :: Word8 <- get
        _size_of_code <- getWord32le
        _size_of_init_data <- getWord32le
        _size_of_uninit_data <- getWord32le
        _addr_of_entry_point <- getWord32le
        _base_of_code <- getWord32le
        when (not pe32plus) $ do _base_of_data <- getWord32le; return ()
        -- Read the optional header Windows fields
        if pe32plus
         then do _image_base <- getWord64le; return ()
         else do _image_base <- getWord32le; return ()
        _sect_alignment <- getWord32le
        _file_alignment <- getWord32le
        _maj_os_version <- getWord16le
        _min_os_version <- getWord16le
        _maj_image_version <- getWord16le
        _min_image_version <- getWord16le
        _maj_subsys_version <- getWord16le
        _min_subsys_version <- getWord16le
        _win32_version <- getWord32le
        size_of_image <- getWord32le
        -- There is more stuff later, but I simply don't care about it
        -- NB: we could trim a little more agressively if we interpreted
        -- the sections as well...
        return $ PEImageLength size_of_image
        
    put = error ""Binary PEImageLength: put""


main :: IO ()
main = do
    files <- getArgs
    forM_ files trimPEToImageSize

trimPEToImageSize :: FilePath -> IO ()
trimPEToImageSize file = do
    putStrLn $ file
    pe_contents <- ByteString.readFile file
    let PEImageLength image_size = decode pe_contents
    
    -- Force the file to close so that the write may succeed
    (ByteString.last pe_contents) `seq` return ()
    
    when (ByteString.length pe_contents > fromIntegral image_size) $ do
        putStrLn $ ""* Trimming to image size ("" ++ show image_size ++ "")""
        let pe_contents' = ByteString.take (fromIntegral image_size) pe_contents
        ByteString.writeFile file pe_contents'
}}}"	guest
3	2786	Blackhole loops are not detected and reported in GHCi	GHCi	6.8.3	normal	normal	_|_		new	2008-11-17T08:46:44-0800	2012-10-22T04:47:49-0700	"While looking into #2783 I noticed this.  It has never worked, and I was vaguely aware of it, but it seems we don't have a ticket.

{{{
let x = x in x
}}}

in GHCi should report `<<loop>>`.  One issue is that the `interruptTargetThread` global var points to the `ThreadId` running the expression, which will keep it alive and prevent it from being detected as deadlocked.  But that's not all: I think the expression itself is being retained by the main thread (perhaps because it is bound to `it`), which will cause the child thread to also stay alive.
"	simonmar
3	7672	boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module	Compiler (Type checker)	7.4.2	normal		7.8.1		new	2013-02-07T11:01:00-0800	2013-04-13T04:35:40-0700	"In a recursive module (i.e. a module that transitively imports itself), the unique ""Name"" of an entity E declared in this module's boot file should be precisely the same as that of the corresponding E defined in the module. Right now GHC appears to treat them as separate entities. (In the module systems literature, this problem has been identified as the ""double vision problem"" [1, Ch 5] and in general has caused problems with implementations of recursive modules. Derek Dreyer and his coauthors have proposed a number of solutions [2], and so have Im et al. more recently in the context of OCaml [3].)

With that being said, the ''immediate'' problem here seems to be that GHC does not actually allow, in the implementing module, the import of its boot file's entities.

There are a couple related errors I can identify with, huzzah!, very small example programs. The crux of the example is that the module A defines a data type T which is essentially the typical Nat data type -- except that the recursive type reference in the successor constructor refers to the ""forward declaration's"" view of the type (in the boot file) rather than the local view of that data type T.

This first example shows that the boot file import is not actually making available the entities it declares:
{{{
module A where
  data T
}}}
{{{
module A where
  import {-# SOURCE #-} qualified A as Decl(T)
  data T = Z | S Decl.T
}}}
The Decl.T reference should have the exact same identity as the locally defined T reference; after tying the module knot, this data type should be the same as if we had defined it with a T instead of Decl.T. However, the entity name T does not even appear to be gotten from the import of the boot file:
{{{
A.hs:3:18: Not in scope: type constructor or class `Decl.T'
}}}
In an earlier version of GHC I tested, 6.12.1, the error message lies on the import statement:
{{{
A.hs:2:44: Module `A' (hi-boot interface) does not export `T'
}}}

In the next example, with the same boot file, we see that the mechanism that checks whether the implementation matches the boot file fails to see the two ""views"" of T as the same. (Note that I changed the definition of T here to make the previous error go away.)
{{{
module A(Decl.T(..)) where
  import {-# SOURCE #-} qualified A as Decl(T)
  data T = Z | S T
}}}
Since Decl.T should point to the same entity as T, the export statement should have the same effect as if it were instead ""(T(..))"". However, GHC again cannot make sense of the reference ""Decl.T"" and then complains that the boot file's T is not provided in the implementation:
{{{
A.hs:1:10: Not in scope: type constructor or class `Decl.T'

<no location info>:
    T is exported by the hs-boot file, but not exported by the module
}}}
(Making the export list empty shows this second error message only.)

Altering this second example by omitting the alias on the import, and by changing the T reference in the type's definition to A.T, results in a well-typed module:
{{{
module A(A.T(..)) where
  import {-# SOURCE #-} qualified A(T)
  data T = Z | S A.T
}}}

A final example shows that, in a module that is ''not'' the implementing module, entities defined in the boot file are imported as one would expect! In the following example, we insert a module B, in between A's boot file and A's implementation, which merely passes along the boot file's view of T.
{{{
module A where
  data T
}}}
{{{
module B(Decl.T(..)) where
  import {-# SOURCE #-} qualified A as Decl(T)
  data U = U Decl.T
}}}
{{{
module A(T(..)) where
  import qualified B(T)
  data T = Z | S B.T
}}}
The error message here, again, lies in the reference B.T in A's implementation:
{{{
A.hs:3:18:
    Not in scope: type constructor or class `B.T'
    Perhaps you meant `A.T' (line 3)
}}}
Notice, however, that the reference to Decl.T in the B module is perfectly well-formed.

I suspect that the general problem lies with double vision, and that the more immediate problem--whereby imports of boot file entities from their implementing modules fail--is merely the manifestation of that.

In the above, wherever I have suggested an intended semantics, I refer primarily to the state of the art in recursive modules systems. A perhaps more pressing justification, however, is that both the Haskell language report and Diatchki et al.'s specification of the module system [4] (seem to) corroborate that intended semantics.

Your friend in the recursive module swamp,[[BR]]
Scott Kilpatrick

----

References

[1] Derek Dreyer. ''[http://www.mpi-sws.org/~dreyer/thesis/main.pdf Understanding and Evolving the ML Module System]'', PhD thesis, 2005.[[BR]]
[2] Derek Dreyer. ''[http://www.mpi-sws.org/~dreyer/courses/modules/dreyer07.pdf A Type System for Recursive Modules]'', ICFP 2007.[[BR]]
[3] Hyeonseung Im, Keiko Nakata, Jacques Garrigue, and Sungwoo Park. ''[http://dl.acm.org/citation.cfm?doid=2048066.2048141 A syntactic type system for recursive modules]'', OOPSLA 2011.[[BR]]
[4] Iavor S. Diatchki, Mark P. Jones, and Thomas Hallgren. ''[http://web.cecs.pdx.edu/~mpj/pubs/hsmods.html A formal specification of the Haskell 98 module system]'', Haskell 2002."	skilpat
5	3996	bug in GHC when compiling HOC (SVN revision 413)	Compiler	6.10.4	lowest		7.6.2		new	2010-04-19T13:22:13-0700	2012-09-12T04:14:15-0700	"I'm trying to compile the Haskell Cocoa binding HOC on Mac OS X 10.6 (Snow Leopard) with GHC 6.10.4. The computer is a MacBook with Intel CPU.

Steps to reproduce:
{{{
1. svn checkout http://hoc.googlecode.com/svn/trunk/ hoc-read-only
2. cd hoc-read-only
3. runhaskell Setup.hs --user configure
4. runhaskell Setup.hs build
}}}
A ""GHC panic"" error occurs. The output is as follows:

{{{
Setup.hs:1:0:
    Warning: In the use of `defaultUserHooks'
             (imported from Distribution.Simple):
             Deprecated: ""Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2
             compatibility in which case you must stick with defaultUserHooks""
Compiling HOC_cbits...
Preprocessing library HOC-1.0...
Preprocessing executables for HOC-1.0...
Building HOC-1.0...
[ 1 of 31] Compiling HOC.THDebug      ( HOC/HOC/THDebug.hs, dist/build/HOC/THDebug.o )
[ 2 of 31] Compiling HOC.Unicode      ( HOC/HOC/Unicode.hs, dist/build/HOC/Unicode.o )
[ 3 of 31] Compiling HOC.TH           ( HOC/HOC/TH.hs, dist/build/HOC/TH.o )
[ 4 of 31] Compiling HOC.FFICallInterface ( HOC/HOC/FFICallInterface.hs, dist/build/HOC/FFICallInterface.o )
[ 5 of 31] Compiling HOC.Dyld         ( HOC/HOC/Dyld.hs, dist/build/HOC/Dyld.o )
[ 6 of 31] Compiling HOC.Base         ( HOC/HOC/Base.hs, dist/build/HOC/Base.o )
[ 7 of 31] Compiling HOC.Arguments    ( HOC/HOC/Arguments.hs, dist/build/HOC/Arguments.o )
[ 8 of 31] Compiling HOC.ID           ( HOC/HOC/ID.hs, dist/build/HOC/ID.o )
[ 9 of 31] Compiling HOC.CannedCIFs   ( HOC/HOC/CannedCIFs.hs, dist/build/HOC/CannedCIFs.o )
[10 of 31] Compiling HOC.NewClass     ( HOC/HOC/NewClass.hs, dist/build/HOC/NewClass.o )
[11 of 31] Compiling HOC.StdArgumentTypes ( HOC/HOC/StdArgumentTypes.hs, dist/build/HOC/StdArgumentTypes.o )
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package containers-0.2.0.1 ... linking ... done.
Loading package packedstring-0.1.0.1 ... linking ... done.
Loading package pretty-1.0.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package bytestring-0.9.1.4 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package parsec-3.1.0 ... linking ... done.
Loading package base-3.0.3.1 ... linking ... done.
Loading package fgl-5.4.2.2 ... linking ... done.
Loading package filepath-1.1.0.2 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.2 ... linking ... done.
Loading package unix-2.3.2.0 ... linking ... done.
Loading package directory-1.0.0.3 ... linking ... done.
Loading package HUnit-1.2.0.3 ... linking ... done.
Loading object (static) dist/build/HOC_cbits.o ... ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.4 for x86_64-apple-darwin):
        loadObj: failed

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
"	andrewe
3	4347	Bug in unification of polymorphic and not-yet-polymorphic type	Compiler (Type checker)	7.1	normal		7.6.2		new	2010-09-27T14:36:08-0700	2012-09-12T04:12:00-0700	"The new type checker in GHC 7 seems to reject some cases of impredicative instantiation that prior versions allowed. I was initially alerted to this by Simon Marlow, who sent a patch for vector-algorithms removing a use of {{{($)}}} where it would have to be instantiated impredicatively.

Initially, I thought this was due to a planned removal of impredicativity, but this cannot be the case, because:

{{{
const :: a -> (forall b. b) -> a
}}}

is accepted by the type checker. However, the simple:

{{{
id :: (forall a. a) -> (forall b. b)
}}}

is not, giving an error message:

{{{
    Couldn't match type `b' with `forall a. a'
      `b' is a rigid type variable bound by
          an expression type signature at <interactive>:1:32
    In the expression: id :: (forall a. a) -> (forall b. b)
}}}

This would seem to indicate that the type is being rewritten to:

{{{
forall b. (forall a. a) -> b
}}}

and then the {{{forall a. a}}} matched with the bare {{{b}}}. It is, of course, fine to rewrite the type this way, since the two are isomorphic, but it is unfortunate that it causes the checker to reject what would otherwise be a valid instantiation."	dolio
3	7503	Bug with PolyKinds, type synonyms & GADTs	Compiler (Type checker)	7.6.1	normal		7.8.1	simonpj	new	2012-12-16T15:37:00-0800	2013-04-12T14:24:20-0700	"GHC incorrectly rejects this program:
{{{
{-# LANGUAGE ExistentialQuantification, DataKinds, PolyKinds, KindSignatures, GADTs #-}
module TestConstraintKinds where
    import GHC.Exts hiding (Any)

    data WrappedType = forall a. WrapType a

    data A :: WrappedType -> * where
        MkA :: forall (a :: *). AW a -> A (WrapType a)

    type AW  (a :: k) = A (WrapType a)
    type AW' (a :: k) = A (WrapType a)

    class C (a :: k) where
        aw :: AW a -- workaround: AW'

    instance C [] where
        aw = aw
}}}

GHC accepts the program when AW is replaced with AW' on that line."	Ashley Yakeley
2	7651	Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)	Build System	7.7	high		7.8.1		new	2013-02-01T18:36:24-0800	2013-04-12T16:58:37-0700	"Building GHC with parallel IO manager on Mac freezes when
compiling the dph libraries in the phase 2.

We '''suspect this is due to a bug in the OS X implementation of kqueue''', for the reasons given below.  In the meantime, we have added an extra IO manager wakeup that appears to work around the problem; see `GHC/Event/Manager.hs`.

Details:

 * This happens only if we specify ""-j"" to ""make"". Note that ""make"" closes stdin of sub-processes if ""-j"" is specified.

 * Even if we specify ""-j"" to ""make"", the problem disappears with stdout/stderr redirection. That is, ""make -jN >& LOG &"" works.

 * The ""-d"" option of ""make"" does not make any effects.

 * Programs compiled with built GHC (with our patches) work well. For test, I compiled a daemon HTTP server which closes stdin/stdout/stderr. It worked well.

An IO manager is polling a kqueue fd. Another Haskell thread on
another native thread registers an event through the same kqueue
fd.  In many cases, this works on Mac. In a certain situation,
MacOS does not deliver an event to the IO manager. If the IO
manager gets up and polls the kqueue fd, the event is delivered.

This bug only appears when building GHC on Mac. I cannot find a
simple way to reproduce it. Even if we find a way to reproduce
it, I guess that we will probably reach a conclusion that this is
a bug of kqueue of Mac.

I have some evidences that kqueue of Mac is buggy:

 * http://comments.gmane.org/gmane.comp.lib.ev/1871
 * http://lists.apple.com/archives/darwin-dev/2011/Jun/msg00016.html
"	kazu-yamamoto
2	7889	Build Error (master branch)	GHCi	7.6.3	high		7.8.1		new	2013-05-04T22:11:06-0700	2013-05-10T17:06:04-0700	"I got this error while building the master branch.
System is Windows 8 64-bit. Code grabbed from github.
{{{
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... ghc-stage2.exe: panic! (the 'impossible' happened)
  (GHC version 7.7.20130504 for i386-unknown-mingw32):
        loadArchive ""z:\\Lang\\Haskell\\ghc_files\\git\\libraries\\integer-gmp\\dist-install\\build\\libHSinteger-gmp-0.5.1.0.a"": failed

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

ghc-stage2.exe: Unknown PEi386 section name `.drectve' (while processing: z:\Lang\Haskell\ghc_files\git\libraries\integer-gmp\dist-install\build\libHSinteger-gmp-0.5.1.0.a)
make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o] Error 1
make: *** [all] Error 2
}}}
"	cg31
3	7779	building GHC overwrites the installed package database if GHC_PACKAGE_PATH is set	Build System	7.4.2	normal		7.8.1	igloo	new	2013-03-19T21:31:28-0700	2013-03-24T15:12:16-0700	"When building GHC, if `GHC_PACKAGE_PATH` is set to a single path, then the build process will register packages in that path instead of in the build tree.  Since `GHC_PACKAGE_PATH` points to the host compiler's package database, the build system overwrites the host compiler's package database, rendering the host compiler unusable.

To reproduce:

1. Get a binary distribution of GHC 7.4.1 and a source distribution of GHC 7.4.2

2. Configure the binary distribution to install in a temporary directory:  `./configure --prefix=$HOME/workspace1`

3. Install the binary distribution

4. Set up the environment to use only the installed compiler: `export PATH=$HOME/workspace1/bin:$PATH; export GHC_PACKAGE_PATH=$HOME/workspace1/lib/ghc-7.4.1/package.conf.d`

5. Configure the source distribution to install in a different directory: `./configure --prefix=$HOME/workspace2`

6. Build the source distribution: `make`

Building will eventually run commands that modify the package database in `GHC_PACKAGE_PATH`.  One of these commands is  `""inplace/bin/ghc-pkg"" update --force rts/package.conf.inplace`.  I confirmed that the database is being modified by making `ghc-pkg` print the name of the file it's about to update."	heatsink
3	7592	Building the latest master branch on FreeBSD 9.1 fails	Build System	7.7	normal		7.8.1	igloo	new	2013-01-15T21:10:10-0800	2013-04-14T11:24:01-0700	"The following sequence fails on FreeBSD 9.1:

{{{
% perl boot
% ./configure --prefix=/ghc-head --with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47 --with-gcc-4.2=/usr/local/bin/gcc47
% gmake -j10 -d MAKE=gmake
...
Putting child 0x801e5fd80 (ghc/stage1/package-data.mk) PID 36063 on the chain.
 Recipe of `ghc/stage1/package-data.mk' is being run.
 Pruning file `compiler/stage1/package-data.mk'.
Live child 0x801e5fd80 (ghc/stage1/package-data.mk) PID 36063 
Configuring ghc-bin-7.7.20130111...
Warning: 'data-dir: ..' is a relative path outside of the source tree. This
will not work when generating a tarball with 'sdist'.
Reaping winning child 0x801e5fd80 PID 36063 
Removing child 0x801e5fd80 PID 36063 from chain.
 Considering target file `ghc/stage1/package-data.mk'.
 File `ghc/stage1/package-data.mk' was considered already.
Re-executing[2]: gmake -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
GNU Make 3.82
Built for amd64-portbld-freebsd9.1
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile `ghc.mk'...
ghc.mk:84: *** Make has restarted itself 2 times; is there a makefile bug?.  Sto
p.
Reaping losing child 0x80156e290 PID 34605 
gmake: *** [all] Error 2
Removing child 0x80156e290 PID 34605 from chain.
}}}

If I type ""gmake -j10 MAKE=gmake"" gain, the building completes.

I believe this is relating to http://www.haskell.org/pipermail/glasgow-haskell-users/2012-March/022150.html

Actually if I remove ""error"" on line 84, this does not happen and the building completes without any problems.

GHC for bootstrapping: 7.4.1, GCC 4.7.3, gmake: 3.82
"	kazu-yamamoto
3	5861	bytestring: incorrect documentation for hGetContents	libraries (other)		normal		7.6.2	duncan	new	2012-02-09T15:50:58-0800	2012-09-12T04:12:11-0700	"(I guess this is the `ByteString` bug tracker?  This copies an email I sent directly to Don Stewart and Duncan Coutts.)

The current documentation [1] for `Data.ByteString.hGetContents` says:

""As with `hGet`, the string representation in the file is assumed to be ISO-8859-1.""

This confuses me -- why would `ByteString` care what the ""string representation"" of a file is, or that it even has one?

Perhaps it's for the benefit of this function's appearance in `ByteString.Char8`.  But the caveats of that module are widely documented throughout, and it's a hack that most people shouldn't use. I think the docs for `hGetContents` should reflect the ""main"" module and its intended use on possibly opaque binary data.

Don Stewart suggested that this is ""a property of the underlying handle"", but I have confirmed that `ByteString` is insensitive to the handle's designated encoding.

{{{
$ cat test-bytestring-handle-encoding.hs
import System.IO

import qualified Data.ByteString as B

test :: TextEncoding -> IO ()
test enc = do
    hdl <- openFile ""snowman"" ReadMode
    hSetEncoding hdl enc
    B.hGetContents hdl >>= (print . B.unpack)
    hClose hdl

main :: IO ()
main = do
    test utf8
    test utf32
    test latin1

$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.0.4
$ ghc-pkg list bytestring
/var/lib/ghc/package.conf.d
  bytestring-0.9.1.10
$ echo -ne '\xe2\x98\x83' > snowman
$ hexdump -C snowman
00000000  e2 98 83                                          |...|
00000003
$ runhaskell test-bytestring-handle-encoding.hs
[226,152,131]
[226,152,131]
[226,152,131]
}}}

[1] http://hackage.haskell.org/packages/archive/bytestring/0.9.2.0/doc/html/Data-ByteString.html#v:hGetContents"	kmcallister
3	7246	Callstack depends on way (prof, profasm, profthreaded	Profiling	7.6.1	normal		7.8.1		new	2012-09-17T03:23:21-0700	2012-10-20T16:04:03-0700	"Consider the attached test case. The expected output is the that of the ```prof``` way, while for ```profasm``` and ```profthreaded```, I get this result:

{{{
=====> callstack003(profthreaded) 19 of 21 [0, 1, 0]
cd . && '/home/jojo/dokumente/Uni/info/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o callstack003 callstack003.hs -O -prof -auto-all -threaded -fprof-auto-calls -fno-full-laziness -fno-state-hack  >callstack003.comp.stderr 2>&1
cd . && ./callstack003  +RTS -p -RTS  </dev/null >callstack003.run.stdout 2>callstack003.run.stderr
Actual stdout output differs from expected:
--- ./callstack003.stdout	2012-09-17 11:27:02.607458948 +0200
+++ ./callstack003.run.stdout	2012-09-17 12:20:33.988109494 +0200
@@ -1,8 +1,8 @@
-[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.doTwice (callstack003.hs:10:15-17)"",""Main.f (callstack003.hs:7:11-36)""]
-[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.doTwice (callstack003.hs:10:22-24)"",""Main.f (callstack003.hs:7:11-36)""]
-[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.doTwice (callstack003.hs:10:15-17)"",""Main.f (callstack003.hs:7:11-36)""]
-[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.doTwice (callstack003.hs:10:22-24)"",""Main.f (callstack003.hs:7:11-36)""]
-[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.doTwice (callstack003.hs:10:15-17)"",""Main.f (callstack003.hs:7:11-36)""]
-[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.doTwice (callstack003.hs:10:22-24)"",""Main.f (callstack003.hs:7:11-36)""]
-[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.doTwice (callstack003.hs:10:15-17)"",""Main.f (callstack003.hs:7:11-36)""]
-[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.doTwice (callstack003.hs:10:22-24)"",""Main.f (callstack003.hs:7:11-36)""]
+[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.f (callstack003.hs:7:11-36)""]
+[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.f (callstack003.hs:7:11-36)""]
+[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.f (callstack003.hs:7:11-36)""]
+[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.f (callstack003.hs:7:11-36)""]
+[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.f (callstack003.hs:7:11-36)""]
+[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.f (callstack003.hs:7:11-36)""]
+[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.f (callstack003.hs:7:11-36)""]
+[""Main.CAF (<entire-module>)"",""Main.main (callstack003.hs:9:8-21)"",""Main.doTwice (callstack003.hs:10:15-24)"",""Main.f (callstack003.hs:7:11-36)""]
*** unexpected failure for callstack003(profthreaded)
}}}

Not sure if this really hurts anyone, and the behavior of the call stack WRT recursive calls is anyways not quite perfect yet (see #7240), this makes adding good test cases a bit difficult."	nomeata
3	7744	Can't install conduit via cabal-install	Compiler	7.6.2	normal		7.8.1		infoneeded	2013-03-05T16:55:04-0800	2013-04-13T05:49:06-0700	"When I did {{{cabal install hoogle}}} it failed on one of the dependencies, called conduit. Here is the output:

{{{
Downloading conduit-1.0.2...
Configuring conduit-1.0.2...
Building conduit-1.0.2...
Preprocessing library conduit-1.0.2...
[1 of 7] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Data/Conduit/Internal.o )
[2 of 7] Compiling Data.Conduit.Util ( Data/Conduit/Util.hs, dist/build/Data/Conduit/Util.o )
[3 of 7] Compiling Data.Conduit     ( Data/Conduit.hs, dist/build/Data/Conduit.o )
[4 of 7] Compiling Data.Conduit.List ( Data/Conduit/List.hs, dist/build/Data/Conduit/List.o )
[5 of 7] Compiling Data.Conduit.Binary ( Data/Conduit/Binary.hs, dist/build/Data/Conduit/Binary.o )
ghc: internal error: evacuate: strange closure type 8
    (GHC version 7.6.2 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Failed to install conduit-1.0.2
}}}"	guest
5	2459	"can't link haskell without ""main"" function, or -no-hs-main broken on windows?"	Driver	6.8.2	lowest	normal	7.6.2		new	2008-07-21T07:22:34-0700	2012-09-12T04:14:00-0700	"can't link haskell without ""main"" function, or -no-hs-main broken on windows?

The issue arose when trying to compile wxHaskell examples with a !WinMain entry point in
the executable rather than the standard ""main"" function, thereby stopping a new console
window being created when the application starts up, i.e. creating a ""windows"" application.

luckily (by chance, I think) the desired objective can be achieved without any change to the haskell 
code as follows, with the support that gcc already provides for a !WinMain entry point,
utilising the wxHaskell example:

{{{
> ghc -o HelloWorl.o -fglasgow-exts -c HelloWorld.hs
> ghc -optl-mwindows -o HelloWorld.exe HelloWorld.o -package wxcore
}}}

OK, so what is the issue ? We what if we want to define our own !WinMain or utilise the 
!WinMain or other entry point provided by another object file or code. According to the 
ghc documentation the way it could be achieved would be, with this example ...

!MyHelloWorld.hs ..

{{{
> module Hello where
> 
> foreign export ccall ""runHsMain"" runMain :: IO ()
> 
> runMain = do
>   putStrLn ""Hello World""
}}}

and mymain.c

{{{
#include ""HsFFI.h""
extern void __stginit_Hello ( void );

extern void runHsMain();
 

int main(int argc, char* argv[])
{

 
  hs_init(&argc, &argv);
  hs_add_root(__stginit_Hello);
  runHsMain();

  hs_exit();
  return 0;
}
}}}


{{{
> ghc -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc -o hello.exe mymain.c MyHelloWorld.o MyHelloWorld_stub.o
> hello.exe
Hello World
}}}

all works fine, but dosn't ghc documentation say, the -no-hs-main option should be used ? OK so use it

{{{
> ghc -no-hs-main -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc  -no-hs-main -o hello.exe mymain.c MyHelloWorld.o MyHelloWorld_stub.o
> hello.exe
Hello World
}}}

OK, works both with and without -no-hs-main, strange?
but how about if we want to define our own !WinMain or dllMain etc (i.e. no main at all)

winmain.c:

{{{
#include <windows.h>
#include ""HsFFI.h""
extern void __stginit_Hello ( void );

extern void runHsMain();
 
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
    LPSTR lpszCmdLine, int nCmdShow) 
{ 
 
  hs_init(0, 0);
  hs_add_root(__stginit_Hello);

  hs_exit();
  return 0;
}
}}}

you can use the above haskell hello example or the wxHaskell !HelloWorld example 
but with edits to main/module name as per !MyHelloWorld, call it !MyHelloWorldW.
But the above Haskell suffices as a test case, and is used in the
following.

linking with winmain, we get this error:

{{{
>ghc -no-hs-main -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to `
__stginit_ZCMain'
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to
`ZCMain_main_closure'
collect2: ld returned 1 exit status
}}}

it appears ghc does something like this (normal operation, for a standard haskell main)

 * create bootstrapping that initialises the ghc runtime and adds the root !__stginit_ZCMain, and runs the haskell main
 * create a ""c"" main that calls/executes the bootstrapping code
 * the executables entry point will be set by default to the ""c"" ""main"" procedure 

it seems that linking the haskell object with an object that already contains a main symbol will:

 * suppress the creation of bootstrapping code
 * executable entry point still set to the default (""main"")

this behaviour is exhibitted regardless of -no-hs-main option

When the haskell objects are linked with other objects and even though -no-hs-main option is 
specified it appears that ghc:

 * creates bootstrapping that initialises the ghc runtime and adds the root !__stginit_ZCMain, and runs the haskell main
 * creates a main that calls/executes the bootstrapping code
 * executable entry point still set to the default (""main"")

i.e. the same behaviour as for ""normal"" execution, this behaviour appears wrong, the behaviour should be:

 * suppress the creation of bootstrapping code (initialisation of haskell
 should be the responsibility of the external code, per guidlines)
 * executable entry point still set to default

i.e., as in the above example hs_add_root initialises the root module (!__stginit_Hello)
and there is no requirement for an !__stginit_ZCMain.


you can get the above example to compile and link with ...

{{{
>ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs

>ghc -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}

but if this is the wxHaskell !HelloWorld example, you would see that the it still starts up as a console
application and not a !WinMain (windows) application.

the effect of using th -main-is option is to insert a ""!___stginit_ZCMain"" symbol into the !HelloWorld.o
object. A ""c"" ""main"" will be created, initialising haskell and invoking the haskell main Hell.runMain. 
The entry point of the executable will be this ""main"", i.e. regard,

[link with ldl-mwindows to set entry to win32,see what happens]
{{{
> ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs

> ghc -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}

the above will compile and run but, will not invoke the winmain, rather it will invoke the
automatically generated ""main"".

the following

{{{
> ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc -optl-mwindows -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o

>winhello
}}}

will invoke the !WinMain routine as a windows application, (in this example a popup will be displayed
reporting an error ""hPutChar invalid arg bad file descriptor"", as it should), ignoring the haskell
supplied main/init.
 
BUT you shouldn't have to compile the haskell module with -main-is ... in order to get the overall exe to link , i.e. the following should work

{{{
>ghc -no-hs-main -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
>ghc -optl-mwindows -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}

but we get ...

{{{
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to `
__stginit_ZCMain'
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to
`ZCMain_main_closure'
collect2: ld returned 1 exit status
}}}

what should be:

 * no-hs-main option should suppress the requirement for a !___stginit_ZCMain symbol, this should enable
  the linking of, and specification of an arbitrary entry point into the executable external to the
  haskell code.

i.e. the last example should work.

the -optl-mwindows on the ghc command line we can flip the .exe entry point for the executable to a windows
entry point, gcc seems to handle it as follows: if the above -mwindows option is given then the entry point
of the executable is set to !WinMainCRTStartup, which in turn calls the !WinMain function (if present) or
the supplied main, it also sets the subsystem to windows."	jvl
3	7389	can't link postgresql-libpq on windows	GHCi	7.4.1	normal		7.8.1		new	2012-11-02T12:49:14-0700	2013-04-12T10:51:18-0700	"i follow the instructions here:
https://github.com/hdbc/hdbc-postgresql/wiki/WindowsInstall

and when cabal tries to link, i get:
{{{
Loading package postgresql-libpq-0.8.2.1 ... ghc.exe: Unknown PEi386 section name `.idata$4' (while processing: c:/PROGRA~2/POSTGR~1/9.1/lib\libpq.a)
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for i386-unknown-mingw32):
        loadArchive ""c:/PROGRA~2/POSTGR~1/9.1/lib\\libpq.a"": failed

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
"	eflister
4	4135	Can't Quote Instance Associated Types in Template Haskell	Template Haskell	6.12.1	low		7.6.2		new	2010-06-14T19:49:21-0700	2012-09-12T04:12:25-0700	"Give this a whirl:
{{{
{-# LANGUAGE TypeFamilies,TemplateHaskell #-}
module Bug where

    class C a where
        type T a

    $([d|  
        instance C (Maybe a) where
            type T (Maybe a) = Char
        |])
}}}

{{{
$ ghc -c Bug.hs 
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.

Bug.hs:7:6:
    Type indexes must match class instance head
    Found `Maybe a[aMy]' but expected `Maybe a[aMx]'
    In the associated type instance for `T'
    In the instance declaration for `C (Maybe a[aMx])'
[glastonbury:~/Projects/Haskell/Truth/Core]$ 
}}}"	Ashley Yakeley
3	6132	Can't use both shebang line and #ifdef declarations in the same file.	Compiler	7.0.4	normal		7.8.1		new	2012-05-29T05:05:29-0700	2012-10-11T13:56:16-0700	"I have an (admittedly awkward) script which can be compiled or interpreted.

If it's compiled, I want the full goodness. If it's interpreted, I want to run a ""minimal"" version (because if I don't have the compiled version, I probably don't have the required libraries either).

The following almost works:



{{{

module Main (main) where
#ifdef FANCY
import qualified System.Console.ANSI as Term
start = Term.setSGR [Term.SetColor Term.Foreground Term.Dull Term.Green]
end = Term.setSGR []
#else
start = return ()
end = return ()
#endif
main :: IO ()
main = do
	start
	putStrLn ""hello world""
	end
}}}


and then I can do:


{{{
$ runghc -cpp main.hs
hello world
^^ plain text
}}}



{{{
$ ghc -O -cpp -DFANCY main.hs
$ ./main
hello world
^^ green text (a.k.a ""fancy"")
}}}


I attempted to make this directly runnable by adding a shebang line of

{{{
#!/usr/bin/runghc -cpp
}}}


But unfortunately that chokes with -cpp:

{{{

$ ghc -O -cpp -DFANCY main.hs

main.hs:1:0:  error: invalid preprocessing directive #!
}}}

"	gfxmonk
3	7650	can't use combining characters in identifiers	Compiler	7.6.2	normal		7.8.1		new	2013-02-01T10:14:42-0800	2013-04-23T14:12:04-0700	"ghc doesn't let me use combining characters in unicode identifiers. Here's a test case with U+308 (COMBINING DIAERESIS) but it affects all accents:
{{{
% cat comb.hs
main = print spın̈alTap
    where spın̈alTap = 11
}}}
{{{
 % ghc comb.hs
[1 of 1] Compiling Main             ( comb.hs, comb.o )

comb.hs:1:18: lexical error at character '\776'
}}}

(This is actually with ghc 7.6.2 but the `Version` drop-down only goes up to 7.6.1.)"	guest
3	5289	Can't use ghci with a library linked against libstdc++	GHCi	7.0.3	normal		7.6.2		new	2011-06-28T21:59:14-0700	2012-09-12T04:12:02-0700	"My `double-conversion` library links to a C++ library. If I build it and try to use it from `ghci`, I get a failure:

{{{

Prelude Data.Double.Conversion.Text Data.Text> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> 
Leaving GHCi.
~ $ ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... can't load .so/.DLL for: stdc++ (libstdc++.so: cannot open shared object file: No such file or directory)
}}}

I can sort of work around this, but then I get a different crash:

{{{
~ $ ln -s /usr/lib64/libstdc++.so.6 libstdc++.so
~ $ LD_LIBRARY_PATH=$(pwd) ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/  :? for help
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... linking ... done.
""Floating point exception (core dumped)
}}}

Unfortunately, `gdb` doesn't give me a useful stack trace from this :-("	bos
3	5666	Can't use writeFile to write unicode characters.	libraries (other)	7.4.2	normal		7.6.2		new	2011-11-28T14:51:24-0800	2013-02-03T12:49:49-0800	"I tried to the ""locale"" environmental variables to ""en_US.utf8"",
but still I cannot write unicode characters.

source:

{{{
main = do
    hSetEncoding stdout utf8
    putStrLn ""αρχίδια""
    writeFile ""hello.txt"" ""σκατούλες""

}}}

output:

{{{
αρχίδια
commitBuffer: invalid argument (Illegal byte sequence)
}}}


without manually hSetEncoding stdin, putStrLn also
fails with the same error message.

From what I was told on #haskell, on linux ghc
uses setlocale to figure out what encoding to use,
but this is not present in OpenBSD.

Simply making those functions read $LANG (I think)
would solve this for OpenBSD, but I might be wrong."	tsou
3	5702	Can't vectorise pattern matching on numeric literals	Data Parallel Haskell	7.3	normal		7.6.2	chak	new	2011-12-14T22:43:49-0800	2012-09-12T03:26:08-0700	"Trying to vectorise
{{{
toBool :: Int -> Bool
toBool 0 = False
toBool _ = True
}}}
we get
{{{
*** Vectorisation error ***
    Can't vectorise expression GHC.Prim.Int#
}}}"	chak
3	7884	Cannot build hedgewars with new haskell 7.6	Compiler	7.6.2	normal				new	2013-05-03T01:02:03-0700	2013-05-03T01:02:03-0700	"Hi All, I post here since this bug *CAN* be a regression between haskell 7.4 and 7.6.

Please look at this log
https://buildd.debian.org/status/fetch.php?pkg=hedgewars&arch=armhf&ver=0.9.18-0.3&stamp=1367518566
Everything is fine with haskell 7.4

and this one
https://launchpadlibrarian.net/138989726/buildlog_ubuntu-saucy-armhf.hedgewars_0.9.18-0.3_FAILEDTOBUILD.txt.gz


this seems to be an uncorrent link with the new haskell"	LocutusOfBorg
4	3937	Cannot killThread in listen/accept on Windows threaded runtime	Runtime System	6.12.1	low		7.6.2		new	2010-03-23T09:24:42-0700	2012-09-12T04:12:22-0700	"The killThread is not able to kill threads accepting socket connections on Windows.

Run attached file either in GHCi:

{{{
runghc.exe ListenOn.hs
}}}


or compile threaded:


{{{
ghc --make -threaded ListenOn.hs
}}}


Resulting binary hangs.

Expected behavior: should finish without problems.

Non-threaded runtime produces expected behavior. Seems to work correctly on Linux.

Affected: ghc-6.10.4 and ghc-6.12.1.

"	guest
3	7114	Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1	Compiler	7.4.1	normal		7.8.1		new	2012-08-03T06:06:41-0700	2012-10-20T13:45:49-0700	"(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
2	5902	Cannot tell from an exception handler whether the exception was asynchronous	Compiler	7.4.1	high		7.8.1	simonmar	new	2012-02-27T07:58:37-0800	2013-05-03T03:46:51-0700	"Following on from #2558 which was closed (by me) as wontfix, we still don't have a way to reliably tell whether an exception we caught was asynchronous or not.  There are some suggestions in #2558, we just need to implement something.  The fix for #3997 was defficient due to this, as exposed by the test program in #5866.

"	simonmar
4	4215	canonicalizePath behaves strangely with paths that do not exist	libraries/directory	6.12.3	low		7.6.2		new	2010-07-23T14:00:05-0700	2013-04-25T05:01:15-0700	"The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system.  The documentation should, minimally, indicate that this is the case.  Ideally, the behavior would be well-defined.

This is complicated by differing behaviors of the underlying realpath(char*, char*) function in Linux and OS X.  On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases.  Specifically, assume the following:

 * $HOME/tmp/foo is a file.
 * $HOME/tmp/bar is a directory.
 * $HOME/tmp/baz does not exist.

Linux:
{{{
Prelude System.Directory> canonicalizePath ""/home/creswick/tmp/foo/subdir""
""/home/creswick/tmp/foo""
Prelude System.Directory> canonicalizePath ""/home/creswick/tmp/bar/subdir""
""/home/creswick/tmp/bar/subdir""
Prelude System.Directory> canonicalizePath ""/home/creswick/tmp/baz/subdir""
""/home/creswick/tmp/baz""
}}}

OS-X:
{{{
Prelude System.Directory> canonicalizePath ""/Users/hudson/tmp/foo/subdir""                                                           
""/Users/hudson/tmp/foo/subdir""
Prelude System.Directory> canonicalizePath ""/Users/hudson/tmp/bar/subdir""
""/Users/hudson/tmp/bar/subdir""
Prelude System.Directory> canonicalizePath ""/Users/hudson/tmp/baz/subdir""
""/Users/hudson/tmp/baz""
}}}
"	creswick
4	5014	canonicalizePath throws exception on paths that do not exist	libraries/directory	7.0.2	low		7.6.2		new	2011-03-11T03:01:18-0800	2013-04-25T03:58:38-0700	"Assume path `foo` exists, but `foo/bar` doesn't. On GHC 6.12, `canonicalizePath ""foo/bar""` gave back a result. On GHC 7.02, I get an exception:

{{{
*** Exception: foo/bar: canonicalizePath: does not exist (No such file or directory)
}}}

The behavior is not defined by the documentation, or at all (see #4215) but it would be nice if it didn't crash."	hesselink
3	7388	CAPI doesn't work with ghci	GHCi	7.6.1	normal		7.6.2	igloo	new	2012-11-02T05:14:52-0700	2012-11-19T18:13:53-0800	"{{{
$ ghc -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history T4012 --interactive -ignore-dot-ghci   
GHCi, version 7.7.20121101: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 3] Compiling T4012_B          ( T4012_B.hs, interpreted )

ByteCodeLink: can't find label
During interactive linking, GHCi couldn't find the following symbol:
  ghczuwrapperZC0ZCmainZCT4012zuBZCprintf
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
  glasgow-haskell-bugs@haskell.org

> 
}}}
"	igloo
3	5974	Casts, rules, and parametricity	Compiler	7.4.1	normal		_|_		new	2012-03-27T23:22:31-0700	2012-09-27T05:23:55-0700	"Pedro wrote this [http://www.haskell.org/pipermail/generics/2012-February/000513.html long message] about the way that his generic-programming was not optimising as it should: 

My reply was in two parts.  The [http://www.haskell.org/pipermail/generics/2012-March/000516.html first] was fairly simple.  The [http://www.haskell.org/pipermail/generics/2012-March/000517.html second] I reproduce below because it highlights a tricky ineraction between RULES and casts, which I don't know how to solve.

Pedro wondered why it made a difference whether you said
{{{
   instance GEnum Nat where
     genum = map to genum'
or
   instance GEnum Nat    -- Fill in from default method
}}}
Well, it turns out that the difference is largely accidental.  Here are the types of the functions involved:
{{{
	to :: Representable a => Rep a -> a
	genum' :: GEnum' a => [a]

	type instance Rep Nat = RepNat
   	type RepNat = U :+: (Rec Nat)
}}}
Consider the instance definition
{{{
     genum = map to genum'
}}}
There are two different ways of typing it:
{{{
(A)	map @RepNat @Nat (to @Nat dReprNat |> g1) (genum' @RepNat dGEnum'_RepNat)
        where 
	    g1 :: Rep Nat -> Nat ~ RepNat -> Nat
          dReprNat :: Representable Nat
          dGEnum'Nat :: GEnum' RepNat
}}}
or
{{{
(B)	map @(Rep Nat) @Nat (to @Nat dReprNat) (genum' @(Rep Nat) dGEnum'_Rep_Nat)
        where 
           dReprNat :: Representable Nat
           dGEnum'Nat :: GEnum' (Rep Nat)
}}}
Which of these is chosen depends on accidental things in the constraint solver; it's not supposed to matter.

But it DOES affect whether the `map/(|||)` rule fires.
{{{  
{-# RULES ""ft |||"" forall f a b. map f (a ||| b) = map f a ||| map f b #-}
}}}

It makes a difference because in (A) we have an instance for `GEnum' RepNat` that uses `|||` directly,
{{{
	instance (GEnum' f, GEnum' g) => GEnum' (f :+: g) where
 	   genum' = map L genum' ||| map R genum'
}}}
 so we get
{{{
	map ... (blah1 ||| blah2)
}}}
But in (B) we need an instance for `GEnum' (Rep Nat)` and that has an extra cast, so we get
{{{
	map ... ((blah1 ||| blah2) |> g)
}}}
And the cast stops the RULE for `map/(|||)` firing.


== Parametricity to the rescue ==

Note that `(|||) :: [a] -> [a] -> [a]`. So by parametricity we know that
{{{
	if g :: [T1] ~ [T2]
then
	((|||) @T1 xs ys |> g)
       =
 	((|||) @T2 (xs |> g) (ys |> g)
}}}
If we used that to push the cast inwards, the RULE would match.  

Likewise, map is polymorphic: `map :: (a->b) -> [a] -> [b]`
So by parametricity
{{{
	if :: [T1] -> [T2]
   then
 	map @T2 @TR f (xs |> g)]
      =
	map @T1 @TR (f |> sym (right g) -> TR) xs
}}}
If we used that to move the cast out of the way, the RULE would match too.

But GHC is nowhere near clever enough to do either of these things.  And it's far from obvious what to do in general.

== Bottom line ==

The choices made by the constraint solver can affect exactly where casts are inserted into the code.  GHC knows how to move casts around to stop them getting in the way of its own transformations, but is helpless if they get in the way of RULES.

I am really not sure how to deal with this.  But it is very interesting!

Simon
"	simonpj
3	5320	check_overlap panic (7.1 regression)	Compiler	7.1	normal		7.6.2	simonpj	new	2011-07-13T06:19:00-0700	2012-09-12T04:12:02-0700	"The attached program is rightfully rejected by GHC 7.0.4 (with {{{""Could not deduce (HMapClass f l) ...""}}}) but makes GHC HEAD panic:
{{{
$ ghc-7.3.20110713 Overlap.hs 
[1 of 1] Compiling Overlap          ( Overlap.hs, Overlap.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.3.20110713 for x86_64-unknown-linux):
	check_overlap
    main:Overlap.HDropClass{tc raS}
      main:Overlap.PZero{tc raZ}
      (main:Overlap.HMap{tc raN} f{tv adi} [sk] l{tv adk} [sk])

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

}}}
Both versions are built with the devel2 BuildFlavour.
"	mikhail.vorozhtsov
5	3238	CInt FFI exports do not use C int in _stub.h header file	Compiler (FFI)	6.11	lowest	normal	7.6.2		new	2009-05-16T13:13:12-0700	2012-09-12T04:14:09-0700	"Ideally if I have a FFI export like this:
{{{
foreign export ccall foo :: CInt -> CInt
}}}
Then the `_stub.h` file should look like:
{{{
#ifdef __cplusplus
extern ""C"" {
#endif
extern int foo(int a1);
#ifdef __cplusplus
}
#endif
}}}
But it actually looks like:
{{{
#include ""HsFFI.h""
#ifdef __cplusplus
extern ""C"" {
#endif
extern HsInt32 foo(HsInt32 a1);
#ifdef __cplusplus
}
#endif
}}}

So what am I complaining about? Well, I specified an FFI export mentioning only C types but the header file uses `HsInt32`. I'd prefer an actual C `int`. I also do not want to  `#include ""HsFFI.h""` because then when using gcc to compile C code that uses this C function I have to know the full path to ghc's include dir so that gcc can find `HsFFI.h`.

The point here is about exporting C functions and trying to integrate into some bigger build system that will be using gcc not ghc to compile C code and link the system together.

I realise this isn't trivial to fix, because GHC defines things like CInt as newtypes for primitive types of known widths (like Int32). However, perhaps there should be a known mapping, even though within the Haskell world CInt is just a newtype. The set of FFI types is already hard-wired into the compiler (with some rules to allow newtype unwrapping etc) so why not extend that hard-wired knowledge to include the real C type (not just the ABI width). This only needs to be used when generating the export header files. An extra bit in the mapping can indicate if it's a C primitive type or if the export header file has to `#include ""HsFFI.h""`.

This ticket is related to #2926 and the solution is almost certainly the same, but the motivation for this problem is slightly different."	duncan
3	3995	Comment delimiters ignored inside compiler pragma	Compiler (Parser)	6.10.4	normal		_|_		new	2010-04-19T11:19:42-0700	2010-05-04T06:27:47-0700	"GHC accepts some pragmas that are not valid comments because of embedded comment delimiters.  If the delimiters are hidden inside an embedded comment or string, they are not recognized by the parser, but they should be according to the Haskell report.  For example, the following has one opening and three closing comment delimiters, but is accepted by the parser.

{{{
{-# RULES
 ""-}"" id 0 = 0
 -- -}
 #-}
}}}"	heatsink
3	7505	Commentary shipped with GHC sources is outdated	Documentation	7.7	normal		7.8.1		new	2012-12-17T07:50:16-0800	2013-01-10T09:06:58-0800	"Commentary that comes with GHC sources is outdated. It contains incorrect links:

 - http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/
 - http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/
 - http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/docs/comm/
All these pages 404. 

The document says it was last updated in 2005 so I guess that information from it has been moved to the wiki. Perhaps it's time to either update or remove this commentary from the sources? Right now it's a bit confusing: should I read this commentary or the wiki?"	jstolarek
4	3744	Comparisons against minBound/maxBound not optimised	Compiler	6.13	low		7.6.2		new	2009-12-10T19:25:59-0800	2012-09-12T04:12:20-0700	"{{{
foo :: Int -> Bool
foo n = n < minBound || n > maxBound
}}}

GHC retains both comparisons even though they are guaranteed to be False. This also happens for other integral types. The optimisation is fairly easy to implement for `Int` and `Word` (only requires some plumbing in !PrelRules) but it's not clear what to do about smaller integral types. For `Int64` and `Word64`, GHC doesn't even inline `minBound` and `maxBound`:

{{{
T.$wfoo :: GHC.Prim.Int64# -> GHC.Bool.Bool
T.$wfoo =
  \ (ww_ss5 :: GHC.Prim.Int64#) ->
    case GHC.Int.$fBoundedInt64_$cminBound
    of _ { GHC.Int.I64# y#_are ->
    case {__ccall hs_ltInt64 GHC.Prim.Int64#
                    -> GHC.Prim.Int64#
                    -> GHC.Prim.State# GHC.Prim.RealWorld
                    -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_arD
           ww_ss5 y#_are GHC.Prim.realWorld#
    of _ { (# _, ds3_arH #) ->
    case ds3_arH of _ {
      __DEFAULT -> GHC.Bool.True;
      0 ->
        case GHC.Int.$fBoundedInt64_$cmaxBound
        of _ { GHC.Int.I64# y#1_ar4 ->
        GHC.IntWord64.gtInt64# ww_ss5 y#1_ar4
        }
    }
    }
    }

T.foo :: GHC.Int.Int64 -> GHC.Bool.Bool
T.foo =
  \ (w_ss3 :: GHC.Int.Int64) ->
    case w_ss3 of _ { GHC.Int.I64# ww_ss5 -> T.$wfoo ww_ss5 }

}}}
"	rl
5	2346	Compilation of large source files requires a lot of RAM	Compiler	6.8.2	lowest	major	7.6.2		new	2008-06-04T17:45:16-0700	2013-01-27T15:00:18-0800	"We have automatically generated source files with up to ~20000 lines of code.

One type definition, two functions called ""grammar"" (cmGrammer, ghGrammar) and one or more functions called ""algebra"" (prettyprint, scoremax, count, ***) are generated. Each function has a where-clause with 100+ locally visible function defined.

Attached, you find two files (ADPTriCombinators.lhs, RnaI.lhs) with helper-functions and three of our source files. One is the smallest example we have and the other the largest. RF00549RED.hs is reduced to only the type, one algebra and one grammar.

Copy all files into a directory and then execute:
{{{
ghc --make RF00390.hs (should work)
ghc --make RF00549.hs (WARNING: EATS ALL MEMORY)
ghc --make RF00549RED.hs (WARNING: EATS ALL MEMORY)
}}}



System Info:
{{{
Linux workstation 2.6.25-ARCH #1 SMP PREEMPT 
Fri May 16 14:52:43 CEST 2008 
i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD 
GNU/Linux (2 GByte RAM, 2 GByte Swap)

gcc version 4.3.0 (GCC)
}}}

Thanks,
Christian Höner zu Siederdissen
"	choener
2	4012	Compilation results are not deterministic	Compiler	6.12.2	high		7.6.2		new	2010-04-24T06:05:40-0700	2013-02-14T12:51:19-0800	"There are some issues with non-determinism in the output of GHC, which means that compilations are not repeatable.  This affects some users (e.g. Debian packagers) who need to be able to get repeatable hashes for the packages of a GHC build.

The cases we know about that lead to non-deterministic results are:

 * The `spec_ids` (specialised Ids) attached to an Id have a non-deterministic ordering
 * CSE can give different results depending on the order in which the bindings are considered, and since the ordering is non-deterministic, the result of CSE is also non-deterministic.  e.g. in `x = z; y = z; z = 3`, where `y` and `x` are exported, we can end up with either `x = y; y = 3` or `y = x; x = 3`.
 * There seems to be something unpredictable about the order of arguments to SpecConstr-generated specialisations, see [http://www.haskell.org/pipermail/glasgow-haskell-users/2011-April/020287.html]
 * The wrappers generated by the `CApiFFI` extension have non-deterministic names. (see comment:15 below).

'''Old ticket description follows'''

Short story: if you use ghc-6.12.1.20100318 (or similar, probably
ghc-6.12.1 release will produce the same results) to bootstrap
ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12,
those two instances of ghc-6.12 will have different ABI hashes and
interfaces in the ghc package. If you use ghc-6.10 for the
bootstrapping, you'll even get differences in the ghc, base and
Cabal packages.

Long story: see logfiles and descriptions at http://darcs.volkswurst.de/boot-tests/ (note that the logfiles are quite large, I really don't want to attach 150 MB of logs to this ticket)."	kili
3	6037	Compile-time crash with sources with non-representable unicode characters	Compiler	7.4.1	normal		7.8.1		new	2012-04-24T01:28:07-0700	2013-03-22T02:57:23-0700	"The following file causes GHC to crash, if compiled in the ""C"" locale.

{{{
$ LC_ALL=C ghc unicode.hs
[1 of 1] Compiling Foo              ( unicode.hs, unicode.o )

unicode.hs:2:1:
    Warning: Pattern match(es) are overlapped
             In an equation for `<stderr>: hPutChar: invalid argument (invalid character)
}}}

unicode.hs:
{{{
module Foo where
δ x = 3
δ x = 4
}}}"	akio
2	7103	Compiler panic, when loading wxc in GHCi	GHCi	7.4.2	high		7.6.2		new	2012-07-28T15:15:56-0700	2012-11-17T09:43:55-0800	"{{{
Loading package wxc-0.90.0.4 ... <interactive>: Unknown PEi386 section name `.idata$4' (while processing: C:\Programs\wxWidgets-2.9.3\lib\gcc_dll\libwxmsw29u_xrc.a)
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.4.2 for i386-unknown-mingw32):
        loadArchive ""C:\\Programs\\wxWidgets-2.9.3\\lib\\gcc_dll\\libwxmsw29u_xrc.a"": failed
}}}
"	Henk-Jan
2	3103	Compiling base with cabal fails.	Compiler	6.10.1	high	normal	7.8.1		new	2009-03-15T16:52:23-0700	2013-01-21T07:26:13-0800	"Compiling base with -fext-core fails with ghc-6.10.1 and ghc-6.10.1rc.

Reproduce with: cd libraries/base/ && cabal build -v --ghc-options=""-fext-core""

I've attached the output from my machine."	Lemmih
3	7258	Compiling DynFlags is jolly slow	Compiler	7.6.1	normal		7.8.1	simonpj	new	2012-09-20T03:04:53-0700	2013-01-31T11:02:49-0800	"Compiling `DynFlags` really takes a long time these days.  

Ian thinks that it's due to the `Read` and `Show` instances he has added (see attached `W2.hs`.

Simon M suggests: instead of using `Read/Show`, you could generate some code in `mkDerivedConstants` to use `ReadP` and `Outputable`, which should be much smaller and faster.

This ticket is
 * To see if we can speed up compilation of `DynFlags` 
 * To check WHY it is so slow.  Are there any lessons we can learn or ways to make it compile faster?  Is it tickling some asymptotically-bad corner of the compiler?

Simon"	simonpj
3	3827	Compiling fails on linux-powerpc	Compiler	6.12.1	normal		_|_		new	2010-01-19T06:34:11-0800	2011-04-10T16:31:26-0700	"I get the following error after doing ./configure && make
{{{
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 6.12.1 for powerpc-unknown-linux):
        Error in array index
}}}
The command where the failure happens is:
{{{
""inplace/bin/ghc-stage1""   -H32m -O    -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.    -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags     -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o
}}}
"	speleologic
4	5262	Compiling with -O makes some expressions too lazy and causes space leaks	Compiler	7.1	low		7.6.2		new	2011-06-16T05:43:54-0700	2012-09-12T04:13:30-0700	"Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.

Here are terms that get compiled too lazy with -O only when full strictness is on:
{{{
seq (id (\a -> seq a (\b -> (undefined::Int))) (undefined::Bool))
\a -> seq (seq a (\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\b -> ([]::[] Int)) length
\a -> seq (id (\b -> seq b (\c -> seq)) (length a)) ([]::[] Int)
}}}

Here are terms which are compiled too lazy with -O regardless of full strictness:
{{{
seq (seq (odd (undefined::Int)) (\a -> (undefined::[] (Int -> Bool))))
foldr (\a -> seq) id ((:) True (undefined::[] Bool))
\a -> foldr (\b -> \c -> seq c (\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False
\a -> (\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\b -> (undefined::([] Bool))))
map (seq (seq (seq 0 (undefined::Bool)) (\a -> \b -> (undefined::Bool)) (undefined::Int)))
map (seq (seq (id (\a -> (undefined::Int)) ([]::[] Int)) (\a -> undefined::Bool)))
\a -> (\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\b -> (undefined::Int -> [] Int)))
}}}

To discover the differences, just run the terms (whose types are [Int] -> [Int]) on some partially or fully-defined small lists.

It is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).

All programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.

Is this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug."	michal.palka
2	5763	Confusing error message	Compiler	7.2.2	high		7.6.2	simonpj	new	2012-01-11T00:26:59-0800	2013-03-25T19:10:20-0700	"For test `indexed-types/should_fail/T4272` we get this type error
{{{
T4272.hs:11:16:
    Occurs check: cannot construct the infinite type:
      x0 = TermFamily x0 x0
    Expected type: TermFamily x0 x0
      Actual type: TermFamily a a
    In the first argument of `prune', namely `t'
    In the expression: prune t (terms (undefined :: TermFamily a a))
    In an equation for `laws':
        laws t = prune t (terms (undefined :: TermFamily a a))
}}}
It's not at all obvious why unifying `(TermFamily x0 x0)` with `(TermFamily a a)` should yield an occurs check. Especially as `TermFamily` is a type function with arity 1, and `x0` is a unification variable.  So the natural way to solve this constraint would be to unify `x0` with `a`, and then the constraint is satisfied.

What goes wrong is that there is ''another'' insolube constraint (which is also reported):
{{{
T4272.hs:11:19:
    Could not deduce (a ~ TermFamily x0 x0)
    from the context (TermLike a)
      bound by the type signature for
                 laws :: TermLike a => TermFamily a a -> b
      at T4272.hs:11:1-54
      `a' is a rigid type variable bound by
          the type signature for laws :: TermLike a => TermFamily a a -> b
          at T4272.hs:11:1
    In the return type of a call of `terms'
    In the second argument of `prune', namely
      `(terms (undefined :: TermFamily a a))'
    In the expression: prune t (terms (undefined :: TermFamily a a))
}}}
The constraint solver finds this latter constraint, can't solve it, ''but still uses it to simplify the first one'', by substituting `(TermFamily x0 x0)` for `a`; and that is what gives the occurs check error.

I don't think that we should use ''insoluble'' constraints to rewrite unsolved constraints.  But it's delicate, so I am not trying to fiddle right now. Hence making this ticket.

(Incidentally, it's not a regression; it's been like this forever.)
"	simonpj
4	1928	Confusing type error message	Compiler (Type checker)	6.8.1	low	normal	_|_		new	2007-11-25T06:44:33-0800	2008-09-30T08:52:09-0700	"The following code (which is part of a bigger module) needs scoped type variables to compile.

{{{
run_state :: forall a s. State s a -> s -> (a,s)
run_state m s = observe_monad unit_op bind_op m where
  unit_op v          = (v,s)
  bind_op :: BindOp (StateE s) a (a,s)
  bind_op Get      k = run_state (k s) s
  bind_op (Put s1) k = run_state (k ()) s1
}}}
However, forgetting to turn on scoped type variables will give a very confusing error message:
{{{
Unimo.hs:56:36:
    Couldn't match expected type `s1' against inferred type `s'
      `s1' is a rigid type variable bound by
           the type signature for `bind_op' at Unimo.hs:55:28
      `s' is a rigid type variable bound by
          the type signature for `run_state' at Unimo.hs:52:22
    In the first argument of `k', namely `s'
    In the first argument of `run_state', namely `(k s)'
    In the expression: run_state (k s) s
}}}
Line 52 is the type signature of run_state and line 55 is the type signature of bind_op. The error message talks about a type variable `s1' which isn't mentioned anywhere. I guess the reason for this is that we have name collision and this is ghc's way of trying to tell the two variables apart. I don't think it works that well though. But I'm afraid I don't have any suggestion on how to make it better."	josef
3	5724	Confusing warning message for incomplete patterns	Compiler	7.3	normal		7.6.2		new	2011-12-24T18:18:47-0800	2012-09-12T04:12:07-0700	"The following code

{{{
{-# OPTIONS_GHC -Wall #-}

import Data.Word

f :: Word8 -> Bool
f 0 = True
f 1 = False
f 2 = True
}}}

Produces the warning

{{{
7:1:
    Warning: Pattern match(es) are non-exhaustive
             In an equation for `f':
                 Patterns not matched: #x with #x `notElem` [0#, 1#, 2#]
}}}

While accurate, this is not exactly user friendly.

Found in GHC 7.4.1 RC 1"	AntoineLatter
3	7854	Constrained method type accepted in Haskell 98 mode	Compiler	7.6.3	normal				new	2013-04-21T22:25:22-0700	2013-05-03T04:21:32-0700	"If I understand [http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/type-class-extensions.html#class-method-types this paragraph] of the GHC manual correctly, the following code should be rejected in Haskell 98 mode:

{{{
{-# LANGUAGE Haskell98 #-}

module Main where

class Compare a where
  comp :: Eq a => a -> a -> Bool
}}}

However, it compiles fine for me both with 7.4.2 and 7.6.1."	refold
3	7543	Constraint synonym instances	Compiler	7.6.1	normal		7.8.1		new	2013-01-01T22:05:16-0800	2013-04-12T15:10:06-0700	"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
4	3427	control what sort of entity a deprecated pragma applies to	Compiler	6.10.4	low	normal	7.6.2		new	2009-08-12T13:05:08-0700	2012-09-12T04:12:17-0700	"Originally reported as part of #3303.

----

It's annoying not being able to control whether a type or identically named constructor is being deprecated. Consider:
{{{
data Foo = Foo ...
}}}
This is a very common idiom. But now we want to switch to smart constructors
{{{
foo :: ... -> Foo
}}}
and eventually stop exporting the constructor Foo. But we cannot specify just the constructor, only both. According to the [http://haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma user guide] the workaround would be to have a module that imports one but not the other, however while that's possible for the type it's not possible for the constructor.

How about
{{{
{-# DEPRECATED constructor Foo ""use `foo' instead"" #-}
}}}
and while we're at it, might as well have
{{{
{-# DEPRECATED type Foo ""..."" #-}
}}}
leaving the unqualified case meaning both as it does now.
"	igloo
4	5251	copyFile does not copy metadata	libraries/directory	7.0.2	low		7.6.2		new	2011-06-10T05:26:33-0700	2012-09-12T04:13:30-0700	"The `copyFile` function fails to copy various metadata to do with a file.

(GHC 7.0.2, directory 1.1.0.0 - not that I expect it to matter.)

The cause is simple: Rather than calling an OS-specific ""please copy this file"" function, the directory package attempts to implement this logic itself. And does it completely wrong.

The fix should be easy; we just need somebody to figure out what the appropriate native OS function is on each platform.
"	Orphi
3	5777	core lint error with arrow notation and GADTs	Compiler	7.4.2	normal		7.6.2	ross	new	2012-01-15T08:11:24-0800	2013-03-04T01:43:32-0800	"The following code panics GHC (with 7.0.3, 7.2 and 7.4.0.20111219):

{{{
{-# LANGUAGE Arrows, GADTs #-}
import Control.Arrow

data Value a where BoolVal :: Value Bool

class ArrowInit f where
    arrif :: f b -> ()

instance ArrowInit Value where
    arrif = proc BoolVal -> returnA -< ()
    -- arrif = arr (\BoolVal -> ())
}}}

I am attaching the -dcore-lint from 7.4.
"	benmos
4	4463	CORE notes break optimisation	Compiler	7.1	low		_|_		new	2010-11-02T02:12:34-0700	2010-11-17T03:22:49-0800	"I think at some point we decided that Core notes shouldn't affect optimisation. Here is a case where they do:

{{{
module Foo where

foo :: Int -> Int
{-# INLINE [1] foo #-}
foo x = x+1

{-# RULES ""foo/foo"" forall x. foo (foo x) = x #-}
}}}

{{{
module Bar where

import Foo

bar :: Int -> Int -> Int
bar x y = foo ({-# CORE ""note"" #-} x `seq` foo y)
}}}

When compiled with -O2, the rule doesn't fire with the note but does fire without it. This is the Core with the note:

{{{
Bar.bar =
  \ (x_aaw :: GHC.Types.Int) (y_aax :: GHC.Types.Int) ->
    Foo.foo
      (__core_note ""note""
       (case x_aaw of _ { GHC.Types.I# _ -> Foo.foo y_aax }))
}}}

For the rule to fire, GHC must move the seq to the outside but because of the note, it doesn't."	rl
4	4938	Core2 CPU not detected correctly	Compiler	7.1	low		7.6.2		new	2011-01-31T15:48:10-0800	2012-09-12T04:13:24-0700	"This is a HEAD build on a Core2 Duo (i386 & x86_64) MacBook Pro. 

Configure Command: `./configure --host=x86_64-apple-darwin --target=x86_64-apple-darwin`

Configure Summary:
{{{
Configure completed successfully.

   Building GHC version  : 7.1.20110131

   Build platform        : i386-apple-darwin
   Host platform         : x86_64-apple-darwin
   Target platform       : x86_64-apple-darwin

   Bootstrapping using   : /usr/bin/ghc
      which is version   : 6.12.3

   Using GCC             : /usr/bin/gcc
      which is version   : 4.2.1

   ld       : /usr/bin/ld
   Happy    : /usr/local/bin/happy (1.18.5)
   Alex     : /usr/local/bin/alex (2.3.3)
   Python   : /usr/bin/python
   Perl     : /usr/bin/perl
   dblatex  : /usr/local/bin/dblatex
   xsltproc : /usr/bin/xsltproc
   HsColour : /Users/wknop/.cabal/bin/HsColour

   Building DocBook HTML documentation : YES
   Building DocBook PS documentation   : YES
   Building DocBook PDF documentation  : YES
}}}

Build fails with:
{{{
compiler/stage2/build/LibFFI_hsc_make.c:1: error: CPU you selected does not support x86-64 instruction set
}}}

Workaround: Adding `-march=core2` to the `x86_64-apple-darwin` section of `aclocal.m4` convinces the compiler that the processor supports i386 and x86_64.
"	altaic
3	7862	Could not deduce (A) from the context (A, ...)	Compiler (Type checker)	7.6.2	normal				new	2013-04-25T00:56:46-0700	2013-05-03T02:45:27-0700	"The following code doesn't compile and produces a strange error:

{{{
{-# LANGUAGE TypeFamilies, FlexibleContexts #-}

module Numeric.AD.Internal.Tower () where

type family Scalar t

newtype Tower s a = Tower [a]

type instance Scalar (Tower s a) = a

class (Num (Scalar t), Num t) => Mode t where
    (<+>) :: t -> t -> t

instance (Num a) => Mode (Tower s a) where
    Tower as <+> _ = undefined
      where
        _ = (Tower as) <+> (Tower as)

instance Num a => Num (Tower s a) where
}}}

{{{
src/Numeric/AD/Internal/Tower.hs:17:24:
    Could not deduce (Num (Scalar (Tower s a)))
      arising from a use of `<+>'
    from the context (Num (Scalar (Tower s a)), Num (Tower s a), Num a)
      bound by the instance declaration
      at src/Numeric/AD/Internal/Tower.hs:14:10-36
    Possible fix:
      add an instance declaration for (Num (Scalar (Tower s a)))
    In the expression: (Tower as) <+> (Tower as)
    In a pattern binding: _ = (Tower as) <+> (Tower as)
    In an equation for `<+>':
        (Tower as) <+> _
          = undefined
          where
              _ = (Tower as) <+> (Tower as)
}}}

Furthermore, Removing the {{{Num (Scalar t)}}} constraint from the {{{Mode}}} class produces a different strange error:
{{{
src/Numeric/AD/Internal/Tower.hs:17:24:
    Overlapping instances for Num (Tower s0 a)
      arising from a use of `<+>'
    Matching givens (or their superclasses):
      (Num (Tower s a))
        bound by the instance declaration
        at src/Numeric/AD/Internal/Tower.hs:14:10-36
    Matching instances:
      instance Num a => Num (Tower s a)
        -- Defined at src/Numeric/AD/Internal/Tower.hs:19:10
    (The choice depends on the instantiation of `a, s0')
    In the expression: (Tower as) <+> (Tower as)
    In a pattern binding: _ = (Tower as) <+> (Tower as)
    In an equation for `<+>':
        (Tower as) <+> _
          = undefined
          where
              _ = (Tower as) <+> (Tower as)
}}}"	alang9
4	4150	CPP+QuasiQuotes confuses compilation errors' line numbers	Compiler (Parser)	6.12.3	low		7.6.2		new	2010-06-23T16:38:47-0700	2012-09-12T04:12:25-0700	"doing an #include of multi-line files inside QuasiQuotes makes GHC report wrong line numbers on errors occurring in normal code which is after the said #include.

{{{
myHtmlsTemplate = [$multiLineStr|
#include ""template.html""
|]

somethingElse :: NoSuchType
somethingElse = 7
}}}

The example code will fail compiling with: {{{Not in scope: type constructor or class `NoSuchType'}}}, but will not report the correct line number of the error.
"	yairchu
5	2140	cpuTimePrecision is wrong for me on Windows (XP)	libraries/base	6.8.2	lowest	normal	7.6.2		new	2008-03-06T03:59:02-0800	2012-09-12T04:13:46-0700	"(From Adrian Hey)

Looking at the source code, this seems to be fixed
at 1000000000 independent of hardware. I'm not sure
if this is supposed to be the same on all Windows XP systems, but it's wrong on my machine at least.

getCPUTime always returns a multiple of 15625000000"	guest
4	5305	crash after writing around 40 gigabytes to stdout	Compiler	7.0.3	low		7.6.2		new	2011-07-06T16:07:33-0700	2012-09-12T04:13:32-0700	"After writing about 40GiB to stdout program crashes with one of these errors:
{{{
<stdout>: commitBuffer: invalid argument (Invalid argument)
<stdout>: hPutBuf: invalid argument (Invalid argument)
}}}
depending on which print function is used (Data.ByteString.Lazy.putStr or IO.putStrLn)

Occurs with 7.0.3, 7.0.2, win7 64bit, winxp 32bit

Compiled with one of these ghc calls:
{{{
ghc -rtsopts -threaded --make rec.hs -O2 -o rec.exe
ghc --make rec.hs -O2 -o rec.exe
ghc --make rec.hs -o rec.exe
}}}

Failed for both, with and without runtime settings:
{{{
rec +RTS -N2 -RTS > rec.txt
rec > rec.txt
}}}

"	lava
3	7894	Crash on :i M.->	Compiler (Parser)	7.6.3	normal				new	2013-05-07T09:50:10-0700	2013-05-07T09:50:10-0700	"{{{
Prelude> :i M.->
ghc: panic! (the 'impossible' happened)
  (GHC version 7.7.20130427 for x86_64-unknown-linux):
	isDataOcc: check me ->
}}}"	monoidal
3	5907	Crashed loading package Safe	Package system	7.0.3	normal		7.6.2		new	2012-02-29T07:21:36-0800	2012-09-12T04:12:12-0700	"{{{
Loading package array-0.3.0.2 ... linking ... done.
Loading package containers-0.4.0.0 ... linking ... done.
Loading package safe-0.3.3 ... ghc: panic! (the 'impossible' happened)
  (GHC version 7.0.3 for i386-unknown-mingw32):
	loadObj ""C:\\Documents and Settings\\\1042\1083\1072\1076\1099\1082\1072\\Application Data\\cabal\\safe-0.3.3\\ghc-7.0.3\\HSsafe-0.3.3.o"": failed
}}}

Before that I installed package Safe using cabal."	guest
3	7610	Cross compilation support for LLVM backend	Compiler (LLVM)	7.6.1	normal		7.8.1	dterei	new	2013-01-19T23:25:45-0800	2013-04-12T15:56:50-0700	"Top level bug to track supporting cross compilation in LLVM backend.

Mostly this shouldn't be too bad but I haven't tried it and know of at least a few significant issues."	dterei
3	7621	Cross-build for QNX ARM smashes stack when using FunPtr wrappers	Compiler (FFI)	7.7	normal		7.8.1		new	2013-01-24T06:41:37-0800	2013-03-24T15:30:07-0700	"I have built an unregistered LLVM cross-compiler for arm-unknown-nto-qnx8.0.0eabi, which I finally got to build using the attached patch.  Simple programs no longer crash like they do in registered ARM cross-compilers (as reported on mailing list at http://www.haskell.org/pipermail/ghc-devs/2013-January/000005.html and other places), however the following code does crash:

{{{
{-# LANGUAGE ForeignFunctionInterface #-}
module Main (main) where

import Foreign.Ptr

foreign import ccall ""wrapper"" wrap_refresh :: ( IO ()) -> IO (FunPtr ( IO ()))

main :: IO ()
main = do
	wrap_refresh (return ())
	return ()
}}}

It seems, from experiments, that any code using the ""wrapper"" imports causes this error:

{{{
$ ./Main
*** stack smashing detected ***: Main terminated
Abort (core dumped)
}}}"	singpolyma
4	3782	"Data Parallel ""Impossible happened"" compiler error"	Data Parallel Haskell	6.12.1	low		7.6.2	benl	new	2009-12-23T13:41:17-0800	2012-10-14T20:28:18-0700	"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
5	2450	Data.Complex.magnitude squares using ^(2 :: Int), which is slow	libraries/base	6.8.3	lowest	normal	7.6.2		new	2008-07-18T05:22:03-0700	2012-09-12T04:13:59-0700	"Data.Complex.magnitude squares using `^(2 :: Int)`, which is slow. Either it should use `sqr x = x * x` or a rule should rewrite `e ^ (2 :: Int)` to do so (or perhaps both; the RULE for general cases, and the manual `sqr` for hugs etc).

More detail in this thread:
http://www.haskell.org/pipermail/haskell-cafe/2008-July/045327.html
"	igloo
3	5412	dataTypeConstrs gives unhelpful error message	libraries/base	7.1	normal		7.6.2		new	2011-08-13T02:22:58-0700	2012-09-12T04:12:03-0700	"Take the following program:

{{{
import Data.Data
foo = dataTypeConstrs (dataTypeOf (0 :: Int))
-- raises: *** Exception: Data.Data.dataTypeConstrs
}}}

The implementation of {{{dataTypeConstrs}}} has the type available as a string at this point, so could easily say:

{{{
Exception: Data.Data.dataTypeConstrs is not supported for Int, 
           as it is not an algebraic data type
}}}"	NeilMitchell
2	6098	debugger does not know the correct type for a newtype field	GHCi	7.5	high		7.8.1		new	2012-05-15T09:13:19-0700	2012-11-17T09:17:57-0800	"This bug is in 7.4.1. I think it was also in 7.0.3. It is also in the current head:[[BR]]
commit 921530b477867edb5158e4ad5bbbdb5c7c531c97[[BR]]
Date:   Tue May 15 10:32:58 2012 +0100

Here is the console log. Notice that the type of allItems is resolved as TWrapper but it should be [Int]. Expressions in conditional breakpoints are failing because of this.


{{{
18:06 tm=3:2 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib
1035> cat bindings-bug.hs
newtype TWrapper = Wrapper
  { mItems :: [Int]
  } deriving Show

main = print $ test $ Wrapper [1]

test Wrapper{ mItems = allItems } = id $
  let headItem = head allItems in
  headItem

18:06 tm=0 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib
1036> ../../ghc/stage2/build/tmp/ghc-stage2 -B. --interactive bindings-bug.hs
GHCi, version 7.5.20120515: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main             ( bindings-bug.hs, interpreted )
Ok, modules loaded: Main.
*Main> :break 7 37
Breakpoint 0 activated at bindings-bug.hs:(7,37)-(9,10)
*Main> :main 
Stopped at bindings-bug.hs:(7,37)-(9,10)
_result :: Int = _
allItems :: TWrapper = _
[bindings-bug.hs:(7,37)-(9,10)] *Main> :list
6  
                                     vv
7  test Wrapper{ mItems = allItems } = id $
8    let headItem = head allItems in
9    headItem
             ^^
10  
[bindings-bug.hs:(7,37)-(9,10)] *Main> head allItems

<interactive>:5:6:
    Couldn't match expected type `[a0]' with actual type `TWrapper'
    In the first argument of `head', namely `allItems'
    In the expression: head allItems
    In an equation for `it': it = head allItems
[bindings-bug.hs:(7,37)-(9,10)] *Main> :continue 
1
*Main> :quit 
Leaving GHCi.
18:06 tm=42 st=0 peter@phnm ~/haskell/ghc-working/inplace/lib
1037> 
}}}
"	phercek
3	1530	debugging :steps inside TH spliced code need to be bypassed	GHCi	6.7	normal	normal	_|_		new	2007-07-13T04:13:25-0700	2013-01-22T16:06:56-0800	See test dynbrk005 for an example	mnislaih
3	5949	Demand analysis attributes manifestly wrong demand type	Compiler	7.4.1	normal		7.8.1		new	2012-03-16T15:45:28-0700	2012-09-27T04:51:50-0700	"(Further to my email to Simon, adding to bug tracker so it doesn't get lost)

Consider:

{{{
e :: (Int, Int) -> Int -> (Int, Int)
e x y = x `seq` if y > 10
        then x
        else e x (y + 1)
}}}

After worker/wrapper we get:

{{{
Rec {
CPR2.$we [Occ=LoopBreaker]
 :: (GHC.Types.Int, GHC.Types.Int)
    -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #)
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType S(AA)L,
 Unf=OtherCon []]
CPR2.$we =
 \ (w_srv :: (GHC.Types.Int, GHC.Types.Int))
   (ww_srt :: GHC.Prim.Int#) ->
   case GHC.Prim.># ww_srt 10 of _ {
     GHC.Types.False ->
       case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT ->
       CPR2.$we w_srv sat_ssS
       };
     GHC.Types.True ->
       case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) }
   }
end Rec }
}}}

The demand type S(AA) is entirely wrong because the box is unused (so it should be U(AA)) and because the two components are not absent -- they are used.

This leads to the worker/wrapper transformation being insufficiently agressive. This bites in practice with examples like:

{{{
d :: M.Map Int Int -> (Int, Int)
d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else
(b, a)) (0, 1) m
}}}

Which generates this inner loop:

{{{
Rec {
CPR2.$wgo2 [Occ=LoopBreaker]
 :: (GHC.Types.Int, GHC.Types.Int)
    -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int
    -> (# GHC.Types.Int, GHC.Types.Int #)
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType S(AA)S,
 Unf=OtherCon []]
CPR2.$wgo2 =
 \ (w_srS :: (GHC.Types.Int, GHC.Types.Int))
   (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) ->
   case w1_srQ of _ {
     Data.Map.Base.Tip ->
       case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) };
     Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 ->
       case kx_ss3 of _ { GHC.Types.I# x1_ssd ->
       case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) ->
       case x_ssa of _ { GHC.Types.I# y_sse ->
       case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT ->
       case GHC.Prim.># sat_st0 2 of _ {
         GHC.Types.False ->
           let {
             sat_ssZ :: (GHC.Types.Int, GHC.Types.Int)
             [LclId]
             sat_ssZ = (ww2_ssh, ww1_ssi) } in
           CPR2.$wgo2 sat_ssZ l_ssk;
         GHC.Types.True ->
           let {
             sat_st6 :: (GHC.Types.Int, GHC.Types.Int)
             [LclId]
             sat_st6 = (ww1_ssi, ww2_ssh) } in
           CPR2.$wgo2 sat_st6 l_ssk
       }
       }
       }
       }
       }
   }
end Rec }
}}}

Note that it allocates a pair every go around the loop. If we just ran the demand analyser on this code again we could eliminate this allocation, but the demand analyser shouldn't be generating code which has these manifest problems.

One way to fix this is to change the ending of dmdTransform to read:

{{{
   if isTopLevel top_lvl
    then fn_ty -- Don't record top level things
    else case dmd of
           Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty,
returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd))
           _
     -> addVarDmd fn_ty var dmd
}}}

But this is a hack. Better suggestions welcome."	batterseapower
3	7436	Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion	Compiler	7.6.1	normal		7.6.3		merge	2012-11-21T04:23:18-0800	2013-04-16T08:55:15-0700	"The following program:

{{{
{-# LANGUAGE DeriveFunctor, DeriveFoldable #-}
import Prelude hiding (foldr)
import Data.Foldable

data List a = Nil | Cons a (List a)
    deriving (Functor, Foldable)

mkList :: Int -> List Int
mkList 0 = Nil
mkList n = Cons n (mkList (n-1))

main :: IO ()
main = print $ foldr (\x y -> y) ""end"" (mkList n)
  where n = 100000
}}}

Takes `n^2` time to run with GHC 7.6.1 -O2.

The generated `Foldable` code looks something like this:

{{{
instance Foldable List where
    foldr f z Nil = z
    foldr f z (Cons x xs) = f x (foldr (\a b -> f a b) z xs)
}}}

Eta-reducing the function, i.e.

{{{
instance Foldable List where
    foldr f z Nil = z
    foldr f z (Cons x xs) = f x (foldr f z xs)
}}}

Makes the program linear in `n` (in this case, runtime goes from 8.160s to 0.004s).

The `Traversable` instance also has the same issue.

There seem to be three different issues:

 * Derived `Foldable` and `Traversable` instances are nearly unusable for large structures.

 * An eta-expanded definition like `foldr` becomes asymptotically worse for some reason. Maybe this is expected behavior for this function, since `f` gets eta-expanded at each iteration?

 * `Foldable` instances are generated with `foldr` instead of `foldMap`.

This isn't directly related, since the code would have the same problem either
way, but since I'm already writing about it... `foldMap` can allow
asymptotically better operations on a structure than `foldr` (for example,
finding the rightmost leaf of a binary tree using `Data.Monoid.Last`), so it
should probably be generated instead. A `foldMap` definition should look like a
simpler version of `traverse`, which is already derivable. Maybe this should be
a separate ticket."	shachaf
3	1544	Derived Read instances for recursive datatypes with infix constructors are too inefficient	Compiler	6.6.1	normal	normal	7.6.2		new	2007-07-17T22:24:51-0700	2013-01-23T08:21:50-0800	"Consider this definition:
{{{
data Exp = C | Exp :+: Exp | Exp :-: Exp deriving ( Read, Show )
}}}
Now, try something like:
{{{
> read ""((((((((((C))))))))))"" :: Exp
}}}
Even this simple expression may take several seconds to parse. It gets worse if you keep adding parenthesis. And even worse if you add more infix constructors...."	jcpetruzza@…
4	4896	Deriving Data does not work for attached code	Compiler	7.1	low		7.6.2		new	2011-01-17T04:14:11-0800	2012-09-12T04:13:23-0700	"I get the following error when I try to derive `Data` for the attached code:

{{{
Main.hs:17:66:
    Couldn't match expected type `Bar (D a b)'
                with actual type `t' a1 b1'
    Expected type: Maybe (c (Bar (D a b)))
      Actual type: Maybe (c (t' a1 b1))
    In the expression: gcast2 f
    In an equation for `dataCast2': dataCast2 f = gcast2 f
}}}
"	mitar
2	5642	Deriving Generic of a big type takes a long time and lots of space	Compiler	7.3	high		7.6.2	dimitris	new	2011-11-16T17:59:06-0800	2013-04-05T22:14:39-0700	"If I load the following module into `ghci` my system will run out of memory after about 15 minutes: 

{{{
{-# LANGUAGE DeriveGeneric #-}

import GHC.Generics

data BigSum = 
    C0   |  C1  | C2   | C3   | C4   | C5   | C6   | C7   | C8   | C9 
  | C10  | C11  | C12  | C13  | C14  | C15  | C16  | C17  | C18  | C19 
  | C20  | C21  | C22  | C23  | C24  | C25  | C26  | C27  | C28  | C29
  | C30  | C31  | C32  | C33  | C34  | C35  | C36  | C37  | C38  | C39
  | C40  | C41  | C42  | C43  | C44  | C45  | C46  | C47  | C48  | C49
  | C50  | C51  | C52  | C53  | C54  | C55  | C56  | C57  | C58  | C59
  | C60  | C61  | C62  | C63  | C64  | C65  | C66  | C67  | C68  | C69
  | C70  | C71  | C72  | C73  | C74  | C75  | C76  | C77  | C78  | C79
  | C80  | C81  | C82  | C83  | C84  | C85  | C86  | C87  | C88  | C89
  | C90  | C91  | C92  | C93  | C94  | C95  | C96  | C97  | C98  | C99
  | C100 | C101 | C102 | C103 | C104 | C105 | C106 | C107 | C108 | C109
  | C110 | C111 | C112 | C113 | C114 | C115 | C116 | C117 | C118 | C119
  | C120 | C121 | C122 | C123 | C124 | C125 | C126 | C127 | C128 | C129
  | C130 | C131 | C132 | C133 | C134 | C135 | C136 | C137 | C138 | C139
  | C140 | C141 | C142 | C143 | C144 | C145 | C146 | C147 | C148 | C149
  | C150 | C151 | C152 | C153 | C154 | C155 | C156 | C157 | C158 | C159
  | C160 | C161 | C162 | C163 | C164 | C165 | C166 | C167 | C168 | C169
  | C170 | C171 | C172 | C173 | C174 | C175 | C176 | C177 | C178 | C179
  | C180 | C181 | C182 | C183 | C184 | C185 | C186 | C187 | C188 | C189
  | C190 | C191 | C192 | C193 | C194 | C195 | C196 | C197 | C198 | C199
  | C200 | C201 | C202 | C203 | C204 | C205 | C206 | C207 | C208 | C209
  | C210 | C211 | C212 | C213 | C214 | C215 | C216 | C217 | C218 | C219
  | C220 | C221 | C222 | C223 | C224 | C225 | C226 | C227 | C228 | C229
  | C230 | C231 | C232 | C233 | C234 | C235 | C236 | C237 | C238 | C239
  | C240 | C241 | C242 | C243 | C244 | C245 | C246 | C247 | C248 | C249
  | C250 | C251 | C252 | C253 | C254 | C255 | C256 | C257 | C258 | C259
  | C260 | C261 | C262 | C263 | C264 | C265 | C266 | C267 | C268 | C269
  | C270 | C271 | C272 | C273 | C274 | C275 | C276 | C277 | C278 | C279
  | C280 | C281 | C282 | C283 | C284 | C285 | C286 | C287 | C288 | C289
  | C290 | C291 | C292 | C293 | C294 | C295 | C296 | C297 | C298 | C299
   deriving Generic
}}}

Big products have the same problem:

{{{
data BigProduct = C 
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    deriving Generic
}}}
"	basvandijk
4	4185	Deriving higher-arity instances for newtype family instances fails	Compiler	6.12.3	low		7.6.2	simonpj	new	2010-07-12T10:47:28-0700	2013-04-15T06:37:10-0700	"
{{{
{-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving #-}
module Baz where

class Bar f where
	bar :: f a -> Int

data family Foo k :: * -> *

instance Bar Maybe where
	bar Nothing = 0
	bar Just{} = 1

newtype instance Foo Int a = FooInt (Maybe a) deriving (Bar)
}}}
fails with


{{{
Baz.hs:13:56:
    Derived instance `Bar (Foo Int)'
      requires illegal partial application of data type family Foo
    In the newtype instance declaration for `Foo'
}}}

Attempting to use StandaloneDeriving:

{{{
{-# LANGUAGE StandaloneDeriving, TypeFamilies, GeneralizedNewtypeDeriving #-}
module Baz where

class Bar f where
	bar :: f a -> Int

data family Foo k :: * -> *

instance Bar Maybe where
	bar Nothing = 0
	bar Just{} = 1

newtype instance Foo Int a = FooInt (Maybe a)

deriving instance Bar (Foo Int)
}}}

gives the super-weird error

{{{

Baz.hs:15:0:
    No family instance for `Foo Int'
    In the stand-alone deriving instance for `Bar (Foo Int)'
}}}

"	LouisWasserman
4	4019	deriving Ord can produce incorrect and inefficient instances	Compiler	6.13	low		7.6.2		new	2010-04-26T08:52:54-0700	2012-09-12T04:12:23-0700	"This bug was spotted by Barak Pearlmutter in http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html.

{{{
data T = T Double deriving( Eq, Ord )

*Main> T (0/0) > T (0/0)
True
*Main> (0/0) > (0/0)
False
}}}

This happens because the derived Ord instance only defines compare and relies on default method definitions for everything else. Comparisons involving !NaNs always return False, however, compare (arbitrarily) returns GT in this case.

Irrespective of this particular wart, this is what GHC ultimately produces for (<=):

{{{
T.$fOrdT_$c<= =
  \ (x_ahF :: T.T) (y_ahG :: T.T) ->
    case x_ahF of _ { T.T a1_afL ->
    case y_ahG of _ { T.T b1_afM ->
    case a1_afL of _ { GHC.Types.I# x#_ah1 ->
    case b1_afM of _ { GHC.Types.I# y#_ah5 ->
    case GHC.Prim.<# x#_ah1 y#_ah5 of _ {
      GHC.Bool.False -> GHC.Prim.==# x#_ah1 y#_ah5;
      GHC.Bool.True -> GHC.Bool.True
    }
    }
    }
    }
    }
}}}

Note that the definition uses two comparisons even though (<=) for Double uses just one: (<=##). In general, relying on default method definitions when deriving Ord can be inefficient because the individual comparison operators might very well be faster than compare for the wrapped types."	rl
5	2530	deriving Show adds extra parens for constructor with record syntax	Compiler	6.8.3	lowest	normal	7.6.2		new	2008-08-21T09:49:59-0700	2013-02-17T12:55:42-0800	"Since record construction binds more tightly than function application, no parentheses are needed when passing a constructor with record syntax to a function constructor. As a result, we can pass {{{Just A {x = 5}}}} as shown below.

{{{
module Main where

data A = A {x :: Int} deriving (Show)

main :: IO ()
main = print $ Just A {x = 5}
}}}

But we get the result in the GHCi session below:

{{{
*Main> main
Just (A {x = 5})
}}}

I tried looking through {{{TcGenDeriv}}}, but didn't figure out quite where the parenifying was done. {{{nested_compose_Expr}}}? {{{show_thingies}}}?

I just wanted to make a ticket for general knowledge. Of course, this is not a real bug. Perhaps you could reclassify it as a feature. Either way, it would be nice to have."	spl
3	5863	Deriving Typeable for data families	Compiler	7.4.1	normal		7.6.2		new	2012-02-10T03:20:50-0800	2012-09-12T04:12:11-0700	"Bas points out that `deriving Typeable` for data families isn't right at all.
{{{
{-# LANGUAGE DeriveDataTypeable, TypeFamilies #-}

import Data.Typeable

class C a where
    data T a :: *

instance C Int where
    data T Int = A1 deriving (Typeable)

instance C Bool where
    data T Bool = A2 deriving (Typeable)
}}}
gives this error:
{{{
TF_Data.hs:12:34:
    Duplicate instance declarations:
      instance Typeable1 T -- Defined at TF_Data.hs:12:34
      instance Typeable1 T -- Defined at TF_Data.hs:15:34
}}}
The real problem is that we should have only one instance for `Typeable T`.  We should only allow 
{{{
deriving instance Typeable1 T
}}}
and prohibit `deriving Typeable` on `data instance` declarations."	simonpj
2	7229	Detecting if a process was killed by a signal is impossible	libraries/process		high		7.8.1		new	2012-09-07T12:24:44-0700	2012-11-17T09:47:34-0800	"Currently there is no good way of detecting if a process was terminated by a signal. We have the following problems:

 * Firstly, the API doesn't make any allowance for it. This may be because the concept doesn't exist on Windows, I'm not sure. But since the concept ''does'' exist on POSIX, we do have to make a decision about what to do there (or if we have made one, document it).
 * `waitForProcess` attempts to give the signal in the exit code, but the underlying C function doesn't use the `WTERMSIG` macro. It so happens that on my system it works fine anyway, but it has no ''right'' to in principle (and in any case, what it does is both sub-optimal (in that getting killed by SIGINT is indistinguishable from returning 3) and undocumented).
 * The C function `getProcessExitCode` is much worse. When a process has exited due to a signal, it tests `WIFSIGNALED`, and if true, sets `errno = EINTR` (huh?) and returns `-1`. Since it is called from `throwErrnoIfMinus1Retry`, the result is that it immediately gets called again: but this time the child doesn't exist anymore. The behaviour in the case of `ECHILD` is, bizarrely, to pretend that there was a child and it exited with status 0, i.e. success. Which is just untrue.

I don't know what the right behaviour is, but the above is both inconsistent and unhelpful. The lack of `WTERMSIG` is easily fixed, but that's the least of the problems here: we really need to work out what ''ought'' to happen before we start making it happen."	benmachine
5	3034	divInt# floated into a position which leads to low arity	Compiler	6.10.1	lowest	normal	7.6.2		new	2009-02-18T01:36:04-0800	2012-09-12T04:14:07-0700	"Tyson Whitehead saw this in the Core output of one of his programs compiled using the MTL StateT:

{{{
$wdigit_s1GR [ALWAYS LoopBreaker Nothing] :: GHC.Prim.Int#
                                           -> GHC.Types.Int
                                           -> Control.Monad.State.Strict.StateT
                                                GHC.Types.Int
                                                (Control.Monad.Error.ErrorT
                                                   GHC.Base.String
                                                   Control.Monad.Identity.Identity)
                                                (GHC.Types.Int, GHC.Types.Int)
[Arity 1
Str: DmdType L]
$wdigit_s1GR =
\ (ww_X1H6 :: GHC.Prim.Int#) ->
  let {
    lvl_s1H5 [ALWAYS Just D(T)] :: GHC.Types.Int
    [Str: DmdType]
    lvl_s1H5 =
      case GHC.Prim.-# 2147483647 ww_X1H6 of wild2_a1xs [ALWAYS Just L] {
        __DEFAULT ->
          case GHC.Base.divInt# wild2_a1xs 10
          of wild21_a1xt [ALWAYS Just L] { __DEFAULT ->
          GHC.Types.I# wild21_a1xt
          };
        (-2147483648) -> lvl_s1Ha
      } } in
  (\ (eta_X1nK :: GHC.Types.Int) (eta_s1Dl :: GHC.Types.Int) ->
     case eta_s1Dl
     of y_XrP [ALWAYS Just A] { GHC.Types.I# ipv_s19d [ALWAYS Just L] ->
     case GHC.Prim.<=# ipv_s19d 214748363
     of wild_a19h [ALWAYS Dead Just A] {
       GHC.Bool.False ->
         case lvl_s1H5
         of wild1_X1zB [ALWAYS Just A]
         { GHC.Types.I# y_X1zG [ALWAYS Just L] ->
         case GHC.Prim.<=# ipv_s19d y_X1zG
         of wild_X1z [ALWAYS Dead Just A] {
           GHC.Bool.False ->
             a_s1Hk
             `cast` (right
}}}

This REALLY SHOULD have arity 3 because that allows:
 * More worker/wrapper
 * Less sharing of trivial partial applications elsewhere in his program

Here is my reply to him, explaining why it all happens:

{{{
Yes - GHC wants to share the work of (maxBound-x)`div`10 between
several partial applications of ""digit"". This is usually a good idea,
but in this case it sucks because it's resulted in a massively
increased arity. IMHO GHC should fix this by:
* Marking divInt# INLINE in the base library. This would result in
your code would just containing uses of quotInt#
* Making some operations cheap even if they may fail
(PrimOp.primpOpIsCheap should change). Though this might mean that we
turn non-terminating programs into terminating ones (such operations
get pushed inside lambdas) but this is consistent with our treatment
of lambdas generally.

Actually, your divInt# call wouldn't even usually be floated out to
between two lambdas, but at the time FloatOut runs there is something
in between the \x lambda and the lambdas from the state monad - the
monadic bind operator! So FloatOut feels free to move the computation
for ""x"" up even though that >>= will go away as soon as we run the
simplifier. What a disaster!
}}}

So one of FloatOut and primOpIsCheap probably needs to be fixed.

I've attached a program that can reproduce this issue."	batterseapower
5	2940	Do CSE after CorePrep	Compiler	6.10.1	lowest	normal	7.6.2	simonpj	new	2009-01-12T04:07:10-0800	2012-09-12T04:14:05-0700	"Common sub-expression analysis is deliberately conservative, but it's really ''too'' conservative: we are missing obvious opportunities.  Consider
{{{
{-# OPTIONS_GHC -XBangPatterns -XMagicHash #-}

module Foo where

import GHC.Base

-- CorePrep evaluates (reverse xs) twice
f xs = let !v1 = reverse (reverse xs)
       	   !v2 = filter id (reverse xs)
       in (v1, v2)

-- Even CSE inside CorePrep would not get this right;
-- the strict evaluation of (reverse xs) doesn't scope
-- over the non-strict version
g xs = reverse (reverse xs) ++ filter id (reverse xs)


-- Duplicate evaluation of (x +# 1#)
h :: Int# -> ( Int, Int )
h x = ( I# (x +# 1#), I# ((x +# 1#) *# 2#) )
}}}
If you compile this you'll see that there are obvious missed CSE opportunities in `f`, `g` and `h`; but they only show up after `CorePrep`.  

I guess the right thing is to CSE after `CorePrep`, but then CSE would have to maintain the `CorePrep` invariants, which isn't trivial.  Something to think about.

Simon"	simonpj
4	5202	Docs on strictness info out of date	Documentation	7.0.3	low		7.6.2		new	2011-05-17T18:28:51-0700	2012-09-12T04:13:29-0700	"http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/faster.html section “How do I find out a function's strictness?”

The one inaccuracy I noticed is that we no longer output P for primitive (primitive types seem to be confusingly given L!); I believe the docs are a hold-over from the old strictness analyzer. Someone better acquainted with the strictness analyzer should give it a lookover."	ezyang
5	2776	Document -pgmL (Use cmd as the literate pre-processor)	Documentation	6.10.1	lowest	minor	7.6.2		new	2008-11-12T20:34:00-0800	2012-09-12T04:14:04-0700	"The GHC option -pgmL (Use cmd as the literate pre-processor) is undocumented, and behaves differently than -pgmF (Use cmd as the pre-processor).

While one can count on the first three arguments to a -pgmF command giving file names, with optional arguments coming later, the ''last'' three arguments to a -pgmL command give the file names. An undocumented ""-h"" argument always comes ''before'' these file arguments, throwing off any command designed according to the documentation for -pgmF. Moreover, an optional argument provided using -opL comes ''before'' any of these arguments.

The undocumented ""-h"" reminds me of the passage in Real World Haskell, how only one reasonable program could have type ""(a, b) -> a"", because there isn't enough information to do anything clever. Here, GHC wants the -pgmL command to emit standard Haskell, but for all it knows, the literate program is in Swahili. GHC isn't really in a good position to be offering advice via options on this conversion, because it has no idea what conversion is taking place. So the ""-h"" is inexplicable.

Also, the example command in GHC manual section 5.10.4. doesn't use argument $1, and probably wants to use $1 rather than $2 for the echo, if in fact it is possible to create circumstance where $1 and $2 differ."	Syzygies
4	4861	Documentation for base does not include special items	libraries/base	7.0.1	low		7.6.2		new	2010-12-24T03:26:59-0800	2012-09-12T04:13:23-0700	"The documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.

For tuples, the documentation for base doesn't include them in either Prelude or Data.Tuple, but the documentation for ghc-prim includes them in GHC.Unit and GHC.Tuple. I think the lack of documentation for tuple types is a bug, since it would be relatively easy for them to be documented, and does make the documentation more complete.

For lists ([], (:)), there is no documentation in either base or ghc-prim. It would be nice if they were documented in Prelude and Data.List, but not if it was too much effort (I can imagine that Haddock can't accept list definitions).

For the arrow type ->, it's unclear if it can reasonably be documented, so it might be worth thinking about but probably not bothering to document.

The reason I'm interested in ensuring complete documentation is that Hoogle currently doesn't know about tuple constructors in the base library, but it does know about them in ghc-prim, which seems wrong."	NeilMitchell
3	5466	Documentation for Chan could be better	libraries/base	7.2.1	normal		_|_		new	2011-09-06T21:10:45-0700	2011-11-23T09:55:09-0800	The summary is two words, and none of the operations say whether they block or not. Someone on reddit was expecting a read to throw an exception if the Chan was empty, for example. It also turns out that isEmptyChan is deprecated, but the documentation doesn't mention it.	pumpkin
3	7460	Double literals generated bad core	Compiler	7.4.2	normal		7.8.1	tibbe	new	2012-11-29T12:52:59-0800	2013-04-12T13:36:22-0700	"The following code results in core containing expression like `doubleFromInteger (wordToInteger sc_s2pw)`:

{{{
{-# LANGUAGE CPP, BangPatterns #-}
module Main (main) where

#define VDIM 100
#define VNUM 100000

import Data.Array.Base
import Data.Array.ST
import Data.Array.Unboxed
import Control.Monad.ST
import GHC.Word
import Control.Monad
import Data.Bits

prng :: Word -> Word
prng w = w'
  where
    !w1 = w `xor` (w `shiftL` 13)
    !w2 = w1 `xor` (w1 `shiftR` 7)
    !w' = w2 `xor` (w2 `shiftL` 17)

type Vec s = STUArray s Int Double

kahan :: Vec s -> Vec s -> ST s ()
kahan s c = do
    let inner w j
            | j < VDIM  = do
                !cj <- unsafeRead c j
                !sj <- unsafeRead s j
                let !y = fromIntegral w - cj
                    !t = sj + y
                    !w' = prng w
                unsafeWrite c j ((t-sj)-y)
                unsafeWrite s j t
                inner w' (j+1)
            | otherwise = return ()
        outer i | i < VNUM = inner i 0 >> outer (i + 1)
                | otherwise = return ()
    outer 0

calc :: ST s (Vec s)
calc = do
    s <- newArray (0,VDIM-1) 0
    c <- newArray (0,VDIM-1) 0
    kahan s c
    return s

main :: IO ()
main = print . elems $ runSTUArray calc
}}}"	tibbe
3	3081	Double output after Ctrl+C on Windows	Runtime System	6.10.1	normal	normal	_|_		new	2009-03-09T02:52:21-0700	2011-03-16T04:00:33-0700	"{{{
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
4	3903	"DPH bad sliceP causes RTS panic ""allocGroup: requested zero blocks"""	Data Parallel Haskell	6.13	low		7.6.2	benl	new	2010-03-01T00:47:36-0800	2012-10-14T20:28:31-0700	"{{{
$ ghci -XPArr
...
Prelude> :m GHC.PArr
Prelude GHC.PArr> sliceP 10 10 [::]
<interactive>: internal error: allocGroup: requested zero blocks
    (GHC version 6.12.1 for i386_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort trap
}}}

`sliceP 10 10 [::]` is bogus. This should have been picked up in the libraries before hitting the RTS assertion.

"	benl
3	5807	DPH library functions don't work without -fvectorise.	Data Parallel Haskell	7.2.2	normal		7.6.2	benl	new	2012-01-22T16:58:29-0800	2012-10-14T20:27:37-0700	"
Mukesh Tiwari reports:

{{{
ghci>import Data.Array.Parallel
ghci>import Data.Array.Parallel.PArray 
ghci>let u = Data.Array.Parallel.PArray.fromList [ 1 .. 10 ]
ghci>:t u
u :: PArray Double
ghci>u
fromList<PArray> [1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0]
ghci>let v = Data.Array.Parallel.fromPArrayP u
ghci>:t v
v :: [:Double:]
ghci>lengthP v
0
}}}"	benl
3	7091	DPH Matrix product memory usage	Data Parallel Haskell	7.4.1	normal		7.8.1	benl	new	2012-07-22T07:46:34-0700	2012-10-14T20:52:50-0700	"This report is from the post at Haskell-cafe ""DPH matrix product"", I'm reporting it here so developers can define if it's a bug or not and its priority.

On a (I think) standar implementation of matrix product on DPH I notice an excessive use of system memory.
At execution time, on matrices of size 300*300 the program does finish (although it is very slow), but on 600*600 it consumes GBs of RAM until the process is aborted.

This is the system information:

- Ubuntu 12.04 32-bit

- Intel® Core™2 Duo CPU T5270 @ 1.40GHz × 2 

- 2.9 GiB RAM

GHC version:

- GHC 7.4.1

DPH libraries:

- dph-base-0.6.1.1

- (dph-lifted-base-0.6.1.1)

- (dph-lifted-vseg-0.6.1.2)

- (dph-prim-interface-0.6.1.1)

- (dph-prim-par-0.6.1.1)

- (dph-prim-seq-0.6.1.1)

Compilation flags:

I'm using two combinations of flags, taken from different sources. In both cases results are identical:

- From https://github.com/ghc/packages-dph: -rtsopts -threaded -fllvm -optlo-O3 -Odph -fcpr-off -fno-liberate-case -package dph-lifted-vseg

- From dph-examples: -rtsopts -threaded -fllvm -Odph -package dph-lifted-vseg -fcpr-off -fno-liberate-case -fsimpl-tick-factor=1000

Execution flags:

+RTS -N

Tests:

- Computing the product of two 400*400 matrices takes 6.037993 seconds. 

- Computing the product of two 600*600 matrices yields ""out of memory (requested 1728053248 bytes)"". 

DPH code:

{{{
{-# LANGUAGE ParallelArrays, ParallelListComp #-}

{-# OPTIONS -fvectorise #-}

module DPH_mmult_wrapper (matMult_wrapper, Matrix_wrapper) where

import qualified Prelude

import Data.Array.Parallel

import Data.Array.Parallel.Prelude.Double as D

import Data.Array.Parallel.Prelude.Int as I

type MMultType = Double

type Matrix = [:[:MMultType:]:]

type MVector = [:MMultType:]

type Matrix_wrapper = PArray (PArray MMultType)

-- matMult_wrapper assumes mB is already transposed

{-# NOINLINE matMult_wrapper #-}

matMult_wrapper :: Matrix_wrapper -> Matrix_wrapper -> Matrix_wrapper

matMult_wrapper mA mB = toPArrayP (mapP toPArrayP (matMult (fromNestedPArrayP mA) (fromNestedPArrayP mB)))

matMult :: Matrix -> Matrix -> Matrix

matMult mA mB = mapP (\row -> mapP (\col -> dotp row col) mB) mA

dotp :: MVector -> MVector -> MMultType

dotp row col = D.sumP (zipWithP (D.*) row col)
}}}

I'm reporting this as I think it is the kind of problems intended to be solved in the last definition of the internal DPH structure (the one from ""Work Efficient Higher-Order Vectorisation"" paper).

If there is any information missing, please comment and I will update the report.

Thanks.
"	mblanco
3	6004	dph-lifted-vseg package doesn't provide Data.Array.Parallel.Prelude.Float module	Data Parallel Haskell	7.4.1	normal		7.8.1	benl	new	2012-04-13T11:08:15-0700	2012-10-14T20:27:48-0700	"dph-lifted-copy package and old dph-par package provide Data.Array.Parallel.Prelude.Float module.

 * http://hackage.haskell.org/package/dph-lifted-copy
 * http://hackage.haskell.org/package/dph-par

But dph-lifted-vseg package doesn't provide Data.Array.Parallel.Prelude.Float module, now.

 * http://hackage.haskell.org/package/dph-lifted-vseg-0.6.1.2"	shelarcy
2	7834	dyn way and INTEGER_LIBRARY=integer-simple	Compiler	7.7	high		7.8.1	igloo	new	2013-04-13T14:51:34-0700	2013-04-24T19:43:43-0700	"a standard bootstrap with
{{{
perl boot
./configure
make INTEGER_LIBRARY=integer-simple
}}}
causes some problems:
  1. there is a panic (at least when `-j4`) ""fromJust..."" (which strangely disappears on the second attempt)
  2. `__word_encode{Float|Double}` is not found by the linker. There are `__int_encode{Float|Double}` symbols available, though, and changing the source helps for linking, but not for correctness, obviously.

I'll add specific details (if not trivially reproducible) as soon as I am back at my dev machine.

The bottom line is that since GHC HEAD now builds the 'dyn' way by default, this kind of bootstrap always fails. Normally not a problem on desktop linux, but in combination with a gmp-less embedded linux and cross-compiling it becomes annoying."	heisenbug
2	5620	Dynamic linking and threading does not work on Windows	Runtime System	7.2.1	high		7.6.2	igloo	new	2011-11-10T03:19:24-0800	2013-04-06T22:33:10-0700	"On Windows, compile this module:
{{{
main = print 42
}}}
With this command:
{{{
ghc --make -threaded -dynamic Main.hs
}}}
Run, and watch it segfault.
"	Lennart
3	7665	dynamicToo001 fails on Windows	Compiler	7.7	normal		7.8.1	igloo	new	2013-02-05T12:07:02-0800	2013-04-13T04:05:27-0700	"`dynamicToo001` fails on Windows:
{{{
=====> dynamicToo001(normal) 1 of 1 [0, 0, 0]
cd . && $MAKE -s --no-print-directory dynamicToo001    </dev/null >dynamicToo001.run.stdout 2>dynamicToo001.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
Makefile:12: recipe for target `dynamicToo001' failed

Stderr:
A001.dyn_o:fake:(.text+0x2e): undefined reference to `__imp_stg_CAF_BLACKHOLE_info'
A001.dyn_o:fake:(.text+0x5f): undefined reference to `__imp_newCAF'
A001.dyn_o:fake:(.text+0x72): undefined reference to `__imp_stg_bh_upd_frame_info'
A001.dyn_o:fake:(.text+0x87): undefined reference to `__imp_ghczmprim_GHCziTypes_Czh_con_info'
c:/ghc64/git/cygwin/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: A001.dyn_o: bad reloc address 0x0 in section `.data'
c:/ghc64/git/cygwin/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [dynamicToo001] Error 1
}}}
"	igloo
3	5786	Dynanmic way fails when GHC built with LLVM backend	Compiler (LLVM)	7.4.1-rc1	normal		7.6.2	dterei	new	2012-01-16T18:30:06-0800	2012-09-12T04:12:08-0700	If I build GHC with the LLVM backend then the 'Dyn' testsuite way fails completely (tested on x64).	dterei
4	4140	dynHelloWorld(dyn) fails in an unreg build	Compiler	6.12.3	low		7.6.2		new	2010-06-17T14:50:54-0700	2012-09-12T04:12:25-0700	"In an unregisterised build, `dynHelloWorld(dyn)` is failing: there is nothing on stdout when output is redirected to a file.

It looks like `GHC.TopHandler.cleanUp` is flushing the wrong `stdout`.
"	igloo
3	7669	Empty case causes warning	Compiler	7.7	normal		7.8.1		new	2013-02-06T11:23:49-0800	2013-04-13T04:19:03-0700	"The following code

{{{
{-# LANGUAGE EmptyCase #-}
{-# OPTIONS_GHC -fwarn-incomplete-patterns #-}
data Void

foo :: Void -> ()
foo x = case x of {}
}}}

causes this warning

{{{
/Users/rae/temp/Scratch.hs:6:9: Warning:
    Pattern match(es) are non-exhaustive
    In a case alternative: Patterns not matched:
Ok, modules loaded: Main.
}}}"	goldfire
3	3134	encodeFloat . decodeFloat	Prelude	6.10.1	normal	normal	_|_		new	2009-03-31T12:56:05-0700	2010-10-14T06:34:08-0700	"> (0.0/0.0)
NaN

> (uncurry encodeFloat . decodeFloat) (0.0/0.0)
-Infinity

It seems reasonable to expect NaN here."	roland
3	7800	Error message when deriving Typeable without PolyKinds	Compiler	7.7	normal		7.8.1	dreixel	new	2013-03-29T03:48:00-0700	2013-04-13T07:27:28-0700	"Module M:

{{{
{-# LANGUAGE PolyKinds #-}
module M where

data A a
}}}

Module N:

{{{
{-# LANGUAGE StandaloneDeriving, DeriveDataTypeable #-}
module N where

import M
import Data.Typeable

deriving instance Typeable A
}}}

We get a confusing error message:

{{{
N.hs:7:1:
    Derived typeable instance must be of form (Typeable A)
    In the stand-alone deriving instance for ‛Typeable A’
}}}

The error disappears when N is compiled with -XPolyKinds. The reason is: without -XPolyKinds, A defaults to A *. I think it's simplest to suggest the flag in the error message."	monoidal
3	7461	"Error messages about ""do"" statements contain false information"	Compiler (Type checker)	7.6.1	normal		7.8.1		new	2012-11-29T16:49:08-0800	2013-04-12T13:39:13-0700	"When GHC complains about a type-error in a ""do"" block, it says, for example:

{{{
main = putChar $ do
  getLine
  return 'x'
}}}

Results in an error:

{{{
    Couldn't match type `IO Char' with `Char'
    Expected type: IO String -> IO Char -> Char
      Actual type: IO String -> IO Char -> IO Char
    In a stmt of a 'do' block: getLine
}}}

I think this error message is pretty directly saying: The '''Actual''' type of ""getLine"" is:

{{{
IO String -> IO Char -> IO Char
}}}

But that is of course non-sense! It is actually talking about the type of the (>>=) binding the ""getLine"" to the rest of the statements.  But the (>>=) is not ""in the statement"" at all, so the error message is plainly wrong.

It would be much better to talk about the type of the entire do block, or maybe the type of the last stmt in the do block (which is the same).

For example, the error could be replaced by:

{{{
    Couldn't match type `IO Char' with `Char'
    Expected type: Char
      Actual type: IO Char
    In a stmt of a 'do' block: return 'x'
}}}

Or by:

{{{
    Couldn't match type `IO Char' with `Char'
    Expected type: Char
      Actual type: IO Char
    In 'do' block: `do { getLine;
                         return 'x' }'
}}}
"	EyalLotem
3	7849	Error on pattern matching of an existential whose context includes a type function	Compiler (Type checker)	7.4.2	normal				new	2013-04-19T21:41:26-0700	2013-04-22T05:53:15-0700	"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 <- readIORef (obs_subjects obs)
      writeIORef (obs_subjects obs) []
      mapM_ (\ (ASubj subj) -> 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
2	7830	Error: operand out of range	Compiler	7.7	high		7.8.1		new	2013-04-12T16:40:23-0700	2013-05-10T15:23:01-0700	"Compiling on linux-powerpc and linux-powerpc64 I get:

{{{
""inplace/bin/ghc-stage1"" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall \
   -H64m -O0    -package-name time-1.4.0.2 -hide-all-packages -i -ilibraries/time/.  \
   -ilibraries/time/dist-install/build -ilibraries/time/dist-install/build/autogen \
   -Ilibraries/time/dist-install/build -Ilibraries/time/dist-install/build/autogen \
   -Ilibraries/time/include   -optP-DLANGUAGE_Rank2Types -optP \
   DLANGUAGE_DeriveDataTypeable -optP-DLANGUAGE_StandaloneDeriving -optP-include \
   -optPlibraries/time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 \
   -package deepseq-1.3.0.2 -package old-locale-1.0.0.5 -Wall -XHaskell2010 -XRank2Types \
   -XDeriveDataTypeable -XStandaloneDeriving -XCPP -O2 -O -dcore-lint \
   -fno-warndeprecated-flags  -no-user-package-db -rtsopts -fno-warn-unused-do-bind \
   -fno-warn-deprecations -fno-warn-unused-imports -fno-warn-identities     -odir \
   libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir \ 
   libraries/time/dist-install/build  -dynamic-too -c libraries/time/./Data/Time/Format.hs \
   -o libraries/time/dist-install/build/Data/Time/Format.o -dyno \
   libraries/time/dist-install/build/Data/Time/Format.dyn_o
/tmp/ghc2806_0/ghc2806_1.s: Assembler messages:

/tmp/ghc2806_0/ghc2806_1.s:51766:0:
     Error: operand out of range (0x000000000000adf8 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51798:0:
     Error: operand out of range (0x000000000000ad90 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51830:0:
     Error: operand out of range (0x000000000000ad28 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51908:0:
     Error: operand out of range (0x000000000000ac1c is not between 0xffffffffffff8000 and 0x0000000000007fff)
}}}

"	erikd
3	5443	Errors when shutting down the event manager loop	Compiler	7.2.1	normal		7.6.2	tibbe	new	2011-08-31T00:33:35-0700	2012-09-12T04:12:03-0700	"As explained in [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/20573 this thread on the GHC list] I use the GHC event manager in my [https://github.com/basvandijk/usb usb library]. I create my own `EventManager` and start a thread which runs the event manager loop. When the library is finalized I automatically shutdown the loop. However this causes error messages from the RTS to be printed.

The following program shows the problem in isolation:
 
{{{
import Control.Concurrent
import GHC.Event

main = do
 em <- new
 tid <- forkIO $ loop em
 threadDelay 2000000
 shutdown em  -- Note that 'killThread tid' has the same effect.
 threadDelay 2000000
}}}

Make sure to build it with `-threaded` enabled:

`$ ghc -threaded --make eventManagerBug.hs`

Running it gives the following errors:

{{{
$ ./eventManagerBug
example: ioManagerWakeup: write: Bad file descriptor
example: ioManagerDie: write: Bad file descriptor
}}}

Note that these errors are printed in the `ioManagerWakeup` function in `rts/posix/Signals.c`."	basvandijk
3	7259	Eta expansion of products in System FC	Compiler	7.6.1	normal		7.8.1	simonpj	new	2012-09-21T02:18:06-0700	2012-10-16T14:06:33-0700	"This ticket is to capture the ideas in these GHC-users threads: [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-August/022790.html PolyKinds Aug 2012] and [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-September/thread.html PolyKinds Sept 2012]

 * We want to add eta-rules to FC.  Sticking to pairs for now, that would amount to adding two new type functions (Fst, Snd), and three new, built-in axioms
{{{
	axPair k1 k2 (a:'(k1,k2)) : a ~ '(Fst a, Snd a)
	axFst k1 k2 (a:k1) (b:k2) : Fst '(a,b) ~ a
	axSnd k1 k2 (a:k1) (b:k2) : Snd '(a,b) ~ a
}}}
  Generalising to arbitrary products looks feasible.

 * Adding these axioms would make FC inconsistent, because 
{{{
	axPair * * (Any '(*,*) ) : Any '(*,*) ~ (Fst .., Snd ..)
}}}
  and that has two different type constructors on each side.  However, I think is readily solved: see below under ""Fixing Any""

 * Even in the absence of Any, it's not 100% obvious that adding the above eta axioms retains consistency of FC.  I believe that Richard is volunteering to check this out.  Right, Richard?

== Type inference ==

I'm a little unclear about the implications for inference.  One route might be this.   Suppose we are trying to solve a constraint
{{{
     [W]  (a:'(k1,ks)) ~ '( t1, t2 )
}}}
where a is an untouchable type variable.  (if it was touchable we'd simply unify it.)  Then we can replace it with a constraint
{{{
    [W]   '(Fst a, Snd a) ~ '( t1, t2)
}}}
Is that it?  Or do we need more?  I'm a bit concerned about constraints like
{{{
    F a ~ e
}}}
where `a:'(k1,k2)`, and we have a type instance like  `F '(a,b) = ...`

Anything else?

I don't really want to eagerly eta-expand every type variable, because (a) we'll bloat the constraints and (b) we might get silly error messages.  For (b) consider the insoluble constraint
{{{
    [W]  a~b
}}}
where `a` and `b` are both skolems of kind `'(k1,k2)`. If we eta-expand both we'll get two insoluble constraints `(Fst a ~ Fst b)` and `(Snd a ~ Snd b)`, and we DEFINITELY don't want to report that as a type error!

Someone pointed out that Agda grapples with this problem and we should talk to them.


== Fixing Any ==

 * I think we can fix the Any problem readily by making Any into a type family, that has no instances.   We certainly allow equalities with a type '''family''' application on the left and a type constructor on the right.

 I have implemented this change already... it seems like a good plan.
	
 * Several people have asked why we need Any at all.  Consider this source program
{{{
         reverse []
}}}
  At what type should we instantiate `reverse` and the empty list `[]`?  Any type will do, but we must choose one; FC doesn't have unbound type variables. So I instantiate it at `(Any *)`:
{{{
         reverse (Any *) ([] (Any *))
}}}
  Why is Any poly-kinded?  Because the above ambiguity situation sometimes arises at other kinds.

 * I'm betting that making Any into a family will mess up Richard's (entirely separate) use of `(Any k)` as a proxy for a kind argument `k`; because now `(Any k1 ~ Any k2)` does not entail `(k1~k2)`. See also the module `GHC.TypeLits` in `base`.  

 We can't solve this by making `Any` to be an ''injective'' type family, because the use in `TypeLits` uses it in a type-class instance, and you can't match on type families!
"	simonpj
1	7382	Evaluating GHCi expressions is slow following the dynamic-by-default change	GHCi	7.7	highest		7.8.1		new	2012-11-01T12:36:49-0700	2012-11-29T11:44:22-0800	In GHC 7.7.20121101 it takes at least half a second for any GHCi expression to get evaluated. This seems to be caused by the system linker redundantly running during the evaluation of an expression.	parcs
2	4144	Exception: ToDo: hGetBuf - when using custom handle infrastructure	libraries/base	7.6.1	high		7.8.1	simonmar	patch	2010-06-20T20:47:09-0700	2013-01-20T22:08:32-0800	"When trying to use the custom handle infrastructure, hGetContents fails like so:

*** Exception: ToDo: hGetBuf

This exception occurs twice in GHC.IO.Handle.Text

The handle implementation I'm using is attached.

It would be neat if I could pass along some witness that my device implements RawDevice, then we could just run the same code that we use for file-descriptors. But I'd be happy enough with a general solution, as I just plan to use this for testing."	AntoineLatter
2	7411	Exceptions are optimized away in certain situations	Compiler	7.6.1	high		7.8.1		new	2012-11-13T05:38:23-0800	2013-04-12T11:40:47-0700	"The issue came up in [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-November/023027.html this thread on glasgow-haskell-users].

== Steps to reproduce: ==

{{{
-- file Foo.hs
import Control.Exception
import Control.DeepSeq
main = evaluate (('a' : undefined) `deepseq` return () :: IO ())
}}}
{{{
$ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs
}}}

=== Expected result: ===
The program should fail with:
{{{
Foo: Prelude.undefined
}}}

=== Actual result: ===

The program succeeds.

Compiling the program with {{{-fno-state-hack}}} helps."	SimonHengel
3	3628	exceptions reported to stderr when they propagate past forkIO	libraries/base	6.10.4	normal	normal	_|_		new	2009-10-30T09:14:34-0700	2009-11-06T03:49:48-0800	"It's not entirely obvious what to do with exceptions that do not get handled within a `forkIO` however reporting them on stderr (or on Windows popping up a message dialog) does not seem right.

We do not have other cases where errors are logged to stderr. The only such case is an exception terminating Main.main (and that's special because it terminates the whole process). If it is vital that someone do something with exceptions in forkIO threads then they should be propagated to another thread, in the worst case the main thread."	duncan
3	7666	excessive space and time usage for rendering (somewhat) deeply nested Docs	libraries/pretty	7.6.2	normal		7.8.1	dterei	new	2013-02-06T02:35:46-0800	2013-04-13T04:12:33-0700	"I was running into serious performance problems when printing moderately sized Doc and Xml data (HaXml goes via Doc).

Since pretty is shipped with ghc, this is potentially dangerous. Users will just assume that these core components are tried and tested, and working efficiently. 

More info: 
http://article.gmane.org/gmane.comp.lang.haskell.cafe/103210

See also:
http://stackoverflow.com/questions/9761507/which-pretty-print-library

Test case (builds an Xml tree with HaXml and renders it via the pretty library):
https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs
"	j.waldmann
3	5840	Extend the supported environment sizes of vectorised closures	Data Parallel Haskell	7.4.1	normal		7.6.2	chak	new	2012-02-02T10:52:02-0800	2012-09-12T04:12:10-0700	"{{{
ghc: panic! (the 'impossible' happened)
  (GHC version 7.2.1 for i386-apple-darwin):
	VectMonad.lookupFamInst: not found: 
    dph-par:Data.Array.Parallel.PArray.PData.PData{tc r4u}
      (ghc-prim:GHC.Types.Int{(w) tc 3J},
       ghc-prim:GHC.Types.Int{(w) tc 3J},
       dph-par:Data.Array.Parallel.PArray.Base.PArray{tc r1}
         (ghc-prim:GHC.Types.Int{(w) tc 3J},
          ghc-prim:GHC.Types.Int{(w) tc 3J},
          ghc-prim:GHC.Types.Double{(w) tc 3u}),
       ghc-prim:GHC.Types.Int{(w) tc 3J},
       ghc-prim:GHC.Types.Int{(w) tc 3J}
       dph-par:Data.Array.Parallel.Lifted.Closure.:->{tc r2} (ghc-prim:GHC.Types.Int{(w) tc 3J}
                                                              dph-par:Data.Array.Parallel.Lifted.Closure.:->{tc r2} ghc-prim:GHC.Types.Int{(w) tc 3J}),
       ghc-prim:GHC.Types.Int{(w) tc 3J})

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
"	mukesh.tiwari
3	4372	Extending quasiquotation support	Template Haskell	6.12.3	normal		7.6.2		new	2010-10-06T03:16:02-0700	2012-09-12T04:12:00-0700	"Gershom Bazerman (gershomb@gmail.com) writes: Attached is an experimental patch (not read for prime-time) that extends quasiquotation syntax. At the moment, quasiquoters can only be single identifiers of type `QuasiQuoter` (and of course declared outside the current module). This patch allows an entire expression of type `QuasiQuoter` in the quoter position. The staging restriction is extended to all free variables in the quasiquoter expression.

So if `qq1 :: Int -> QuasiQuoter`, one can now write `[$qq1 12 | ... |]`

This syntax would be quite useful for my own project (jmacro), and from discussions at ICFP, to others who also are beginning to take serious advantage of quasiquotation.

Here's one use case. Suppose jmt is a `QuasiQuoter` which returns both a parsed Javascript expression and its ""module signature"" (or ""typing environment"" if you prefer). Then, one can pass that typing environment directly into another quasiquoter in a different module, so that further code can be typechecked at compile-time with functions defined in the first quasiquote available to the Javascript typechecker. This style of programming is currently possible, but it requires defining additional new modules which contain `QuasiQuoters` parameterized with each successive typing environment.

There are a number of tricky choices made in this patch, not all of which are perhaps correct.

First, currently, the quoter and quotation are lexed and parsed as a single token. To avoid reinvoking the lexer and/or parser, now '[$' is lexed as one token, and a flag is set in the lexer state which lexes the `|...|]` (i.e. the quotation) as a single quotation on encountering the first vbar. This means that guards can't be used inside a quasiquoter expression -- i.e. `[$let x | True = 1 in qq1 x|..|]` would fail to parse. This also means that while now in ghc 7, one can write `[qq|..]`, to parse a full expression rather than identifier, we need the dollar sign as well.

The former problem (stealing guards within quasiquoter expressions) can be fixed by a syntax change which moves from a single vbar to a new symbol (perhaps `$|` or `||` ?) to signal the transition between the quoter expression and the quote itself. I tend to feel that the loss of guards within quasiquoter expressions is not too painful, however. Adding a new symbol between quoter and quotee also would simplify the necessary changes to the lexer, removing the need to set a special flag in the lexer state.

The second problem (need to reintroduce a dollar) is somewhat irritating, but not terribly so. One could either introduce the dollar in all cases, which allows simplifying the lexer and parser, or keep the dollarless syntax as well for single identifiers, which adds both complexity and duplicate syntax, but keeps the default case especially lightweight.

The patch as it stands introduces ""extended quasiquotations"" as an orthogonal change that doesn't affect the existing quasiquotation machinery, and, at the moment, only allows for quasiquotations of expressions (i.e., not patterns, etc.).

If there is sentiment that this is useful and could be accepted, modulo whatever requested tweaks, I'd be happy to do whatever work is necessary -- implementing changes, adding documentation, pushing the changes through to quasiquoters in other positions, etc.
"	simonpj
2	7068	Extensive Memory usage (regression)	Compiler	7.4.1	high		7.8.1	simonpj	new	2012-07-11T07:32:21-0700	2012-08-20T03:25:11-0700	"The ""bling raytracer"" project [1] can not be compiled with recent GHC versions (personally tested 7.4.1 on Linux / OS X / Windows, that 7.4.2 fails in the same way was reported on IRC).

The problem is that when compiling the ""Transform.hs"" source file [2] GHC allocates more RAM than any of my machines can bear (8+ GB).

This does not happen with 7.0.x versions of GHC. Also, reducing the optimization level from O2 to O1 makes the problem go away. To reproduce this bug I'd recommend

> hg clone -r eb0f7f91bde6 https://code.google.com/p/bling-raytracer/
> cabal build

There was no consensus on IRC if this is really a GHC bug or I should simply tinker with the GHC options / source file until it works. But since the code in question does not use any obscure extensions (in fact, no extensions at all) and could be compiled with many GHC versions from 6.4 onward, I thought you might want to hear about it.

[1] http://code.google.com/p/bling-raytracer/
[2] http://code.google.com/p/bling-raytracer/source/browse/src/Graphics/Bling/Transform.hs?r=9499d979762ddcbc1ff31aea053dfcf3d4590a08
"	waldheinz
3	670	External Core is broken	External Core	6.8.2	normal	blocker	_|_	tim	new	2006-01-24T23:49:12-0800	2011-08-28T16:58:42-0700	"{{{
$ ghc -fext-core Main.hs
$ ghc -fglasgow-exts Main.hcr
ghc-6.5: panic! (the `impossible' happened, GHC version 6.5):
	tcIfaceGlobal (local): not found:
    Main.main{v rrl}
    []

Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
}}}

Main.hs consists of:
{{{ main = putStr ""Hello world!"" }}}

I'll fix this myself if I still have commit access; I just want to have a record of it."	KirstenChevalier
3	5630	External Core needs love	Compiler	7.2.1	normal		7.6.2		new	2011-11-13T00:04:33-0800	2012-09-12T04:12:06-0700	"{{{
{-# LANGUAGE GADTs #-}

data T a b where
  T1 :: a -> b -> T [a] (a,b)
  
main = putStrLn "":(""
}}}

and then ""ghc this.hs -fext-core""
results in

{{{
>ghc core-sandbox.hs -fext-core
ghc core-sandbox.hs -fext-core
[1 of 1] Compiling Main             ( core-sandbox.hs, core-sandbox.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.2.1 for i386-unknown-mingw32):
	make_exp (App _ (Coercion _))

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
"	quux
3	7903	Failure to find class instance specified with extra parentheses	Compiler	7.6.3	normal				new	2013-05-10T10:47:20-0700	2013-05-15T09:09:44-0700	"The following two-line program fails to compile under GHC 7.6.3 and compiles fine with GHC 7.4.1:

{{{
instance Eq (((->) a) b)
instance (Ord b) => Ord (((->) a) b)
}}}

Error message:

{{{
    Could not deduce (Eq (a -> b))
      arising from the superclasses of an instance declaration
    from the context (Ord b)
}}}
Compilation goes through if I tweak the {{{Eq}}} instance to use ""{{{((->) a b)}}}"" or ""{{{(a -> b)}}}"" in place of ""{{{(((->) a) b)}}}"".

"	conal
3	3971	FFI callback segfaults on PPC	Compiler (FFI)	6.12.3	normal		_|_		new	2010-04-09T09:50:49-0700	2011-04-10T16:30:24-0700	"ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:

{{{
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
   Cabal-1.8.0.3
   QuickCheck-2.1.0.3
   array-0.3.0.0
   base-3.0.3.2
   base-4.2.0.1
   bin-package-db-0.0.0.0
   binary-0.5.0.2
   bytestring-0.9.1.6
   containers-0.3.0.0
   directory-1.0.1.1
   Segmentation fault
}}}

(Now, trying to install zlib, I also get:
{{{
 ./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p
Configuring zlib-0.5.2.0...
Setup: failed to parse output of 'ghc-pkg dump'
}}}
although I can see nothing wrong with the output of 'ghc-pkg dump' &mdash; reported under [http://hackage.haskell.org/trac/hackage/ticket/599 Bug 559 in the Cabal trac].)

Wolfram"	wkahl
4	5387	ffi/should_run fptr02 fails on OS X amd64	Compiler	7.3	low		7.6.2		new	2011-08-06T12:43:40-0700	2012-09-12T04:13:33-0700	"
`ffi/should_run fptr02` fails for me on OS X amd64:

{{{
{-# LANGUAGE ForeignFunctionInterface #-}

module Main where

import Foreign
import Control.Monad

foreign import ccall ""&free"" pfree :: FunPtr (Ptr a -> IO ())

main = replicateM_ 1000000 $ newForeignPtr pfree nullPtr
}}}

{{{
$ '/Users/ian/ghc/git/val64/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts  -o fptr02 fptr02.hs -debug
[1 of 1] Compiling Main             ( fptr02.hs, fptr02.o )
Linking fptr02 ...
$ gdb fptr02
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type ""show copying"" to see the conditions.
There is absolutely no warranty for GDB.  Type ""show warranty"" for details.
This GDB was configured as ""x86_64-apple-darwin""...Reading symbols for shared libraries ... done 

(gdb) r +RTS -DS
Starting program: /Users/ian/ghc/git/val64/testsuite/tests/ffi/should_run/fptr02 +RTS -DS
Reading symbols for shared libraries ++. done
created capset 0 of type 2
assigned cap 0 to capset 0

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000000100b042c0
0x0000000100b042c0 in ?? ()
(gdb) bt
#0  0x0000000100b042c0 in ?? ()
#1  0x000000010031ba4b in scheduleFinalizers (cap=0x1003cd380, list=0x100bfe070) at rts/Weak.c:107
#2  0x0000000100321926 in GarbageCollect (force_major_gc=rtsFalse, do_heap_census=rtsFalse, gc_type=0, cap=0x1003cd380) at rts/sm/GC.c:656
#3  0x0000000100311a75 in scheduleDoGC (cap=0x1003cd380, task=0x1009003c0, force_major=rtsFalse) at rts/Schedule.c:1448
#4  0x0000000100310c6a in schedule (initialCapability=0x1003cd380, task=0x1009003c0) at rts/Schedule.c:547
#5  0x00000001003122bb in scheduleWaitThread (tso=0x100b05390, ret=0x0, cap=0x1003cd380) at rts/Schedule.c:1939
#6  0x0000000100308d54 in rts_evalLazyIO (cap=0x1003cd380, p=0x100392a30, ret=0x0) at rts/RtsAPI.c:494
#7  0x000000010030b3d0 in real_main () at rts/RtsMain.c:63
#8  0x000000010030b4c3 in hs_main (argc=3, argv=0x7fff5fbff860, main_closure=0x100392a30) at rts/RtsMain.c:111
#9  0x0000000100001480 in start ()
(gdb) up
#1  0x000000010031ba4b in scheduleFinalizers (cap=0x1003cd380, list=0x100bfe070) at rts/Weak.c:107
107                 runCFinalizer((void *)farr->payload[0],
(gdb) p farr
$1 = (StgArrWords *) 0x100bd6ae0
(gdb) p (void *)farr->payload[0]
$2 = (void *) 0x100b042c0
(gdb) p4 0x100b042c0
0x100b042d8:    0xaaaaaaaaaaaaaaaa
0x100b042d0:    0xaaaaaaaaaaaaaaaa
0x100b042c8:    0xaaaaaaaaaaaaaaaa
0x100b042c0:    0xaaaaaaaaaaaaaaaa
(gdb) p4 0x100bd6ae0
0x100bd6af8:    0x0
0x100bd6af0:    0x100b042c0
0x100bd6ae8:    0x20
0x100bd6ae0:    0x100337018 <stg_ARR_WORDS_info>
}}}
"	igloo
4	4105	ffi005 fails on OS X	Compiler	6.12.2	low		7.6.2		new	2010-05-29T11:43:57-0700	2012-09-12T04:12:24-0700	"The ffi005 test is failing on OS X x86.

The test is only run the optc way, but we get other bad results when compiling in other ways.

normal:
{{{
{-# LANGUAGE ForeignFunctionInterface #-}

import Control.Monad
import Foreign.C

main :: IO ()
main = doit sin mysin (encodeFloat 7926335344172077 (-54))

doit :: (CDouble -> CDouble) -> (CDouble -> CDouble) -> CDouble -> IO ()
doit f g x = do let fx = f x
                    gx = g x
                when (fx /= gx) $ do print x
                                     print (decodeFloat x)
                                     print fx
                                     print gx
                                     print (fx - gx)

foreign import ccall ""sin"" mysin :: CDouble -> CDouble
}}}
{{{
$ ghc q.hs -o q; ./q
0.4400000000000002
(7926335344172077,-54)
0.4259394650659998
0.42593946506599983
-5.551115123125783e-17
}}}
optc:
{{{
{-# LANGUAGE ForeignFunctionInterface #-}

import Control.Monad
import Foreign
import Foreign.C

main :: IO ()
main = do sin_addr <- wrapId sin
          doit sin (dyn_sin sin_addr) (encodeFloat 7926335344172077 (-54))
          freeHaskellFunPtr sin_addr

doit :: (CDouble -> CDouble) -> (CDouble -> CDouble) -> CDouble -> IO ()
doit f g x = do let fx = f x
                    gx = g x
                when (fx /= gx) $ do print x
                                     print (decodeFloat x)
                                     print fx
                                     print gx
                                     print (fx - gx)

foreign import ccall ""wrapper"" wrapId :: (CDouble -> CDouble) -> IO (FunPtr (CDouble -> CDouble))
foreign import ccall ""dynamic"" dyn_sin :: FunPtr (CDouble -> CDouble) -> (CDouble -> CDouble)
}}}
{{{
$ ghc w.hs -o w -fvia-c -O; ./w
0.4400000000000002
(7926335344172077,-54)
0.42593946506599983
0.4259394650659998
5.551115123125783e-17
}}}
optasm:
{{{
{-# LANGUAGE ForeignFunctionInterface #-}

import Control.Monad
import Foreign
import Foreign.C

main :: IO ()
main = do sin_addr <- wrapId sin
          doit sin (dyn_sin sin_addr) (encodeFloat 7926335344172077 (-54))
          freeHaskellFunPtr sin_addr

doit :: (CDouble -> CDouble) -> (CDouble -> CDouble) -> CDouble -> IO ()
doit f g x = do let fx = f x
                    gx = g x
                when (fx /= gx) $ do print x
                                     print (decodeFloat x)
                                     print fx
                                     print gx
                                     print (decodeFloat fx)
                                     print (decodeFloat gx)
                                     print (fx == gx)
                                     print (decodeFloat fx == decodeFloat gx)
                                     print (fx - gx)

foreign import ccall ""wrapper"" wrapId :: (CDouble -> CDouble) -> IO (FunPtr (CDouble -> CDouble))
foreign import ccall ""dynamic"" dyn_sin :: FunPtr (CDouble -> CDouble) -> (CDouble -> CDouble)
}}}
{{{
$ ghc r.hs -o r -O; ./r
0.4400000000000002
(7926335344172077,-54)
0.4259394650659998
0.4259394650659998
(7673043264614500,-54)
(7673043264614500,-54)
False
True
0.0
}}}
"	igloo
4	2161	finaliser of a ForeignPtr called while references from unreachable threads exist	Runtime System	6.8.2	low	major	7.6.2		new	2008-03-16T20:54:03-0700	2012-09-12T04:12:15-0700	"I believe that I've managed to distill a crash which has been driving
me crazy for a few days into a short enough test case (22 lines) that
it might be useful.

In short: the threaded RTS will call the finialiser of a ForeignPtr
while an exception handler still holds a reference to it:

{{{
% ghc -make fptest.hs cbits.c -threaded
[1 of 1] Compiling Main             ( fptest.hs, fptest.o )
Linking fptest ...
% ./fptest
New object getting created: 66f010
Finaliser getting called for 66f010
Use called for 66f010

}}}

I'm hoping that this is useful to someone who knows the RTS.

Cheers,"	agl
4	4833	Finding the right loop breaker	Compiler	7.0.1	low		7.6.2		new	2010-12-10T07:11:35-0800	2012-09-12T04:13:22-0700	"This ticket reports a DPH-related optimisation problem.  

Two files are attached. `Repr.hs` defines the type families and classes:

 * `PR` is the class which defines basic operations (`rep` for replication and `idx` for indexing). It has only a fixed number of instance.  

 * `PRepr a` is the representation type of `a`. It must be an instance of `PR`

 * `PA` is the class which defines conversions to and from representation types; all vectorised user-defined types are instances of `PA`

 * `repPA` is an example of a generic operation: we convert the argument to its representation type, perform the PR operation on it and convert it back

 * `Wrap` is a representation type which simply wraps a `PA` type; `instance PA (a,b)` is an example of how it is used

In `Dict.hs`, we define the recursive type `S` and its `PA` instance which basically looks exactly like what the vectoriser would generate. Note that we don't have to define a `PR` instance which is the whole point. This all works but if we look at the Core, we see that the `PA` dictionary of `S` is recursive:
{{{
Dict.$fPAS =
  Repr.D:PA
    @ Dict.S
    ($dPR_ad1 `cast` ...)
    $ctoPRepr_acn
    $cfromPRepr_acq
    $ctoArrPRepr_act
    $cfromArrPRepr_acG

$dPR_ad5 :: Repr.PR (Repr.Wrap Dict.S)
$dPR_ad5 = Repr.$fPRWrap @ Dict.S Dict.$fPAS

$dPR_ad1 [Occ=LoopBreaker]
  :: Repr.PR (GHC.Types.Double, Repr.Wrap Dict.S)
$dPR_ad1 =
  Repr.$fPR(,)
    @ GHC.Types.Double @ (Repr.Wrap Dict.S) Repr.$fPRDouble $dPR_ad5
}}}
Note that `$dPR_ad1` is a loop breaker. This means that foo in Dict.hs can't be optimised properly:
{{{
Dict.foo =
  \ (s_ac0 :: Dict.S) (n_ac1 :: GHC.Types.Int) ->
    case (Repr.rep
            @ (Repr.PRepr Dict.S)
            ($dPR_ad1 `cast` ...)
            n_ac1
            (case s_ac0 of _ { Dict.S x_ac2 y_ac3 ->
             (x_ac2,
              y_ac3 `cast` ...) `cast` ...
             })) `cast` ...
    of _ { Repr.P2 xs_ac8 ds_ddJ ->
    case ds_ddJ `cast` ...
    of _ { Repr.PWrap ys_ac9 ->
    (Dict.PS xs_ac8 ys_ac9) `cast` ...
    }
    }
}}}
The `(rep $dPR_ad1)` call can't be resolved even though we know what it is. This is actually due to an unfortunate choice of loop breaker: $dPR_ad5 would work much better here. In general, we would perhaps like to say that we always want to pick PR (Wrap t) dictionaries as loop breakers in such cases.

Although what we'd really like is for foo itself to become a recursive function which can't happen with the current set up. I might have an idea how to do this but I need to think a bit more about it.
"	simonpj
2	7772	Finish support for DYNAMIC_GHC_PROGRAMS on Windows	Compiler	7.7	high		7.8.1	igloo	new	2013-03-15T16:22:53-0700	2013-03-15T16:22:53-0700	"Finish support for `DYNAMIC_GHC_PROGRAMS` on Windows.

{{{
#include <stdarg.h>
#include <stdio.h>
#include <Windows.h>
#include <Shlwapi.h>

#include ""Rts.h""

LPTSTR path_dirs[] = {
    TEXT(""libraries/haskeline/dist-install/build""),
    TEXT(""compiler/stage2/build""),
    TEXT(""ghc/stage2/build/tmp""),
    TEXT(""libraries/transformers/dist-install/build""),
    TEXT(""libraries/template-haskell/dist-install/build""),
    TEXT(""libraries/hpc/dist-install/build""),
    TEXT(""libraries/hoopl/dist-install/build""),
    TEXT(""libraries/bin-package-db/dist-install/build""),
    TEXT(""libraries/binary/dist-install/build""),
    TEXT(""libraries/Cabal/Cabal/dist-install/build""),
    TEXT(""libraries/process/dist-install/build""),
    TEXT(""libraries/pretty/dist-install/build""),
    TEXT(""libraries/directory/dist-install/build""),
    TEXT(""libraries/time/dist-install/build""),
    TEXT(""libraries/old-locale/dist-install/build""),
    TEXT(""libraries/filepath/dist-install/build""),
    TEXT(""libraries/Win32/dist-install/build""),
    TEXT(""libraries/containers/dist-install/build""),
    TEXT(""libraries/bytestring/dist-install/build""),
    TEXT(""libraries/deepseq/dist-install/build""),
    TEXT(""libraries/array/dist-install/build""),
    TEXT(""libraries/base/dist-install/build""),
    TEXT(""libraries/integer-gmp/dist-install/build""),
    TEXT(""libraries/ghc-prim/dist-install/build""),
    TEXT(""rts/dist/build""),
    NULL
};

void die(char *fmt, ...) {
    va_list argp;

    fprintf(stderr, ""error: "");
    va_start(argp, fmt);
    vfprintf(stderr, fmt, argp);
    va_end(argp);
    fprintf(stderr, ""\n"");

    exit(1);
}

void setPath(void) {
    LPTSTR *dir;
    LPTSTR path;
    int n;
    int len = 0;
    LPTSTR exePath, s;
    HMODULE hExe;

    hExe = GetModuleHandle(NULL);
    if (hExe == NULL) {
        die(""GetModuleHandle failed"");
    }
    exePath = malloc(10000); // XXX
    GetModuleFileName(hExe, exePath, 10000); // XXX
    for(s = exePath; *s != '\0'; s++) {
        if (*s == '\\') {
            *s = '/';
        }
    }
    s = StrRChr(exePath, NULL, '/');
    if (s == NULL) {
        die(""No directory separator in executable path: %s"", exePath);
    }
    s[0] = '\0';
    n = s - exePath;

    for (dir = path_dirs; *dir != NULL; dir++) {
        len += n + 7/* /../../ */ + lstrlen(*dir) + 1/* semicolon */;
    }
    len++; // NUL

    path = malloc(10000); // XXX
    s = path;
    for (dir = path_dirs; *dir != NULL; dir++) {
        StrCpy(s, exePath);
        s += n;
        StrCpy(s, ""/../../"");
        s += 7;
        StrCpy(s, *dir);
        s += lstrlen(*dir);
        s[0] = ';';
        s++;
    }
    s[0] = '\0';

    if (! SetEnvironmentVariable(TEXT(""PATH""), path)) {
        printf(""SetEnvironmentVariable failed (%d)\n"", GetLastError());
    }
}

HINSTANCE loadDll(LPTSTR dll) {
    HINSTANCE h;
    DWORD dw;
    LPVOID lpMsgBuf;

    h = LoadLibrary(dll);

    if (h == NULL) {
        dw = GetLastError();
        FormatMessage(
            FORMAT_MESSAGE_ALLOCATE_BUFFER |
            FORMAT_MESSAGE_FROM_SYSTEM |
            FORMAT_MESSAGE_IGNORE_INSERTS,
            NULL,
            dw,
            MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
            (LPTSTR) &lpMsgBuf,
            0, NULL );
        die(""loadDll failed: %d: %s\n"", dw, lpMsgBuf);
    }

    return h;
}

void *GetNonNullProcAddress(HINSTANCE h, char *sym) {
    void *p;

    p = GetProcAddress(h, sym);
    if (p == NULL) {
        die(""Failed to find address for %s"", sym);
    }
    return p;
}

HINSTANCE GetNonNullModuleHandle(LPTSTR dll) {
    HINSTANCE h;

    h = GetModuleHandle(dll);
    if (h == NULL) {
        die(""Failed to get module handle for %s"", dll);
    }
    return h;
}

typedef int (*hs_main_t)(int , char **, StgClosure *, RtsConfig);

int main(int argc, char *argv[]) {
    void *p;
    HINSTANCE hRtsDll, hProgDll;

    StgClosure *main_p;
    RtsConfig *rts_config_p;
    hs_main_t hs_main_p;

    setPath();

    // hRtsDll = loadDll(TEXT(""libHSrts_debug-ghc7.7.20130315.dll""));
    // hRtsDll = loadDll(TEXT(""libHSrts_thr-ghc7.7.20130315.dll""));
    // hRtsDll = loadDll(TEXT(""libHSrts-ghc7.7.20130315.dll""));
    hProgDll = loadDll(TEXT(""ghc-stage2.exe.dll""));
    hRtsDll = GetNonNullModuleHandle(TEXT(""libHSrts-ghc7.7.20130315.dll""));

    hs_main_p    = GetNonNullProcAddress(hRtsDll,  ""hs_main"");
    rts_config_p = GetNonNullProcAddress(hRtsDll,  ""defaultRtsConfig"");
    main_p       = GetNonNullProcAddress(hProgDll, ""ZCMain_main_closure"");

    return hs_main_p(argc, argv, main_p, *rts_config_p);
}
}}}

Gives:
{{{
Segmentation fault/access violation in generated code
}}}
"	igloo
3	7858	Fix definitions of abs/signum for Floats/Doubles	libraries/base	7.6.3	normal				new	2013-04-22T20:38:29-0700	2013-04-22T20:38:29-0700	"The current definition of abs doesn't work correctly for -0.0 (negative zero); and the signum function doesn't return NaN on NaN. The issue is discussed in detail in the following thread:

   http://www.haskell.org/pipermail/libraries/2013-April/019677.html

To summarize, the proposal is to change both the Float and Double instance definitions for signum/abs as follows:

{{{
    signum x 
         | x == 0    = x
         | isNaN x   = x
         | x > 0     = 1
         | otherwise = negate 1
    abs x    
         | isNegativeZero x = 0
         | x >= 0           = x
         | otherwise        = negate x
}}}

Simon PJ expressed interest in taking advantage of the underlying platforms floating-point instructions when available to speed things up, and the above referenced thread has some discussion regarding how this might be done. However, it might be best to start with a ""correct"" implementation first, and then later worry about speed.

On a related note, this ""bug"" is actually present in the Haskell'98 standard definition itself, which seems to have overlooked NaN's and negative-0's. It'd be great if the standard got a similar amendment as well."	lerkok
3	5996	fix for CSE	Compiler	7.5	normal		7.8.1	simonpj	patch	2012-04-10T12:41:48-0700	2012-10-07T18:25:06-0700	"The current version of CSE is slightly broken -- contrary to the comments
explaining it, it does not add an additional mapping when it substitutes the RHS
of some binding. Taking the example from ```CSE.lhs```

{{{
module Test2 where

data C a b = C a b
a = undefined
{-# NOINLINE a #-}
b = undefined
{-# NOINLINE b #-}

x1 = C a b
x2 = C x1 b
y1 = C a b
y2 = C y1 b
}}}

We want to detect that ```y1``` is the same as ```x1``` and so rewrite it to
```y1 = x1```. But at this point we also want to add a new substitution that
changes ```y1``` to ```x1```. So that we can get ```y2 = C x1 b``` and then
```y2 = x2```. This is '''not''' done by the current code:
{{{
> ghc -O2 -fforce-recomp Test2.hs -ddump-simpl -dsuppress-all -rtsopts
[1 of 1] Compiling Test2            ( Test2.hs, Test2.o )

==================== Tidy Core ====================
Result size = 40

b = undefined
a = b
x1 = \\ @ a_aaf @ b_aag -> C (a) (b)
x2 = \\ @ b_aao @ a_aap @ b1_aaq -> C (x1) (b)
y1 = x1
y2 = \\ @ b_aaG @ a_aaH @ b1_aaI -> C (x1) (b)
}}}

I wrote a patch to fix that and we get the desired result:
{{{

> ~/dev/ghc-work/inplace/bin/ghc-stage2 -O2 -fforce-recomp Test2.hs -ddump-simpl -dsuppress-all -rtsopts
[1 of 1] Compiling Test2            ( Test2.hs, Test2.o )

==================== Tidy Core ====================
  Result size = 30

b = undefined
a = b
x1 = \\ @ a_aal @ b_aam -> C (b) (b)
x2 = \\ @ b_aau @ a_aav @ b1_aaw -> C (x1) (b)
y1 = x1
y2 = x2
}}}

The fix seems quite easy but it made nofib unhappy -- see nofib1
attachment. Apparently there is quite a bit additional alloctation happening in
a few benchmarks. I managed to narrow it down to the ```GHC.IO.Encoding.*```
modules. Adding a simple ```GHC_OPTIONS -fno-cse``` seems to improve the
performance quite a bit (and above the current HEAD!) -- see nofib2 attachment.
There seems to be a bit more code bloat, but the performance looks worth it. I
haven't yet looked into exactly what causes the excessive allocation with CSE in
the ```GHC.IO.Encoding.*``` modules (and I'm also a bit surprised by that -- I
thought the main issue with CSE would be bigger memory usage). So any
suggestions are more than welcome. ;)

All the patches are in https://github.com/michalt/ghc (branch ""cse"") and
https://github.com/michalt/packages-base (branch ""cse"").
"	michalt
3	3178	Fix linking -lpthread for semaphores	libraries/unix	6.10.2	normal	normal	_|_		new	2009-04-19T17:28:40-0700	2010-12-07T00:11:56-0800	"Hello,

On the GNU/Hurd OS, the posix semaphore library does not link because
of undefined reference to sem_* functions.  I do not know how the ghc
build process works, could it be that it forgets to use -lpthread for
that library?

Samuel
"	sthibaul
4	5608	Fix T3807 for Mac OS X 10.5	Test Suite	7.3	low		7.6.2		new	2011-11-06T12:33:03-0800	2012-09-12T04:13:34-0700	"Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):
{{{
=====> T3807(normal) 591 of 3083 [0, 0, 1]
cd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
Failed to open shared library: dlopen(./T3807test.so, 10): Symbol not found: ___gmp_set_memory_functions
Referenced from: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.3.20111106/integer-gmp-0.3.0.0/libHSinteger-gmp-0.3.0.0-ghc7.3.20111106.dylib
Expected in: dynamic lookup
Stderr:
make[3]: *** [T3807] Error 1
*** unexpected failure for T3807(normal)
}}}
Validates on
{{{
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$ 
}}}
and
{{{
$ uname -a
Linux tn24 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:40:53 UTC 2011 i686 GNU/Linux
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$ 
}}}
Best regards
Thorkil"	thorkilnaur
3	7866	floor (0/0) :: Int is different with -O0 and -O1	Compiler	7.6.2	normal				new	2013-04-26T02:18:21-0700	2013-04-26T02:18:21-0700	"This program:
{{{
main = print (floor (0/0) :: Int)
}}}

prints a different result with -O0:
{{{
0
}}}
and -O1:
{{{
-9223372036854775808
}}}"	alang9
5	3070	floor(0/0) should not be defined	Prelude	6.10.1	lowest	normal	7.6.2	squadette	new	2009-03-04T07:33:26-0800	2012-09-12T04:14:08-0700	"floor(0/0) returns some giant negative integer - it should return NaN or undefined.

The bug appears to be in some implementation of 'properFraction' in the standard library.

[from Andrej Bauer, from Barak Pearlmutter (from ???)]"	carette
4	2926	Foreign exported function returns wrong type	Compiler (FFI)	6.10.1	low	normal	_|_		new	2009-01-08T07:41:23-0800	2010-07-19T09:40:38-0700	"I call foo, foreign export ccall foo :: Int -> IO CInt, from C code like this: printf(""%d\n"", (int)foo((HsInt32)2500)); but when I remove the (int) cast, gcc complains (warnings, not errors) because it thinks that the thing that foo returns is a HsInt32, and not a C int. The type for foo clearly specifies it is a CInt. 

The bug is that GHC is probably not generating a CInt, but a HsInt32. 

{{{
{-# LANGUAGE ForeignFunctionInterface #-}
-- name this file ExportHaskellToCStruct.hs
module ExportHaskellToCStruct(foo) where
import Foreign.C
import Data.List
foreign export ccall foo :: Int -> IO CInt

foo = return . genericLength .  f

f :: Int -> [Int]
f 0 = []
f n = n:(f (n-1))
}}}

{{{
#include <stdio.h>                                                                                                                                           
#include ""/correctpathto/include/HsFFI.h""         /*    FIX PATH for your installation */                                                                                                          
#define __GLASGOW_HASKELL__                                                                                                                                  

#ifdef __GLASGOW_HASKELL__
#include ""ExportHaskellToCStruct_stub.h""
#endif

#ifdef __GLASGOW_HASKELL__
extern void __stginit_ExportHaskellToCStruct(void);
#endif

int main(int argc, char *argv[])
{
  int i;

  hs_init(&argc, &argv);
#ifdef __GLASGOW_HASKELL__
  hs_add_root(__stginit_ExportHaskellToCStruct);
#endif

  for (i = 0; i < 5; i++) {
    printf(""%d\n"", (int)foo((HsInt32)2500)); 
  }

  hs_exit();
  return 0;
}
}}}

{{{
gcc --version
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
}}}"	fasta
3	322	fromInteger-related pattern match overlap warnings	Compiler	6.4	normal	normal	_|_	simonpj	new	2005-03-13T20:19:50-0800	2010-02-20T07:14:06-0800	"{{{
The compiler incorrectly gives ""Warning: Pattern match(es) are 
overlapped"" for this file:

{-# OPTIONS -Werror #-}

module Buggy where

	instance (Num a) => Num (Maybe a) where
		(Just a) + (Just b) = Just (a + b)
		_ + _ = Nothing
		(Just a) - (Just b) = Just (a - b)
		_ - _ = Nothing
		(Just a) * (Just b) = Just (a * b)
		_ * _ = Nothing
		negate (Just a) = Just (negate a)
		negate _ = Nothing
		abs (Just a) = Just (abs a)
		abs _ = Nothing
		signum (Just a) = Just (signum a)
		signum _ = Nothing
		fromInteger = Just . fromInteger

	f :: Maybe Int -> Int
	f 1 = 1
	f Nothing = 2
	f _ = 3

}}}"	ashley-y
3	6070	Fun with the demand analyser	Compiler	7.4.1	normal		7.8.1	simonpj	new	2012-05-02T06:33:23-0700	2013-01-16T15:23:30-0800	"Max writes: I've been trying to speed up the supercompiler, and in the process
I've noticed some infelicities in the demand analyser that might be
worth looking at.

== Infelicity 1: analysis does not take into account extra unboxing done by the CPR transformation ==
An example is:
{{{
e :: (Int, Int) -> Int -> (Int, Int)
e x y = x `seq` if y > 10
         then x
         else e x (y + 1)
}}}
Because x is seqed, the occurrence in the ""then"" branch gets the CPR
property so e has the CPR property overall. However, the overall
demand on x is S(AA), i.e. the demand analyser believes the x box is
used -- if the box were unused it would get the demand U(LL). So the
overall demand type is S(AA)U(L)m, and the worker looks like:
{{{
Rec {
CPR2.$we [Occ=LoopBreaker]
  :: (GHC.Types.Int, GHC.Types.Int)
     -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #)
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType S(AA)L,
 Unf=OtherCon []]
CPR2.$we =
  \ (w_srv :: (GHC.Types.Int, GHC.Types.Int))
    (ww_srt :: GHC.Prim.Int#) ->
    case GHC.Prim.># ww_srt 10 of _ {
      GHC.Types.False ->
        case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT ->
        CPR2.$we w_srv sat_ssS
        };
      GHC.Types.True ->
        case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) }
    }
end Rec }
}}}
But if we demand-analysed $we then GHC would say that it had the
demand type U(LL)L and unbox the pair argument! It seems silly that
the demand analyser outputs code that can be improved further by just
running demand analysis again.

Somewhere where this really bit me in practice is in:
{{{
d :: M.Map Int Int -> (Int, Int)
d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else
(b, a)) (0, 1) m
}}}
Which generates this inner loop:
{{{
Rec {
CPR2.$wgo2 [Occ=LoopBreaker]
  :: (GHC.Types.Int, GHC.Types.Int)
     -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int
     -> (# GHC.Types.Int, GHC.Types.Int #)
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType S(AA)S,
 Unf=OtherCon []]
CPR2.$wgo2 =
  \ (w_srS :: (GHC.Types.Int, GHC.Types.Int))
    (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) ->
    case w1_srQ of _ {
      Data.Map.Base.Tip ->
        case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) };
      Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 ->
        case kx_ss3 of _ { GHC.Types.I# x1_ssd ->
        case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) ->
        case x_ssa of _ { GHC.Types.I# y_sse ->
        case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT ->
        case GHC.Prim.># sat_st0 2 of _ {
          GHC.Types.False ->
            let {
              sat_ssZ :: (GHC.Types.Int, GHC.Types.Int)
              [LclId]
              sat_ssZ = (ww2_ssh, ww1_ssi) } in
            CPR2.$wgo2 sat_ssZ l_ssk;
          GHC.Types.True ->
            let {
              sat_st6 :: (GHC.Types.Int, GHC.Types.Int)
              [LclId]
              sat_st6 = (ww1_ssi, ww2_ssh) } in
            CPR2.$wgo2 sat_st6 l_ssk
        }
        }
        }
        }
        }
    }
end Rec }
}}}
We can save a number of allocations proportional to the size of the
Map if the demand analyser didn't have this problem.

I hacked up the analyser to ""fix"" this by changing the lines at line
473 onward to read:
{{{
    if isTopLevel top_lvl
     then fn_ty	-- Don't record top level things
     else case dmd of
            Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty,
returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd))
            _
      -> addVarDmd fn_ty var dmd
}}}
So if we demand a CPRish variable (such as bound by a case scrutinee
or a U(LL)-demanded lambda-binder) in the evalDmd then I throw away
the Box part of the evalDmd on the basis that after CPRing we won't
demand the box at all.

I doubt this hack is the right solution (and I haven't tried it to see
how it affects the libraries) but perhaps it gives you some ideas.


== Infelicity 2: a case where demand summarisation hurts us ==

I found practical examples where summarising the demand transfomer of
a function as a single strictness signature hurt us. The examples were
code like:
{{{
h :: (Int, Int) -> Int -> (Int, Int)
h x y = if y > 10
         then x
         else h (case h x 0 of (y1, y2) -> (y2, y1)) (y + 1)
}}}
If, at the innermost use of h, we re-analyse h in the demand
C(C(U(LL))) rather than just unleashing the vanilla DmdSig computed
from the demand C(C(S)) then we can unbox the pair argument. Currently
GHC just gives h the DmdType SU(L) which doesn't eliminate the
allocation of the pair at all.

This situation occurs in practice with code like:
{{{
c :: M.Map Int Int -> (Int, Int)
c m = M.foldrWithKey (\k v (a, b) -> if k + v > 2 then (a, b) else (b,
a)) (0, 1) m
}}}
The difference from my earlier example d is that I'm using the version
of `foldrWithKey` that doesn't call `seq`. Current GHC generates this
inner loop:
{{{
Rec {
CPR2.c_go2 [Occ=LoopBreaker]
  :: (GHC.Types.Int, GHC.Types.Int)
     -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int
     -> (GHC.Types.Int, GHC.Types.Int)
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType U(L*)S,
 Unf=OtherCon []]
CPR2.c_go2 =
  \ (z_spW :: (GHC.Types.Int, GHC.Types.Int))
    (ds_spU :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) ->
    case ds_spU of _ {
      Data.Map.Base.Tip -> z_spW;
      Data.Map.Base.Bin rb_sqq kx_sq2 x_sq9 l_sqj r_sq5 ->
        case kx_sq2 of _ { GHC.Types.I# x1_sqc ->
        case CPR2.c_go2 z_spW r_sq5 of wild2_sqk { (a_sqh, b_sqg) ->
        case x_sq9 of _ { GHC.Types.I# y_sqd ->
        case GHC.Prim.+# x1_sqc y_sqd of sat_sqp { __DEFAULT ->
        case GHC.Prim.># sat_sqp 2 of _ {
          GHC.Types.False ->
            let {
              sat_sqo :: (GHC.Types.Int, GHC.Types.Int)
              [LclId]
              sat_sqo = (b_sqg, a_sqh) } in
            CPR2.c_go2 sat_sqo l_sqj;
          GHC.Types.True -> CPR2.c_go2 wild2_sqk l_sqj
        }
        }
        }
        }
        }
    }
end Rec }
}}}
I implemented this but the overhead of reanalysing a function at each
occurrence site is prohibitive (with my changes paraffins took 2.5s to
compile instead of 0.3s). It does fix the problem though.

A scheme like in ""stricterness more relevant"" but with let-binding
that is polymorphic in the use-site demand might be able to detect the
extra strictness here. I think Stefan Holdermanns has a paper
describing such a system. But this is anyway much harder to fix than
my first infelicity.
"	simonpj
4	345	GADT - fundep interaction	Compiler (Type checker)	6.4	low	normal	_|_	simonpj	new	2005-04-08T03:02:38-0700	2009-11-19T04:53:27-0800	"{{{
GADTs and fundeps don't seem to interact in the way
that I (perhaps naively) expect. I expected that for
each case, the type variables would be instantiated
according to the type of the constructors, and then the
fundep would be used to figure out the result type. 

{-# OPTIONS_GHC -fglasgow-exts #-}

data Succ n
data Zero

class Plus x y z | x y -> z
instance Plus Zero x x
instance Plus x y z => Plus (Succ x) y (Succ z)

infixr 5 :::

data List :: * -> * -> * where
              Nil :: List a Zero
              (:::) :: a -> List a n -> List a (Succ n)

append :: Plus x y z => List a x -> List a y -> List a z
append Nil ys = ys
append (x ::: xs) ys = x ::: append xs ys

{-
  GHC 6.4 says:

    Couldn't match the rigid variable `y' against `Succ z'
      `y' is bound by the type signature for `append'
      Expected type: List a y
      Inferred type: List a (Succ z)
    In the expression: x ::: (append xs ys)
    In the definition of `append': append (x ::: xs) ys
= x ::: (append xs ys)
-}
}}}"	bring
3	7148	generalized newtype and  type families is unsound	Compiler (Type checker)	7.6.1-rc1	normal		7.8.1	simonpj	new	2012-08-14T20:39:33-0700	2012-10-16T15:32:00-0700	"the code from 
http://joyoftypes.blogspot.com/2012/08/generalizednewtypederiving-is.html
type checks in the release candidate

also see discussion here http://www.reddit.com/r/haskell/comments/y8kca/generalizednewtypederiving_is_very_very_unsafe/

(punch line: the generalized newtype deriving + type families or gadts allows users to write unsafeCoerce etc)

perhaps a simple near term solution is to have any module using generalized new type deriving be inferred to be unsafe by default? "	carter
3	5498	Generalized newtype deriving allows creating of instances I can't create by hand	Compiler	7.3	normal		7.6.2		new	2011-09-21T02:44:43-0700	2012-09-12T04:12:04-0700	"First here is a simple module that establishes a list where once created (with a min element) subsequent elements inserted should always be larger than the min:

{{{
-- | Here we expose a MinList API that only allows elements
-- to be inserted into a list if they are at least greater
-- than an initial element the list is created with.
module MinList (
        MinList,
        newMinList,
        insertMinList,
        printIntMinList
    ) where

data MinList a = MinList a [a]

newMinList :: Ord a => a -> MinList a
newMinList n = MinList n []

insertMinList :: Ord a => MinList a -> a -> MinList a
insertMinList s@(MinList m xs) n | n > m     = MinList m (n:xs)
                                 | otherwise = s

printIntMinList :: MinList Int -> IO ()
printIntMinList (MinList min xs) = putStrLn $ ""MinList Int :: MinList "" ++ show min ++ "" "" ++ show xs
}}}

Now I import this module and use generalized newtype deriving to create a function I couldn't create by hand:
{{{
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
-- | We use newtype to create an isomorphic type to Int
-- with a reversed Ord dictionary. We now use the MinList
-- API of MinList to create a new MinList. Then we use newtype
-- deriving to convert the newtype MinList to an Int
-- MinList. This final result breaks the invariants of
-- MinList which shouldn't be possible with the exposed
-- API of MinList.
module Main where

import MinList

class IntIso t where
    intIso :: c t -> c Int

instance IntIso Int where
    intIso = id

newtype Down a = Down a deriving (Eq, IntIso)

instance Ord a => Ord (Down a) where
    compare (Down a) (Down b) = compare b a

fine :: MinList (Down Int)
fine = foldl (\x y -> insertMinList x $ Down y) (newMinList $ Down 0) [-1,-2,-3,-4,1,2,3,4]

bad :: MinList Int
bad = intIso fine

main = do
    printIntMinList bad
}}}

The problem here is the isoInt method where I can do:
{{{
isoInt :: MinList (Down Int) -> MinList Int
}}}
which I shouldn't be able to do since I don't have the constructors for `MinList`.

This is the reason I've currently disabled newtype deriving in Safe Haskell but potentially we can enable it if this bug is fixed."	dterei
3	7269	GeneralizedNewtypeDeriving and PolyKinds	Compiler	7.6.1	normal		7.8.1	dreixel	new	2012-09-24T09:46:04-0700	2013-04-12T07:50:35-0700	"The following code

{{{
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}

class C (a :: k)

instance C Int

newtype MyInt = MyInt Int deriving C
}}}

fails with this error:
{{{
    Cannot derive well-kinded instance of form `C k (MyInt ...)'
      Class `C' expects an argument of kind `k'
    In the newtype declaration for `MyInt'
}}}

I believe this should work, and I think I know what's going on. I'm working on it."	dreixel
2	6147	GeneralizedNewtypeDeriving should fail with data families	Compiler (Type checker)	7.2.1	high		7.8.1	simonpj	new	2012-06-06T04:10:31-0700	2013-03-25T18:36:34-0700	"Here is an example:

{{{
{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-}
module Foo where

data family T a
data instance T Int = T_Int Int

class C a where
  foo :: a -> T a

instance C Int where
  foo = T_Int

newtype Foo = Foo Int deriving(C)
}}}

The `deriving(C)` clause on `Foo` should fail but instead it derives an instance which can't possible be correct since there is no corresponding `data instance T Foo`. This is closely related to #2721 (where newtype deriving was disabled in the presence of associated types) but much more difficult to test for. Probably also related to #1496."	rl
3	7443	Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile	Profiling	7.4.2	normal		7.8.1		new	2012-11-23T04:26:31-0800	2013-04-12T12:49:51-0700	"Some background: This is C code generated when I turned on profiling with -fprof-auto -fprof-cafs, on Haskell code that contains a large amount of injected TemplateHaskell code. GHC takes several minutes to compile this on its side; but for some reason it emits the attached C code, which (if compiled with -O) takes ""forever"" to compile. At least, I killed it after consuming 3 hours of CPU and occupying 9GB of RAM.

I also opened a GCC bug for this; but a cursory look seems to indicate this C code is trying to build a linked list in memory, which it seems should be doable in a much more straightforward way. In fact since the list of CAFs will not change in run-time, it should be possible to initialize it in compile time as:
{{{
ENTRY entry_0[1] = { ..., link = NULL };
ENTRY entry_1[1] = { ..., link = entry_0 };
...
head = entry_n;
}}}
And this is before wondering why not use an array of entries instead of a linked list in the 1st place. That said, I am just guessing here, I have no understanding of what is really going on, other than the fact I was forced to add {-# OPTIONS_GHC -optc -O0 #-} to the offending file.

Attached is a tgz file containing the generated C code (plus a version which is post-CPP, so you can just try to compile it in various ways on systems without GHC installed)."	orenbenkiki
5	3351	Generated ghc man page missing xrefs	Documentation	6.10.3	lowest	minor	7.6.2		new	2009-07-05T05:22:27-0700	2012-09-12T04:14:10-0700	"The man page for ghc is generated from xml files.  Currently, this ignores xrefs, turning, for example

{{{
<entry>enable almost all warnings (details in <xref linkend=""options-sanity""/>)</entry>
}}}
to
  enable almost all warnings (details in )

This leads to stunted sentences as well as missing information."	kaol
3	5966	getAppUserDataDirectory does not respect XDG specification	libraries/directory	7.4.1	normal		7.6.2		new	2012-03-25T11:06:43-0700	2012-09-12T04:12:13-0700	"getAppUserDataDirectory function from System.Directory module returns path to a dot-dir under home directory. This swamps home with many hidden directories, when there are many applications installed. There is [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html XDG specification] for this situation, which suggests using $XDG_DATA_HOME environment variable.

So, getAppUserDataDirectory should behave approximately like this when $XDG_DATA_HOME is set:
{{{
getAppUserDataDirectory appName = do
    path <- getEnv ""XDG_DATA_HOME""
    return (path++'/':appName)
}}}
"	ordcoder
3	7473	getModificationTime gives only second-level resolution	libraries/directory	7.6.1	normal		7.8.1		new	2012-12-03T05:01:40-0800	2013-04-30T04:57:56-0700	"The `System.Directory.getModificationTime` function only returns time with second-level granularity. This is no good for applications like `ghc --make` where we need to compare file timestamps.

The fix should be simple, here's a patch (compiles but not tested) that should fix it for Unix, for Windows we will need a different fix, probably using the Win32 API directly, rather than the mingw C api.
{{{
diff --git a/System/Directory.hs b/System/Directory.hs
index cfe7cd9..f27bfc4 100644
--- a/System/Directory.hs
+++ b/System/Directory.hs
@@ -995,14 +995,14 @@ The operation may fail with:
 getModificationTime :: FilePath -> IO UTCTime
 getModificationTime name = do
 #ifdef mingw32_HOST_OS
- -- ToDo: use Win32 API
+ -- ToDo: use Win32 API so we can get sub-second resolution
  withFileStatus ""getModificationTime"" name $ \ st -> do
  modificationTime st
 #else
   stat <- Posix.getFileStatus name
-  let mod_time :: Posix.EpochTime
-      mod_time = Posix.modificationTime stat
-  return $ posixSecondsToUTCTime $ realToFrac mod_time
+  let mod_time :: POSIXTime
+      mod_time = Posix.modificationTimeHiRes stat
+  return $! posixSecondsToUTCTime mod_time
 #endif
 
 #endif /* __GLASGOW_HASKELL__ */
}}}"	duncan
3	5761	Getting stdout and stderr as a single handle from createProcess does not work on Windows	libraries/process		normal		7.6.2		new	2012-01-10T07:32:25-0800	2012-09-12T04:12:08-0700	"The following test case works on Linux (an as far as I know on Mac OS X too), but not on Windows.
{{{
{-# OPTIONS_GHC -fno-warn-missing-signatures #-}
module Spec (main) where
import           Test.HUnit
import           System.Process
import           System.IO

subprocess = concat $
  [ ""module Main where\n""
  , ""import System.IO\n""
  , ""main = do\n""
  , ""  hPutStr stderr \""foo\""\n""
  , ""  hFlush stderr\n""
  , ""  hPutStrLn stdout \""bar\""\n""
  , ""  hFlush stdout\n""
  ]

main = runTestTT $ TestCase $ do
  (Just hin, Just hout, Nothing, _) <-
    createProcess $ (proc ""runhaskell"" []) {
        std_in = CreatePipe
      , std_out = CreatePipe
      , std_err = UseHandle stdout
    }
  hPutStrLn hin subprocess
  hClose hin
  line <- hGetLine hout
  line @?= ""foobar""
}}}

Do we consider this a bug?  If not, what would be the suggested way to do that?"	SimonHengel
4	3588	ghc -M should emit dependencies on CPP headers	Compiler	6.10.4	low	normal	7.6.2		new	2009-10-15T04:53:00-0700	2012-09-12T04:12:18-0700	"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
3	947	ghc -O space leak: CSE between different CAFs	Compiler	6.5	normal	normal	_|_		new	2006-10-16T18:04:27-0700	2012-10-15T17:13:34-0700	"Consider the following program for generating the 1,000,000th prime:

{{{
module Main (main) where

sieve0 (n:ns) (p:ps)
    | p*p == n  = sieve0 (filter (\n -> n`mod`p /= 0) ns) ps
    | otherwise = n:sieve0 ns (p:ps)

primes0 :: [Int]
primes0 = 3:sieve0 [5,7..] primes0

primes :: [Int]
primes = 2:3:sieve0 [5,7..] primes0

main = print $ primes !! 1000000
}}}

The intention of the separate primes0 function is to limit the number of primes that need to be held in memory. Unfortunately, ghc -O combines the common subexpressions in primes0 and primes so this effort is wasted. The resulting program needs noticably more memory than required, as can be seen by replacing the definition of {{{primes}}} by

{{{
primes = 2:3:sieve0 (iterate (2+) 5) primes0
}}}

which prevents the CSE from happening.

Excerpt of {{{+RTS -s}}} output, original version:
{{{
12,099,221,160 bytes allocated in the heap
279,720,116 bytes copied during GC
 15,834,912 bytes maximum residency (6 sample(s))
}}}
modified version that prevents CSE:
{{{
127,736,408 bytes copied during GC (scavenged)
    233,388 bytes copied during GC (not scavenged)
     30,624 bytes maximum residency (1 sample(s))
}}}

Tested with ghc 6.4.2 and a current (as of 2006-10-17) darcs ghc 6.5."	int-e@…
3	7098	GHC 7.4.1 reports an internal error and core dumps while using DPH	Compiler	7.4.1	normal		7.8.1	benl	new	2012-07-25T20:40:52-0700	2012-10-14T20:26:02-0700	"While compiling a DPH program I got the following error,
{{{
Main: internal error: allocGroup: requested zero blocks
    (GHC version 7.4.1 for i386_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
}}}
I have attached the code files that I was using."	Prasanna
4	2356	GHC accepts multiple instances for the same type in different modules	Compiler	6.8.3	low	normal	_|_		new	2008-06-10T05:25:27-0700	2013-01-27T11:06:00-0800	"as mentioned by Simon PJ in this thread:

http://www.haskell.org/pipermail/haskell/2008-June/020436.html

here is the example, spelled out:
{{{
module B0 where
class C a where c :: a -> String
data T = T deriving Show

module B1 where
import B0
instance C T where c _ = ""B1""
b = c T

module B2 where
import B0
instance C T where c _ = ""B2""
b = c T

module Main where
import B1
import B2
main = print (B1.b,B2.b)
}}}
this is accepted without flags or errors and prints `(""B1"",""B2"")`.

the [http://haskell.org/onlinereport/decls.html#sect4.3.2 language report, section 4.3.2] clearly states:

  A type may not be declared as an instance of a particular class more than once in the program.
"	claus
2	7456	GHC API displays linker messages to stdout instead of via log_action	GHC API	7.4.2	high		7.8.1	igloo	new	2012-11-28T07:48:07-0800	2013-04-12T13:22:42-0700	"At least in the LinkInMemory mode, GHC API displays linker messages, such as 

{{{
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
}}}

on stdout instead of using the log_action handler for them, just as for all the other kinds of messages. Moreover, I haven't found any way of suppressing these messages apart of setting verbosity=0, which turns off other important messages. I can see no GHC flags that does this and this linker does not accept any special linker flags. I don't know the policy about severity levels, but I suppose severity SevOutput could be fine for these messages, by similarity to ""compiling M ... done."" messages which have such severity."	MikolajKonarski
4	4162	GHC API messes up signal handlers	GHC API	6.12.3	low		7.6.2		new	2010-06-30T12:38:48-0700	2012-09-12T04:12:25-0700	"A side-effect of using the {{{runGhc}}} function is that some signal handlers are modified and not restored afterwards (see function {{{initGhcMonad}}}). In particular, the handler for {{{SIGINT}}} installed by ghc throws an exception to a thread stored in a global variable, which initially corresponds to the thread from which {{{runGhc}}} was run.

This is a particularly problematic for programs that wish to run ghc ""in the background"" on its own thread. For example, consider this code:

{{{
import qualified GHC
import qualified MonadUtils as GHC
import qualified GHC.Paths as GHC

import Control.Concurrent ( forkIO, threadDelay )

main = do
   putStrLn ""waiting for 5 seconds...""
   threadDelay $ 5 * 1000 * 1000
   putStrLn ""starting...""
   forkIO $ GHC.runGhc (Just GHC.libdir) (GHC.liftIO $ putStrLn ""hello"")
   putStrLn ""waiting for 10 seconds""
   threadDelay $ 10 * 1000 * 1000
   putStrLn ""exiting after final wait""
}}}

One can interrupt this program with Ctrl-C during the first five seconds of execution only.

It is not clear to me how one can safely workaround this problem. For instance, one could manually restore the program's original handlers at the beginning of execution, that is, transform:

{{{
runGhc action
}}}

into something like this:

{{{
runGhc $ (liftIO restoreProgramHandlers >> action)
}}}

but I don't know if this is safe (i.e., what happens if ghc is run without its own handlers installed).
"	jcpetruzza
3	7430	GHC API reports CPP errors in confusing ways	GHC API	7.6.1	normal		7.8.1		new	2012-11-19T14:33:04-0800	2013-04-12T12:34:47-0700	"When there is a CPP error, the GHC API provides a normal error message (such as in case of type errors), e.g., 
{{{
error: missing binary operator before token ""(""
}}}
but it does not say it's a CPP error. In addition (and unlike for type errors), GHC API throws an exception, e.g., 
{{{
phase `C pre-processor' failed (exitcode = 1)
}}}
which states the error comes from CPP, but is otherwise uninformative and not tied in any way to the normal error message. 

Ideally, all the information would be in the error message and the exception that disrupts the normal control flow would not be thrown.

Here's how to reproduce this: in the following repo (uh, just realised it's a rather large repo)
{{{
https://github.com/Mikolaj/ghc/tree/CPPrunGhc
}}}
run
{{{
ghc --make GhcRun.hs -package ghc-7.6.1
}}}
and then
{{{
./GhcRun
}}}
You should get
{{{
Normal error message:
Severity: SevError  SrcSpan: RealSrcSpan (SrcSpanPoint {srcSpanFile = ""Ticks.hs"", srcSpanLine = 1, srcSpanCol = 0})  MsgDoc:  error: missing binary operator before token ""(""

Exception:
GhcRun: phase `C pre-processor' failed (exitcode = 1)
}}}"	MikolajKonarski
2	7752	GHC as a library documentation out of sync	Documentation	7.6.2	high		7.8.1		new	2013-03-07T15:54:20-0800	2013-04-13T05:54:40-0700	"The example program(s) at

http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-as-a-library.html

no longer compile. The docs probably just need a bit of tweaking.
"	tibbe
5	4022	GHC Bindist is Broken on FreeBSD/amd64	libraries (other)	6.13	lowest		7.6.2	pgj	new	2010-04-27T04:15:18-0700	2012-09-12T04:14:15-0700	"After correcting the name of the FreeBSD/amd64 platform in `PlatformSupportsSharedLibs` it turned out that shared libraries do not build on that platform at all.  Log shows that the problem is with the integer-gmp library where the sources are not compiled with the `-fPIC` flag.

Excerpt from the build log:

{{{
...
""inplace/bin/ghc-stage1"" libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o `/usr/bin/find libraries/integer-gmp/dist-install/build -name ""*_stub.dyn_o"" -print` -shared -dynamic -dynload deploy -dylib-install-name /usr/local/lib/ghc-6.13.20100427/`basename ""libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so"" | sed 's/^libHS//;s/[-]ghc.*//'`/`basename ""libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so""` -no-auto-link-packages -packageghc-prim-0.2.0.0 -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.0-ghc6.13.20100427.so
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value
...
}}}

According to Simon Marlow, it looks like it is building the in-tree gmp library rather than using a local one, and perhaps there is no shared version, so `gcc` picks up the static one and complains. There should be a shared gmp library when shared Haskell libraries are being built.
"	pgj
3	7904	GHC calls the cc1 of a gcc thats not the first in PATH	Compiler	7.6.3	normal				new	2013-05-10T22:12:55-0700	2013-05-11T19:12:21-0700	"I was earlier today trying to build some haskell code that ffi's out to some c code that uses SSE4 / AVX intrinsics, and was getting odd errors about not understanding -mavx or -msse4.2  , which was quite surprising since I was able to build those same c source files with clang or the gcc 4.8 i have at the top of my path.

After some digging (and running dtrace while trying to bulld my code),  I found that some point in the build process, ghc/cabal was running the cc1 of the apple gcc-llvm v4.2 (ie the gcc version i had used to build the ghc and comes with apple dev tools current version, and which lacks support for avx or sse4.2 ).

I only hit this problem because i was deliberately writing code that would only compile assuming avx / sse4.2 support on the c compiler side, though this does have the implication that when ghc users are doing a simple cabalized build of some c code that has SIMD intrinsics, it'll only use simd <= ssse3, no higher. This could result in certain  haskell codes on os x that lean on vectorized ffi's being 2x slower or worse than on other architectures perhaps.

I'll be working around this problem in my own software development by rebuilding ghc on my mac using gcc 4.8 and see if that resolves that problem.

That ends my overview  of the bug whereby ghc uses the cc1 of the gcc that built it even when others are earlier in the path (which creates unexpected problems when naively using ghc as the c compilation driver).

Now for the feature request:

 assuming theres a good reason for having the cc1 choice hard coded in, it'd probably be helpful for ghc to issue a warning when the hardwired cc1 refers to a gcc that isn't the first one visible when looking up gcc in the $path.

"	carter
5	1883	"GHC can't find library using ""short"" name"	Compiler	6.6.1	lowest	normal	7.6.2		new	2007-11-12T17:10:38-0800	2013-01-26T15:00:15-0800	"I wanted to build HDBC-postgresql 1.0.1[1] today, and ran into a problem where my test program would not load and instead gave this error:

{{{
  can't load .so/.DLL for: pq (addDLL: unknown error)
}}}

I traced this to the 'extra-libraries' directive in the .cabal file. It read

{{{
Extra-Libraries: pq
}}}

When I changed it to 

{{{
Extra-Libraries: libpq
}}}

The error went away. Somehow ""pq"" is not enough to get ""libpq.dll"" loaded. 

Note that building on Windows required some other changes.[2] 

This was using Cabal 1.1

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-postgresql-1.0.1.0

[2] From http://software.complete.org/hdbc/wiki/FrequentlyAskedQuestions

To build on Windows, you must specify where the postgresql include and library files are. Follow these two steps:

   1. Ensure the files are NOT installed in a directory with spaces in the name (e.g. ""C:\Program Files""). For example, install them in c:\pgsql.
   2. Assuming postgresql is installed in C:\pgsql, add the following information to the .cabal file:
{{{
      include-dirs: C:\pgsql\include, C:\pgsql\include\server, .
      extra-lib-dirs: C:\pgsql\bin
}}}
      Notice the ""."" at the end of include-dirs to ensure the current directory is also searched. Also notice ""bin"" directory is specified in ""extra-lib-dirs."" This is important in the next step.
   3. HDBC-postgresl depends on ""libpa.dll"" in the bin directory above. The .cabal file refers to the ""pq"", but that doesn't work on Windows. Change it to libpq like so:

      Extra-Libraries: libpq
"	m4dc4p
3	7428	GHC compile times are seriously non-linear in program size	Compiler	7.4.2	normal		7.8.1		new	2012-11-19T00:46:38-0800	2013-04-12T12:00:43-0700	When compiling the attached code with -O2 GHC runs out of memory. Experimenting with different monad stacks shows exponential memory usage.	nudded
2	7320	GHC crashes when building on 32-bit Linux in a Linode	Runtime System	7.6.1	high		7.6.2	simonmar	new	2012-10-11T23:43:47-0700	2012-12-07T07:32:57-0800	"
Trying to build {{{haskell-src-exts}}} crashes in a 32-bit Linux Linode (under Xen).

GHC 7.0.4 seems ok, but I've tried GHC 7.2.2, 7.4.1 and 7.6.1 and they all either segfault or issue a bad instruction when building. This also happens when building GHC from source. 

GHC 7.6.1 crashes more frequently than the others. When run under GDB it usually dies at the same program point (0x093c6263). Running GHC with -v says it's in the 'Tidy Core' stage.

I've tried under the latest Arch, as well as Debian. The Linode has 1GB of real RAM and 4GB of swap, so it shouldn't be running out of memory.

The Linode has been stable otherwise, it runs apache and trac, and has had uptimes of 3 months or more.

Running Ubuntu-32bit under Parallels (using OSX as the host) with the same memory configuration seems fine.
"	benl
4	5537	ghc doesn't find libffi.so.5 in testsuite	Test Suite	7.3	low		7.6.2		new	2011-10-07T07:48:18-0700	2012-09-12T04:13:33-0700	"Running the testsuite, more or less every dyn test fails with
{{{
Wrong exit code (expected 0 , actual 127 )
Stdout:

Stderr:
./T5041: error while loading shared libraries: libffi.so.5: cannot open shared object file: No such file or directory
}}}
(some fail for other reasons before getting to that stage).

Running `make TEST=whichever` in the testsuite directory, all the tests I tried passed the dyn way, so it seems to be an issue with the testsuite-driver."	daniel.is.fischer
3	7542	GHC doesn't optimize (strict) composition with id	Compiler	7.6.1	normal		7.8.1	simonpj	new	2013-01-01T13:35:41-0800	2013-04-12T15:08:37-0700	"Newtype constructors and selectors have no runtime overhead, but some uses of them do. For example, given `newtype Identity a = Identity { runIdentity :: a }`, `Identity` turns into `id`, but `Identity . f` turns into `id . f`, which is distinct from `f`, because it gets eta-expanded to `\x -> f x`.

It would be nice to be able to compose a newtype constructor with a function without any overhead. The obvious thing to try is strict composition:

{{{
(#) :: (b -> c) -> (a -> b) -> a -> c
(#) f g = f `seq` g `seq` \x -> f (g x)
}}}

In theory this should get rid of the eta-expansion. In practice, the generated Core looks like this:

{{{
foo :: (a -> b) -> [a] -> [b]
foo f = map (id # f)
-- becomes
foo = \f e -> map (case f of g { __DEFAULT -> \x -> g x }) e
}}}

Different variations of `(#)`, and turning `-fpedantic-bottoms` on, don't seem to affect this. A simpler version, `foo f = map (f `seq` \x -> f x)`, generates the same sort of Core.

In one library we resorted to defining a bunch of functions of the form `identityDot :: (a -> b) -> a -> Identity b; identityDot = unsafeCoerce`. It would be better to be able to rely on GHC to do the optimization directly, if we use strict composition anyway."	shachaf
3	7909	GHC doesn't respect -optl and -optc in a couple of places	Compiler	7.6.3	normal		7.8.1	simonmar	new	2013-05-14T05:01:57-0700	2013-05-14T05:01:57-0700	"A legitimate use of `-optl` and `-optc` is to pass options that should ''always'' be passed to gcc, such as `-B<something>` if we're invoking `gcc` against a particular set of libraries.  For this to work, we have to ensure that `-optl` and `-optc` options are always passed.

In `joinObjectFiles`, we don't add the options from `-optl`.  I suspect that we don't want to just add them, because we also put the `-l` options in this list, so we should separate the two.

In `mkExtraObj`, we don't add the options from `-optc`.

Probably we should refactor things so that these options are automatically added by `SysTools.runCc` and friends, being careful about option ordering.
"	simonmar
4	1171	GHC doesn't respect the imprecise exceptions semantics	Compiler	6.6	low	normal	_|_		new	2007-02-24T13:39:49-0800	2013-02-13T08:40:28-0800	"Yhc bug 122 appears to be a GHC bug: http://code.google.com/p/yhc/issues/detail?id=122 , discussed here: http://thread.gmane.org/gmane.comp.lang.haskell.yhc/720

To reproduce:
Download and install Yhc two separate times, once doing ""scons"" to build, once doing ""scons type=release"". Follow the steps outlined in the above bug report with the standard version, and it gives the correct behaviour. Try again with the release version and it gives the wrong behaviour. GHC 6.4.2 works fine. The difference between the two is that type=release builds with -O, normal doesn't.

Changing the code slightly, by introducing ""obvious"" assert statements in Package.hs makes the bug go away. Creating reduced tests cases didn't get very far...

This has been replicated on Mac and Windows with GHC 6.6. If you have any further questions about the code then feel free to email me or the Yhc list. Marking as severity=major because silently doing something different is about as bad as they come.

Thanks to Thorkil for doing the detective work to track this down as far as GHC."	neil
3	7565	GHC fails without an error when building text-0.11.2.3	Compiler	7.6.1	normal		7.8.1		infoneeded	2013-01-09T12:41:05-0800	2013-04-12T15:21:16-0700	"Coming from [here](https://github.com/haskell/cabal/issues/1173).

I installed GHC-7.6.1 from the binary package, on my CentOS 6 webspace. Then I wanted to install `cabal-install`, but the compilation failed at the `text` package without a message.

They told me it is an error with GHC, so I try to submit here."	guest
3	7362	GHC generated DLL does not work on Windows XP/Server 2003	Build System	7.4.1	normal		7.8.1		infoneeded	2012-10-23T11:16:40-0700	2013-04-12T09:17:31-0700	"When loading a DLL generated with the Haskell Platform 2012.2.0.0 into a C++ client, the client hangs on Windows XP/Server 2003 in a Windows NT kernel function:

{{{
ntoskrnl.exe!IoIs32bitProcess+0x25
ntoskrnl.exe!FsRtlAddBaseMcbEntry+0x82
ntoskrnl.exe!FsRtlInsertPerStreamContext+0x48e
ntoskrnl.exe!_snwprintf+0x1c
ntoskrnl.exe!KeInitializeQueue+0x3b
ntoskrnl.exe!KeDelayExecutionThread+0x1c7
ntoskrnl.exe!FsRtlInsertPerStreamContext+0x48e
ntoskrnl.exe!SePrivilegeObjectAuditAlarm+0x240f
ntoskrnl.exe!MmFreeContiguousMemory+0x90d
wow64cpu.dll+0x42d9
wow64cpu.dll+0x40e5
wow64.dll+0x6a5a
wow64.dll+0x97f4
wow64.dll+0x9886
wow64cpu.dll+0x3980
wow64win.dll+0x6fe0
ntdll.dll+0x1c846
ntdll.dll+0x57f16
kernel32.dll+0x751f2
EU_561_2006_12_12.dll+0xc7bbc 
}}}

(The stack trace was created with Process Explorer. The last frame was created by our DLL.)

The same DLL works fine on newer Windows versions.

The problem does not occur when building the DLL with the Haskell Platform 2011.4.0.0.
"	Michael Marte
3	5762	GHC gives incorrect warnings with simple applications of the view patterns extension	Compiler	7.3	normal		_|_		new	2012-01-10T08:30:28-0800	2012-01-10T08:46:00-0800	"GHC is not able to infer exhaustivity of f1 in the following example
{{{
{-# LANGUAGE ViewPatterns #-}
{-# OPTIONS_GHC -fwarn-incomplete-patterns #-}
module VP where


f1, f2 :: Either Int Int -> Either Int Int

f1 (id -> Left _ ) = undefined
f1 (id -> Right _ ) = undefined

f2 (Left _ ) = undefined
f2 (Right _ ) = undefined


f (id -> _) = undefined

}}}
 

GHC outputs:
{{{

[1 of 1] Compiling VP               ( VP.hs, interpreted )

VP.hs:8:1:
    Warning: Pattern match(es) are non-exhaustive
             In an equation for `f1': Patterns not matched: _
Ok, modules loaded: VP.
}}}


I've tested this with GHC 7.0.4, 7.2.2, and 7.4.1-rc1 on Mac OS X. 

BTW: There is neither a version entry for 7.2.2 nor for 7.4.1-rc1 in Trac.

"	jmg
4	3517	GHC has lots of extra hidden IOErrorType values	libraries/base		low	normal	7.6.2		new	2009-09-15T16:55:01-0700	2012-09-12T04:12:17-0700	"I was fixing bytestring's hGet (see #3514) and I discover that I cannot produce the same exception as System.IO.hGet does in the same circumstance.

There are two problems:

One is that GHC's internal IOError has more information than one can set via System.IO.Error.mkIOError. In particular it has a function name.

The other is that System.IO.hGet throws an `InvalidArgument` `IOErrorType`, however this is not exported and there are no smart constructors or testers for this error type. This is problematic for two reasons, portable code cannot generate these error types to mirror the standard System.IO and secondly no code can actually catch these errors except in a general ""catch all"" style because they cannot be distinguished from each other.

Code that wants to mirror System.IO (like bytestring or utf8-string) has to import GHC.IO.Exception and use cpp to do it differently for hugs and nhc."	duncan
2	6022	GHC infers over-general types	Compiler	7.4.1	high		7.8.1	simonpj	new	2012-04-19T00:30:32-0700	2013-03-25T18:38:45-0700	"Consider
{{{
f x = x + head
}}}
GHC will (with no flags) will compile this almost-certainly-wrong program, giving `f` the type
{{{
    f :: forall a. Num ([a] -> a) => ([a] -> a) -> [a] -> a
}}}
There's nothing wrong with that type, and in principle someone might later define a suitable instance of `Num`, but (a) it's not Haskell 98, and (b) it's unlikely to be right, so we've deferred a type error from the definition site of `f` to the (perhaps much later) call site.

I think GHC should complain, and require a type signature if that's what you really want.  This came up on [http://stackoverflow.com/questions/10091874/haskell-why-is-there-no-type-mismatch-and-why-does-this-compile Stackoverflow]"	simonpj
4	5550	GHC infinite loop when compiling vector	Compiler	7.2.1	low		7.6.2		merge	2011-10-12T01:38:39-0700	2013-04-03T00:43:20-0700	"Bas reports: When benchmarking my new [https://github.com/basvandijk/vector-bytestring vector-bytestring] package I discovered that building the following program causes GHC to go into, what seems to be, an infinite loop:
{{{
import Data.Vector (Vector)
import qualified Data.Vector.Generic as VG

main = print $ VG.foldl f z (VG.fromList [] :: Vector Int)

f = flip (:)
z = []
}}}
I build it with:
{{{
$ ghc --make vectorGHCloop.hs -O2
}}}
It compiles fine without the -O2 or if you specify `-fno-enable-rewrite-rules`. So it's probably a loop in a rule somewhere.

Note that the program also builds fine when I change the 'f' and 'z' to:
{{{
f = (+)
z = 0
}}}

I use vector-0.9 and ghc-7.2.1.

"	simonpj
3	5722	GHC inlines class method forever	Compiler	7.2.1	normal		_|_	simonpj	new	2011-12-23T18:46:29-0800	2011-12-28T06:00:10-0800	"irene-knapp showed me this over IRC, I refined the test case a bit:

{{{
{-# LANGUAGE FlexibleContexts, MultiParamTypeClasses #-}
module Bug () where

class C a b where
  discord :: C a b => a b () -- Remove the constraint and it works
  rhyme :: a b ()

instance C (,) b => C (,) [b] where
  discord = discord
  rhyme = discord
}}}
GHC 7.2.2 compiling this with -O loops forever. I've worked out:
 * The `C a b` context in the class is completely superfluous but the bug isn't triggered without it.
 * The pattern of recursion in the two method signatures is fragile: `rhyme = rhyme` doesn't trigger the bug, for example.
 * Adding a `NOINLINE discord` stops the bug from triggering. Similarly, compiling without optimisations doesn't trigger the bug.
 * While it's looping, GHC slowly but steadily chews through all of your memory."	benmachine
3	7072	GHC interpreter does not find stat64 symbol on Linux	GHCi	7.4.2	normal		7.8.1		new	2012-07-13T02:22:56-0700	2012-10-20T14:32:25-0700	"Mailing list discussion available at: [http://www.haskell.org/pipermail/haskell-cafe/2012-July/102253.html]. The issue is that, when using runghc against a library using the sqlite3 C library (persistent-sqlite), the stat64 symbol is not resolved. After some research, I came up with the following minimal reproducing C code:


{{{
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>

typedef int stat_func(const char*, struct stat*);

stat_func *foo = &stat;

void stat_test(void)
{
	struct stat buf;

	printf(""About to stat-test.c\n"");
	foo(""stat-test.c"", &buf);
	printf(""Done\n"");
}
}}}

When using stat directly, gcc inlines the call and produces assembly which simply makes a system call, thereby avoiding the need for the stat symbol. However, when using a function pointer (as sqlite3 does), the symbol is retained, and then runghc does not resolve it.

In the linked mailing list discussion, Tristan Ravitch found a Stack Overflow thread ([http://stackoverflow.com/questions/5478780/c-and-ld-preload-open-and-open64-calls-intercepted-but-not-stat64]) which explains that the GNU linker has special handling for the stat, stat64, and a few other library functions. glibc itself does not provide those symbols directly, relying on the linker to fix the references. (I could not find reference to this in any official documentation.)

As a workaround, I declared some local functions which call stat and stat64 (patch available at [https://github.com/yesodweb/persistent/commit/d7daf0b2fa401fd97ef62e4e74228146d15d8601]). So there is a workaround available, and therefore this isn't high priority for me. But I do think it's worth some kind of fix.

Without having a good understanding of the GHC interpreter, my guess would be that it needs to replicate the stat/stat64/etc hack that the GNU linker is performing. Of course, this guess may be incorrect.

Tested on Ubuntu 12.04 64-bit, though I believe it will affect any recent version of Linux, whether 32- or 64-bit."	snoyberg
3	5400	GHC loops on compiling with optimizations	Compiler	7.0.4	normal		_|_		new	2011-08-09T22:49:12-0700	2011-09-05T08:40:51-0700	"When compiling the snippet below with optimizations enabled (i.e. `ghc -O test.hs`), GHC does not seem to terminate. This happens with at least 7.0.3 and 7.0.4. Without optimizations, it builds fine.

{{{
data A = A Int

class C a where 
    fromHsk :: C a => a -> Int

instance C Int where 
    fromHsk = fromHsk

instance C A where 
    fromHsk (A s) = fromHsk s

main = undefined

}}}

When building this example with GHC 6.12.4, it fails with a complaint about the bogus type constraints in the declaration of fromHsk:

{{{
test.hs:3:0:
    All of the type variables in the constraint `C a'
    are already in scope (at least one must be universally quantified here)
        (Use -XFlexibleContexts to lift this restriction)
    When checking the class method: fromHsk :: (C a) => a -> Int
    In the class declaration for `C'
}}}

After removing these unneeded constraint (i.e. changing the declaration of `fromHsk` to `fromHsk :: a -> Int`, the snippet above builds even with GHC 7.0.4 and optimizations."	noschinl
2	5539	GHC panic -  Simplifier ticks exhausted	Compiler	7.3	high		7.6.2	simonpj	new	2011-10-08T15:05:07-0700	2013-03-22T03:27:54-0700	"When trying to install `blaze-builder` with a freshly installed GHC 7.3.20111007 linux/amd64 build, the following panic occurs:

{{{
$ cabal install  blaze-builder
Resolving dependencies...
Configuring blaze-builder-0.3.0.1...
Building blaze-builder-0.3.0.1...
Preprocessing library blaze-builder-0.3.0.1...
...
[10 of 13] Compiling Blaze.ByteString.Builder.HTTP ( Blaze/ByteString/Builder/HTTP.hs, dist/build/Blaze/ByteString/Builder/HTTP.o )
[11 of 13] Compiling Blaze.ByteString.Builder.Int ( Blaze/ByteString/Builder/Int.hs, dist/build/Blaze/ByteString/Builder/Int.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.3.20111007 for x86_64-unknown-linux):
	Simplifier ticks exhausted
    When trying UnfoldingDone a_s9oE{v} [lid]
    To increase the limit, use -fsimpl-tick-factor=N (default 100)
    If you need to do this, let GHC HQ know, and what factor you needed
    To see detailed counts use -ddump-simpl-stats
    Total ticks: 5123

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}"	hvr
3	7687	ghc panic on TH and deriveJSON	Template Haskell	7.4.2	normal		7.8.1		new	2013-02-13T17:21:32-0800	2013-04-13T05:09:55-0700	"{{{
{-# LANGUAGE CPP,TemplateHaskell #-}
module Main (main) where

import Data.Aeson.TH
data Test     = Test Int deriving Show
deriveJSON id ''Test
main = return ()
}}}
will give
{{{
Building aeson-test-0.0.1...
Preprocessing test suite 'test-aeson-test' for aeson-test-0.0.1...
[1 of 1] Compiling Main             ( src\Main.hs, dist\build\test-aeson-test\test-aeson-test-tmp\Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
ghc.exe: panic! (the 'impossible' happened)
Loading package text-0.11.2.3 ... linking ... done.
  (GHC version 7.4.2 for i386-unknown-mingw32):
Loading package attoparsec-0.10.4.0 ... linking ... done.
	loadObj ""C:\\Users\\User\\AppData\\Roaming\\cabal\\hashable-1.2.0.5\\ghc-7.4.2\\HShashable-1.2.0.5.o"": failed
Loading package blaze-builder-0.3.1.0 ... linking ... done.

Loading package dlist-0.5 ... linking ... done.
Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Loading package hashable-1.2.0.5 ... 

ghc.exe: Unknown PEi386 section name `.text.startup' (while processing: C:\Users\User\AppData\Roaming\cabal\hashable-1.2.0.5\ghc-7.4.2\HShashable-1.2.0.5.o)
}}}
"	guest
5	3960	ghc panic when attempting to compile DPH code	Data Parallel Haskell	6.12.1	lowest		7.6.2	rl	new	2010-04-05T15:13:28-0700	2012-09-12T04:14:15-0700	"the function ""tmpfn"" in the attached code causes ghc to panic (the 'impossible' happened).  This bug is present in ghc 6.12.1 and 6.13.20100226
{{{
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.1 for i386-apple-darwin):
	VectMonad.lookupFamInst: not found: 
    dph-seq:Data.Array.Parallel.Lifted.PArray.PData{tc rq5}
      (dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         ghc-prim:GHC.Types.Double{(w) tc 3u},
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         ghc-prim:GHC.Types.Double{(w) tc 3u},
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         (dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
            (ghc-prim:GHC.Types.Int{(w) tc 3J},
             ghc-prim:GHC.Types.Double{(w) tc 3u})),
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         ghc-prim:GHC.Types.Double{(w) tc 3u},
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         (dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
            (ghc-prim:GHC.Types.Int{(w) tc 3J},
             ghc-prim:GHC.Types.Double{(w) tc 3u})),
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         ghc-prim:GHC.Types.Double{(w) tc 3u})
}}}"	jwlato
5	1012	ghc panic with mutually recursive modules and template haskell	Template Haskell	6.8.2	lowest	normal	7.6.2		new	2006-11-18T18:03:49-0800	2013-05-02T08:01:29-0700	"When compiling the files below using ghc --make Main.hs I get the following error:
{{{
[1 of 5] Compiling ModuleA[boot]    ( ModuleA.hs-boot, nothing )
[2 of 5] Compiling ModuleC          ( ModuleC.hs, ModuleC.o )
[3 of 5] Compiling ModuleB          ( ModuleB.hs, ModuleB.o )
Loading package base ... linking ... done.
Loading package template-haskell ... linking ... done.
ghc-6.6: panic! (the 'impossible' happened)
  (GHC version 6.6 for powerpc-apple-darwin):
        Maybe.fromJust: Nothing
}}}


ModuleA.hs:
{{{
module ModuleA where

import ModuleB
}}}

ModuleA.hs-boot:
{{{
module ModuleA where
}}}

ModuleB.hs:
{{{
{-# OPTIONS -fth #-}
module ModuleB where

import ModuleC

$(nothing)
}}}

ModuleC.hs:
{{{
module ModuleC where

import Language.Haskell.TH

import {-# SOURCE #-} ModuleA

nothing = return [] :: Q [Dec]
}}}

Main.hs:
{{{
module Main.hs

import ModuleA

main = return ()
}}}"	guest
5	3915	GHC panic; possibly related to mutually recursive modules	Compiler	6.12.1	lowest		7.6.2		new	2010-03-07T17:50:59-0800	2012-09-12T04:14:15-0700	GHC panics when an instance block is uncommented in State.hs in http://patch-tag.com/r/bob/Domination.  The attached patch uncomments it.   It might be related to mutually recursive modules.	bob
3	7729	GHC panics. Invalid core	Compiler	7.6.2	normal		7.6.3		new	2013-03-01T08:15:07-0800	2013-03-11T01:52:00-0700	"Following code snippet triggers panic:

{{{
{-# LANGUAGE FlexibleContexts, TypeFamilies #-}
module Monad where

class Monad m => PrimMonad m where
  type PrimState m

class MonadTrans t where
  lift :: Monad m => m a -> t m a

class (PrimMonad (BasePrimMonad m), Monad m) => MonadPrim m where
  type BasePrimMonad m :: * -> *
  liftPrim :: BasePrimMonad m a -> m a


newtype Rand m a = Rand {
  runRand :: Maybe (m ()) -> m a
  }

instance (Monad m) => Monad (Rand m) where
  return           = Rand . const . return
  (Rand rnd) >>= f = Rand $ \g -> (\x -> runRand (f x) g) =<< rnd g

instance MonadTrans Rand where
  lift = Rand . const

instance MonadPrim m => MonadPrim (Rand m) where
  type BasePrimMonad (Rand m) = BasePrimMonad m
  liftPrim = liftPrim . lift
}}}

GHC 7.6.2 panics
{{{
$ ghc-7.6.2 -c Monad.hs 
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.2 for x86_64-unknown-linux):
        cgLookupPanic (probably invalid Core; try -dcore-lint)
    $dMonadTrans{v ahe} [lid]
    static binds for:
    local binds for:
    main:Monad.lift{v ra} [gid[ClassOp]]
    main:Monad.liftPrim{v rc} [gid[ClassOp]]
    main:Monad.$p1PrimMonad{v rgv} [gid[ClassOp]]
    main:Monad.$p1MonadPrim{v rgA} [gid[ClassOp]]
    main:Monad.$p2MonadPrim{v rgB} [gid[ClassOp]]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}

whereas 7.4.2 reports type error
{{{
$ ghc-7.4.2 -c Monad.hs 

Monad.hs:28:14:
    Occurs check: cannot construct the infinite type: m0 = t0 m0
    Expected type: BasePrimMonad (Rand m) a -> Rand m a
      Actual type: m0 a -> Rand m a
    In the expression: liftPrim . lift
    In an equation for `liftPrim': liftPrim = liftPrim . lift
}}}"	Khudyakov
3	5615	ghc produces poor code for `div` with constant powers of 2.	Compiler	7.4.1-rc1	normal		7.6.2	daniel.is.fischer	new	2011-11-09T01:38:08-0800	2013-04-21T10:37:51-0700	"The code for Int {{{(div x c)}}} where {{{c}}} is a constant of the form 2^n^ should be implemented with an arithmetic right shift, currently it's a call to a function.  This optimization should be done for all signed types.

"	Lennart
4	4124	GHC rejects instance quotations with splices in the instance head	Template Haskell	6.12.1	low		7.6.2		new	2010-06-08T15:35:45-0700	2012-09-12T04:12:25-0700	"I think the following code should be accepted.

{{{
{-# LANGUAGE TemplateHaskell #-}
class Storable a where
data X = X
[d| instance Storable $( [t| X |] ) where |]
}}}

GHC disagrees, saying:

{{{
test.hs:4:4:
    Illegal instance declaration for `Storable t_aKj'
        (All instance types must be of the form (T a1 ... an)
         where a1 ... an are type *variables*,
         and each type variable appears at most once in the instance head.
         Use -XFlexibleInstances if you want to disable this.)
    In the instance declaration for `Storable $[t| X |]'
    In the Template Haskell quotation
      [d| 
          instance Storable $[t| X |] where |]
    In the expression:
        [d| 
            instance Storable $[t| X |] where |]
}}}

This checking seems inappropriate before the type is actually spliced in!"	lilac
3	6047	GHC retains unnecessary binding	Compiler	7.4.1	normal		7.6.2	simonpj	new	2012-04-26T01:13:23-0700	2012-09-12T04:12:14-0700	"milan posted this example on #6042, I'm making a separate ticket for it.  He says:

----------

BTW, when I preparing for the advanced functional programming course, I found out that the following code

{{{
module Test where
factorial :: Int -> Int
factorial n | n > 0 = f n 1
  where f 0 acc = acc
        f n acc = f (n-1) (n * acc)
}}}

produces the following STG, on both GHC 7.0.4 and 7.4.1, with unused method `factorial_f`:

{{{
Test.factorial2 =
    \u srt:(0,*bitmap*) []
        Control.Exception.Base.patError
            ""a.hs:(4,1)-(6,35)|function factorial"";
SRT(Test.factorial2): [Control.Exception.Base.patError]
Test.$wf =
    \r [ww_srk ww1_sro]
        case ww_srk of wild_srm {
          __DEFAULT ->
              case *# [wild_srm ww1_sro] of sat_srK {
                __DEFAULT ->
                    case -# [wild_srm 1] of sat_srL {
                      __DEFAULT -> Test.$wf sat_srL sat_srK;
                    };
              };
          0 -> ww1_sro;
        };
SRT(Test.$wf): []
Test.factorial_f =
    \r [w_srs w1_srv]
        case w_srs of w2_srN {
          GHC.Types.I# ww_sry ->
              case w1_srv of w3_srM {
                GHC.Types.I# ww1_srz ->
                    case Test.$wf ww_sry ww1_srz of ww2_srB {
                      __DEFAULT -> GHC.Types.I# [ww2_srB];
                    };
              };
        };
SRT(Test.factorial_f): []
Test.factorial1 = NO_CCS GHC.Types.I#! [1];
SRT(Test.factorial1): []
Test.factorial =
    \r srt:(0,*bitmap*) [n_srD]
        case n_srD of wild_srP {
          GHC.Types.I# x_srG ->
              case ># [x_srG 0] of wild1_srO {
                GHC.Types.False -> Test.factorial2;
                GHC.Types.True ->
                    case Test.$wf x_srG 1 of ww_srJ {
                      __DEFAULT -> GHC.Types.I# [ww_srJ];
                    };
              };
        };
SRT(Test.factorial): [Test.factorial2]
}}}

The `Test.factorial_f` appears also in asm and in the object file.
----------

simonpj explained to me why this is happening: `factorial_f` is being retained because it is referenced in an INLINE pragma for `factorial`.  In fact it will never be used, because `factorial_f` itself is also INLINE.

We're going to investigate possible workarounds/solutions.

Note it's only a code size issue, performance is not affected (compile time is affected a little though).  We're not sure how much it happens.
"	simonmar
3	1290	ghc runs preprocessor too much	Driver	6.7	normal	normal	_|_		new	2007-04-26T03:24:21-0700	2013-01-21T15:38:13-0800	"When an external preprocessor has been specified with -F -pgmF, and then using ghc --make, ghc runs the preprocessor on every .hs file, even those for which compilation is skipped.  This seem unnecessary and it slows down recompilation significantly when you have many files.

  -- Lennart"	guest
2	7316	GHC segfaults on ARM	Compiler	7.4.2	high		7.6.2		new	2012-10-09T12:33:25-0700	2013-05-10T12:58:08-0700	"Sorry for the lack of detail. I thought I'd file this upstream. We've been seeing this in Ubuntu with 7.4.2. Some cabal packages, like chell, fail to build with a segfault in ghc.

{{{
[3 of 4] Compiling Test.Chell.Main  ( lib/Test/Chell/Main.hs, dist-ghc/build/Test/Chell/Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package time-1.4 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package patience-0.1.1 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package monads-tf-0.1.0.0 ... linking ... done.
Loading package text-0.11.2.0 ... linking ... done.
Loading package system-filepath-0.4.6 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package options-0.1.1 ... linking ... done.
make: *** [build-ghc-stamp] Error 11
}}}

Full build log attached. I'll try to reduce the example and/or reproduce with 7.6 soon. (I can also provide you with SSH access to hardware if you need it)."	laney
4	2182	ghc sessions (--make, --interactive, ghc api) erroneously retain instances	GHCi	6.9	low	normal	_|_		new	2008-03-27T17:07:54-0700	2008-09-30T08:52:09-0700	"{{{
$ compiler/stage2/ghc-inplace --interactive
GHCi, version 6.9.20080317: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
Prelude> :i Functor
class Functor f where fmap :: (a -> b) -> f a -> f b
        -- Defined in GHC.Base
instance Functor Maybe -- Defined in Data.Maybe
instance Functor [] -- Defined in GHC.Base
instance Functor IO -- Defined in GHC.IOBase
Prelude> fmap not (True,True)

<interactive>:1:0:
    No instance for (Functor ((,) Bool))
      arising from a use of `fmap' at <interactive>:1:0-19
    Possible fix: add an instance declaration for (Functor ((,) Bool))
    In the expression: fmap not (True, True)
    In the definition of `it': it = fmap not (True, True)
Prelude> :m +Data.Array
Prelude Data.Array> :i Functor
class Functor f where fmap :: (a -> b) -> f a -> f b
        -- Defined in GHC.Base
instance (Ix i) => Functor (Array i) -- Defined in GHC.Arr
instance Functor ((->) r) -- Defined in Control.Monad.Instances
instance Functor ((,) a) -- Defined in Control.Monad.Instances
instance Functor (Either a) -- Defined in Control.Monad.Instances
instance Functor Maybe -- Defined in Data.Maybe
instance Functor [] -- Defined in GHC.Base
instance Functor IO -- Defined in GHC.IOBase
Prelude Data.Array> fmap not (True,True)
(True,False)
Prelude Data.Array> :m -Data.Array
Prelude> :i Functor
class Functor f where fmap :: (a -> b) -> f a -> f b
        -- Defined in GHC.Base
instance Functor ((->) r) -- Defined in Control.Monad.Instances
instance Functor ((,) a) -- Defined in Control.Monad.Instances
instance Functor (Either a) -- Defined in Control.Monad.Instances
instance Functor Maybe -- Defined in Data.Maybe
instance Functor [] -- Defined in GHC.Base
instance Functor IO -- Defined in GHC.IOBase
Prelude> fmap not (True,True)
(True,False)
}}}"	claus
2	7678	GHC should compile cleanly with clang	Compiler	7.7	high		7.8.1	thoughtpolice	new	2013-02-10T00:35:36-0800	2013-04-14T00:14:02-0700	"I'm running into several difficulties (which I'll catalog shortly) building GHC HEAD with Clang 3.2. These mostly seem to be difficulties relating to the preprocessor and the fact clang does not really respect ```-traditional-cpp``` mode, and that it is stricter than gcc about whitespace and whatnot too. This means code like:

{{{

{-# RULES

 ""thing"" ...

  #-}

}}}

becomes invalid: ```clang``` is strict about the fact that preprocessor definitions must occur on the beginning of a line. There seems to be a bug in the preprocessor directive source code to this effect (that it doesn't handle whitespace before a directive.) It's quite unfortunate, because we do this a lot.

This also causes build failures in the parser due to some crazy CPP hackery we do. I'll follow up with that shortly.

As a workaround, we may have to force ```CPP``` to just continue being ```cpp``` which will Do The Right Thing, while ```CC``` will use ```clang``` instead. Or we'll have to have some script that seds whitespace out or something.

This currently blocks #7602 since I can't test my fix otherwise."	thoughtpolice
3	5448	GHC stuck in infinite loop compiling with optimizations	Compiler	7.0.3	normal		_|_		new	2011-08-31T16:09:28-0700	2011-12-28T06:00:43-0800	"GHC gets stuck compiling the attached program. 
Removing 'deriving Eq' from the last line restores GHC's ability to terminate.

Is this the same as the [http://haskell.org/ghc/docs/6.12.2/html/users_guide/bugs.html inliner loop bug]?  Who knows."	ronwalf
3	7190	GHC's -fprof-auto does not work with LINE pragmas	Profiling	7.4.2	normal		7.8.1		new	2012-08-26T11:46:41-0700	2013-04-12T07:07:25-0700	"Please note the difference between the two .prof files created. The ""profnopragma"" one contains a ""main"" and the ""profpragma"" one doesn't.  I came across this problem profiling a much larger source. In that case, ghc failed to profile anything within my source code at all!

{{{
[timothy@timothy haskell]$ cat profpragma.hs
f=""hi""{-# LINE 1 ""hi.hs"" #-}
main :: IO (){-# LINE 2 ""hi.hs"" #-}
main = print f{-# LINE 3 ""hi.hs"" #-}
[timothy@timothy haskell]$ cat profnopragma.hs
f=""hi""
main :: IO ()
main = print f
[timothy@timothy haskell]$ ghc profpragma.hs -prof -fprof-auto
[timothy@timothy haskell]$ ghc profnopragma.hs -prof -fprof-auto
[timothy@timothy haskell]$ ./profpragma +RTS -p
""hi""
[timothy@timothy haskell]$ ./profnopragma +RTS -p
""hi""
[timothy@timothy haskell]$ cat profpragma.prof 
	Sun Aug 26 20:30 2012 Time and Allocation Profiling Report  (Final)

	   profpragma +RTS -p -RTS

	total time  =        0.00 secs   (0 ticks @ 1000 us, 1 processor)
	total alloc =      49,704 bytes  (excludes profiling overheads)

COST CENTRE MODULE           %time %alloc

CAF         GHC.IO.Encoding    0.0    5.6
CAF         GHC.IO.Handle.FD   0.0   69.8
CAF         GHC.Conc.Signal    0.0    1.4
CAF         Main               0.0   21.7


                                                      individual     inherited
COST CENTRE MODULE                  no.     entries  %time %alloc   %time %alloc

MAIN        MAIN                     46           0    0.0    0.7     0.0  100.0
 CAF        Main                     91           0    0.0   21.7     0.0   22.1
  f         Main                     92           1    0.0    0.3     0.0    0.3
 CAF        GHC.Conc.Signal          87           0    0.0    1.4     0.0    1.4
 CAF        GHC.IO.Handle.FD         85           0    0.0   69.8     0.0   69.8
 CAF        GHC.IO.Encoding          80           0    0.0    5.6     0.0    5.6
 CAF        GHC.IO.Encoding.Iconv    66           0    0.0    0.5     0.0    0.5
[timothy@timothy haskell]$ cat profnopragma.prof 
	Sun Aug 26 20:30 2012 Time and Allocation Profiling Report  (Final)

	   profnopragma +RTS -p -RTS

	total time  =        0.00 secs   (0 ticks @ 1000 us, 1 processor)
	total alloc =      49,704 bytes  (excludes profiling overheads)

COST CENTRE MODULE           %time %alloc

CAF         GHC.IO.Encoding    0.0    5.6
CAF         GHC.IO.Handle.FD   0.0   69.8
CAF         GHC.Conc.Signal    0.0    1.4
main        Main               0.0   20.8


                                                      individual     inherited
COST CENTRE MODULE                  no.     entries  %time %alloc   %time %alloc

MAIN        MAIN                     46           0    0.0    0.7     0.0  100.0
 CAF        Main                     91           0    0.0    0.9     0.0   22.1
  f         Main                     93           1    0.0    0.3     0.0    0.3
  main      Main                     92           1    0.0   20.8     0.0   20.8
 CAF        GHC.Conc.Signal          87           0    0.0    1.4     0.0    1.4
 CAF        GHC.IO.Handle.FD         85           0    0.0   69.8     0.0   69.8
 CAF        GHC.IO.Encoding          80           0    0.0    5.6     0.0    5.6
 CAF        GHC.IO.Encoding.Iconv    66           0    0.0    0.5     0.0    0.5

}}}
"	timthelion
2	6063	GHC's build-time ld-flag checks are problematic	Compiler	7.4.1	high		7.8.1	thoughtpolice	patch	2012-04-30T09:05:27-0700	2013-05-04T19:28:32-0700	"If the linker that GHC was built against happened to recognize the `--hash-size` and `--reduce-memory-overhead` flags, but the current system linker does not, GHC will indiscriminately pass those flags to the current linker when attempting to link anything, and the linking will fail due to an 'unrecognized option' error.

I have experienced this behavior when I upgraded to GHC 7.4.1 on debian. The GHC package in question was built against `bfd ld`, which recognized those linker flags, but my system linker is `gold`, which does not recognized those flags. Therefore, I could not build anything until i reverted to `bfd ld`.

(Relevant commits: 3275b7bd2a803a3adc0b952b6fbfeb738fc15a74 and 9ccb59ed6e5edf73c876e87429e69e8848162497)"	parcs
5	3061	GHC's GC default heap growth strategy is not as good as other runtimes	Runtime System	6.10.1	lowest	normal	7.6.2		new	2009-03-02T18:07:36-0800	2012-09-12T04:14:08-0700	"This is a GC performance ticket. The benchmark is the binary-trees benchmark, and the issue is whether or not GHC's ability to grow the heap without a heap check is comparably worse than other similar language runtimes. 

Looking at the binary-trees benchmark, we see that GHC does very well on a parallel system, when we give a GC hint to the size.

E.g. the attached binary-trees program is very very competitive:

Compile with:

{{{
    ghc -O2 -fasm --make -threaded A.hs 
}}}

Run with:

{{{
    $ /A 20  +RTS -N4 -H340M
}}}

And we get:

{{{
    $ time ./A +RTS -N4 -H340M -RTS 20          
stretch tree of depth 21	 check: -1
2097152	 trees of depth 4	 check: -2097152
524288	 trees of depth 6	 check: -524288
131072	 trees of depth 8	 check: -131072
32768	 trees of depth 10	 check: -32768
8192	 trees of depth 12	 check: -8192
2048	 trees of depth 14	 check: -2048
512	 trees of depth 16	 check: -512
128	 trees of depth 18	 check: -128
32	 trees of depth 20	 check: -32
long lived tree of depth 20	 check: -1
./A +RTS -N4 -H340M -RTS 20  17.08s user 0.30s system 315% cpu 5.511 total
}}}

However, without that GC hint performance deteriorates dramatically,

{{{
$ time ./A +RTS -N4  -RTS 20      
stretch tree of depth 21	 check: -1
2097152	 trees of depth 4	 check: -2097152
524288	 trees of depth 6	 check: -524288
131072	 trees of depth 8	 check: -131072
32768	 trees of depth 10	 check: -32768
8192	 trees of depth 12	 check: -8192
2048	 trees of depth 14	 check: -2048
512	 trees of depth 16	 check: -512
128	 trees of depth 18	 check: -128
32	 trees of depth 20	 check: -32
long lived tree of depth 20	 check: -1
./A +RTS -N4 -RTS 20  33.83s user 0.42s system 136% cpu 25.033 total
}}}

So 5x slow down. 

Could the GC heap growth algorithm be tuned? Other language runtimes, that are slower than Haskell's on this benchmark when our GC hint is in play, don't seem to suffer as badly without the hint:

    http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all

See e.g. Erlang. So: is there a better growth algorithm?



"	dons
3	7296	ghc-7 assumes incoherent instances without requiring language `IncoherentInstances`	Compiler (Type checker)	7.6.1	normal		7.8.1	simonpj	new	2012-10-04T05:50:04-0700	2013-04-12T07:58:10-0700	"the attached examples works with ghc-7 and returns

{{{
    *Main> a
    [Spec1 Spec2]
    *Main> b
    []
}}}

(One may wish that b also returned [Spec1 Spec2])

ghc-6 complains with

{{{
Splittable.hs:16:36:
    Overlapping instances for Test a Spec2
      arising from a use of `test' at Splittable.hs:16:36-43
    Matching instances:
      instance [overlap ok] Test a Spec2
        -- Defined at Splittable.hs:20:13-24
      instance [overlap ok] Test Bool Spec2
        -- Defined at Splittable.hs:25:13-27
    (The choice depends on the instantiation of `a'
     To pick the first instance above, use -XIncoherentInstances
     when compiling the other instance declarations)
    In the second argument of `($)', namely `test a b'
    In the expression: map Spec1 $ test a b
    In the definition of `test':
        test a (Spec1 b) = map Spec1 $ test a b
Failed, modules loaded: none.
}}}

After adding `IncoherentInstances` the file also goes through ghc-6 with the same results.
"	maeder
3	6149	ghc-7.4.2 tests for profasm seg-fault under solaris	Compiler	7.4.2-rc1	normal		7.8.1		new	2012-06-07T04:10:19-0700	2012-10-12T12:44:23-0700	"I've compiled http://www.haskell.org/ghc/dist/stable/dist/ghc-7.4.2-src.tar.bz2 from 05-Jun-2012 under x86 solaris.

The results of running the testsuite will be attached.
Can these failures be observed on kgardas-opensolaris-x86-head, too?
"	maeder
2	7143	ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version	Compiler (LLVM)	7.6.1-rc1	high		7.8.1	dterei	new	2012-08-13T19:59:48-0700	2013-01-17T20:17:08-0800	"I have downloaded:

ghc: ghc-7.6.0.20120810-x86_64-windows.exe

mingw64: http://www.drangon.org/mingw/mirror.php?num=2&fname=mingw-w64-bin-x86_64-20120807.7z 

llvm64: http://www.drangon.org/mingw/mirror.php?num=2&fname=llvm-3.1-w64-bin-x86_64-20120610.7z

my path contains:

{{{
/c/ghc/ghc-7.6.0.20120810/bin:/c/Users/Cetin/AppData/Roaming/cabal/bin:/c/llvm/bin:/c/mw64/bin
}}}


When I run:

{{{
ghc -fllvm --make Main.hs
}}}

I get:

{{{
[1 of 1] Compiling Main             ( Main.hs, Main.o )

<no location info>:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM
}}}

Attached is the output from:

{{{
ghc -v3 -fllvm --make Main.hs
}}}

for all Main.hs - it mentions:

{{{
*** LlVM CodeGen:
Error (figuring out LLVM version): : runInteractiveProcess: invalid argument (Invalid argument)

<no location info>:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM
*** LLVM Optimiser:
"""" ""C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.ll"" ""-o"" ""C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.bc"" ""-mem2reg"" ""--enable-tbaa=true""


Failed: """" ""C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.ll"" ""-o"" ""C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.bc"" ""-mem2reg"" ""--enable-tb
}}}"	cetinsert
1	7134	ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32	GHCi	7.6.1-rc1	highest		7.8.1	igloo	new	2012-08-12T18:18:53-0700	2013-03-13T05:44:48-0700	"I downloaded ghc-7.6.0.20120810-x86_64-windows.exe and attempting to run GHCi dumps the following error message:

{{{
C:\Users\Cetin>ghci
GHCi, version 7.6.0.20120810: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error: R_X86_64_PC32: Hig
h bits are set in 7f9585f95a0 for WaitForSingleObject
    (GHC version 7.6.0.20120810 for x86_64_unknown_mingw32)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

}}}

Tested on Windows 8 Release Preview 64-bit."	cetinsert
3	7241	GHC-7.6.1 panics on template haskell code	Template Haskell	7.6.1	normal		7.8.1	simonpj	new	2012-09-14T14:55:09-0700	2012-10-14T17:24:48-0700	"While experimenting with TH I stumbled upon a repeating compiler panic. After minifying I got this example which triggers the failure:


{{{
% cat Peekler.hs
module Peekler where

import Language.Haskell.TH

tst = do
  o <- newName ""Foo""
  return $ [DataD [] o [] [RecC o []] [''Show]]
}}}



{{{
% cat PeeklerTest.hs
module PeeklerTest where

import Peekler

$(tst)

test = print Foo
}}}



{{{
% ghci -XTemplateHaskell PeeklerTest.hs             
GHCi, version 7.6.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 2] Compiling Peekler          ( Peekler.hs, interpreted )
[2 of 2] Compiling PeeklerTest      ( PeeklerTest.hs, interpreted )
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.1 for i386-unknown-linux):
        lookupExactOcc
<<details unavailable>>

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

> 
Leaving GHCi.
}}}





{{{
% ghc  -XTemplateHaskell PeeklerTest.hs
[1 of 2] Compiling Peekler          ( Peekler.hs, Peekler.o )
[2 of 2] Compiling PeeklerTest      ( PeeklerTest.hs, PeeklerTest.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.1 for i386-unknown-linux):
        lookupExactOcc
    Foo_a18S{tc}
    [main:PeeklerTest.Foo{tc a18S} defined at PeeklerTest.hs:5:3,
     main:PeeklerTest.Foo{d a18S} defined at PeeklerTest.hs:5:3]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}



{{{
% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04.1 LTS
Release:        12.04
Codename:       precise
}}}

"	akamaus
3	7329	ghc-7.6.1 win64: internal error: R_X86_6 4_PC32: High bits are set in WSAGetLastError	GHCi	7.6.1	normal		7.8.1		new	2012-10-14T11:00:25-0700	2013-04-12T08:47:32-0700	"While updating cabal-dev to build against ghc-7.6 and cabal 1.16, I got the following error during linking:
{{{
[ 8 of 19] Compiling Distribution.Dev.CabalInstall ( src\Distribution\Dev\CabalInstall.hs, dist\build\cabal-dev\cabal-dev-tmp\Distribution\Dev\CabalInstall.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.0 ... linking ... done.
Loading package zlib-0.5.4.0 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package Win32-2.3.0.0 ... linking ... done.
Loading package filepath-1.3.0.1 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package directory-1.2.0.0 ... linking ... done.
Loading package old-time-1.1.0.1 ... linking ... done.
Loading package tar-0.4.0.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.2.3 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package network-2.4.0.1 ... linking ... ghc.exe: internal error: R_X86_64_PC32: High bits are set in 7fef1cec8ed for WSAGetLastError
    (GHC version 7.6.1 for x86_64_unknown_mingw32)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Failed to install cabal-dev-0.9.1
cabal.exe: Error: some packages failed to install:
cabal-dev-0.9.1 failed during the building phase. The exception was:
ExitFailure 255
}}}

At least on my system this is a reproducible crash. I'm using windows 7, 64bit with the 64bit GHC.

{{{
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.1
$ cabal --version
cabal-install version 1.16.0
using version 1.16.0.1 of the Cabal library
$ cabal-dev --version
cabal-dev 0.9
built with Cabal 1.10.1.0
}}}

The command that causes the crash here is to simply run `cabal-dev install` on my locally modify source for cabal-dev:
{{{
The top commit in my local branch is:
commit 1a0cadb226b3a0ba65b762172e20e6d2033fc3a3
Merge: 0c5752b 6db5e32
Author: Jonathan Daugherty <jtd@galois.com>
Date:   Wed Jun 27 12:25:02 2012 -0700

    Merge pull request #61 from jonathanjouty/patch-1

    Minor typo in README.md
}}}

If you want to try reproducing this, my Git diff looks like this:
{{{
diff --git a/cabal-dev.cabal b/cabal-dev.cabal
index 5c25721..684591a 100644
--- a/cabal-dev.cabal
+++ b/cabal-dev.cabal
@@ -49,7 +49,7 @@ Bug-Reports:         http://github.com/creswick/cabal-dev/issues
 Copyright:           2010-2012 Galois, Inc.
 Category:            Development
 Build-type:          Custom
-Cabal-version:       >=1.6
+Cabal-version:       >=1.14
 Data-Files:
   admin/cabal-config.in,
   admin/00-index.tar
@@ -78,6 +78,7 @@ Executable cabal-dev
   Main-is: Main.hs
   GHC-Options: -Wall
   Extensions: TemplateHaskell
+  default-language: Haskell2010
 
   if flag(no-cabal-dev)
     Buildable: False
@@ -93,7 +94,7 @@ Executable cabal-dev
     -- avoid using it:
     if impl(ghc >= 6.12)
       Build-depends:
-        containers >= 0.3 && < 0.5
+        containers >= 0.3
 
     -- Require this specific version that came with GHC 6.10 because
     -- of packaging problems with containers-0.2
@@ -106,18 +107,18 @@ Executable cabal-dev
         containers == 0.1.0.2
 
     Build-depends:
-      bytestring >= 0.9 && < 0.10,
-      directory >= 1.0 && < 1.3,
-      filepath >= 1.1 && < 1.4,
-      Cabal >= 1.10.0.0 && < 1.15,
-      HTTP >= 4000.0.9 && < 4000.3,
-      mtl >= 1.1 && < 2.2,
-      network >= 2.2 && < 2.4,
-      pretty >= 1.0 && < 1.2,
-      process >= 1.0 && < 1.2,
-      tar >= 0.3 && < 0.4,
-      zlib >= 0.5 && < 0.6,
-      transformers >= 0.2 && < 0.4,
+      bytestring >= 0.9,
+      directory >= 1.0,
+      filepath >= 1.1,
+      Cabal >= 1.10.0.0,
+      HTTP >= 4000.0.9,
+      mtl >= 1.1,
+      network >= 2.2,
+      pretty >= 1.0,
+      process >= 1.0,
+      tar >= 0.3,
+      zlib >= 0.5,
+      transformers >= 0.2,
 
       -- Template haskell is special: the compiler will die if a
       -- version other than the one that is shipped with the compiler
@@ -126,7 +127,7 @@ Executable cabal-dev
       template-haskell
 
   if os(windows)
-     build-depends: Win32 >= 2.1  && < 2.3
+     build-depends: Win32 >= 2.1
 
   Build-tools:
     cabal >= 0.8.2
@@ -154,15 +155,17 @@ Executable ghc-pkg-6_8-compat
   Main-is: GhcPkgCompat.hs
   Build-Depends:
     base < 5,
-    Cabal >=1.2 && < 1.15
+    Cabal >=1.2
 
   GHC-Options: -Wall
   HS-Source-Dirs: src
+  default-language: Haskell2010
 
 Executable cabal-dev-test
   Main-is: RunTests.hs
   GHC-Options: -Wall
   HS-Source-Dirs: src, test
+  default-language: Haskell2010
   if flag(no-cabal-dev) || !flag(build-tests)
     Buildable: False
   else
@@ -174,17 +177,18 @@ Executable cabal-dev-test
         base >= 3 && < 4
 
     Build-depends:
-      MonadRandom >= 0.1 && < 0.2,
-      random >= 1 && < 1.1,
-      test-framework >= 0.3 && < 0.6,
+      MonadRandom >= 0.1,
+      random >= 1,
+      test-framework >= 0.3,
       test-framework-hunit >= 0.2,
-      HUnit >= 1.2 && <2
+      HUnit >= 1.2
 
   if os(windows)
-     build-depends: Win32 >= 2.1  && < 2.3
+     build-depends: Win32 >= 2.1
 
 
 Executable fake-ghc-cabal-dev
+  default-language: Haskell2010
   HS-Source-Dirs: src/
   Build-depends: base
   Main-is: FakeGhc.hs
diff --git a/src/Distribution/Dev/RewriteCabalConfig.hs b/src/Distribution/Dev/RewriteCabalConfig.hs
index d4ce0f6..e39bde4 100644
--- a/src/Distribution/Dev/RewriteCabalConfig.hs
+++ b/src/Distribution/Dev/RewriteCabalConfig.hs
@@ -18,6 +18,7 @@ module Distribution.Dev.RewriteCabalConfig
     )
 where
 
+import Control.Exception         ( catch, SomeException(SomeException) )
 import Control.Applicative       ( Applicative, pure, (<$>) )
 import Data.Maybe                ( fromMaybe )
 import Data.Traversable          ( traverse, Traversable )
@@ -39,7 +40,7 @@ readConfig s = case readFields s of
 -- XXX: we should avoid this lazy IO that leaks a file handle.
 readConfigF :: FilePath -> IO (Either String [Field])
 readConfigF fn =
-    (readConfig <$> readUTF8File fn) `catch` \e -> return $ Left $ show e
+    (readConfig <$> readUTF8File fn) `catch` \(SomeException e) -> return $ Left $ show e
 
 readConfigF_ :: FilePath -> IO [Field]
 readConfigF_ fn = either error id <$> readConfigF fn
}}}"	dagit
4	3739	ghc-cabal mishandles relative paths in arguments	Build System		low		7.6.2		new	2009-12-09T10:50:29-0800	2012-09-12T04:12:20-0700	"Just making a record of this one, don't expect it to get fixed in a hurry

ghc-cabal chdirs into the source directory when it runs, because cabal wants to run there. Unfortunately this means relative paths in the arguments are treated as relative to the cabal file, rather than the directory where ghc-cabal was invoked. This is notably an issue for --package-db, which currently requires an absolute path in order to avoid this issue.

(This appears to be the last thing in ghc which needs an absolute path; when it's gone, a lot of things become simpler)"	asuffield
4	4048	ghc-pkg should check for existence of extra-libraries	Package system	6.12.2	low		7.6.2		new	2010-05-05T06:30:01-0700	2012-09-12T04:12:23-0700	"In #3930 we decided that all `extra-libraries` should be found either on the system search path or the paths in the package's `library-dirs` field.  We should make `ghc-pkg` check this when registering a package - it can use `gcc -print-search-dirs` to get the system search path.
"	simonmar
2	5442	ghc-pkg unregister --user/--global/--package-conf not normative	ghc-pkg	7.2.1	high		7.8.1		new	2011-08-30T12:43:36-0700	2012-11-17T07:53:05-0800	"For package P,

""ghc-pkg unregister --user P"" drops the global package if P is not in user.

""ghc-pkg unregister --global P"" drops the user package if P is in user.

""ghc-pkg unregister --package-conf=<dir> P"" drops the user or the global package, preferring the user one, if P is not found in <dir>.

Same with ""ghc-pkg --user unregister P"", ""ghc-pkg unregister P --user"", etc.

GHC versions 6.10, 6.12, 7.0, 7.2."	guest
2	7598	ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range)	Compiler	7.7	high		7.8.1		new	2013-01-16T13:46:59-0800	2013-04-14T04:03:15-0700	"Hello,
an attempt to compile today GHC HEAD on linux powerpc fails with this message
{{{
""inplace/bin/ghc-stage1"" -static  -H32m -O    -package-name ghc-7.7.20130115 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../rts/dist/build -Icompiler/stage2 -Icompiler/. -Icompiler/parser -Icompiler/utils   -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.17.0 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.0.2 -package transformers-0.3.0.0 -package unix-2.6.1.0  -Wall -fno-warn-name-shadowing -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2  -no-user-package-db -rtsopts      -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf  o -hcsuf hc -c compiler/codeGen/StgCmmPrim.hs -o compiler/stage2/build/StgCmmPrim.o
/tmp/ghc20445_0/ghc20445_0.s: Assembler messages:

/tmp/ghc20445_0/ghc20445_0.s:98896:0:
     Error: operand out of range (0x00000000000081ac is not between 0xffffffffffff8000 and 0x0000000000007ffc)
make[1]: *** [compiler/stage2/build/StgCmmPrim.o] Error 1
make: *** [all] Error 2
}}}
The platform is 32bit PowerPC running debian wheezy which provides GHC 7.4.1 used for bootstrapping GHC HEAD."	kgardas
2	7490	ghc-stage1 panic when building a cross-compiler or cross-building a compiler	Compiler	7.7	high		7.8.1	igloo	new	2012-12-08T11:29:35-0800	2013-01-31T13:28:38-0800	"{{{
""inplace/bin/ghc-stage1"" -static  -H64m -O0 -fasm    -package-name integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/.    -optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0  -package-name integer-simple -Wall -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O -fasm  -no-user-package-db -rtsopts      -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20121205 for i386-unknown-nto-qnx):
	expectJust initTcInteractive

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1
make: *** [all] Error 2
}}}
"	singpolyma
4	4942	GHC.ConsoleHandler does not call back application when Close button is pressed	GHC API	6.12.3	low		7.6.2		new	2011-02-01T17:54:31-0800	2012-09-12T04:13:24-0700	"The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.

{{{
import Control.Concurrent (threadDelay)
import GHC.ConsoleHandler
import System.IO

onConsoleEventReceived :: ConsoleEvent -> IO ()
onConsoleEventReceived event = withFile ""console_event.log"" AppendMode $ \ file -> do
  hPutStrLn file $ case event of
    ControlC  -> ""Received Ctrl-C event""
    Break     -> ""Received Ctrl-Break event""
    Close     -> ""Received X button event""
    _         -> ""Received other console event""
  hFlush file
    
main :: IO ()
main = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)
}}}

The host OS is Windows XP SP3.

Please let me know if you need any more info."	Amatic
3	7482	GHC.Event overwrites main IO managers hooks to RTS	libraries/base	7.4.1	normal		7.8.1	AndreasVoellmy	new	2012-12-05T08:15:33-0800	2013-04-12T13:56:54-0700	"The IO manager registers two file descriptors with the RTS which the RTS uses to send control and wakeup signals to the IO manager. The main IO manager is started up by default and registers some file descriptors that it has allocated with the RTS.  

The base package also exposes a GHC.Event module which when initialized will also register files with the RTS, overwriting the main IO manager's files. Now the RTS can no longer signal the main IO manager."	AndreasVoellmy
3	7500	GHC: internal error: getMBlock: mmap: Operation not permitted	Compiler	7.4.1	normal		7.8.1		new	2012-12-14T03:27:18-0800	2013-04-12T14:21:03-0700	"Trying to calculate partition of a number using generating fuction with memoization, like this:


{{{
#!/usr/bin/runhaskell

part'' :: Int -> Integer
part'' = ( map part' [0..] !!)

part' :: Int -> Integer
part' 0 = 1
part' 1 = 1
part' n =  
    sum $ map (\k ->
    let kk = fromInteger(k); k1 = floor(1/2*kk*(3*kk-1)); k2 = floor(1/2*kk*(3*kk+1)) in
    (-1)^(k+1) * ( (part (n-k1)) + (part (n-k2))) ) [1..toInteger(n)]

part n = 
    if n < 0 then 0 else part'' n

main = print $ part 20000

}}}

Then i watch how memory usage grows up to 2G (RES) and program stops:

{{{
./bug.hs
bug.hs: internal error: getMBlock: mmap: Operation not permitted
    (GHC version 7.4.1 for i386_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportab
}}}

The kernel is compiled with PAE, and machine has 8G of RAM
"	guest
3	5898	ghc: internal error: Invalid Mach-O file	Compiler	7.0.4	normal		7.6.2		new	2012-02-26T13:39:34-0800	2012-09-12T04:12:11-0700	"I am running Mac OS 10.5.8 on a PowerPC processor.

{{{
$ cabal --version
cabal-install version 0.10.2
using version 1.10.2.0 of the Cabal library 
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.4
$ machine
ppc7450
}}}

`cabal install yesod-core` fails with

{{{
Loading package wai-logger-0.1.4 ... linking ... ghc: internal error: Invalid Mach-O file:Address out of bounds while relocating object file
    (GHC version 7.0.4 for powerpc_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}"	jeffshaw
5	1612	GHC_PACKAGE_PATH and $topdir bug	Package system	6.6.1	lowest	normal	7.6.2		new	2007-08-12T04:06:22-0700	2013-01-26T14:21:44-0800	"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
4	5291	GhcDynamic build fails on Windows: can't find DLLs	Build System	7.0.3	low		7.6.2		new	2011-07-01T00:40:27-0700	2012-09-12T04:13:31-0700	"Enabling GhcDynamic causes the Windows build to fail:

{{{
""inplace/bin/ghc-stage2.exe""   -H64m -O0 -fasm     -i -iutils/ghctags/. -iutils/ghctags/dist-install/build -iutils/ghctags/dist-install/build/autogen -Iutils/ghctags/dist-install/build -Iutils/ghctags/dist-install/build/autogen        -package ghc -no-user-package-conf -rtsopts     -odir utils/ghctags/dist-install/build -hidir utils/ghctags/dist-install/build -stubdir utils/ghctags/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c utils/ghctags/./Main.hs -o utils/ghctags/dist-install/build/Main.o
/home/Max/Programming/Checkouts/ghc.shared/inplace/bin/ghc-stage2.exe: error while loading shared libraries: libHSprocess-1.0.1.4-ghc7.1.20110630.dll: cannot open shared object file: No such file or directory
}}}

The reason is that Windows searches for DLLs in the application directory, and the DLLs that a dynamic GHC depends on are not placed in that directory. (See http://msdn.microsoft.com/en-us/library/ms682586(v=vs.85).aspx)

Presumably the fix is to have the build system copy the dependent DLLs into inplace/bin as the final act of the stage2 build.  (I'm not sure what happens after GHC is installed - presumably the DLLs are put into System32 or something?)"	batterseapower
5	552	GHCi  :m  doesn't restore default decl	GHCi	5.0	lowest	normal	_|_		new	2001-06-08T04:47:59-0700	2009-07-17T17:35:37-0700	"GHCi should remember what the 'default' setting in 
force for a module is, so that after :m Foo one gets 
the default setting for Foo.

This means that GHC should really record the default 
setting in the interface file.

So this is related to the current bug that GHCi 
doesn't remember the original source-level imports for 
the module.  As a result :m Foo (where Foo is a 
compiled module) does not produce the right top-level 
environment"	simonpj
3	7794	"GHCi ""Prelude.undefined"" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented"	GHCi	7.6.2	normal		7.8.1		new	2013-03-25T19:26:52-0700	2013-04-13T07:19:17-0700	"A number of non-trivial operations fail in ghci on ARM (specifically armhf on both Debian experimental and Ubuntu raring).  I initially noticed this as conduit's doctests failing, but reduced this to:
{{{
  $ ghci
  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.
  Prelude> data Type a = Nothing
  *** Exception: Prelude.undefined
}}}
This is a singularly unhelpful exception, coming as it does without context, but I eventually tracked it down to ByteCodeItbls.mkJumpToAddr having no specific implementation for ARM and thus falling back to the default of ""undefined"".  I've tried adding this:
{{{
+#elif arm_TARGET_ARCH
+type ItblCode = Word32
+mkJumpToAddr a
+    = [ 0xe51ff004      -- ldr pc, [pc, #-4]    # pc reads as <current insn>+8
+      , fromIntegral (ptrToInt a) ]
}}}
This definitely changes the nature of the problem, so I think I'm on the right track, and I'm reasonably confident that that's the correct branch implementation; but when I actually try it in practice I get crashes (SIGSEGV/SIGILL/SIGBUS) with trashed stack traces, so I'm clearly not done yet.  Friends of mine suggest that I may need to `__clear_cache` or equivalent, which sounds plausible, so my current line of attack is figuring out how to glue that in; but if any actual GHC hackers can spot something obviously missing in the meantime then that would be great."	cjwatson
3	2841	Ghci + foreign export declarations result in undefined symbols	Compiler (FFI)	6.10.1	normal	major	_|_		new	2008-12-04T07:44:58-0800	2008-12-09T07:20:16-0800	"When using ghci and foreign export declarations, calling any function, _even_ test, will result in an unknown symbol error. 

Another bug is that the compiler is not purely functional in the sense that without history (see below) it is possible for it to work in one instance, but even then it doesn't. GHCi should have the property that if X works in a state S of the OS (collection of files, etc), then it should work in all states S', obtained by adding extra stuff to S, but not modifying anything.  Currently, GHCi is breaking this fundamental property. 

{{{
$ ghci New.hs
*Main> foo 1
<interactive>: New_stub.o: unknown symbol `Main_zdffoozuavi_closure'
}}}

{{{
{-# LANGUAGE ForeignFunctionInterface #-}

-- save in a file New.hs

foreign export ccall foo :: Int -> IO Int -- add this line and ghci will return something like New_stub.o: unknown symbol `Main_zdffoozuaIc_closure'

-- if you first try without the line, it works. If you still have stub files in the current directory, it will fail with the same message as before. 

foo :: Int -> IO Int
foo = return . length .  f

f :: Int -> [Int]
f 0 = []
f n = n:(f (n-1))

test = 1
}}}"	fasta
3	3569	ghci can't handle utf-8 chinese char correctly when modify.	GHCi	6.10.4	normal	normal	_|_	judah	new	2009-10-08T23:49:55-0700	2011-04-26T13:49:02-0700	"ubuntu 8.04, ghc 6.10.4,gnome-terminal
if you can't display chinese char and under ubuntu, may be you can use ubuntu's language support.
=======================================================
Using chinese string inside ghci such as:

Prelude> ""大家好，这是一段中文""

when use backspace, left arrow or any other action cause the cursor relocate.Will find out that the cursor can't relocate correctly, 
i.e. 
i use backspace to delete the whole string, ghci still display thing like below:
Prelude> ""大家好，这

if now use <Enter> to execute, resault just ""Prelude>""

After several test i find out that, ghci ""display part"" treat every chinese char as two chars/bytes(or maybe longer), but ghci ""inside"" treat chinese char as one unicode char correctly.

Chinese can encode 2 to 4 bytes long, under Linux 2 to 4 bytes under diffrent locale setting, under Windows 2 bytes long. 

"	guest
3	7789	GHCI core dumps when used with VTY	GHCi	7.4.2-rc1	normal		7.8.1	igloo	new	2013-03-23T12:45:09-0700	2013-04-13T06:58:05-0700	"Load the attached script in ghci:

{{{
$ghci ghci-coredumper.hs

}}}

(you need the vty-menu package from hackage) and type die


{{{
>die

}}}

You may see a menu with a set of ten numbers.  If you do press enter repeatedly. Eventually it will core dump(at least it does for me) Unfortunately I have been unable to collect this core dump, but here is the output at least:


{{{

7f7ad1fc4000-7f7ad1fc5000 rwxp 000fd000 00:10 2839271                    /usr/lib/libm-2.17.so
7f7ad1fc5000-7f7ad2032000 r-xp 00000000 00:10 3028085                    /usr/lib/libgmp.so.10.1.1
7f7ad2032000-7f7ad2231000 ---p 0006d000 00:10 3028085                    /usr/lib/libgmp.so.10.1.1
7f7ad2231000-7f7ad2232000 r-xp 0006c000 00:10 3028085                    /usr/lib/libgmp.so.10.1.1
7f7ad2232000-7f7ad223b000 rwxp 0006d000 00:10 3028085                    /usr/lib/libgmp.so.10.1.1
7f7ad223b000-7f7ad2252000 r-xp 00000000 00:10 2839310                    /usr/lib/libpthread-2.17.so
7f7ad2252000-7f7ad2451000 ---p 00017000 00:10 2839310                    /usr/lib/libpthread-2.17.so
7f7ad2451000-7f7ad2452000 r-xp 00016000 00:10 2839310                    /usr/lib/libpthread-2.17.so
7f7ad2452000-7f7ad2453000 rwxp 00017000 00:10 2839310                    /usr/lib/libpthread-2.17.so
7f7ad2453000-7f7ad2457000 rwxp 00000000 00:00 0 
7f7ad2457000-7f7ad245a000 r-xp 00000000 00:10 2839316                    /usr/lib/libdl-2.17.so
7f7ad245a000-7f7ad2659000 ---p 00003000 00:10 2839316                    /usr/lib/libdl-2.17.so
7f7ad2659000-7f7ad265a000 r-xp 00002000 00:10 2839316                    /usr/lib/libdl-2.17.so
7f7ad265a000-7f7ad265b000 rwxp 00003000 00:10 2839316                    /usr/lib/libdl-2.17.so
7f7ad265b000-7f7ad265d000 r-xp 00000000 00:10 2839280                    /usr/lib/libutil-2.17.so
7f7ad265d000-7f7ad285c000 ---p 00002000 00:10 2839280                    /usr/lib/libutil-2.17.so
7f7ad285c000-7f7ad285d000 r-xp 00001000 00:10 2839280                    /usr/lib/libutil-2.17.so
7f7ad285d000-7f7ad285e000 rwxp 00002000 00:10 2839280                    /usr/lib/libutil-2.17.so
7f7ad285e000-7f7ad2865000 r-xp 00000000 00:10 2839273                    /usr/lib/librt-2.17.so
7f7ad2865000-7f7ad2a64000 ---p 00007000 00:10 2839273                    /usr/lib/librt-2.17.so
7f7ad2a64000-7f7ad2a65000 r-xp 00006000 00:10 2839273                    /usr/lib/librt-2.17.so
7f7ad2a65000-7f7ad2a66000 rwxp 00007000 00:10 2839273                    /usr/lib/librt-2.17.so
7f7ad2a66000-7f7ad2ac0000 r-xp 00000000 00:10 3403181                    /usr/lib/libncursesw.so.5.9
7f7ad2ac0000-7f7ad2cbf000 ---p 0005a000 00:10 3403181                    /usr/lib/libncursesw.so.5.9
7f7ad2cbf000-7f7ad2cc3000 r-xp 00059000 00:10 3403181                    /usr/lib/libncursesw.so.5.9
7f7ad2cc3000-7f7ad2cc5000 rwxp 0005d000 00:10 3403181                    /usr/lib/libncursesw.so.5.9
7f7ad2cc5000-7f7ad2ce6000 r-xp 00000000 00:10 2839312                    /usr/lib/ld-2.17.so
7f7ad2e39000-7f7ad2eba000 rwxp 00000000 00:00 0 
7f7ad2ee4000-7f7ad2ee6000 rwxp 00000000 00:00 0 
7f7ad2ee6000-7f7ad2ee7000 r-xp 00021000 00:10 2839312                    /usr/lib/ld-2.17.so
7f7ad2ee7000-7f7ad2ee8000 rwxp 00022000 00:10 2839312                    /usr/lib/ld-2.17.so
7f7ad2ee8000-7f7ad2ee9000 rwxp 00000000 00:00 0 
7fff979b8000-7fff979d9000 rwxp 00000000 00:00 0                          [stack]
7fff979fe000-7fff97a00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Neúspěšně ukončen (SIGABRT) (core dumped [obraz paměti uložen])

}}}

Sometimes it dumps immediately, sometimes it takes a while.

Sometimes the errors are different:


{{{
*** Exception: user error (Terminal does not define required capability ""cup"")
*Main> 

}}}


{{{
*** Exception: user error (Terminal does not define required capability ""setab"")
*Main> 
<stdin>: hWaitForInput: end of file

}}}

But mostly it just core dumps."	timthelion
3	5071	GHCi crashes on large alloca/allocaBytes requests	Compiler	7.0.3	normal		_|_		new	2011-03-31T16:22:12-0700	2011-12-13T01:36:54-0800	"GHCi, and ghc, seems to exit (crash?) on certain types of memory allocation exceptions.

The FFI addendum says that the allocation functions should be able to return null:
http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-230005

Section 5.8 says this:

> If any of the allocation functions fails, a value of Ptr.nullPtr is produced. If free or reallocBytes is applied to a memory area that has been allocated with alloca or allocaBytes, the behaviour is undefined. Any further access to memory areas allocated with alloca or allocaBytes, after the computation that was passed to the allocation function has terminated, leads to undefined behaviour. Any further access to the memory area referenced by a pointer passed to realloc, reallocBytes, or free entails undefined behaviour.


In practice, code examples and documentation appear to rely on `alloca` '''NOT''' returning a `nullPtr`:
 * http://en.wikibooks.org/wiki/Haskell/FFI
 * http://www.haskell.org/haskellwiki/HSFFIG/Examples
 * http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html

I reported this on the libraries list, and offered a documentation tweak, and I was asked to create a ticket:
http://www.haskell.org/pipermail/libraries/2011-March/016117.html

That email has details about the testing I did at the time to see the crashing behavior in ghci. I was using ghc 7.0.2 on 64bit windows, but this also appears to affect 7.0.3 on linux.  It's likely that other versions of ghc are affected.

My recommendation would be to make the exception thrown by `alloca` catchable.  Possibly offering an alternative to `alloca`, say `alloca'`, that can produce a `nullPtr` instead of using exceptions.  I would advice against changing the existing `alloca` function to produce `nullPtr` as that could make a lot of existing code unsafe.

For example, it would be nice if the following printed ""exception"", instead of exiting:
{{{
$ ulimit -d 100000 -m 1000000 -v 100000
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
$ ./Alloca 
Alloca: out of memory (requested 2148532224 bytes)
$ cat Alloca.hs
import Foreign
import Foreign.Marshal
import Foreign.Marshal.Alloc
import GHC.Exception
import System.IO.Error

main :: IO ()
main = do
  (allocaBytes maxBound compare)
    `catch` (\_ -> print ""exception"")
  where
  compare p = print ((nullPtr :: Ptr Int) == p)
}}}"	guest
3	3333	GHCi doesn't load weak symbols	GHCi	6.10.4	normal	normal	7.6.2		new	2009-06-27T16:59:42-0700	2013-04-28T07:00:45-0700	"GHCi fails to load modules with weak symbols.  The compiler, in contrast, has no trouble with them.  The attached Cabal package demonstrates the problem.  After building and installing:

{{{
:Prelude> :m +WeakTest
Prelude WeakTest> weak_test 0
Loading package WeakTest-0 ... linking ... <interactive>: /home/heatsink/.cabal/lib/WeakTest-0/ghc-6.10.3/HSWeakTest-0.o: unknown symbol `weak_test'
}}}

I encountered this problem while trying to build a package that contains C++ code.  Because GCC generates weak symbols when compiling C++, libraries that contain C++ code will not work in GHCi.  (Granted, this is not the only problem with mixing C++ and Haskell.)"	heatsink
4	3625	GHCI doesn't work with dtrace on OS X	GHCi	6.10.4	low	normal	7.6.2		new	2009-10-29T22:09:20-0700	2012-09-12T04:12:18-0700	"On OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script:

{{{
provider haskell {
  probe demo__trace(char*);
};
}}}

and this C file:

{{{
void demo_trace( char *s )
{
  HASKELL_DEMO_TRACE(s);
}
}}}

When we compile it, we get:

{{{
newbie:dtrace-demo rl$ nm demo-trace.o
         U ___dtrace_probe$haskell$demo__trace$v1$63686172202a
         U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0
         U ___dtrace_typedefs$haskell$v1
00000000 T _demo_trace
}}}

When linked as a dynamic library, the undefined symbols disappear:

{{{
newbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o 
newbie:dtrace-demo rl$ nm demo-trace.dylib 
00000000 t __mh_dylib_header
000008b0 T _demo_trace
}}}

But GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, `ghci -package dtrace-demo` produces this error:

{{{
unknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a'
Loading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0'
}}}

Unless I'm mistaken, the only solution is to use dlopen instead of a hand-written linker as the dtrace symbols are actually resolved by the kernel.

The problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies."	rl
3	4029	ghci leaks memory when loading a file	GHCi		normal		_|_		new	2010-04-28T09:16:33-0700	2010-08-11T06:27:23-0700	"In the 6.12 series, ghci leaks memory when loading definitions.  This appears to be a regression from previous releases.  The problem appears in both 6.12.1 and 6.12.2, but not in 6.8.3 or 6.10.4.

As a test, take the attached Hello World file, fire up ghci, and :load Hello.hs.  Watch the memory usage of ghci---each time you repeat the load command, the memory usage of the process grows.  (It grows slowly on this simple example, but on a real project, the growth can be several megabytes per :load.)

I discovered this due to my workflow.  When programming Haskell, I typically use emacs with haskell-mode, and frequently reload the definitions of the code I am working on.  After upgrading to 6.12.1, after coding for some time, I noticed my 8GB machine was swapping.  (It is faster to :reload the file rather than :load, and reloading doesn't appear to suffer from the memory leak, but sometimes I switch between modules and :reload is not applicable.)

My workaround for now is to regularly restart my ghci processes to prevent their memory usage from growing so much that my system starts swapping.

I have observed this bug on 32- and 64-bit GHCi on various versions of Ubuntu, on both Intel and AMD processors.
"	blarsen
3	5435	GHCi linker should run constructors for linked libraries	Compiler	7.2.1	normal		7.8.1		new	2011-08-26T21:05:16-0700	2012-11-07T09:51:04-0800	As far as I can tell from my experimentation, any library that contains a function with __attribute__((constructor)) on it won't have its constructor(s) run when loaded, or its destructors run when unloaded. This violates assumptions that some libraries make.	pumpkin
2	7056	"GHCi loadArchive ""libiconv.a"":failed Unknown PEi386 section name `.drectve'"	GHCi	7.4.1	high		7.6.2		new	2012-07-06T22:21:42-0700	2013-04-14T07:44:03-0700	"
cygwin 1.7
{{{
$ iconv --version
iconv (GNU libiconv 1.14)
}}}

E:/Develop/haskell/conv.hs :
{{{
import Codec.Text.IConv as IConv
import Data.ByteString.Lazy as ByteString

main :: IO ()
main = ByteString.interact (convert ""UTF-8"" ""GBK"")        
}}}

then 

{{{
GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :load ""e:/Develop/haskell/conv.hs""
[1 of 1] Compiling Main             ( E:\Develop\haskell\conv.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package iconv-0.4.1.0 ... ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for i386-unknown-mingw32):
	loadArchive ""d:/cygwin/lib\\libiconv.a"": failed

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

*Main> Leaving GHCi.
<interactive>: Unknown PEi386 section name `.drectve' (while processing: d:/cygwin/lib\libiconv.a)
}}}

"	songpp
2	781	GHCi on x86_64, cannot link to static data in shared libs	Compiler	6.5	high	normal	7.8.1		new	2006-05-31T02:15:57-0700	2013-05-16T01:22:27-0700	"System.Posix.getEnvironment fails on Linux 2.6.16-1.2108_FC4smp
with a segfault. (x86_64)

{{{
[aleator@thoth HopenCV]$ ghci
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 6.5.20060527, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base-1.0 ... linking ... done.
Prelude> :m +System.Posix.Env
Prelude System.Posix.Env> getEnv ""USER""
Loading package unix-1.0 ... linking ... done.
Just ""aleator""
Prelude System.Posix.Env> getEnvironment
Segmentation fault
}}}"	guest
2	4245	ghci panic: thread blocked indefinitely in an MVar operation	GHCi	6.12.3	high		7.6.2	tibbe	new	2010-08-07T14:55:36-0700	2013-03-22T02:21:43-0700	"I stumbled across this error today:
{{{
phil ~
$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> 
[1]+  Stopped                 ghci
phil ~
$ fg
ghci
^C^C

Prelude> 
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.3 for i386-apple-darwin):
	thread blocked indefinitely in an MVar operation

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

phil ~
$
}}}

Steps to reproduce:
 * start ghci
 * ctrl-z
 * fg
 * ctrl-c
 * ctrl-c
 * enter
 * wait ~2 seconds

I'm not sure if it is related but while waiting for the impossible to happen, any characters typed are not echoed to the screen."	pturnbull
4	1201	ghci runs Template Haskell splices 4 times	Template Haskell	6.6	low	normal	_|_	simonpj	new	2007-03-06T04:48:08-0800	2013-01-22T09:26:05-0800	"ghci (both 6.6 and HEAD) appears to run Template Haskell splices 4 times, as shown here:
{{{
$ ghci -fth -v0
Prelude> :m + Language.Haskell.TH
Prelude Language.Haskell.TH> $(do runIO $ (Random.randomIO :: IO Int) >>= print; [| 1 |] )
7184082642420483628
-8222359774145102883
2625059211496099566
1462332877512834399
1
}}}"	igloo
3	6107	GHCi runtime linker cannot link with duplicate common symbols	Compiler	7.4.1	normal		7.8.1		new	2012-05-17T04:15:01-0700	2012-10-12T04:51:51-0700	"GHCi's runtime linker reports duplicate common symbols as fatal error. According to the nm manual: ""When  linking,  multiple common symbols may appear with the same name"".
This means that for example one cannot link using the FFI with libraries having multiple common symbols if TH splices are used.

To illustrate let's create two object files both defining the same common symbol:

commonSym.c
{{{
volatile commonSym;
}}}

{{{
$ gcc -o commonSym.o commonSym.c -c
$ gcc -o commonSym2.o commonSym.c -c
$ nm commonSym.o commonSym2.o

commonSym.o:
0000000000000004 C commonSym

commonSym2.o:
0000000000000004 C commonSym
}}}

Now we create two dummy .hs files, one having a TH splice which (i'm guessing) triggers the runtime linker.

Works.hs
{{{
module Works where
}}}

DoesntWork.hs
{{{
{-# LANGUAGE TemplateHaskell #-}
module DoesntWork where
$(return [])
}}}

{{{
$ ghc Works.hs commonSym.o commonSym2.o
[1 of 1] Compiling Works            ( Works.hs, Works.o )

$ ghc DoesntWork.hs commonSym.o commonSym2.o
[1 of 1] Compiling DoesntWork       ( DoesntWork.hs, DoesntWork.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) commonSym.o ... done
Loading object (static) commonSym2.o ... 

GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   commonSym
whilst processing object file
   commonSym2.o
(...)
}}}

Just to make sure that this -should- link:

works.c
{{{
extern commonSym;
int main (void)
{
    int _ = commonSym;
}
}}}

{{{
$ gcc -o works.o works.c -c
$ nm works.o
                 U commonSym
0000000000000000 T main
$ gcc -o works works.o commonSym.o commonSym2.o
$ ./works ; echo $?
0
}}}"	exFalso
3	3242	ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)	GHCi	7.4.1	normal	normal	7.6.2		new	2009-05-18T20:30:25-0700	2012-09-12T03:26:07-0700	"On Windows, when attempting to use Hipmunk from ghci, it produces the error:
{{{
ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
}}}
To reproduce:
{{{
cabal install Hipmunk
ghci
:m + Physics.Hipmunk
initChipmunk
}}}

Presumably this has something to do with there being no libm on Windows."	jeffz1
3	7133	GHCi: strange behaviour after CTRL-C, followed by 'hPutChar: resource vanished (Broken Pipe)' when quitting	GHCi	7.4.1	normal		7.8.1	tibbe	new	2012-08-10T06:49:52-0700	2012-12-06T10:06:42-0800	"Example:  (launching GHCi from Terminal.app)

{{{
GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 1
1
Prelude> [1..]
^CPrelude> 1
^CPrelude> 10
^CPrelude> 1+2
^CPrelude> :q
<stdout>: hPutChar: resource vanished (Broken pipe)
}}}

This behaviour does not occur when I run GHCi from within Aquamacs (some output elided):

{{{
GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> 1
1
Prelude> [1..]
[1,2,3,4,5, ... 475,476,47  ^C ^C7,478,479,480, ... 539,540,541Interrupted.
Prelude> 1
1
Prelude> :q
Leaving GHCi.

Process haskell finished
}}}

I'm using the Haskell Platform for Mac OSX, 2012.2.0.0 32 bit, running on OSX 10.6.8."	DuncanMortimer
4	5388	ghcilink003 and ghcilink006 fail on OSX	Compiler	7.0.4	low		7.6.2		new	2011-08-06T14:46:17-0700	2012-09-12T04:13:33-0700	"
`ghcilink003` and `ghcilink006` fail on OSX (both x86 and amd64) for me, e.g.
{{{
=====> ghcilink003(normal) 3 of 6 [0, 0, 0]
cd . && $MAKE -s --no-print-directory ghcilink003    </dev/null >ghcilink003.run.stdout 2>ghcilink003.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
<command line>: user specified .o/.so/.DLL could not be loaded (dlopen(/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib, 9): no suitable image found.  Did find:
        /usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib: can't map)
Whilst trying to load:  (dynamic) /usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib
Additional directories searched: (none)
make[1]: *** [ghcilink003] Error 1
}}}

This seems to be because I can't dlopen `libstdc++.dylib`:
{{{
$ cat q.c

#include <dlfcn.h>
#include <stdio.h>

int main(void) {
    void *p;
    p = dlopen(""/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib"", RTLD_LAZY);
    printf(""Result: %p\n"", p);
    printf(""Error: %s\n"", dlerror());
    return 0;
}

$ gcc q.c -o q
$ ./q 
Result: 0x0
Error: dlopen(/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib, 1): no suitable image found.  Did find:
        /usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib: can't map
}}}

{{{
$ otool -L /usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib
/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib:
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
}}}

{{{
$ file /usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib
/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib: Mach-O universal binary with 3 architectures
/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib (for architecture i386):Mach-O dynamically linked shared library stub i386
/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib (for architecture ppc7400):      Mach-O dynamically linked shared library stub ppc
/usr/lib/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib (for architecture x86_64):       Mach-O 64-bit dynamically linked shared library stub x86_64
}}}
"	igloo
3	7464	git tag for base-4.6.0.0 missing	libraries/base	7.6.1	normal		7.8.1	igloo	new	2012-11-30T01:43:56-0800	2013-04-12T13:45:37-0700	I assume this is the same as {{{ghc-7.6.1-release}}}.  But it would be nice to have the proper tag.  I need this information, so that I can refer that commit with git submodules.	SimonHengel
3	7644	Hackage docs for base library contain broken links	Documentation	7.6.1	normal		7.8.1		new	2013-01-31T06:13:24-0800	2013-04-12T16:49:41-0700	"http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/GHC-IOArray.html

Is a 404, presumably because it's {{{ {-# HADDOCK_OPTIONS hide #-} }}} so the haddocks don't get documented?

However it is linked to from the master index

http://hackage.haskell.org/package/base-4.6.0.0

...which as far as I can see has links to all modules irrespective of whether they are hidden or not.

A different example relates to source links:

If you look at the Prelude docs here:

http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Prelude.html

Then some of the source links point to URLs like

http://hackage.haskell.org/packages/archive/%01/%02/doc/html/src/GHC-Classes.html#Ord

...which looks like some substitution operation has failed (%01 -> package name, %02 -> version, I presume). An attempt to manually fix the package name and version still leads to a 404.

Some other source links from the Prelude are fine, though, for example:

http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/src/GHC-Enum.html#Enum

This is a regression but I don't know how recently; I certainly used to be able to follow links like that back in the 7.0 era, but I don't when it started failing."	JulesBean
5	3771	haddock: internal error: evacuate: strange closure type 19269	Compiler	6.12.1	lowest		7.6.2		new	2009-12-17T06:35:57-0800	2012-09-12T04:14:14-0700	"Here are the last few lines of `make` output
{{{
""rm"" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
(echo   libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix/dist-install/build/cbits/execvpe.p_o libraries/unix/dist-install/build/cbits/dirUtils.p_o     `/usr/bin/find libraries/unix/dist-install/build -name ""*_stub.p_o"" -print`; /usr/bin/find libraries/unix/dist-install/build/System/Posix_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Module_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Prim_p_o_split libraries/unix/dist-install/build/System/Posix/Directory_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker_p_o_split libraries/unix/dist-install/build/System/Posix/Env_p_o_split libraries/unix/dist-install/build/System/Posix/Error_p_o_split libraries/unix/dist-install/build/System/Posix/Files_p_o_split libraries/unix/dist-install/build/System/Posix/IO_p_o_split libraries/unix/dist-install/build/System/Posix/Process_p_o_split libraries/unix/dist-install/build/System/Posix/Process/Internals_p_o_split libraries/unix/dist-install/build/System/Posix/Resource_p_o_split libraries/unix/dist-install/build/System/Posix/Temp_p_o_split libraries/unix/dist-install/build/System/Posix/Terminal_p_o_split libraries/unix/dist-install/build/System/Posix/Time_p_o_split libraries/unix/dist-install/build/System/Posix/Unistd_p_o_split libraries/unix/dist-install/build/System/Posix/User_p_o_split libraries/unix/dist-install/build/System/Posix/Signals_p_o_split libraries/unix/dist-install/build/System/Posix/Signals/Exts_p_o_split libraries/unix/dist-install/build/System/Posix/Semaphore_p_o_split libraries/unix/dist-install/build/System/Posix/SharedMem_p_o_split -name '*.p_o' -print) | ""xargs""  ""/usr/bin/ar"" clqs  libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
""inplace/bin/mkdirhier"" libraries/unix/dist-install/doc/html/unix/
""inplace/bin/ghc-cabal"" haddock dist-install libraries/unix --with-haddock=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/haddock --with-ghc=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/ghc-stage2  
Running Haddock for unix-2.4.0.0...
Preprocessing library unix-2.4.0.0...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ffi-1.0, rts-1.0
haddock: internal error: evacuate: strange closure type 19269
    (GHC version 6.12.1 for powerpc_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/unix/dist-install/doc/html/unix/unix.haddock] Error 6
make: *** [all] Error 2
}}}
I did the following to build:
{{{
./configure --prefix=/usr/local/ghc-6.12.4
make
}}}

I'm on `Darwin power-mac-g5.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:54:29 PDT 2009; root:xnu-1228.12.14~1/RELEASE_PPC Power Macintosh`.

What other information do you need?"	dbueno
3	7624	Handling ImplicitParams in Instance Declaration	Documentation	7.6.1	normal		7.8.1		new	2013-01-25T00:50:23-0800	2013-04-12T16:04:48-0700	"The  GHC documentation states that ImplicitParam's may not be used in class or instance declaration constraints.   see for example http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/other-type-extensions.html In practice though, at least on the Mac, all recent version of GHC have permitted such instances.  At the very least the documentation should make clear that the compiler might permit such instances, but they have undefined behaviour.  Ideally, these would simply be permitted.  

[http://joyoftypes.blogspot.com/2013/01/using-compiler-bugs-for-fun-and-profit.html Why I think the (undocumented) current behavior is correct]"	philipjf
3	7695	Hang when locale-archive and gconv-modules are not there	None	7.6.2	normal		7.8.1		new	2013-02-15T09:28:25-0800	2013-04-13T05:15:15-0700	"Running a (statically) compiled program in an environment where /usr/lib/locale or /usr/lib/gconv (or ../lib64/..) are not there, causes it to hog the CPU and rapidly allocate memory (this happens for example in an empty chroot).

Steps to reproduce:

{{{
echo ""main = return ()"" > test.hs
ghc -static -optl-static -optl-pthread -o test test.hs
chroot `pwd` /test
}}}

Strace output:

{{{
$ /strace -e trace=file -e signal= /test
execve(""/test"", [""/test""], [/* 17 vars */]) = 0
open(""/usr/lib64/locale/locale-archive"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(""/usr/share/locale/locale.alias"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/locale/de_DE.UTF-8/LC_CTYPE"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/locale/de_DE.utf8/LC_CTYPE"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/locale/de_DE/LC_CTYPE"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/locale/de.UTF-8/LC_CTYPE"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/locale/de.utf8/LC_CTYPE"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/locale/de/LC_CTYPE"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/gconv/gconv-modules.cache"", O_RDONLY) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/gconv/gconv-modules"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
}}}

Strace output (with LC_ALL=C):

{{{
$ LC_ALL=C strace -e trace=file -e signal= /test
execve(""/test"", [""/test""], [/* 18 vars */]) = 0
open(""/usr/lib64/gconv/gconv-modules.cache"", O_RDONLY) = -1 ENOENT (No such file or directory)
open(""/usr/lib64/gconv/gconv-modules"", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
}}}

In both cases, there are no further system calls (apart from timer ticks and mmap).

I was also able to reproduce this behavior without a chroot, by replacing the paths from strace's output with something nonexistent in the binary (manually, with a hex-editor). I didn't try dynamically linked binaries, yet.

One problem ''may'' be, that iconv_open constantly returns -1 if it doesn't find the files listed above.
"	hpd
5	3003	Happy does not reject pragmas	Build System	6.10.1	lowest	normal	7.6.2		new	2009-02-05T09:50:58-0800	2012-09-12T04:14:07-0700	"I was about to report a bug in GHC's handling of -fno-warn-missing signatures in pragmas, but wasn't able to reproduce it. Then I noticed it: the problem was that the pragma was at the very top of a {{{.y}}} file, where it was simply discarded, like this:
{{{
{-# OPTIONS_GHC -fno-warn-missing-signatures #-} {- -*- Haskell -*- -}

{
}}}
Happy should probably not just silently discard pragmas.

"	SamB
3	7539	Hard ghc api crash when calling runStmt on code which has not been compiled	Compiler	7.6.1	normal		7.8.1		new	2012-12-29T09:13:59-0800	2013-01-09T04:10:53-0800	"(See attached example program demonstrating the crash.) When the session flags are set to 

{{{
  let flags = flags0 { hscTarget = HscNothing, ghcLink = NoLink } -- Crashes
}}}

and we later try to run the code (`runStmt`), the GHC API crashes. If instead we set the flags to

{{{
  let flags = flags0 { hscTarget = HscNothing, ghcLink = LinkBinary } -- Okay
}}}

we get a nice error message instead:

{{{
Undefined symbols for architecture i386:
  ""_ZCMain_main_closure"", referenced from:
      _main in ghc72975_0.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
TestGhc: TestGhc: phase `Linker' failed (exitcode = 1)
}}}

The exact crash varies from run to run. Most often it is

{{{
Bus error: 10
}}}

Sometimes it is

{{{
Segmentation fault: 11
}}}

and in all my testing I've only once seen

{{{
TestGhc: internal error: stg_ap_v_ret
    (GHC version 7.4.2 for i386_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort trap: 6
}}}

(This is on a Mac, confirmed with both ghc 7.4 and ghc 7.6).
"	edsko
4	3722	Haskeline Iconv needs HAVE_LANGINFO_H	libraries (other)	6.12.1 RC1	low		7.6.2		new	2009-12-03T17:45:00-0800	2012-09-12T04:12:19-0700	"per libraries/base/GHC/IO/Encoding/Iconv.hs, libraries/haskeline/System/Console/Haskeline/Backend/Iconv.hsc should test for HAVE_LANGINFO_H, and default codeset to """" in its absence.  (No langinfo.h on Haiku.)"	donn
3	7876	hClose002 for ghci hangs on Mac OS X	Compiler	7.6.3	normal				new	2013-05-01T11:57:45-0700	2013-05-01T12:09:09-0700	"I'm on OS X 10.7.5

{{{
ghc : ade1ae97ed52c493ec415c1601dace39b64071dd
testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b
base : b3387abfbc94b69e977c232386acad4dde7597e8
}}}

hClose002 fails with these three ways:

{{{
$ make TESTS=hClose002
# ... snip ...
Unexpected failures:
   ../../libraries/base/tests/IO  hClose002 [bad exit code] (ghci,threaded1,threaded2)
}}}

The test opens a file in !WriteMode, closes it ""without telling the IO library"", then hCloses it twice. Then it does that again in !ReadMode. Thus there are four hClose calls in total. It is the third one that hangs."	nfrisby
2	7919	Heap corruption (segfault) from large 'let' expression	Runtime System	7.6.3	high		7.8.1	simonmar	patch	2013-05-17T13:31:16-0700	2013-05-17T23:29:30-0700	"The attached test program reliably triggers an assertion in the storage manager with the `-debug` rts.

{{{
LargeUse: internal error: ASSERTION FAILED: file rts/sm/GCUtils.c, line 208

    (GHC version 7.6.3 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}

This behaviour is reproducible with many recent ghc versions (tried 7.6.3, 7.4.2, 6.12.3) and all fail at the same assertion when using the `-debug` rts. (Without `-debug` we get a more random variety of segfaults and GC errors.)

It looks like a pretty clear case of heap corruption. I'll explain why...

The test program uses TH to generate a program that looks like this:
{{{
data Large = Large Int Int ... -- 512 non-strict Int fields

test =
  let step (Large i1 i2 ... i512) =
        let j1 = i1 + i4
            j2 = i2 + i7
            ...
            j511 = i511 + i510
            j512 = i512 + i1
         in Large j1 j2 ... j512

   in runSteps step 100000 (Large 1 1 ... 1)

-- basically an unfoldr:
runSteps :: (state -> (state, Int)) -> Int -> state -> [Int]
runSteps f n i | n <= 0    = []
               | otherwise = case f i of
                               (i', r) -> r : runSteps f (n - 1) i'
}}}

We use TH to generate this program, and we use a ""size"" parameter that determines size of the data constructor (and corresponding letrec). This makes it easy to find the size threshold where it fails.

For small sizes this program works fine, and for larger values it triggers the assert. With ghc 7.6.3 on a x86-64 machine, the magic threshold is 511: that is, the program works fine with size 510 and hits the assertion at size 511. This is suspiciously close to 512. And of course on a 64bit machine 512 * 8 is 4k, which is the storage manager's block size. And the failing assertion is in a bit of the storage manager that is dealing with blocks...

{{{
        // If this block does not have enough space to allocate the
        // current object, but it also doesn't have any work to push, then 
        // push it on to the scanned list.  It cannot be empty, because
        // then there would be enough room to copy the current object.
        if (bd->u.scan == bd->free)
        {
            ASSERT(bd->free != bd->start);
            push_scanned_block(bd, ws);
        }
}}}

So it looks very much like we have a situation where something is writing over the end of a block and messing up the SM's data structures.

But, it is not nearly as simple as the data constructor being too big. We can demonstrate other programs that use much larger data constructors without any problem at all. Our suspicion falls on the big letrec.

Indeed with this program if we change the data constructor to have strict fields then it no longer fails, and we can run it with much larger data constructor sizes. What would be different between strict and non-strict fields here? Well, one observation is that when it is strict then ghc can (and does) turn the code into a big cascade of case expressions, while when it is non-strict then the STG code is all 'let's.

{{{
        case tpl_s6jQ of tpl_s6Ak {
          __DEFAULT ->
              case tpl_s6jS of tpl_s6Al {
                __DEFAULT ->
                    case tpl_s6jU of tpl_s6Am {
    -- etc for all 500+ elements
}}}
versus
{{{
              let {
                sat_s5UK :: GHC.Types.Int
                [LclId] =
                    \u [] GHC.Num.$fNumInt_$c+ i511_s5Ly i1_s5E9; } in
              let {
                sat_s62X :: GHC.Types.Int
                [LclId] =
                    \u [] GHC.Num.$fNumInt_$c+ i510_s5R2 i509_s5UG; } in
              let {
                sat_s62W :: GHC.Types.Int
                [LclId] =
                    \u [] GHC.Num.$fNumInt_$c+ i509_s5UG i506_s5UC; } in
    -- etc for all 500+ elements
}}}

Note also, that it is nothing to do with the obvious space leak here. If we modify the code to generate an NFData instance and to use deepseq at each iteration then we eliminate the space leak, but we keep the big stg 'let', and it still fails."	duncan
3	3048	Heap size suggestion gets ignored when -G1 flag is passed	Runtime System	6.10.1	normal	minor	_|_		new	2009-02-24T18:19:43-0800	2009-03-03T09:38:58-0800	"Try running any program with {{{-G1}}} and a large {{{-H}}} option -- for example, cichelli from the nofib suite:
{{{
$ ./cichelli  +RTS -s -H32M -G1
[output snipped]
41,211,752 bytes allocated in the heap
      19,329,984 bytes copied during GC
       1,760,916 bytes maximum residency (34 sample(s))
          36,724 bytes maximum slop
               7 MB total memory in use (0 MB lost due to fragmentation)
}}}

Here, the suggestion of 32M seems to have been ignored, as the heap is at most 7M during execution. Whereas without {{{-G1}}}:
{{{
./cichelli  +RTS -s -H32M
[output snipped]
41,212,300 bytes allocated in the heap
       1,121,304 bytes copied during GC
          49,484 bytes maximum residency (1 sample(s))
          36,824 bytes maximum slop
              31 MB total memory in use (0 MB lost due to fragmentation)
}}}

Here, the size suggestion is used and a 32M heap is allocated.

Shouldn't the GC use the heap size suggestion even when there is only one generation?"	tim
3	806	hGetBufNonBlocking doesn't work on Windows	libraries/base	6.4.2	normal	normal	_|_		new	2006-06-26T22:52:35-0700	2013-03-02T21:06:40-0800	"All HAppS (http://happs.org/HAppS/README.html) applications fail with an internal error: asyncRead# when compiled with the  -threaded option.

To reproduce the error:
- compile any of the apps in the example subdirectory with -threaded and access it over the net (http://localhost:8000).

For example: 

ghc --make -v -fallow-overlapping-instances -fglasgow-exts -threaded httpd.hs -o httpd

The same programs compiled without -threaded work fine.

Tested on Windows XP with latest SP/patches and gcc 6.4.2.
 
Let me know if you would like more info or the full compilation trace."	titto@…
3	2628	hIsTerminalDevice returns True for /dev/null (aka NUL) on Windows	libraries/base	6.8.3	normal	normal	_|_		new	2008-09-27T10:27:04-0700	2011-04-06T01:29:42-0700	"test 2228 is failing for me in an msys window on Windows:
{{{
-BlockBuffering Nothing
+LineBuffering
 BlockBuffering Nothing
}}}
because isatty behaves unexpectedly on mingw:
{{{
#include <stdio.h>
#include <unistd.h>

int main(void) {
    int i;
    i = fileno(stdin);
    printf(""%d\n"", i);
    i = fileno(stdout);
    printf(""%d\n"", i);
    i = isatty(0);
    printf(""%d\n"", i);
    i = isatty(1);
    printf(""%d\n"", i);
    return 0;
}
}}}
{{{
$ ./w            
0
1
0
0

$ ./w < /dev/null
0
1
64
0
}}}
"	igloo
5	3376	hpc and CPP don't mix on Windows	Code Coverage	6.10.4	lowest	normal	7.6.2	andy@…	new	2009-07-16T09:21:57-0700	2012-09-12T04:14:11-0700	"Originaly reported by Dominic Steinitz here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-July/017511.html

On Windows, with these files:

CommonHPC.hs:
{{{
module Main (main) where

import Common

main = do
  test
  test

test = do
  putStrLn $ show $ fact 4
  putStrLn $ show $ fact 5
}}}

Common.hs:
{{{
module Common (fact) where

fact 0 = 1
fact n = n * fact (n-1)
}}}

This works:
{{{
$ ghc -fhpc --make CommonHPC
$ ./CommonHPC
$ cat CommonHPC.exe.tix
Tix [ TixModule ""Main"" 693125724 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule ""Common"" 4136915291 8 [2,9,9,9,9,9,9,11]]
}}}

but with `-cpp` we get no ticks for Common:
{{{
$ ghc -fhpc --make CommonHPC -cpp
$ ./CommonHPC
$ cat CommonHPC.exe.tix
Tix [ TixModule ""Main"" 693125724 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule ""Common"" 3370079577 0 []]
}}}
"	igloo
5	1853	hpc mix files for Main modules overwrite each other	Code Coverage	6.8.1	lowest	normal	7.6.2	AndyGill	new	2007-11-07T19:08:12-0800	2013-01-28T07:50:33-0800	"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
5	3191	hpc reports spurious results with .lhs files even after processing with ghc -E	Code Coverage	6.10.2	lowest	normal	7.6.2	andy@…	new	2009-04-25T01:44:12-0700	2012-09-12T04:14:09-0700	"I've done a bit of investigation and it seems there are at least two problems:

1. I have literate haskell files (.lhs).

2. Even if I run them through the pre-processor (ghc -E) they still don't work 
but if I manually remove these lines (which seem to get inserted by the
pre-processor)

{-# LINE 1 ""ASNTYPE.lhs"" #-}
#line 1 ""ASNTYPE.lhs""

then it does actually work.

I still have a problem with another project which doesn't use literate haskell
but does require the use of -cpp and has got #ifdef's. I haven't got to the
bottom of it yet but I'm suspicious that lines starting with # cause hpc to
misbehave.

It's strange that hpc should behave like this as I would have thought it
wouldn't care about hs / lhs and # as ghc would have done some of its standard
processing before hpc got engaged.

This happens on linux and windows (not surprisingly)."	dominic
4	4931	hsc2hs emits invalid OPTIONS_GHC pragmas	hsc2hs	7.0.1	low		7.6.2		new	2011-01-29T02:57:12-0800	2012-09-12T04:13:24-0700	"If I write
{{{
#define FOO ""bar baz""
}}}
in my hsc code, hsc2hs emits
{{{
{-# OPTIONS_GHC -optc-DFOO=""bar baz"" #-}
}}}
which GHC refuses to compile.

For my local hsc2hs I didn't bother with {{{goodForOptD}}} AI and have removed {{{outOption}}} for {{{""define""}}} key in {{{outSpecial}}} altogether."	awson
3	2189	hSetBuffering stdin NoBuffering doesn't work on Windows	libraries/base	6.8.2	normal	normal	7.6.2		new	2008-03-31T14:22:42-0700	2013-03-02T21:05:32-0800	"The following program repeats inputted characters until the escape key is pressed.


{{{
import IO
import Monad
import Char

main :: IO ()
main = do hSetBuffering stdin NoBuffering
          inputLoop
          
inputLoop :: IO ()
inputLoop = do i <- getContents
               mapM_ putChar $ takeWhile ((/= 27) . ord) i
}}}


Because of the ""hSetBuffering stdin NoBuffering"" line it should not be necessary to press the enter key between keystrokes. This program works correctly in WinHugs (sep 2006 version). However, GHC 6.8.2 does not repeat the characters until the enter key is pressed. The problem was reproduced with all GHC executables (ghci, ghc, runghc, runhaskell), using both cmd.exe and command.com on Windows XP Professional."	FalconNL
3	7877	hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X	GHCi	7.6.3	normal				new	2013-05-01T13:13:37-0700	2013-05-01T13:13:37-0700	"{{{
$ make TESTS=""hSetBuffering002 hSetBuffering004""
# ... snip ...
Unexpected failures:
   ../../libraries/base/tests/IO  hSetBuffering002 [bad exit code] (ghci)
   ../../libraries/base/tests/IO  hSetBuffering004 [bad stdout or stderr] (ghci)
}}}

For 002, there's a stderror message: `<stdin>: hGetLine: illegal operation (handle is closed)`

For 004, it seems like ghci is trying to parse the part of the .genscript file that the program is supposed to use as stdin.

I'm on OS X 10.7.5

{{{
ghc : ade1ae97ed52c493ec415c1601dace39b64071dd
testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b
base : b3387abfbc94b69e977c232386acad4dde7597e8
}}}"	nfrisby
3	7161	hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles	libraries/base	7.6.1-rc1	normal		7.8.1		new	2012-08-18T15:57:41-0700	2012-10-16T07:57:10-0700	"The `hSetNewlineMode` and `hSetEncoding` functions from `GHC/IO/Handle.hs` do not check that the Handle is in an open mode. It is possible to use them on closed handles. hSetEncoding on a closed Handle triggers a segfault. Similarly, the operations are also both possible on semi-closed handles, and given the way hGetContents is implemented, this will affect the result of hGetContents which is clearly against the intention of the hGetContents/semi-closed stuff.

Both functions use the `withAllHandles__` helper. Unlike similar helpers like `wantReadableHandle_` this one doesn't do any handle mode checking.

Additionally, `hSetBuffering` and `hSetBinary` mode also use the `withAllHandles__` pattern and don't obviously check for an open handle but I've not verified this."	duncan
3	7378	Identical alts/bad divInt# code	Compiler	7.6.1	normal		7.8.1		new	2012-10-31T06:33:28-0700	2013-04-12T10:39:19-0700	"[http://stackoverflow.com/questions/13139875/removing-case-with-duplicate-branches-from-haskells-core This] may be the same as #7360, but it may also be a problem in the code generation for `divInt#`. I've reduced it to the following minimal test case:

When compiling

{{{
fun :: Int -> Int
fun i = i `div` 2
}}}

with `ghc -O2 -funfolding-use-threshold=150`, the generated core becomes

{{{
Div2.fun =
  \ (i_aeH :: GHC.Types.Int) ->
    case i_aeH of _ { GHC.Types.I# ww_aiV ->
    case GHC.Prim.># ww_aiV 0 of _ {
      GHC.Types.False ->
        case GHC.Prim.<# ww_aiV 0 of _ {
          GHC.Types.False -> GHC.Types.I# (GHC.Prim.quotInt# ww_aiV 2);
          GHC.Types.True ->
            GHC.Types.I#
              (GHC.Prim.-# (GHC.Prim.quotInt# (GHC.Prim.+# ww_aiV 1) 2) 1)
        };
      GHC.Types.True ->
        case GHC.Prim.<# ww_aiV 0 of _ {
          GHC.Types.False -> GHC.Types.I# (GHC.Prim.quotInt# ww_aiV 2);
          GHC.Types.True ->
            GHC.Types.I#
              (GHC.Prim.-# (GHC.Prim.quotInt# (GHC.Prim.+# ww_aiV 1) 2) 1)
        }
    }
    }
}}}

with two identical `case` alternatives, and in the `True` case, the next comparison is guaranteed to return `False`.

The generated core is good if the divisor is negative, though, so that speaks for taking a look at `divInt#`."	daniel.is.fischer
5	2184	if findExecutable finds a file that matchs the argument, check if it is an executable	libraries/directory	6.8.2	lowest	normal	7.6.2		new	2008-03-28T17:49:54-0700	2012-09-12T04:13:55-0700	"When search finds a file that matchs with the fileName argument of findExecutable, it doesn't check if the file is an executable file.

{{{
 do
  path <- getEnv ""PATH""
  search (splitSearchPath path)
  where
    fileName = binary <.> exeExtension

    search :: [FilePath] -> IO (Maybe FilePath)
    search [] = return Nothing
    search (d:ds) = do
        let path = d </> fileName
        b <- doesFileExist path
        if b then return (Just path)
             else search ds
}}}

findExecutable mustn't returns a file that it isn't an executable file, for example

(~/bin is in PATH variable)
{{{
$ touch ~/bin/foofile
$ ghci
$ :m System.Directory
$ findExecutable ""foofile""
}}}

shows that findExecutable returns IO (Just ""/home/iago/bin/foofile"").

Altought is not a bug, could be good add a new funcion (findExecutables for example) to return all the executables in all the paths of PATH variable that matchs with a given filename (like which -a).

"	iago
3	7520	Implement cardinality analysis	Compiler	7.6.1	normal		7.8.1		new	2012-12-21T10:06:31-0800	2013-04-12T14:37:59-0700	"Ilya is well on the way to a cardinality analyser.  Today I realised that it'll help a lot with CPS-heavy code.  For example, here's what happens with
{{{
data DT = DT {
                field1 :: Int
              , field2 :: Int
              , field3 :: Int }
  deriving( Read )
}}}
After strictness analysis and simplification we get this:
{{{
$wa_sD5 =
  \ (ww_sD1 :: GHC.Prim.Int#)
    (@ b_awu)
    (w_sD3 :: W2.DT -> Text.ParserCombinators.ReadP.P b_awu) ->
    case GHC.Prim.<=# ww_sD1 11 of _ {
      GHC.Types.False -> Text.ParserCombinators.ReadP.Fail @ b_awu;
      GHC.Types.True ->
        Text.Read.Lex.expect1
          a_su6
          @ b_awu
          (\ _ ->
             Text.Read.Lex.expect1
               a_suf
               @ b_awu
               (\ _ ->
                  Text.Read.Lex.expect1
                    a_sum
                    @ b_awu
                    (\ _ ->
                       Text.Read.Lex.expect1
                         a_suv
                         @ b_awu
                         (\ _ ->
                            GHC.Read.$fReadInt5
                              GHC.Read.$fReadInt_$sconvertInt
                              Text.ParserCombinators.ReadPrec.minPrec
                              @ b_awu
                              (\ (a2_XB0 [Dmd=Just L] :: GHC.Types.Int) ->
                                 Text.Read.Lex.expect1
                                   lvl_svA
                                   @ b_awu
                                   (\ _ ->
                                      Text.Read.Lex.expect1
                                        lvl_svE
                                        @ b_awu
                                        (\ _ ->
                                           Text.Read.Lex.expect1
                                             lvl_svI
                                             @ b_awu
                                             (\ _ ->
                                                GHC.Read.$fReadInt5
                                                  GHC.Read.$fReadInt_$sconvertInt
                                                  Text.ParserCombinators.ReadPrec.minPrec
                                                  @ b_awu
                                                  (\ (a2_XBa [Dmd=Just L] :: GHC.Types.Int) ->
...
}}}
Look at all those nested continuations! Then the subsequent float-out pass floats out lots of MFEs, but entirely fruitlessly because all these are actually one-shot lambdas.

I'm not certain that the analysis will catch them all, but it might."	simonpj
3	7206	Implement cheap build	Compiler	7.4.2	normal		_|_	simonpj	new	2012-08-31T05:06:24-0700	2013-02-13T00:56:12-0800	"We sometimes see stuff like this:
{{{
f n ps = let ys = [1..x]
         in map (\zs. ys ++ zs) ps
}}}
You might think the `(++)` would fuse with the `[1..x]`, via foldr/build fusion, but it doesn't.  Why not?  Because it would be WRONG to do so in this case:
{{{
f ns ps = let ys = map expensive ns
          in map (\zs. ys ++ zs) ps
}}}
If we fused the `(++)` with the `map` we might call `expensive` once for each element of `ps`.

This is fairly easy to fix. The point is that `[1..x]` is cheap; we'd prefer to fuse it even if doing so involves computing 1, 1+1, 2+1, etc multiple times.  Suppose we express this fact thusly:
{{{
enumFromTo lo hi = cheapBuild (\cn. ....lo...hi...)
map f xs = build (\cn. ...f...xs...)
}}}
Now we want the `foldr/cheapBuild` rule to fire even if that would involve duplicating the call to `cheapBuild`.  And we already have a way to do that: we make `cheapBuild` into a `CONLIKE` function.

Happily it's almost all simply a change to the libraries, not the compiler itself.

I just need to execute on this, but I keep failing to get round to it.  Below is the beginning. One missing piece is that I need to replace the hack for `build` in the occurrence analyser, so that it works for `cheapBuild` too.  (At least until we have Ilya's cardinality analyser.)

Simon

{{{
diff --git a/GHC/Base.lhs b/GHC/Base.lhs
index 6a36eb5..b78edf5 100644
--- a/GHC/Base.lhs
+++ b/GHC/Base.lhs
@@ -304,6 +304,12 @@ build   :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]

 build g = g (:) []

+cheapBuild   :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]
+{-# INLINE CONLIKE [1] cheapBuild #-}
+-- cheapBuild is just like build, except that it is CONLIKE
+-- See Note [cheapBuild]
+cheapBuild g = g (:) []
+
-- | A list producer that can be fused with 'foldr'.
-- This function is merely
--
@@ -320,6 +326,8 @@ augment g xs = g (:) xs
{-# RULES
""fold/build""    forall k z (g::forall b. (a->b->b) -> b -> b) . 
                 foldr k z (build g) = g k z
+""fold/cheapBuild""    forall k z (g::forall b. (a->b->b) -> b -> b) . 
+                     foldr k z (cheapBuild g) = g k z

 ""foldr/augment"" forall k z xs (g::forall b. (a->b->b) -> b -> b) . 
                 foldr k z (augment g xs) = g k (foldr k z xs)
@@ -343,6 +351,12 @@ augment g xs = g (:) xs
""augment/build"" forall (g::forall b. (a->b->b) -> b -> b)
                        (h::forall b. (a->b->b) -> b -> b) .
                        augment g (build h) = build (\c n -> g c (h c n))
+
+""augment/cheapBuild"" forall (g::forall b. (a->b->b) -> b -> b)
+                       (h::forall b. (a->b->b) -> b -> b) .
+                       augment g (cheapBuild h) = build (\c n -> g c (h c n))
+   -- 'augment' doesn't necessarily have a cheap argument, so we revert to 'build'
+
""augment/nil""   forall (g::forall b. (a->b->b) -> b -> b) .
                         augment g [] = build g
  #-}
@@ -351,6 +365,20 @@ augment g xs = g (:) xs
--      augment g (augment h t) = augment (\cn -> g c (h c n)) t
\end{code}

+Note [cheapBuild]
+~~~~~~~~~~~~~~~~~
+cheapBuild is just like build, except that it is CONLIKE
+
+It is used in situations where fusion is more imortant than sharing,
+ie in situation where its argument function 'g' in (cheapBuild g) is
+cheap.
+
+Main example: enumerations of one kind or another:
+    f x = let xs = [x..] 
+              go = \y. ....go y'....(map (h y) xs)...
+          in ...
+Here we woud like to fuse the map with the [x..]
+

 ----------------------------------------------
--              map     
@@ -831,7 +859,7 @@ a `iShiftRL#` b | b >=# WORD_SIZE_IN_BITS# = 0#

 -- Rules for C strings (the functions themselves are now in GHC.CString)
{-# RULES
-""unpack""       [~1] forall a   . unpackCString# a             = build (unpackFoldrCString# a)
+""unpack""       [~1] forall a   . unpackCString# a             = cheapBuild (unpackFoldrCString# a)
""unpack-list""  [1]  forall a   . unpackFoldrCString# a (:) [] = unpackCString# a
""unpack-append""     forall a n . unpackFoldrCString# a (:) n  = unpackAppendCString# a n

diff --git a/GHC/Enum.lhs b/GHC/Enum.lhs
index cea3ced..561a995 100644
--- a/GHC/Enum.lhs
+++ b/GHC/Enum.lhs
@@ -376,9 +376,9 @@ instance  Enum Char  where
     enumFromThenTo (C# x1) (C# x2) (C# y) = efdtChar (ord# x1) (ord# x2) (ord# y)

 {-# RULES
-""eftChar""       [~1] forall x y.        eftChar x y       = build (\c n -> eftCharFB c n x y)
-""efdChar""       [~1] forall x1 x2.      efdChar x1 x2     = build (\ c n -> efdCharFB c n x1 x2)
-""efdtChar""      [~1] forall x1 x2 l.    efdtChar x1 x2 l  = build (\ c n -> efdtCharFB c n x1 x2 l)
+""eftChar""       [~1] forall x y.        eftChar x y       = cheapBuild (\c n -> eftCharFB c n x y)
+""efdChar""       [~1] forall x1 x2.      efdChar x1 x2     = cheapBuild (\ c n -> efdCharFB c n x1 x2)
+""efdtChar""      [~1] forall x1 x2 l.    efdtChar x1 x2 l  = cheapBuild (\ c n -> efdtCharFB c n x1 x2 l)
""eftCharList""   [1]  eftCharFB  (:) [] = eftChar
""efdCharList""   [1]  efdCharFB  (:) [] = efdChar
""efdtCharList""  [1]  efdtCharFB (:) [] = efdtChar
@@ -510,7 +510,7 @@ instance  Enum Int  where
-- In particular, we have rules for deforestation

 {-# RULES
-""eftInt""        [~1] forall x y. eftInt x y = build (\ c n -> eftIntFB c n x y)
+""eftInt""        [~1] forall x y. eftInt x y = cheapBuild (\ c n -> eftIntFB c n x y)
""eftIntList""    [1] eftIntFB  (:) [] = eftInt
  #-}

@@ -539,7 +539,7 @@ eftIntFB c n x0 y | x0 ># y    = n

 {-# RULES
""efdtInt""       [~1] forall x1 x2 y.
-                     efdtInt x1 x2 y = build (\ c n -> efdtIntFB c n x1 x2 y)
+                     efdtInt x1 x2 y = cheapBuild (\ c n -> efdtIntFB c n x1 x2 y)
""efdtIntUpList"" [1]  efdtIntFB (:) [] = efdtInt
  #-}

@@ -646,8 +646,8 @@ instance  Enum Integer  where
     enumFromThenTo x y lim = enumDeltaToInteger x (y-x) lim

 {-# RULES
-""enumDeltaInteger""      [~1] forall x y.  enumDeltaInteger x y     = build (\c _ -> enumDeltaIntegerFB c x y)
-""efdtInteger""           [~1] forall x y l.enumDeltaToInteger x y l = build (\c n -> enumDeltaToIntegerFB c n x y l)
+""enumDeltaInteger""      [~1] forall x y.  enumDeltaInteger x y     = cheapBuild (\c _ -> enumDeltaIntegerFB c x y)
+""efdtInteger""           [~1] forall x y l.enumDeltaToInteger x y l = cheapBuild (\c n -> enumDeltaToIntegerFB c n x y l)
""enumDeltaInteger""      [1] enumDeltaIntegerFB   (:)    = enumDeltaInteger
""enumDeltaToInteger""    [1] enumDeltaToIntegerFB (:) [] = enumDeltaToInteger
  #-}
}}}"	simonpj
3	1057	Implicit parameters on breakpoints	GHCi	6.8.2	normal	normal	_|_		new	2006-12-18T02:42:59-0800	2009-11-16T05:11:47-0800	"Bring implicit parameters into the examine scope in breakpoints.

Test case is ghci.debugger break004"	mnislaih
3	7026	Impredicative implicit parameters	Compiler (Type checker)	7.4.2	normal		_|_		new	2012-06-23T10:36:30-0700	2012-06-28T01:45:20-0700	"There doesn't seem to be a way to make impredicative implicit parameters work in 7.4.2:

{{{
{-# LANGUAGE ImplicitParams, ImpredicativeTypes #-}
module Bug where

    f1 :: Maybe ((?a :: Bool) => Char)
    f1 = Just 'C'

    f2 :: Maybe ((?a :: Bool) => Bool)
    f2 = Just ?a
}}}


{{{
$ ghc -c Bug.hs 

Bug.hs:5:15:
    Couldn't match expected type `(?a::Bool) => Char'
                with actual type `Char'
    In the first argument of `Just', namely 'C'
    In the expression: Just 'C'
    In an equation for `f1': f1 = Just 'C'

Bug.hs:8:15:
    Unbound implicit parameter (?a::(?a::Bool) => Bool)
      arising from a use of implicit parameter `?a'
    In the first argument of `Just', namely `?a'
    In the expression: Just ?a
    In an equation for `f2': f2 = Just ?a
}}}

I believe this used to work?"	Ashley Yakeley
5	1330	Impredicativity bug: Church2 test gives a rather confusing error with the HEAD	Compiler (Type checker)	6.7	lowest	normal	7.6.2	simonpj	new	2007-05-05T08:23:10-0700	2012-09-12T04:13:36-0700	"The Church2 test gives a rather confusing error with the HEAD:
{{{
Church2.hs:27:14:
    Couldn't match expected type `CNat'
           against inferred type `(a -> a) -> a -> a'
      Expected type: CNat -> CNat
      Inferred type: CNat -> CNat
    In the first argument of `n', namely `(mul m)'
    In the expression: n (mul m) n1
}}}
In particular the lines
{{{
      Expected type: CNat -> CNat
      Inferred type: CNat -> CNat
}}}
are confusing, and I'm not sure why it's giving two expected/inferred pairs of types."	igloo
4	5224	Improve consistency checking for family instances	Compiler	7.0.3	low		7.6.2	simonpj	new	2011-05-26T08:15:41-0700	2012-09-12T04:13:30-0700	"Several compiler-performance tests got worse when I added the new generic default methods (with Pedro):
 * `T3064`: peak_megabytes_allocated 24 is more than maximum allowed 16
 * `IndTypesPerf`: needs more than the 20M heap it is given
 * `T4801`: max_bytes_used 31.4M is more than maximum allowed 30M

For the first two of these we know exactly why: the (necessarily) eager overlap check is reading interface files that are otherwise not read, becuase of the new `Rep` type family instances in `Data.Maybe` and so on.  Both these tests use type families.

For T4801 it's more mysterious.  The test does not use type families, and no new interface files are read, but residency increases.  So the cause may be different.

I'm pretty sure we can improve matters by propagating a bit more info; specifically, rather than a module simply saying ""I have some type familily instances"" it can say ""I have type family instances for F, G, H"".

I have marked the three tests as expect-broken for now, with the ticket to remind me to get back to it.
"	simonpj
5	2988	Improve float-in	Compiler	6.10.1	lowest	normal	7.6.2		new	2009-01-29T03:50:07-0800	2012-09-12T04:14:06-0700	"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
5	3781	Improve inlining for local functions	Compiler	6.12.1	lowest		7.6.2		new	2009-12-23T01:59:38-0800	2013-02-06T10:21:50-0800	"I found that `boyer2/Rewritefuns.onewayunify1` has a join point that really should be inlined.  It should get a big discount from scrutinizing free variables.  But the inlining mechanism only take account of arguments, not free variables.  There's a small optimisation opportunity here, which this ticket records. 

Here's the code:
{{{
Rewritefns.onewayunify1 =
  \ (t1_acm :: Lisplikefns.Lisplist)
    (t2_acn :: Lisplikefns.Lisplist)
    (u_aco :: Lisplikefns.Lisplist) ->
    case t2_acn of wild_ao1 {
      __DEFAULT ->
        case t1_acm of wild_Xok {
          __DEFAULT ->
            let {
              $j_spS
                :: GHC.Prim.State# GHC.Prim.RealWorld
                   -> (GHC.Bool.Bool, Lisplikefns.Lisplist)
              [LclId,
               Arity=1,
               Unf=Unf{Src=<vanilla>, TopLvl=False, Arity=1, Value=True,
                       ConLike=True, Cheap=True, Expandable=True,
                       Guidance=IF_ARGS [0] 10 0}]
              $j_spS =
                \ _ ->
                  Rewritefns.onewayunify1lst
                    (case wild_Xok of _ {
                       Lisplikefns.Nil -> Lisplikefns.Nil;
                       Lisplikefns.Cons ds1_anT ->
                         case ds1_anT of _ { (_, y_anY) -> y_anY }
                     })
                    (case wild_ao1 of _ {
                       Lisplikefns.Nil -> Lisplikefns.Nil;
                       Lisplikefns.Cons ds1_anT ->
                         case ds1_anT of _ { (_, y_anY) -> y_anY }
                     })
                    u_aco } in
            case wild_Xok of _ {
              Lisplikefns.Nil ->
                case wild_ao1 of _ {
                  Lisplikefns.Nil ->
                    case Lisplikefns.$fEqLisplist_$c== Lisplikefns.Nil Lisplikefns.Nil
                    of _ {
                      GHC.Bool.False -> (GHC.Bool.False, u_aco);
                      GHC.Bool.True -> $j_spS GHC.Prim.realWorld#
                    };
                  Lisplikefns.Cons ds1_anJ ->
                    case ds1_anJ of _ { (x_anN, _) ->
                    case Lisplikefns.$fEqLisplist_$c== Lisplikefns.Nil x_anN of _ {
                      GHC.Bool.False -> (GHC.Bool.False, u_aco);
                      GHC.Bool.True -> $j_spS GHC.Prim.realWorld#
                    }
                    }
                };
              Lisplikefns.Cons ds1_anJ ->
                case ds1_anJ of _ { (x_anN, _) ->
                case wild_ao1 of _ {
                  Lisplikefns.Nil ->
                    case Lisplikefns.$fEqLisplist_$c== x_anN Lisplikefns.Nil of _ {
                      GHC.Bool.False -> (GHC.Bool.False, u_aco);
                      GHC.Bool.True -> $j_spS GHC.Prim.realWorld#
                    };
                  Lisplikefns.Cons ds1_Xof ->
                    case ds1_Xof of _ { (x_Xom, _) ->
                    case Lisplikefns.$fEqLisplist_$c== x_anN x_Xom of _ {
                      GHC.Bool.False -> (GHC.Bool.False, u_aco);
                      GHC.Bool.True -> $j_spS GHC.Prim.realWorld#
                    }
                    }
                }
                }
            };
          Lisplikefns.Atom x_ao3 -> (GHC.Bool.False, u_aco)
        };
}}}
You can see that `$j_sps` scrutinises `wild_Xok` and `wild_ao1`, but it currently gets no discount for doing so.
"	simonpj
4	4985	Improve locations in ghci errors	Compiler	7.0.1	low		7.6.2		new	2011-02-27T11:12:58-0800	2012-09-12T04:13:25-0700	"
This shows GHC complaining of an error in line 9 of a 7 line file. The error is really on line 4. My guess is it's adding the line within the `:{` ... `:}` to the line of the `:}`, in which case the best fix is probably to remember the position of the `:{` and set the line number to that when evaluating the expression.

{{{
Prelude> :! cat script_me
:{
let y1 = 1
    y2 = 2
    Y3 = 3
    y4 = 4
    y5 = 5
:}
Prelude> :! wc -l script_me
7 script_me
Prelude> :script script_me

script_me:9:5: Not in scope: data constructor `Y3'
}}}

Additionally, errors in `.ghci` files currently have `<interactive>` as their location. Probably `sourceConfigFile` in `ghc/InteractiveUI.hs` should set the filename.
"	igloo
3	2255	Improve SpecConstr for free variables	Compiler	6.8.2	normal	normal	_|_		new	2008-05-01T00:43:45-0700	2013-03-26T09:23:29-0700	"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
5	2642	Improve SpecConstr for join points	Compiler	6.8.3	lowest	normal	7.6.2		new	2008-10-02T05:22:04-0700	2012-09-12T04:14:03-0700	"This is another `SpecConstr` improvement suggestion.  See also #2598, #2255.

Roman writes: Yes, this is turning into a major problem, in fact. This is the simplest example I could find:
{{{
foo :: Int -> Int :*: (Int :*: Int) -> Int
foo 0 p = p `seq` 0
foo i (m :*: (n1 :*: n2)) =
  case (case even (i-n1-n2) of
          True  -> (i `div` 2, (n1-1) :*: (n2-1))
          False -> (i-1, (n1+1) :*: (n2+1))) of
   (j, p) -> foo (if even i then i-m else i+m) ((m-1) :*: p)
}}}
The pattern here seems to be
{{{
        let j x = ....
        in ...(j (C a b)).... (j (C p q)) ...
}}}
So a C value is built every time j is called.  Simon Marlow also saw something very similar in some STM code he was optimising recently.

Here's a possible solution:
  * extend `SpecConstr` to work on *non-recursive* functions too.
  * look for the call pattern not in j's RHS (as we do for recursive fns) but in the body of the let

A possible restriction is to do all this only for local, non-recursive fns that are themselves defined in the RHS of a recursive function.  The motivation would be do it only when we're in a loop, and being in the body of a recursive function is a big clue.

Do you think that would address the cases you've encountered?   It would be a bit like making join-points eager to inline (specialisation is a bit like partial inlining) except that
  * we'd get sharing when there were two calls applied to the same constructor
  * it'd only happen if that argument was taken apart in the join point

Roman comments: No, the last restriction is not good: we often have
{{{
foo p = let j x' = ... foo (x',c) ...
         in ... j (C a) ... j (C b) ...
}}}
Here, the join point doesn't take apart the argument. In fact, this
probably makes it a bit trickier: we want to specialise the join point and
*then* specialise foo, getting
{{{
foo p = let j x' = ... foo (x',c) ...
             {-# RULES j (C z) = j' z #-}
             j' z = ... foo (C z,c) ...
         in ... j' a ... j' b ...

{-# RULES foo (C x,y) = foo' x y #-}
foo' x y = ...
}}}
A problem is that for `SpecConstr` to specialise `foo`, `j` must be specialised
and *simplified* first to expose the structure of the argument in the
recursive call. Can this be done without running SpecConstr twice? Or is
running `pecConstr/Simplify` repeatedly (until it produces no more
specialisations) acceptable?

"	simonpj
4	4366	in-tree GMP build problem with shared libraries	Build System	6.13	low		7.6.2		new	2010-10-05T05:05:04-0700	2012-09-12T04:12:30-0700	"Reported by  Vivian McPhail <haskell.vivian.mcphail@gmail.com> on glasgow-haskell-users:

{{{
Trying to build rc1 from source

linux x86_64
BuildFlavour = perf

It seems that the -fPIC flag is set, but an error still occurs (
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
)

""inplace/bin/ghc-stage1"" -fPIC -dynamic  -O -H64m    -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.2 -package rts-1.0  -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags     -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc -c libraries/base/./Data/Typeable.hs-boot -o libraries/base/dist-install/build/Data/Typeable.dyn_o-boot
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.2-ghc7.0.0.20100924.so] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
}}}"	simonmar
2	3927	Incomplete/overlapped pattern warnings + GADTs = inadequate	Compiler	6.12.1	high		7.8.1	simonpj	new	2010-03-18T02:01:55-0700	2013-03-22T03:19:00-0700	"Consider these defintions
{{{
data T a where
  T1 :: T Int
  T2 :: T Bool

-- f1 should be exhaustive
f1 :: T a -> T a -> Bool
f1 T1 T1 = True
f1 T2 T2 = False

-- f2 is exhaustive too, even more obviously
f2 :: T a -> T a -> Bool
f2 T1 (T1 :: T Int) = True
f2 T2 (T2 :: T Bool) = False

-- f3's first equation is unreachable
f3 :: T a -> T a -> Bool
f3 T2 T1 = False
f3 _  _  = True 
}}}
With HEAD (GHC 6.13) we get
{{{
G1.hs:11:1:
    Warning: Pattern match(es) are non-exhaustive
             In the definition of `f1':
                 Patterns not matched:
                     T1 T2
                     T2 T1
}}}
This is wrong.  
 * `f1` should behave like `f2`, and be accepted without warning.
 * `f3` has an inaccessible branch that is not reported.

The type checker accepts just the right programs, but the rather simple-minded approach to overlap warnings isn't doing the right thing.  

Note to self: the reason is that `tcPat` does not insert a coercion on the second arg to narrow the type, because there's no ''type'' reason to do so.  So for `f1` we get
{{{
f1 a (x:T a) (y:T a)
  = case x of { T1 (cox:a~Int) ->
      case y of { T1 (coy:a~Int) -> ... }
}}}
In the inner case it's not obvious that T2 is inaccessible.  If we refined eagerly we might get
{{{
f1 a (x:T a) (y:T a)
  = case x of { T1 (cox:a~Int) ->
      case (y |> T cox) of { T1 (coy:Int~Int) -> ... }
}}}
and now the scrutinee of the inner case has type `(T Int)` and the `T2` constructor obviously can't occur.

Fix this with the new inference engine."	simonpj
5	2256	Incompleteness of type inference: must quantify over implication constraints	Compiler	6.8.2	lowest	normal	7.6.2	simonpj	new	2008-05-01T06:59:43-0700	2012-09-12T04:13:56-0700	"Consider this program (from Iavor)
{{{
f x = let g y = let h :: Eq c => c -> ()
                    h z = sig x y z
                in ()
      in fst x

sig :: Eq (f b c) => f () () -> b -> c -> ()
sig _ _ _ = ()
}}}
This example is rejected by both Hugs and GHC but I think that it is a
well typed program. The Right Type to infer for g is this:
{{{
g :: forall b. (forall c. Eq c => Eq (b,c)) => b -> ()
}}}
but GHC never quantifies over implication constraints at the moment.  As a result, type inference is incomplete (although in practice no one notices).  I knew about this, but I don't think it's recorded in Trac, hence this ticket.

Following this example through also led me to notice a lurking bug: see ""BUG WARNING"" around line 715 of `TcSimplify`.  "	simonpj
3	5775	Inconsistency in demand analysis	Compiler	7.5	normal		7.6.2		new	2012-01-14T11:43:24-0800	2012-09-12T03:26:08-0700	"A small program:

{{{
{-# LANGUAGE MagicHash, UnboxedTuples #-}
module U where
import GHC.Prim
import GHC.Types

idx :: Addr# -> Int -> Int
{-# INLINE idx #-}
idx a (I# i) = case readIntOffAddr# a i realWorld# of (# _, y #) -> I# y

f :: Int -> Int -> Int
{-# INLINE f #-}
f x y = y + x

foo :: Addr# -> Int -> Int
foo a n = n `seq` loop (idx a 0) 1
  where
    loop x i = case i >= n of
      False -> loop (f x (idx a i)) (i+1)
      True  -> x
}}}

GHC infers the demand `LU(L)` for `loop`, only unboxes the second argument, ultimately generates a loop of type `Int -> Int# -> Int` and always allocates a thunk for the first argument:

{{{
      $wloop_si9 [Occ=LoopBreaker] :: Int -> Int# -> Int
      [LclId, Arity=2, Str=DmdType LL]
      $wloop_si9 =
        \ (w1_shU :: Int) (ww1_shX :: Int#) ->
          case >=# ww1_shX ww_si5 of _ {
            False ->
              $wloop_si9
                (case readIntOffAddr# @ RealWorld w_si2 ww1_shX realWorld#
                 of _ { (# _, y_a9S #) ->
                 case w1_shU of _ { I# y1_ahb -> I# (+# y_a9S y1_ahb) }
                 })
                (+# ww1_shX 1);
            True -> w1_shU
          }; }
}}}

But if I change the pragma on `f` from `INLINE` to `NOINLINE`, `loop` gets the demand `U(L)U(L)m` and GHC manages to unbox both arguments as well as the result, producing a nice tight loop:

{{{
      $wloop_sii [Occ=LoopBreaker] :: Int# -> Int# -> Int#
      [LclId, Arity=2, Str=DmdType LL]
      $wloop_sii =
        \ (ww1_shW :: Int#) (ww2_si0 :: Int#) ->
          case >=# ww2_si0 ww_sib of _ {
            False ->
              case readIntOffAddr# @ RealWorld w_si8 ww2_si0 realWorld#
              of _ { (# _, y1_Xac #) ->
              case f (I# ww1_shW) (I# y1_Xac) of _ { I# ww3_Xin ->
              $wloop_sii ww3_Xin (+# ww2_si0 1)
              }
              };
            True -> ww1_shW
          }; }
}}}

It would be nice if this happened in both cases."	rl
3	2057	inconsistent .hi file error gets ignored	Compiler	6.8.2	normal	normal	_|_		new	2008-01-19T08:59:02-0800	2008-09-30T08:51:40-0700	"{{{
[20 of 20] Compiling Main             ( ./Main.hs, dist/build/cabal/cabal-tmp/Main.o )
The interface for `main:Hackage.Config'
Declaration for savedConfigToConfigFlags
Unfolding of Hackage.Config.savedConfigToConfigFlags:
  Can't find interface-file declaration for variable Distribution.Simple.Setup.a401
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error
Linking dist/build/cabal/cabal ...
dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `sfsu_info':
(.text+0x70cc): undefined reference to `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `rf7U_closure':
(.data+0xf28): undefined reference to `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
collect2: ld returned 1 exit status
}}}

Now, the inconsistent .hi file was entirely my fault. However note that `ghc --make` did not stop at the error! It continued and tried to link.

This is bad because sometimes linker errors are very long and a user might loose the real source of the error.

The error gets raised in `iface/TcIface.lhs` by `importDecl`. The uses of that function look like they are translating the error into failure in other monads ok. It's not immediately obvious at what point in the propagation of this error it gets ignored and linking continues irrespective.

It should not be too hard to reproduce I hope. Generating inconsistent .hi files is fairly easy to do. In this case I just built cabal-install against an existing Cabal. Then rebuilt and re-registered a slightly changed Cabal lib. Then did another build of cabal-install without cleaning first."	duncan
3	7327	Inconsistent behavior for relative paths in runProcess	libraries/process	7.6.1	normal		7.8.1		infoneeded	2012-10-13T10:38:13-0700	2013-04-25T16:50:42-0700	"This was initially reported as a bug in cabal:

https://github.com/haskell/cabal/issues/1058

The relevant fix demonstrates the issue:

https://github.com/snoyberg/cabal/commit/48082b90726093298df8559b365ed08805ca6d8f

It seems that on Linux, a relative path for the executable is derived from the new working directory, whereas on Mac it is derived from the old working directory. (I have not tested on other systems.) Ideally, the behavior would be consistent across OSes, which IMO the more intuitive behavior being the current Mac behavior. The simplest solution would be to always turn the relative paths into absolute paths before changing working directories. However, doing so may introduce a performance hit.

Alternatively, a documentation fix would be good so that it's at least obvious that behavior is platform-specific. I can write a patch for either the change in behavior or the updated documentation, I'd just like to know which is preferred."	snoyberg
4	3649	inconsistent exception between unix/windows for running non-existant program	libraries/process	6.10.4	low	normal	7.6.2		new	2009-11-09T09:16:39-0800	2012-09-12T04:12:18-0700	"{{{
handle (print . isDoesNotExistError) $ do
  (_,_,_,hnd) <- createProcess (proc ""foobar"" [])
  print =<< waitForProcess hnd
}}}

On Windows this prints `True` since it throws a ""does not exists"" kind of IOException. On Unix instead the createProcess call succeeds and then waiting on the process claims it terminated with an exit code of 127.

It is annoying that we need two different error handling mechanisms in this case. For example Cabal wants to know when it tries to run a program that cannot be found (eg when it tries to run sh.exe on Windows).

It would be better if the behaviour was consistent. The behaviour on Windows seems to be the more sensible one. We should be able to make the Unix behaviour the same since the exceve call does indeed return an error code when loading the new executable image fails."	duncan
3	7842	Incorrect checking of let-bindings in recursive do	Compiler (Type checker)	7.7	normal				new	2013-04-16T17:00:50-0700	2013-05-06T18:19:20-0700	"I have run into a problem with the type-checking of recursive do blocks, which reduces to the following example:

{{{
{-# LANGUAGE RecursiveDo #-}
module Bug where

bug :: (Int -> IO Int) -> IO (Bool, Char)
bug m =
  mdo i <- m i1      -- RECURSION

      let i1 :: Int
          i1 = i     -- RECURSION

          -- This appears to be monomorphic, despite the type signature.
          f :: b -> b
          f x = x

      return (f True, f 'a')
}}}

This program is rejected with the errors shown below.  The problem appears to be that somehow `f` has become monomorphic, despite its type-signature.   This seems to happen only when `f` is part of a `let` block that is also involved in the recursion.

Here is the error reported by GHC 7.7.20130215:

{{{
Bug.hs:15:23:
    Couldn't match expected type `Char' with actual type `Bool'
    In the return type of a call of `f'
    In the expression: f 'a'
    In the first argument of `return', namely `(f True, f 'a')'

Bug.hs:15:25:
    Couldn't match expected type `Bool' with actual type `Char'
    In the first argument of `f', namely 'a'
    In the expression: f 'a'
    In the first argument of `return', namely `(f True, f 'a')'
}}}"	diatchki
3	5982	Incorrect dynamic library name in OSX	libraries/base	7.4.1	normal		7.6.2		new	2012-04-01T22:05:40-0700	2012-09-12T04:12:13-0700	"When building a simple program that is built using -dynamic, the resulting executable fails with the following error:

/Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib
  Referenced from: /usr/local/lib/ghc-7.4.1/libHSrts-ghc7.4.1.dylib
  Reason: image not found
[1]    90849 trace trap

The workaround in this case is to execute the following two commands:

otool -id /usr/local/lib/ghc-7.4.1/libffi.dylib /usr/local/lib/ghc-7.4.1/libffi.dylib

install_name_tool /usr/local/lib/ghc-7.4.1/libHSrts-ghc7.4.1.dylib -change /Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib /usr/local/lib/ghc-7.4.1/libffi.dylib


which is to say that the library  at /usr/local/lib/ghc-7.4.1/libffi.dylib  is identified as being /Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib which causes the linker to fail.





"	r0ml
3	7653	incorrect handling of StackOverflow exception in the event manager	libraries/base	7.7	normal		7.8.1	tibbe	patch	2013-02-02T06:33:17-0800	2013-04-12T16:59:59-0700	"Under high pressure of `registerTimeout`s the event manager thread's stack overflows.

Testcases:
Shachaf initially reported this testcase on #ghc,
which is irreproducible locally:
{{{
import Control.Monad;
import Control.Concurrent
main = replicateM_ 1000000 (forkIO (threadDelay 1))
}}}
to be compiled and run as follows:
{{{
$ ghc -O2 -threaded Main.hs && time ./Main +RTS -N
}}}
Limiting the stack to the minimum helped to reproduce this locally, both on x86 and x64:
{{{
import Control.Monad
import Control.Concurrent
main = replicateM_ 502 (forkIO (threadDelay 1)) -- 504 on x64
}}}
{{{
$ ghc -O2 -threaded -with-rtsopts=""-N8 -K4"" rplfrk.hs && ./rplfrk # -K8 on x64
}}}
and this, though less deterministically:
{{{
import Control.Monad
import Control.Concurrent
main = replicateM_ 340 ( forkIO (threadDelay 1))
}}}
{{{
$ ghc -O2 -threaded -rtsopts repl2-x86.hs && ./repl2-x86 +RTS -N1 -K4
}}}
Error messages look like:
{{{
Stack space overflow: current size 4 bytes.
Use `+RTS -Ksize -RTS' to increase it.
repl2-x86: sendWakeup: invalid argument (Bad file descriptor)
[...repeated...]
repl2-x86: ioManagerDie: write: Bad file descriptor
}}}
"	nus
2	7028	incorrect link paths for in mac os x after install	Build System	7.4.2	high		7.8.1	igloo	new	2012-06-23T22:15:43-0700	2012-10-11T14:20:21-0700	"I've built and installed 7.4.2 fron source:
{{{
iceman:ghc-7.4.2 andy$ otool -L /usr/local/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib/usr/local/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib:
	/usr/local/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/andy/src/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
}}}
Lib rts still links again the libffi in my home directory.

It should be linked against:
  /usr/local/lib/ghc-7.4.2/libffi.dylib

This problem also affects the binary distribution.
"	andykitchen
4	5041	Incorrect Read deriving for MagicHash constructors	Compiler	7.0.2	low		_|_		new	2011-03-22T18:37:34-0700	2011-04-19T23:35:34-0700	"Greetings,

A fellow in #haskell on freenode just discovered the following bug:

{{{
{-# LANGUAGE MagicHash #-}

data Note = A# deriving (Show, Read)
}}}

show works fine, but read doesn't:

{{{
*Main> show A#
""A#""
*Main> read (show A#)
*** Exception: Prelude.read: no parse
}}}

Probably not a surprising omission, and hopefully not difficult to fix."	dolio
4	4471	Incorrect Unicode output on Windows Console	Compiler	6.12.3	low		7.6.2		new	2010-11-04T11:31:44-0700	2013-03-07T23:44:36-0800	"To reproduce,

 * start a windows console
 * Change the console's font to a ttf unicode font, like ""Lucida Console"".
 * Type ""chcp 65001"" to set it to the UTF-8 code page.

test.hs
{{{
main = putStrLn ""∷⇒∀→←⋯⊢""
}}}

Output to the console is garbled. `runghc test.hs`:
{{{
∷⇒∀→←⋯⊢
→←⋯⊢
⋯⊢
∷⇒∀→←⋯⊢→←⋯⊢←⋯⊢⋯⊢⊢⊢⊢<stdout>: hFlush: permission denied (Permission denied)
}}}

Piping works correctly. `runghc test.hs > output && type output`:
{{{
∷⇒∀→←⋯⊢
}}}

ghci fails. `ghci test.hs`
{{{
GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main             ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
∷*** Exception: <stdout>: hPutChar: permission denied (Permission denied)
*Main>
}}}"	sankeld
4	4955	increase error message detail for module lookups failure due to hi references	Compiler	6.12.1	low		7.6.2		new	2011-02-11T05:38:45-0800	2012-09-12T04:13:24-0700	"Consider the following build log. In particular note that we start by cleaning any local build files (rm dist).

Additionally, the user reports that `transformers` is not installed and `ghc-pkg check` reports no problems.

{{{
00:14:25 | morn@twi:~/dev/darcs/fastconvert -> rm -rf dist 
00:14:27 | morn@twi:~/dev/darcs/fastconvert -> cabal configure -v
[...]
Dependency attoparsec ==0.8.1.1: using attoparsec-0.8.1.1
Dependency base ==4.2.0.0: using base-4.2.0.0
Dependency bytestring ==0.9.1.5: using bytestring-0.9.1.5
Dependency cmdlib ==0.3: using cmdlib-0.3
Dependency containers ==0.3.0.0: using containers-0.3.0.0
Dependency darcs ==2.5: using darcs-2.5
Dependency datetime ==0.2: using datetime-0.2
Dependency directory ==1.0.1.0: using directory-1.0.1.0
Dependency filepath ==1.1.0.3: using filepath-1.1.0.3
Dependency hashed-storage ==0.5.4: using hashed-storage-0.5.4
Dependency mtl ==1.1.1.0: using mtl-1.1.1.0
Dependency old-time ==1.0.0.3: using old-time-1.0.0.3
Dependency utf8-string ==0.3.6: using utf8-string-0.3.6
Using Cabal-1.8.0.2 compiled by ghc-6.12
Using compiler: ghc-6.12.1
[...]
00:14:31 | morn@twi:~/dev/darcs/fastconvert -> cabal build -v          
[...]
/usr/bin/ghc --make -o dist/build/darcs-fastconvert/darcs-fastconvert -hide-all-packages -fbuilding-cabal-package -package-conf dist/package.conf.inplace -i -idist/build/darcs-fastconvert/darcs-fastconvert-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/darcs-fastconvert/darcs-fastconvert-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -hidir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -stubdir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -package-id attoparsec-0.8.1.1-280af3ab9743111575ea0031e8a83455 -package-id base-4.2.0.0-73995e854f236dc2acd577d7c791221d -package-id bytestring-0.9.1.5-2d4a9d624c3be86b70c04730e5f12aca -package-id cmdlib-0.3-3ef785632945f8811c8ebbd1d2e9345b -package-id containers-0.3.0.0-409fe3b8f0dda25b98e03716d26be411 -package-id darcs-2.5-47653bbe1982b022915b3fa65161767f -package-id datetime-0.2-6f38d66fddaaa0ccccffea38d6fe8d60 -package-id directory-1.0.1.0-10fc46e61b67ff4a83f3e553454d003c -package-id filepath-1.1.0.3-07812de93a673f50011d47451bcaac87 -package-id hashed-storage-0.5.4-8a6b02d90d8e1d05f233c1e31eb4a367 -package-id mtl-1.1.1.0-7772b7b72936d947193a773ada65461a -package-id old-time-1.0.0.3-b53830b41b1085071f61ca7772f44e0c -package-id utf8-string-0.3.6-a7e240d06fa0c09cfff1a5445b521d24 -O -Wall -fno-warn-unused-do-bind ./main.hs
[1 of 5] Compiling Utils            ( Utils.hs, dist/build/darcs-fastconvert/darcs-fastconvert-tmp/Utils.o )
[...]
[3 of 5] Compiling Import           ( Import.hs, dist/build/darcs-fastconvert/darcs-fastconvert-tmp/Import.o )
Failed to load interface for `Control.Monad.Trans.Error':
  no package matching `transformers-0.2.2.0' was found
}}}

The message
{{{
Failed to load interface for `Control.Monad.Trans.Error':
  no package matching `transformers-0.2.2.0' was found
}}}
appears to be due to a .hi file from one of the dependencies of the current compilation. This hi file references a module from the transformers package.

 1. it is hard for a user to know what is causing this module to be looked up (ie that it is a .hi file)
 2. it is almost impossible to work out which existing registered package contains a .hi file that refers to the non-existent `transformers` package.

If the error message specified that it was a .hi file that caused the lookup and gave e.g. the file name (or package+ver+module) of the .hi file that caused the lookup of `transformers` then this would make it much easier for the user to work out what is going on and which registered package is at fault: e.g.

{{{
Failed to load interface for `Control.Monad.Trans.Error':
  the package `transformers-0.2.2.0' was found
  referenced by `Data.Foo` from `foo-1.0`.
}}}

Clearly there is a deeper problem here, that a registered package is out-of-sync with its registration information: the .hi refers to a package that is not mentioned in the package registration.

One way this could happen is due to inplace registrations, since it is easy in that case to rebuild the inplace .hi files without also re-registering. It may be sensible to rethink how Cabal does inplace registrations to prevent it getting out of sync.

We may also wish to have a ghc-pkg register/update/check mode that reads the .hi files and verifies them against the package registration info."	duncan
5	926	infinite loop in ShutdownIOManager()	Runtime System	6.5	lowest	normal	_|_		new	2006-10-07T06:42:40-0700	2009-07-07T01:23:26-0700	"Hi,

I have found a way to 'hang' a DLL created using ghc-6.5.20061006 under Win32. This occurs when I dynamically load DLL built using GHC, call one of its exported functions that uses file IO and then exit my program without explicitly releasing the DLL first. I have uploaded a test application to http://eeter.fi.tartu.ee/~mark/ghc_hang.zip that demonstrates this issue.

I am not sure if I can call this a bug, as when I unload the DLL, everything works fine. But this does not happen in GHC-6.4.2 or older versions.

Regards,
Mark"	guest
4	1176	Infinite loop when printing error message	Compiler	6.6	low	normal	_|_	thorkilnaur	new	2007-02-25T12:14:46-0800	2013-01-21T08:41:45-0800	"I am trying to compile a file that has a known compile error.  Ghc gets into an infinite loop trying to output the error message.

Here's the session (captured using EMACS shell):

{{{
pberry@Dal:~/bridge_ghc_bug$ uname -a
Linux Dal 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux
pberry@Dal:~/bridge_ghc_bug$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
pberry@Dal:~/bridge_ghc_bug$ ghc -v --make main.hs
Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6
Using package config file: /usr/lib/ghc-6.6/package.conf
wired-in package base mapped to base-2.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.0
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: main.hs
Stable obj: []
Stable BCO: []
compile: input file main.hs
Created temporary directory: /tmp/ghc5182_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main             ( main.hs, main.o )
*** Parser:
*** Renamer/typechecker:

main.hs:30:12:
    No instance for (Show Rank)
      arising from use of `show' at main.hs:30:12-19
    Possible fix: add an instance declaration for (Show Rank)
    In the first argument of `(~?=)', namely `show Ten'
    In the expression: (show Ten) ~?= ""T""
    In the second argument of `($)', namely
	`[(show Two) ~?= ""2"", (show Three) ~?= ""3"", (show Four) ~?= ""4"",
      (show Five) ~?= ""5"", (show Six) ~?= ""6"", (show Seven) ~?= ""7"",
  (show Eight) ~?= ""8"", (show Nine) ~?= ""9"", (show Ten) ~?= ""T"",
}}}

At this point ghc goes into an (apparently) infinite loop outputting spaces.  When I interrupt it using Ctrl-C, it says:

{{{
*** Deleting temp files:
Deleting: /tmp/ghc5182_0/ghc5182_0.s
Warning: deleting non-existent /tmp/ghc5182_0/ghc5182_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc5182_0
}}}

Here's the file main.hs:

{{{
import System
import Test.HUnit
import Control.Monad
import Data.List

data Card = Card Rank Suit

data Suit = Clubs | Diamonds | Hearts | Spades
    deriving (Enum, Eq)

data Rank = Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten | Jack | Queen | King | Ace
    deriving (Enum, Ord, Eq)

type Hand = [Card]

hand :: String -> Hand
hand = undefined

main = undefined

allTests = test $
           [show Two ~?= ""2""
           ,show Three ~?= ""3""
           ,show Four ~?= ""4""
           ,show Five ~?= ""5""
           ,show Six ~?= ""6""
           ,show Seven ~?= ""7""
           ,show Eight ~?= ""8""
           ,show Nine ~?= ""9""
           ,show Ten ~?= ""T""
           ,hand ""AK76543/32/AK2/3"" ~?= exampleHand
           ]
    where exampleHand = []
}}}"	Paul_Berry@…
5	367	Infinite loops can hang Concurrent Haskell	Compiler	6.4.1	lowest	normal	_|_	ezyang	new	2005-04-26T00:35:26-0700	2013-01-24T09:24:36-0800	"{{{
An infinite loop that does not allocate can hang 
Concurrent Haskell, becuase no thread switching 
occurs.  Demo code below (from Koen Claessen).

Bites occasionally, but not often.

Simon



module Main where

import Control.Concurrent
  ( forkIO
  , threadDelay
  , killThread
  , newEmptyMVar
  , takeMVar
  , putMVar
  )

import Data.IORef

import IO( hFlush, stdout )

timeout :: Int -> a -> IO (Maybe a)
timeout n x =
  do put ""Race starts ...""
     resV <- newEmptyMVar
     pidV <- newEmptyMVar

     let waitAndFail =
           do put ""Waiting ...""
              threadDelay n
              put ""Done waiting!""
              putMVar resV Nothing

         eval =
           do put ""Evaluating ...""
              x `seq` put ""Done!""
              putMVar resV (Just x)

     -- used ""mfix"" here before but got non-termination 
problems
     -- (not sure they had anything to do with mfix)
     pid1  <- forkIO $ do pid2 <- takeMVar pidV
                          eval
                          killThread pid2
     pid2  <- forkIO $ do waitAndFail
                          killThread pid1
     putMVar pidV pid2

     put ""Blocking ...""
     takeMVar resV

put s =
  do putStrLn s
     hFlush stdout

main =
  do timeout 1 (sum (repeat 1))
<<<

The above program produces the following (expected 
result):

>>>
Race starts ...
Blocking ...
Evaluating ...
Waiting ...
Done waiting!
<<<

If you replace 'sum (repeat 1)' by 'last (repeat 1)' the
program hangs.


}}}"	simonpj
3	5646	Initialise tuples using pragmas	Data Parallel Haskell	7.3	normal		7.6.2	chak	new	2011-11-17T18:26:07-0800	2012-09-12T04:12:06-0700	Fix `initBuiltinTyCons` in `Vectorise.Builtins.Base`.	chak
3	5928	INLINABLE fails to specialize in presence of simple wrapper	Compiler	7.4.1	normal		7.6.2		new	2012-03-11T10:29:08-0700	2013-01-08T15:47:43-0800	"If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.)

Here's an example where it fails. First, the simple wrapper module:

{{{
module Repro where

import Data.Hashable
import Data.HashMap.Strict as M

infixl 9  !
(!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b
m ! x = case M.lookup x m of  -- lookup is INLINABLE
    Just y -> y
    Nothing -> error ""Repro.!""
}}}

and then the call site:

{{{
module Test (test) where

import Data.HashMap.Strict as M

import Repro

test :: M.HashMap Int Int -> Int
test m = m ! 42
}}}

To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered-containers is:

{{{
lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v
lookup k0 = go h0 k0 0
  where
    h0 = hash k0
    go !_ !_ !_ Empty = Nothing
    go h k _ (Leaf hx (L kx x))
        | h == hx && k == kx = Just x
        | otherwise          = Nothing
    go h k s (BitmapIndexed b v)
        | b .&. m == 0 = Nothing
        | otherwise    = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m))
      where m = mask h s
    go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s))
    go h k _ (Collision hx v)
        | h == hx   = lookupInArray k v
        | otherwise = Nothing
#if __GLASGOW_HASKELL__ >= 700
{-# INLINABLE lookup #-}
#endif
}}}

If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that.

The core for `Repro` and `Test` is:

{{{
$ ghc -O2 Test.hs -fforce-recomp -ddump-simpl 
[1 of 2] Compiling Repro            ( Repro.hs, Repro.o )

==================== Tidy Core ====================
Result size = 28

lvl_rNZ :: [GHC.Types.Char]
[GblId]
lvl_rNZ = GHC.CString.unpackCString# ""Repro.!""

Repro.!1 :: forall b_aBU. b_aBU
[GblId, Str=DmdType b]
Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ

Repro.!
  :: forall a_atJ b_atK.
     (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) =>
     Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK
[GblId,
 Arity=4,
 Str=DmdType LLLL,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [0 0 0 0] 70 0}]
Repro.! =
  \ (@ a_aBT)
    (@ b_aBU)
    ($dEq_aBV :: GHC.Classes.Eq a_aBT)
    ($dHashable_aBW :: Data.Hashable.Hashable a_aBT)
    (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU)
    (x_atM :: a_aBT) ->
    case Data.HashMap.Base.lookup
           @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL
    of _ {
      Data.Maybe.Nothing -> Repro.!1 @ b_aBU;
      Data.Maybe.Just y_atN -> y_atN
    }



[2 of 2] Compiling Test             ( Test.hs, Test.o )

==================== Tidy Core ====================
Result size = 20

Test.test2 :: GHC.Types.Int
[GblId,
 Caf=NoCafRefs,
 Str=DmdType m,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [] 10 110}]
Test.test2 = GHC.Types.I# 42

Test.test1
  :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int
     -> Data.Maybe.Maybe GHC.Types.Int
[GblId,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False,
         ConLike=False, Cheap=False, Expandable=False,
         Guidance=IF_ARGS [] 40 0}]
Test.test1 =
  Data.HashMap.Base.lookup
    @ GHC.Types.Int
    @ GHC.Types.Int
    GHC.Classes.$fEqInt
    Data.Hashable.$fHashableInt
    Test.test2

Test.test
  :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int
     -> GHC.Types.Int
[GblId,
 Arity=1,
 Str=DmdType L,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [0] 40 0}]
Test.test =
  \ (m_aPx
       :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) ->
    case Test.test1 m_aPx of _ {
      Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int;
      Data.Maybe.Just y_atN -> y_atN
    }
}}}
"	tibbe
3	6056	INLINABLE pragma prevents worker-wrapper to happen.	Compiler	7.4.1	normal		7.8.1	simonpj	new	2012-04-28T06:45:35-0700	2012-10-09T07:30:33-0700	"When working on containers I found out that a method returning a pair marked as INLINABLE does not go through a worker/wrapper transformation to get a worker that would return unboxed pair.

For example:

{{{
module Test where

smallerAndRest :: Ord a => a -> [a] -> (Maybe a, [a])
smallerAndRest x [] = (Nothing, [])
smallerAndRest x (y:ys) | y < x = (Just y, ys)
                        | otherwise = smallerAndRest x ys

{-# INLINABLE smallerAndRest #-}
}}}

With the `INLINABLE` pragma, `-ddump-prep` prints
{{{
==================== CorePrep ====================
Result size = 42

lvl_rkg :: forall a_ajz. (Data.Maybe.Maybe a_ajz, [a_ajz])
[GblId, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []]
lvl_rkg =
  \ (@ a_ajz) -> (Data.Maybe.Nothing @ a_ajz, GHC.Types.[] @ a_ajz)

Rec {
Test.smallerAndRest [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker]
  :: forall a_a9I.
     GHC.Classes.Ord a_a9I =>
     a_a9I -> [a_a9I] -> (Data.Maybe.Maybe a_a9I, [a_a9I])
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLSm, Unf=OtherCon []]
Test.smallerAndRest =
  \ (@ a_ajz)
    ($dOrd_sko :: GHC.Classes.Ord a_ajz)
    (x_skq :: a_ajz)
    (ds_skk :: [a_ajz]) ->
    case ds_skk of _ {
      [] -> lvl_rkg @ a_ajz;
      : y_skp ys_sks ->
        case GHC.Classes.< @ a_ajz $dOrd_sko y_skp x_skq of _ {
          GHC.Types.False ->
            Test.smallerAndRest @ a_ajz $dOrd_sko x_skq ys_sks;
          GHC.Types.True ->
            let {
              sat_skw :: Data.Maybe.Maybe a_ajz
              [LclId]
              sat_skw = Data.Maybe.Just @ a_ajz y_skp } in
            (sat_skw, ys_sks)
        }
    }
end Rec }
}}}

but without the `INLINABLE` pragma, we get
{{{
==================== CorePrep ====================
Result size = 57

Rec {
Test.$wsmallerAndRest [Occ=LoopBreaker]
  :: forall a_a9I.
     GHC.Classes.Ord a_a9I =>
     a_a9I -> [a_a9I] -> (# Data.Maybe.Maybe a_a9I, [a_a9I] #)
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLS, Unf=OtherCon []]
Test.$wsmallerAndRest =
  \ (@ a_a9I)
    (w_skC :: GHC.Classes.Ord a_a9I)
    (w1_skE :: a_a9I)
    (w2_sky :: [a_a9I]) ->
    case w2_sky of _ {
      [] -> (# Data.Maybe.Nothing @ a_a9I, GHC.Types.[] @ a_a9I #);
      : y_skD ys_skG ->
        case GHC.Classes.< @ a_a9I w_skC y_skD w1_skE of _ {
          GHC.Types.False ->
            Test.$wsmallerAndRest @ a_a9I w_skC w1_skE ys_skG;
          GHC.Types.True ->
            let {
              sat_skV :: Data.Maybe.Maybe a_a9I
              [LclId]
              sat_skV = Data.Maybe.Just @ a_a9I y_skD } in
            (# sat_skV, ys_skG #)
        }
    }
end Rec }

Test.smallerAndRest [InlPrag=INLINE[0]]
  :: forall a_a9I.
     GHC.Classes.Ord a_a9I =>
     a_a9I -> [a_a9I] -> (Data.Maybe.Maybe a_a9I, [a_a9I])
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLSm, Unf=OtherCon []]
Test.smallerAndRest =
  \ (@ a_a9I)
    (w_skL :: GHC.Classes.Ord a_a9I)
    (w1_skM :: a_a9I)
    (w2_skN :: [a_a9I]) ->
    case Test.$wsmallerAndRest @ a_a9I w_skL w1_skM w2_skN
    of _ { (# ww1_skR, ww2_skS #) ->
    (ww1_skR, ww2_skS)
    }
}}}
Here the worker-wrapper creates a variant, which returns unboxed pair.


I assume that there is no simple solution to this, because the worker/wrapper changes the INLINABLE on `smallerAndRest` to INLINE. The INLINABLE could be added to `$wsmallerAndRest`, but then #5928 causes the specialization to fail.

Maybe at least both `smallerAndRest` and `$wsmallerAndRest` could be marked `INLINABLE`? Then it is not sure that `smallerAndRest` gets INLINED and `$wsmallerAndRest` exposed, but it is not worse than current situation."	milan
4	5298	Inlined functions aren't fully specialised	Compiler	7.0.3	low		7.6.2		new	2011-07-03T20:20:21-0700	2012-09-12T04:13:31-0700	"When a function is inlined, it can expose other functions as candidates for specialisation, but GHC doesn't specialise them.

For instance, given the two modules

{{{
module A where

{-# INLINABLE fac #-}
fac :: Num a => a -> a
fac 0 = 1
fac n = n * fac (n-1)

{-# INLINE f #-}
f :: Num a => a -> a
f a = fac a
}}}


{{{
module B where

import A

g :: Int -> Int
g x = f x
}}}

we see that f is inlined, but fac isn't specialised for Ints:

{{{
B.g :: Int -> Int
[GblId,
 Arity=1,

 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [0] 30 0}]
B.g =
  \ (x_ary :: Int) ->
    A.fac @ Int $fNumInt x_ary
}}}

Removing the INLINE pragma on f doesn't help.

Either of the following changes will cause fac to be specialised:

 * adding {-# SPECIALISE f :: Int -> Int #-} to module B
 * defining ""g x = fac x"" instead

This happens with both GHC 7.0.3 and GHC HEAD"	reinerp
3	7245	INLINEing top-level patterns causes ghc to emit 'arity missing' traces	Compiler	7.6.1	normal		7.8.1		new	2012-09-16T21:02:18-0700	2012-10-20T16:00:20-0700	"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
3	2607	Inlining defeats selector thunk optimisation	Compiler	6.8.3	normal	normal	_|_		new	2008-09-18T02:11:07-0700	2011-04-02T09:06:02-0700	"From a [http://www.haskell.org/pipermail/haskell-cafe/2008-September/047665.html post on haskell-cafe].

Lev Walkin wrote:

> I wondered why would a contemporary GHC 6.8.3 exhibit such a leak?
> After all, the technique was known in 2000 (and afir by Wadler in '87)
> and one would assume Joe English's reference to ""most other Haskell
> systems"" ought to mean GHC.

Thanks for this nice example - Don Stewart pointed me to it, and  Simon PJ and I just spent some time this morning diagnosing it.

Incedentally, with GHC 6.8 you can just run the program with ""+RTS -hT"" to get a basic space profile, there's no need to compile it for profiling - this is tremendously useful for quick profiling jobs.  And in this case we see the the heap is filling up with (:) and Tree constructors, no thunks.

Here's the short story:  GHC does have the space leak optimisation you refer to, and it is working correctly, but it doesn't cover all the cases you might want it to cover.  In particular, optimisations sometimes interact badly with the space leak avoidance, and that's what is happening here.  We've known about the problem for some time, but this is the first time I've seen a nice small example that demonstrates it.

{{{
>     -- Lazily build a tree out of a sequence of tree-building events
>     build :: [TreeEvent] -> ([UnconsumedEvent], [Tree String])
>     build (Start str : es) =
>             let (es', subnodes) = build es
>                 (spill, siblings) = build es'
>             in (spill, (Tree str subnodes : siblings))
>     build (Leaf str : es) =
>             let (spill, siblings) = build es
>             in (spill, Tree str [] : siblings)
>     build (Stop : es) = (es, [])
>     build [] = ([], [])
}}}

So here's the long story.  Look at the first equation for build:
{{{
>     build (Start str : es) =
>             let (es', subnodes) = build es
>                 (spill, siblings) = build es'
>             in (spill, (Tree str subnodes : siblings))
}}}
this turns into
{{{
      x = build es
      es' = fst x
      subnodes = snd x

      y = build es'
      spill = fst y
      siblings = snd y
}}}
now, it's the ""siblings"" binding we're interested in, because this one is never demanded - in this example, ""subnodes"" ends up being an infinite list of trees, and we never get to evaluate ""siblings"".  So anything referred to by siblings will remain in the heap.

The space-leak avoidance optimisation works on all those ""fst"" and ""snd"" bindings: in a binding like ""siblings = snd y"", when y is evaluated to a pair, the GC will automatically reduce ""snd y"", so releasing the first component of the pair.  This all works fine.

But the optimiser sees the above code and spots that es' only occurs once, in the right hand side of the binding for y, and so it inlines it.  Now we have

{{{
      x = build es
      subnodes = snd x

      y = build (fst x)
      spill = fst y
      siblings = snd y
}}}

Now, usually this is a good idea, but in this case we lost the special space-leak avoidance on the ""fst x"" expression, because it is now embedded in an expression.  In fact in this case the thunk goes away entirely, because build is strict.

But now, when the program runs, the thunk for siblings retains y, which retains x, which evaluates to a pair, the second component of which evaluates to an infintely growing list of Trees (the first components is a chain of ""fst y"" expressions that constantly get reduced by the GC and don't take up any space).
"	simonmar
5	2273	inlining defeats seq	Compiler	6.9	lowest	normal	7.6.2		new	2008-05-08T10:05:39-0700	2013-02-01T12:08:29-0800	"Consider this module:
{{{
module Q (tcExtendIdEnv2) where

-- Interesting code:

tcExtendIdEnv2 :: M a
tcExtendIdEnv2 = do env <- getEnv
                    let level :: Int
                        level = thLevel (tcl_th_ctxt env)
                    level `seq` tc_extend_local_id_env level

{-# NOINLINE tc_extend_local_id_env #-}
tc_extend_local_id_env :: Int -> 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 <- m env
                                       unIOEnv (f r) env )
    return a = IOEnv (\ _ -> 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
3	7109	Inlining depends on datatype size, even with INLINE pragmas	Compiler	7.5	normal		7.8.1	simonpj	new	2012-08-01T06:11:45-0700	2012-10-14T11:23:15-0700	"Consider the following code:
{{{
data Logic = T | F
           | Not Logic

instance GEq Logic

testEqLogic = geq (Not T) (Not F)
}}}

With a proper definitions of generic equality `geq` in class `GEq`, and an `instance Generic Logic`, we get the following core code with -O1:
{{{
Rec {
Bug.$fGEqLogic_$cgeq [Occ=LoopBreaker]
  :: Bug.Logic -> Bug.Logic -> GHC.Types.Bool
[GblId, Arity=2, Caf=NoCafRefs, Str=DmdType SS]
Bug.$fGEqLogic_$cgeq =
  \ (x_ap1 :: Bug.Logic) (y_ap2 :: Bug.Logic) ->
    case x_ap1 of _ {
      Bug.T ->
        case y_ap2 of _ {
          Bug.T -> GHC.Types.True;
          Bug.F -> GHC.Types.False;
          Bug.Not g1_aBc_ayJ -> GHC.Types.False
        };
      Bug.F ->
        case y_ap2 of _ {
          Bug.T -> GHC.Types.False;
          Bug.F -> GHC.Types.True;
          Bug.Not g1_aBc_ayJ -> GHC.Types.False
        };
      Bug.Not g1_aBc_ayJ ->
        case y_ap2 of _ {
          __DEFAULT -> GHC.Types.False;
          Bug.Not g1_aBc1_XAu -> Bug.$fGEqLogic_$cgeq g1_aBc_ayJ g1_aBc1_XAu
        }
    }
end Rec }
}}}

Nice and simple, looking just like what we would expect for an equality function for datatype `Logic`.

Now we add one more constructor to datatype `Logic` (and adapt the `Generic` instance accordingly):
{{{
data Logic = T | F
           | Not Logic 
           | And Logic Logic
}}}

GHC (HEAD) now generates 3000 lines of core code for the `Bug.$fGEqLogic_$cgeq` function, instead of something only slightly longer than above.

Why is this? The second version of our `Logic` datatype is as easy to optimise as the first version; only the terms involved will be slightly longer. Attached file `Bug2.hs` is the input which gives the correct behaviour, while `Bug3.hs` is the input with one added constructor. (You might wonder if it has to do with the fact that the added constructor has more than one argument, but this is not the source of the problem.) Both files have `INLINE` pragmas pretty much everywhere (in fact, we're not `deriving Generic` so that we can put `INLINE` pragmas on `to` and `from`)."	dreixel
3	7141	Inlining the single method of a class can shadow rules	Compiler	7.4.2	normal		7.8.1	simonpj	new	2012-08-13T09:16:35-0700	2012-08-13T09:16:35-0700	"This shows up in `template-haskell`, module `Language.Haskell.TH.Syntax`, where the single method of the `Lift` class:

{{{
class Lift t where
  lift :: t -> Q Exp
}}}

has a `RULE`:

{{{
{-# RULES ""TH:liftString"" lift = \s -> return (LitE (StringL s)) #-}
}}}

There is currently no way of preventing `lift` from being inlined."	pcapriotti
2	7833	installed GHC refers to libffi in the build directory	Build System	7.6.2	high		7.8.1	igloo	new	2013-04-13T07:36:43-0700	2013-04-16T18:27:15-0700	"In #7806, Kazu reported that on OS X:

After ""make install"", the installed GHC refers to libffi in the build directory.
{{{
% otool -L ghc | grep libffi

    /Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.0.0)
}}}
So, after I did ""make maintainer-clean"", the installed GHC could not find a libffi.
"	igloo
3	7908	InstanceSigs suggestion not accepted	Compiler	7.7	normal				new	2013-05-14T03:46:00-0700	2013-05-14T14:29:48-0700	"Attached testcase compiles, but when
uncommenting either of the lines 19, 21 or 23,
I get an error:

{{{
pr7908.hs:23:12:
    Method signature does not match class; it should be
      (>>-) :: forall (c :: k -> *) d.
               Hidden k c -> (forall (a :: k). c a -> d) -> d
    In the instance declaration for `Monad' k (Hidden k)'
Failed, modules loaded: none.
}}}

But in fact I basically copied the suggestion into my file! (with slight modification ""Hidden k c"" --> ""Hidden c"")

This may be because of the rank2 type or because of the polykinds appearing."	heisenbug
5	3055	Int / Word / IntN / WordN are unequally optimized	Compiler	6.11	lowest	normal	7.6.2		new	2009-03-01T05:48:00-0800	2012-09-12T04:14:08-0700	"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 '\<Int\|\<Word'
}}}

- some instances have special cases for `Int`, but not for the others (for instance, the `Enum` instance for `Int` uses specialised `enumFromTo` code, the `Word` version uses generic code; `base/GHC/Enum.hs` and `base/GHC/Word.hs`)

- some `RULES` help optimizing the special cases for `Int` further (again, see the `Enum` instance for `Int` for an example)

See this thread [http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016705.html ""Int vs Word performance?""] for more discussion.

related tickets: #2270, #3051"	claus
4	229	Integer overflow in array allocation	libraries/base	6.4.1	low	normal	_|_		new	2004-06-16T01:14:56-0700	2009-11-17T08:15:23-0800	"When asked to create a sufficiently large array ghci 
coredumps.

{{{
\begin{code}
import Data.Array.ST
import Control.Monad.ST
import GHC.Base

example = runST (do arr <- newArray (minInt,maxInt) 
False
		    go arr)
  where go :: STArray s Int Bool -> ST s Bool
	go arr = readArray arr 3
\end{code}
}}}

Load this into ghci and type 'example'."	josefs
3	7811	intermittent 'unexpected' results of test ghcpkg01	ghc-pkg	7.6.2	normal		7.8.1	igloo	new	2013-04-03T10:52:07-0700	2013-04-13T08:18:42-0700	"I get this unexpected error from ghcpkg01

{{{
Actual stderr output differs from expected:
...
+WARNING: cache is out of date: localXXX/package.cache
+  use 'ghc-pkg recache' to fix.
}}}

when running the full suite, but cannot reproduce it when running just that test; it passes when run individually.

(This was also reported in #5503.)"	nfrisby
4	4170	"Invalid ""duplicate instance"" error"	Template Haskell	6.12.3	low		7.6.2		new	2010-07-04T13:09:00-0700	2012-09-12T04:12:26-0700	"Test case:
{{{
{-# LANGUAGE TemplateHaskell #-}

import Language.Haskell.TH

class LOL a

lol :: Q [Dec]
lol = [d|
    instance LOL Int
    |]

instance LOL Int
}}}
Error:

{{{
duplicateinstance.hs:9:13:
    Duplicate instance declarations:
      instance LOL Int -- Defined at duplicateinstance.hs:9:13-19
      instance LOL Int -- Defined at duplicateinstance.hs:12:9-15
    In the Template Haskell quotation
      [d| 
          instance LOL Int where |]
    In the expression:
        [d| 
            instance LOL Int where |]
    In the definition of `lol':
        lol = [d| 
                  instance LOL Int where |]
}}}
"	verdelyi
3	2496	Invalid Eq/Ord instances in Data.Version	libraries/base	6.8.3	normal	normal	_|_	duncan	new	2008-08-07T02:37:21-0700	2013-02-02T11:36:31-0800	"(From Adrian Hey)

In Data.Version we have:

{{{
data Version = 
  Version {versionBranch :: [Int]
          ,versionTags :: [String]
          }

instance Eq Version where
  v1 == v2  =  versionBranch v1 == versionBranch v2 
                && sort (versionTags v1) == sort (versionTags v2)
                -- tags may be in any order

instance Ord Version where
  v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2
}}}

The ""laws"" for valid Eq/Ord instances were argued about recently but the H98 report seems reasonably clear that (==) is supposed to test for equality and the compare method is supposed to define a total ordering. There is also an implied but not explicitly stated law that:

{{{
 (x == y = True)  <-> (x `compare` y = EQ)
}}}
and also this I guess..
{{{
 (x == y = False)  <-> ~(x `compare` y = EQ)
}}}

This law is implied by the Eq constraint on the Ord class (which seems to serve no purpose otherwise).

See also:
[http://www.haskell.org/pipermail/haskell-prime/2008-March/002330.html]



 
"	guest
2	7567	invalidateModSummaryCache throws exception if ms_hs_date is 0	Compiler	7.6.1	high		7.8.1		new	2013-01-10T08:37:42-0800	2013-01-10T09:24:03-0800	It will try to subtract one, and the negative value will cause `Time.toClockTime: invalid` input to be thrown.	edsko
3	7723	iOS patch no 12: Itimer.c doesn't work on iOS	Runtime System	7.7	normal		7.8.1		new	2013-02-26T03:24:38-0800	2013-04-26T19:15:43-0700	"As it stands, rts/posix/Itimer.c dies at runtime on iOS.

I am in the process of tidying up a solution for this."	StephenBlackheath
3	7066	isInstance does not work for compound types	Template Haskell	7.4.2	normal		7.8.1	simonpj	new	2012-07-11T05:05:34-0700	2012-10-14T09:36:37-0700	"Consider

{{{
import Language.Haskell.TH.Syntax                                                
                                                                                 
data A = A                                                                       
                                                                                 
test :: Q [Dec]                                                                  
test = do                                                                        
  tp <- [t| (Int, A) |]                                                          
  inst1 <- isInstance ''Show [ tp ]                                              
  runIO $ print inst1                                                            
  return []  
}}}
                                                                    
This prints True even though there is no Show instance for A (the Show instance it finds is for pairs, but it does not verify that there are Show instances for the pair components)."	edsko
3	1473	isSpace is too slow	libraries/base	6.6.1	normal	normal	_|_		new	2007-07-01T04:11:07-0700	2013-01-22T08:16:47-0800	"In the thread starting http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012608.html
Neil Mitchell compares the speed is isSpace to C's functions:
{{{
C's isspace: 0.375
C's iswspace: 0.400
Char.isSpace: 0.672
}}}
The thread contains some discussions of possible solutions."	igloo
3	6087	Join points need strictness analysis	Compiler	7.4.1	normal		7.6.2		new	2012-05-10T05:05:36-0700	2013-03-20T11:31:06-0700	"I came across this code in the `nofib/spectral` progam `knights`, in the code for `KnightHeuristic.possibleMoves`:
{{{
let {
  $j_sU3
    :: GHC.Types.Int -> GHC.Types.Int -> [KnightHeuristic.Direction]
  [LclId, Arity=2]
  $j_sU3 =
    \ (ww2_sRl :: GHC.Types.Int) (ww3_sRm :: GHC.Types.Int) ->
      case ww2_sRl of ww4_XQY { GHC.Types.I# ww5_sQU ->
      case GHC.Prim.>=# ww5_sQU 1 of _ {
        GHC.Types.False -> go1_azF ys_azM;
        GHC.Types.True ->
          case ds1_azR of _ { GHC.Types.I# y1_azp ->
          case GHC.Prim.<=# ww5_sQU y1_azp of _ {
            GHC.Types.False -> go1_azF ys_azM;
            GHC.Types.True ->
              case ww3_sRm of wild6_XAB { GHC.Types.I# x_XAE ->
              case GHC.Prim.>=# x_XAE 1 of _ {
                GHC.Types.False -> go1_azF ys_azM;
                GHC.Types.True ->
                  case GHC.Prim.<=# x_XAE y1_azp of _ {
                    GHC.Types.False -> go1_azF ys_azM;
                    GHC.Types.True ->
                      case GHC.List.notElem
                             @ ChessSetList.Tile
                             ChessSetList.isSquareFree_$dEq
                             (ww4_XQY, wild6_XAB)
                             wild2_azW
                      of _ {
                        GHC.Types.False -> go1_azF ys_azM;
                        GHC.Types.True ->
                          GHC.Types.:
                            @ KnightHeuristic.Direction y_azL (go1_azF ys_azM)
                      }
                  }
              }
              }
          }
          }
      }
      } } in
case y_azL of _ {
  KnightHeuristic.UL ->
    $j_sU3
      (case ww_sQJ of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 1)
       })
      (case ww1_sQK of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 2)
       });
  KnightHeuristic.UR ->
    $j_sU3
      (case ww_sQJ of _ { GHC.Types.I# x_ayl ->
       GHC.Types.I# (GHC.Prim.+# x_ayl 1)
       })
      (case ww1_sQK of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 2)
       });

...lots more similar case alternatives follow...
}}}
Just look at all those `Int`s getting boxed, and the immediately unboxed by the join point!  The strictness analyser would spot this easily, but presumably the join point is constructed after strictness analysis.

There must be an opportunity here to run a later strictness analysis pass."	simonpj
3	7643	Kind application error	Compiler (Type checker)	7.6.1	normal		7.8.1	simonpj	new	2013-01-31T05:55:01-0800	2013-04-12T16:48:50-0700	"Compiling the attached program with -dcore-lint fails. This failure is a reduced version of code taken from the primitive package, version 0.5.0.1.

To see the failure:

{{{
ghc -dcore-lint --make Main.hs
}}}

The failure does not occur with GHC 7.4."	gmainland
3	5945	Lambda lifting	Compiler	7.4.1	normal		7.8.1	simonpj	new	2012-03-16T10:40:26-0700	2012-09-27T04:53:40-0700	"Dan Rosen asks whether GHC has a lambda lifter.  Yes, it does: GHC's full-laziness pass also doubles as a lambda lifter

 * It's controlled by the `floatOutLambdas` field of `CoreMonad.FloatOutSwitches`
 * This in turn is set from the `floatLamArgs` field of `DynFlags` in `SimplCore`
 * The `DynFlags` are set in module `DynFlags` (see `-ffloat-all-lams`, `-ffloat-lam-args`)

However on trying a small experiment on 
{{{
	f x = map (\y -> (x,y))
}}}

I see a bug and an infelicity.

 * Bug: the comment with the `floatOutLambdas` field definition claims that `Nothing` means float all lambdas to the top.  But the code in `SetLevels.destLevel` treats `(Just 0)` and `Nothing` identically, which contradicts the comment. Workaround: use `(Just 100)`

 * Infelicity: with `-ffloat-lam-args=100` we get
{{{
lvl_sdQ =
  \ (@ t_acm) (@ t_acn) (x_a9H :: t_acm) (y_a9I :: t_acn) ->
    (x_a9H, y_a9I)

Foo.f =
  \ (@ t_acm)
    (@ t_acn)
    (x_a9H [Dmd=Just L] :: t_acm)
    (eta_B1 :: [t_acn]) ->
    GHC.Base.map
      @ t_acn @ (t_acm, t_acn) (lvl_sdQ @ t_acm @ t_acn x_a9H) eta_B1
}}}
 which is good, but then the next simplifier run inlines it straight back in again, via `SimplUtils.preInlineUnconditionally`.

 I think `preInlineUnconditionally` should be a bit less gung-ho, perhaps, but I don't want to change it until I've see if there are any performance regressions.
"	simonpj
3	5401	LANGUAGE pragma parser nit	Compiler (Parser)	7.0.3	normal		7.6.2	igloo	new	2011-08-09T23:03:33-0700	2012-10-25T09:29:19-0700	"A language pragma like
{{{
{-# LANGUAGE 
    TypeOperators,
    FlexibleContexts #-}
}}}
parses just fine but
{{{
{-# LANGUAGE 
    TypeOperators,
    FlexibleContexts
#-}
}}}
doesn't, saying:
{{{
    Cannot parse LANGUAGE pragma
    Expecting comma-separated list of language options,
    each starting with a capital letter
}}}
An OPTIONS pragma, on the other hand, accepts either format without complaint."	nwf
5	2933	LDFLAGS ignored by build system	Build System	6.10.1	lowest	normal	7.6.2		new	2009-01-09T11:43:01-0800	2012-09-12T04:14:05-0700	"I have required libs installed in `/opt/csw/lib` which is not on the ordinary system linker path. This includes things like `libgmp` etc. That means that to link ghc I want to pass `-R/opt/csw/lib` so that at runtime I do not need to set `LD_LIBRARY_PATH`.

The `./configure --help` mentions `LDFLAGS` however this is ignored. When building gcc the equivalent makes everything work out fine. It would be nice if this were supported.

Note also that `--with-gmp-includes` and `--with-gmp-libraries` are only half helpful. They add -L and -I options during the build only. That lets ghc link stuff using gmp. There are still two problems however:

 * Running such programs does not work if the gmp lib dir is not on the standard runtime linker path (which is quite likely given that it was not on the standard compile-time linker path).
 * It does not cause the final built ghc to automatically use -L/path/to/gmp/lib. Again I think if it's using `-L/path/to/gmp/lib` it should also use `-R/path/to/gmp/lib` or it'll link but not run.

Some people claim that -R is evil. If we think it is evil and we choose not to use it for `--with-gmp-includes` and `--with-gmp-libraries` then those two become less than useful and it becomes more important to support `LD_OPTIONS`/`LDFLAGS` properly so that distros like the Solaris CSW can use it. For example, see http://www.opencsw.org/standards/pkg-walkthrough which recommends:
{{{
export LD_OPTIONS='-R/opt/csw/lib/$ISALIST -R/opt/csw/lib -L/opt/csw/lib'
}}}

Note: the workaround is to modify the driver script of the bootstrapping ghc and add `-optl-R/the/extra/lib` and then do the same for the script template that will get used by the stage1/2 inplace and final ghc, or to temporarily use LD_LIBRARY_PATH and modify the final ghc driver script during/after install."	duncan
3	6092	Liberate case not happening	Compiler	7.4.1	normal		7.8.1	simonpj	new	2012-05-11T14:55:53-0700	2012-10-09T10:29:44-0700	"Simon M writes: Johan Tibell and I were looking at the code GHC produces for `isPrefixOf`:
{{{
isPrefixOf :: (Eq a) => [a] -> [a] -> Bool
isPrefixOf [] _  =  True
isPrefixOf _  [] =  False
isPrefixOf (x:xs) (y:ys)= x == y && isPrefixOf xs ys
}}}
and noticed that it differs between 6.12 and 6.14 onwards incl 7.5, with the 6.12 code more heavily optimised.  In particular, 6.12 applies liberate case so the unboxing of the Eq dictionary is pulled out of the loop, but 6.14 isn't doing this.

Here's the 6.12 core:
{{{
$ ghc -ddump-simpl -O2 isprefixof.hs -c -fliberate-case   

==================== Tidy Core ====================
Test.isPrefixOf :: forall a_ade.
                   (GHC.Classes.Eq a_ade) =>
                   [a_ade] -> [a_ade] -> GHC.Bool.Bool
GblId
[Arity 3
 NoCafRefs
 Str: DmdType LSL]
Test.isPrefixOf =
  \ (@ a_adE)
    ($dEq_adK :: GHC.Classes.Eq a_adE)
    (eta_B2 :: [a_adE])
    (eta1_B1 :: [a_adE]) ->
    case eta_B2 of _ {
      [] -> GHC.Bool.True;
      : ipv_se3 ipv1_se4 ->
        case eta1_B1 of _ {
          [] -> GHC.Bool.False;
          : ipv2_se7 ipv3_se8 ->
            case $dEq_adK of _ { GHC.Classes.D:Eq tpl1_Xk _ ->
            case tpl1_Xk ipv_se3 ipv2_se7 of _ {
              GHC.Bool.False -> GHC.Bool.False;
              GHC.Bool.True ->
                letrec {
                  isPrefixOf1_seA :: [a_adE] -> [a_adE] -> GHC.Bool.Bool
                  LclId
                  [Arity 2
                   Str: DmdType SL]
                  isPrefixOf1_seA =
                    \ (ds_ddM :: [a_adE]) (ds1_ddN :: [a_adE]) ->
                      case ds_ddM of _ {
                        [] -> GHC.Bool.True;
                        : ipv4_Xes ipv5_Xeu ->
                          case ds1_ddN of _ {
                            [] -> GHC.Bool.False;
                            : ipv6_XeA ipv7_XeC ->
                              case tpl1_Xk ipv4_Xes ipv6_XeA of _ {
                                GHC.Bool.False -> GHC.Bool.False;
                                GHC.Bool.True -> isPrefixOf1_seA ipv5_Xeu ipv7_XeC
                              }
                          }
                      }; } in
                isPrefixOf1_seA ipv1_se4 ipv3_se8
            }
            }
        }
    }
}}}
and the 6.14 code (also 7.5):
{{{
$ ghc-stage2 -ddump-simpl -O2 isprefixof.hs -c -fspec-constr

==================== Tidy Core ====================
Test.isPrefixOf
  :: forall a_aav.
     GHC.Classes.Eq a_aav =>
     [a_aav] -> [a_aav] -> GHC.Bool.Bool
[GblId,
 Arity=3,
 Caf=NoCafRefs,
 Str=DmdType LSL,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=3, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [1 0 0] 19 0}]
Test.isPrefixOf =
  \ (@ a_age)
    ($dEq_agk :: GHC.Classes.Eq a_age)
    (eta_B2 :: [a_age])
    (eta1_B1 :: [a_age]) ->
    letrec {
      isPrefixOf1_sha [Occ=LoopBreaker]
        :: [a_age] -> [a_age] -> GHC.Bool.Bool
      [LclId, Arity=2, Str=DmdType SL]
      isPrefixOf1_sha =
        \ (ds_dgm :: [a_age]) (ds1_dgn :: [a_age]) ->
          case ds_dgm of _ {
            [] -> GHC.Bool.True;
            : ipv_sgD ipv1_sgE ->
              case ds1_dgn of _ {
                [] -> GHC.Bool.False;
                : ipv2_sgH ipv3_sgI ->
                  case GHC.Classes.== @ a_age $dEq_agk ipv_sgD ipv2_sgH of _ {
                    GHC.Bool.False -> GHC.Bool.False;
                    GHC.Bool.True -> isPrefixOf1_sha ipv1_sgE ipv3_sgI
                  }
              }
          }; } in
    isPrefixOf1_sha eta_B2 eta1_B1
}}}"	simonpj
5	3509	libffi.so not found on Mac OS X (10.5.8)	Build System	6.11	lowest	normal	7.6.2		new	2009-09-13T16:00:53-0700	2012-09-12T04:14:11-0700	"building with dynamic libraries on Mac OS X dies with an error about libffi.so

To reproduce:
{{{
add a build.mk with ""GhcLibWays = v  dyn""
sh boot && ./configure --enable-shared && make
}}}

If I copy one of the libffi*dylib files that does appear to have been built correctly to libffi.so, the build proceeds but then loops in the build process.

partial trace:
{{{
(cd .libs && rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib libffi.5.dylib)
(cd .libs && rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib)
ar cru .libs/libffi.a  src/debug.o src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi.o src/x86/darwin.o src/x86/ffi64.o src/x86/darwin64.o
""inplace/bin/mkdirhier"" inplace/lib/
""cp"" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/hsc2hs
ranlib: file: .libs/libffi.a(ffi64.o) has no symbols
ranlib: file: .libs/libffi.a(darwin64.o) has no symbolstouch inplace/lib/hsc2hs

ranlib .libs/libffi.a
ranlib: file: .libs/libffi.a(ffi64.o) has no symbols
ranlib: file: .libs/libffi.a(darwin64.o) has no symbols
creating libffi.la
(cd .libs && rm -f libffi.la && cp -p ../libffi.la libffi.la)
/bin/sh ./libtool --tag=CC   --mode=link gcc -Wall -g -fexceptions -w  -w -o libffi_convenience.la  src/debug.lo src/prep_cif.lo src/types.lo src/raw_api.lo src/java_raw_api.lo src/closures.lo     src/x86/ffi.lo src/x86/darwin.lo src/x86/ffi64.lo src/x86/darwin64.lo                    
ar cru .libs/libffi_convenience.a src/.libs/debug.o src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/darwin.o src/x86/.libs/ffi64.o src/x86/.libs/darwin64.o
ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols
ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols
ranlib .libs/libffi_convenience.a
ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols
ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols
creating libffi_convenience.la
(cd .libs && rm -f libffi_convenience.la && cp -p ../libffi_convenience.la libffi_convenience.la)
make[4]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build'
make[3]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build'
cp .libs/libffi.5.0.9.dylib /Users/mwotton/projects/ghc/libffi/libffi.5.0.9.dylib
(cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib libffi.5.dylib || { rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib libffi.5.dylib; }; })
(cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib libffi.dylib || { rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib; }; })
cp .libs/libffi.lai /Users/mwotton/projects/ghc/libffi/libffi.la
cp .libs/libffi.a /Users/mwotton/projects/ghc/libffi/libffi.a
chmod 644 /Users/mwotton/projects/ghc/libffi/libffi.a
ranlib /Users/mwotton/projects/ghc/libffi/libffi.a
ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(ffi64.o) has no symbols
ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(darwin64.o) has no symbols
libtool: install: warning: remember to run `libtool --finish /usr/local/lib'
touch libffi/stamp.ffi.build-shared
""cp"" libffi/libffi.a libffi/libHSffi.a
""cp"" libffi/libffi.so libffi/libHSffi-ghc6.11.20090913.dylib
""cp"" libffi/libffi.a libffi/libHSffi_p.a
cp: libffi/libffi.so: No such file or directory
make[1]: *** [libffi/libHSffi-ghc6.11.20090913.dylib] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
nice make -j 2  145.90s user 70.38s system 78% cpu 4:37.08 total
}}}
"	mwotton
4	5292	libHSghc exports more symbols than Windows can handle	Compiler	7.0.3	low		7.6.2		new	2011-07-02T16:58:26-0700	2012-09-12T04:13:31-0700	"If you build GHC with shared libraries enables, the generated libHSghc.dll will export 65536 symbols. This is the limit that Windows DLLs can handle (the source of the limitation is that they use 16-bit integers to represent ""ordinals"").

Unfortunately, this means that the generated DLL is actually missing a ton of exports! Bad things happen at this point, including runtime crashes in GHCs linker. One interesting feature is that there seems to be a bug with GetProcAddress for modules that have filled up their export lists like this, so if hmod is a handle to the loaded DLL, GetProcAddress(hmod, ""LocalAlloc"") will succeed even though LocalAlloc is not exported by the DLL.

The number of symbols exported varies wildly depending on how you build the compiler. A ""quick"" build (from build.mk.sample) only exports 39k symbols, which is under the limit, but the kind of build that validate does ends up hitting the limits. (This difference was the source of some fun debugging confusion for me...)

Because of this bug, we won't be able to distribute a dynamically linked GHC on Windows. It is also preventing me from getting plugins06 to pass on Windows.

One workaround would be to build GHC with settings that result in less exported symbols until we get below the limit again -- i.e. export less unfoldings. This might adversely impact compiler performance, however."	batterseapower
3	5983	Libraries installed in wrong place	libraries/base	7.4.1	normal		7.6.2		new	2012-04-01T22:09:31-0700	2012-09-12T04:12:13-0700	"All of the installed libraries are placed in  /Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/lib/ghc-7.4.1  by the installation package.

However, all of the dylib files report an otool -D of the form  /usr/local/lib/ghc-7.4.1/...

The workaround is to create a link from /usr/local/lib/ghc-7.4.1 to /Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/lib/ghc-7.4.1

However, the installer should either create this link, or (better) invoke   otool -id as part of the installation process and set the correct dylib path for all the dylibs.
"	r0ml
3	5355	Link plugins against existing libHSghc	Compiler	7.0.3	normal		7.6.2		new	2011-07-29T05:16:14-0700	2012-09-12T04:12:02-0700	"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
2	7097	linker fails to load package with binding to foreign library	Runtime System	7.4.2	high		7.8.1		new	2012-07-25T09:54:04-0700	2013-05-01T12:40:48-0700	"GHCI is unable to load 'network' package on Windows. The versions:
{{{
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 7.4.2
}}}
{{{
$ ghc-pkg list network
c:/mnt/data1/ghc32b\lib\package.conf.d:
    network-2.3.0.14
}}}

The test code:
{{{
import Network

main = withSocketsDo $ do listenOn (PortNumber 3333) -- >>= accept
}}}

The failure:
{{{
> ghci winsock-load-failure.hs
GHCi, version 7.4.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main             ( winsock-crash.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package text-0.11.2.2 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package network-2.3.0.14 ... linking ... <interactive>: C:\mnt\data1\ghc32b\network-2.3.0.14\ghc-7.4.2\HSnetwork-2.3.0.14.o: unknown symbol `__imp__WSACleanup'
ghc.exe: unable to load package `network-2.3.0.14'
}}}

The load trace log ('+RTS -Dl'):
{{{
[...snip...]
lookupSymbol: looking up __imp__WSACleanup@0
initLinker: start
initLinker: idempotent return
lookupSymbol: symbol not found
<interactive>: C:\mnt\data1\ghc32b\network-2.3.0.14\ghc-7.4.2\HSnetwork-2.3.0.14.o: unknown symbol `__imp__WSACleanup'
[...snip...]
}}}

The symbol to be resolved:
{{{
$ nm network-2.3.0.14/ghc-7.4.2/HSnetwork-2.3.0.14.o |grep WSACleanup
         U __imp__WSACleanup@0
}}}

The actual symbol in the foreign library:
{{{
$ objdump -p  /c/Windows/System32/ws2_32.dll
c:/Windows/System32/ws2_32.dll:     file format pei-i386
[...snip...]
[Ordinal/Name Pointer] Table
[...snip...]
        [ 115] WSACleanup
[...snip...]
}}}

The test snippet only works when compiled by ghc (so the resulting binary is produced by ld.bfd)."	nus
4	4836	literate markdown not handled correctly by unlit	Compiler	7.0.1	low		7.6.2		new	2010-12-12T11:22:52-0800	2012-09-12T04:13:23-0700	"This simple program in literate haskell, using markdown in the comments gives unlit problems:
{{{
### Ok so lets try this again.

### A page that loads and compiles:

> myfact 0 = 1  
> myfact n = n * n-1

Lets see if it works!
}}}

If I run unlit and collect the output I can see where it went wrong:
{{{
$ ~/lib/ghc-7.0.1/unlit Main.lhs Main.lpp
$ cat Main.lpp
### Ok so lets try this again.

### A page that loads and compiles:

  myfact 0 = 1  
  myfact n = n * n-1


}}}

When I look through the source code of unlit.c I think the place to check for this would be here:
{{{
    if ( c == '#' ) {
      if ( ignore_shebang ) {
         c1 = egetc(istream);
         if ( c1 == '!' ) {
           while (c=egetc(istream), !isLineTerm(c)) ;
           return SHEBANG;
         }
         myputc(c, ostream);
         c=c1;
      }
      if ( leavecpp ) {
        myputc(c, ostream);
        while (c=egetc(istream), !isLineTerm(c))
            myputc(c,ostream);
        myputc('\n',ostream);
        return HASH;
      }
    }
}}}

It seems that cabal has a similar unlit function:
http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.10.0.0/src/Distribution-Simple-PreProcess-Unlit.html#unlit

I haven't tested it but, I think the cabal version would handle this case correctly (or be easier to fix than a C program from 1990).  Would it be possible/wise/feasible to extract the cabal version and make it a permanent replacement for the current unlit.c code?"	guest
3	7885	LLVM build broken	Compiler (LLVM)	7.7	normal				new	2013-05-03T09:25:41-0700	2013-05-06T09:22:35-0700	"The LLVM build has been broken for a number of weeks. Unfortunately this happened before I started running nightly LLVM builds. Here is the error I see (taken from the nightly build log):

{{{
inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn-p-dyn.haskell ""DynFlags"" ""Annotations Avail Bag BasicTypes Binary Bitmap BlockId BreakArray BufWrite ByteCodeAsm ByteCodeInstr ByteCodeItbls ByteCodeLink CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Fingerprint FiniteMap ForeignCall Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes Id IdInfo IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal Maybes MkCore MkGraph MkId Module MonadUtils 
 Name NameEnv NameSet ObjLink OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcType TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet""
dll-split: internal error: scavenge_one: strange object -385875968
    (GHC version 7.7.20130502 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
make[1]: *** [compiler/stage2/dll-split.stamp] Error 134
make: *** [all] Error 2
Command exited with non-zero status 2
4506.92user 192.03system 1:19:51elapsed 98%CPU (0avgtext+0avgdata 4147968maxresident)k
1400inputs+13715568outputs (3major+33440223minor)pagefaults 0swaps
}}}"	gmainland
4	4308	LLVM compiles Updates.cmm badly	Compiler (LLVM)	6.13	low		7.6.2		new	2010-09-13T18:43:50-0700	2012-09-12T04:12:30-0700	"Simon M. reported that compiled rts/Updates.cmm on x86-64 with the LLVM backend produced some pretty bad code. The ncg produces this:

{{{
stg_upd_frame_info:
.Lco:
       movq 8(%rbp),%rax
       addq $16,%rbp
       movq %rbx,8(%rax)
       movq $stg_BLACKHOLE_info,0(%rax)
       movq %rax,%rcx
       andq $-1048576,%rcx
       movq %rax,%rdx
       andq $1044480,%rdx
       shrq $6,%rdx
       orq %rcx,%rdx
       cmpw $0,52(%rdx)
       jne .Lcf
       jmp *0(%rbp)
.Lcf:
       [...]
}}}

The LLVM backend produces this though:

{{{
stg_upd_frame_info:                     # @stg_upd_frame_info
# BB#0:                                 # %co
       subq    $104, %rsp
       movq    8(%rbp), %rax
       movq    %rax, 24(%rsp)          # 8-byte Spill
       movq    %rbx, 8(%rax)
       mfence
       movq    $stg_BLACKHOLE_info, (%rax)
       movq    %rax, %rcx
       andq    $-1048576, %rcx         # imm = 0xFFFFFFFFFFF00000
       andq    $1044480, %rax          # imm = 0xFF000
       shrq    $6, %rax
       addq    %rcx, %rax
       addq    $16, %rbp
       cmpw    $0, 52(%rax)
       movsd   %xmm6, 88(%rsp)         # 8-byte Spill
       movsd   %xmm5, 80(%rsp)         # 8-byte Spill
       movss   %xmm4, 76(%rsp)         # 4-byte Spill
       movss   %xmm3, 72(%rsp)         # 4-byte Spill
       movss   %xmm2, 68(%rsp)         # 4-byte Spill
       movss   %xmm1, 64(%rsp)         # 4-byte Spill
       movq    %r9, 56(%rsp)           # 8-byte Spill
       movq    %r8, 48(%rsp)           # 8-byte Spill
       movq    %rdi, 40(%rsp)          # 8-byte Spill
       movq    %rsi, 32(%rsp)          # 8-byte Spill
       je      .LBB1_4
}}}

This has two main problems:

  1. mfence instruction (write barrier) isn't required. (write-write barriers aren't required on x86)
  2. LLVM backend is spilling a lot of stuff unnecessarily.

Both these I think are fairly easy fixes. LLVM is handling write barriers quite naively at the moment so 1. is easy. The spilling problem I think is related to a previous fix I made where I need to explicitly kill some of the stg registers if they aren't live across the call, otherwise LLVM rightly thinks they are live since I always pass the stg registers around (so live on entry and exit of every function unless I kill them)."	dterei
3	7297	LLVM incorrectly hoisting loads	Compiler (LLVM)	7.7	normal		7.8.1	dterei	new	2012-10-04T11:29:14-0700	2013-01-31T01:12:53-0800	"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
3	7694	LLVM: bootstrapping with LLVM 3.2 does not work	Compiler (LLVM)	7.7	normal		7.8.1	dterei	new	2013-02-15T05:19:26-0800	2013-05-03T11:56:21-0700	Building GHC itself using the LLVM back end no longer works with LLVM 3.2 (3.1 is fine). On Linux x86_64, the stage2 compiler fails for me. Unfortunately running the test suite with stage=1 did not produce any quality failures that would help us track down the problem. This does not appear to be related to the new codegen since using LLVM 3.1 does not cause a failure.	gmainland
4	4428	Local functions lose their unfoldings	Compiler	7.1	low		7.6.2		new	2010-10-22T17:12:56-0700	2012-09-12T04:12:31-0700	"I'm attaching 2 modules, both should be compiled with -O2. Let's look at the inteface of `Foo`:

{{{
  foo :: (GHC.Types.Int, GHC.Types.Int)
         -> [GHC.Types.Int]
         -> [GHC.Types.Int]
    {- Arity: 2, Strictness: U(U(L)U(L))L, Inline: INLINE (sat-args=2),
       Unfolding: InlineRule (2, False, False)
                  (\ ds :: (GHC.Types.Int, GHC.Types.Int) xs :: [GHC.Types.Int] ->
                   case @ [GHC.Types.Int] ds of wild { (i, n) ->
                   let {
                     step :: forall t.
                             ([t], GHC.Types.Int, GHC.Types.Int)
                             -> Data.Maybe.Maybe (([t], GHC.Types.Int, GHC.Types.Int), t)
                       {- Inline: INLINE[0] (sat-args=1) -}
                     = ...

}}}

Note how `step`, which is local to `foo`, has an `INLINE` pragma but no unfolding. Now, let's look at `Bar`. For some reason, GHC only inlines `foo` into `bar` in phase 1. This is probably unrelated but still surprising. The main problem, though, is that `step`, not having an unfolding, doesn't get inlined at all despite the `INLINE` pragma. "	rl
3	7668	Location in -fdefer-type-errors	Compiler (Type checker)	7.6.2	normal		7.8.1		new	2013-02-06T10:28:49-0800	2013-04-13T04:18:17-0700	"Consider

{{{
x :: Char
x = 'x' + 1

y :: Char
y = 'y' + 1
}}}

Run `ghci -fdefer-type-errors`:

{{{
*Main> x
*** Exception: G.hs:5:9:
    No instance for (Num Char) arising from a use of `+'
    In the expression: 'y' + 1
    In an equation for `y': y = 'y' + 1
(deferred type error)
*Main> y
*** Exception: G.hs:5:9:
    No instance for (Num Char) arising from a use of `+'
    In the expression: 'y' + 1
    In an equation for `y': y = 'y' + 1
(deferred type error)
}}}

The first exception is wrong. It seems that the missing `Num Char` instance is filled with the same error message in all places where the constraint should be supplied."	monoidal
5	3533	mac installer package deletes old version of ghc	Compiler	6.10.4	lowest	normal	7.6.2		new	2009-09-22T09:29:46-0700	2012-09-12T04:14:12-0700	"The Mac installer package on the ghc downloads page (the .pkg, not the .tar.bz2), deletes an existing installation of ghc if it already exists.  There is no warning of this behaviour on the download page, or in the installer itself.

At least a warning should be given.  Even better, would be to leave the existing installation of ghc intact.  Best of all would be for the installer to prompt whether you want to keep the old version or delete it."	malcolm.wallace@…
3	3654	Mach-O GHCi linker lacks support for a range of relocation entries	Runtime System	6.13	normal	normal	7.6.2		new	2009-11-10T21:50:25-0800	2012-09-12T04:11:58-0700	"The Mach-O code of the GHCi linker `rts/Linker.c` lacks support for a range of relocation entries.  It used to silently ignore many of them.  The following patch makes it barf() when it encounters an unsupported entry:
{{{
Wed Nov 11 13:07:12 EST 2009  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Barf on unhandled Mach-O relocations in the ghci linker
  
  - It might be worthwhile to MERGE this to 6.12, BUT somebody should validate
    it on PPC/Mac OS X first.
}}}
Moreover, at least one entry type —i.e., `GENERIC_RELOC_LOCAL_SECTDIFF`— is not correctly implemented.

This is an unsatisfactory situation as the transition from Mac OS X 10.5 (Leopard) to 10.6 (Snow Leopard) showed.  In that case, changes in `ld` suddenly created a so far unsupported entry type.  This was before the above patch; so, the ignored entry led to an incorrectly relocated image, which crashed GHCi with a SIGBUS.

Instead of trying to improve the dynamic linker, IMHO, GHC should use dynamic libraries with `dlopen()` and leave the implementation of dynamic linking to the OS vendor.  This has a number of advantages:
 * The RTS gets smaller & simpler, and we eliminate a whole category of potentially tricky bugs.
 * Dynamically loaded code can use dtrace probes (and other features requiring linker trickery).
 * Packages that GHC links to, don't need to be in memory twice (once statically and once dynamically linked).
 * Potential performance advantage due to optimisations in the OS' dynamic linker.

The main obstacle with using dynamic libraries and `dlopen()` appears to be the required on-the-fly conversion of GHC-generated object files into dynamic libraries.  Otherwise, SimonM says that it is already possible to compile GHC itself dynamically-linked at the moment that the linker will then use `dlopen()` for loading packages.

More details are in the following thread on `cvs-ghc@haskell.org`:
  [http://www.haskell.org/pipermail/cvs-ghc/2009-November/050941.html]
  [http://www.haskell.org/pipermail/cvs-ghc/2009-October/050893.html]

"	chak
5	2867	"Make a way to tell GHC that a pragma name should be ""recognised"""	Compiler	6.10.1	lowest	normal	7.6.2		new	2008-12-09T13:34:58-0800	2012-09-12T04:14:05-0700	"GHC warns about unrecognised pragmas, but other impls can add pragmas inbetween GHC releases. If you want to use those pragmas then you can't just use `-Wall -Werror` when compiling. We could make a pragma to tell GHC to not warn about other pragmas, e.g.
{{{
{-# KNOWN_PRAGMA FOO #-}
}}}
would make GHC not warn about `FOO` pragmas.

Suggested in #2847.
"	igloo
5	1693	Make distclean (still) doesn't	Build System	6.6.1	lowest	normal	7.6.2	igloo	new	2007-09-14T02:21:05-0700	2013-01-28T02:15:27-0800	"There are various ways in which `make distclean` does not remove all the files it should.  Please keep adding to this bug description as you find more.

The following things are not currently distcleaned and should be, and hence are ending up in the source distribution:

{{{
libraries/haddock.css
libraries/haddock-util.js
}}}"	simonpj
3	7080	Make RULES and SPECIALISE more consistent	Compiler	7.4.2	normal		_|_		new	2012-07-16T04:05:24-0700	2013-04-23T21:23:53-0700	"This [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-July/022580.html glasgow-haskell-users email thread] describes the inconsistency between RULES and SPECIALISE pragmas. Consider
{{{
module Test where

import Data.Monoid
import Control.Monad.Writer.Strict

f :: Monad m => 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
3	7353	Make system IO interruptible on Windows	libraries/base	7.6.1	normal		7.8.1		new	2012-10-20T09:50:22-0700	2013-03-02T21:21:32-0800	"Currently, IO operations (connect, read, etc.) cannot be interrupted on Windows.  Additionally, threadWaitRead and threadWaitWrite do not work on Windows (IIRC, they can't tell if the given file descriptor is a socket or not, so they assume it's not).

The reason is that GHC does not have an IO manager for Windows like it does for *nix.  For Windows with -threaded, the network package uses blocking FFI calls, which cannot be interrupted by asynchronous exceptions.  Thus, System.Timeout and killThread can't be used to time out and interrupt network IO.

I'm working on a program that needs to run on a Windows XP machine for long periods of time, interacting with a couple intermittent network services.  This issue is making things very difficult for me, so I want to get it fixed.  I do not need to support thousands of concurrent connections efficiently; I just need my program to run reliably.

What needs to happen for IO to be interruptible on Windows with -threaded ?  I'm willing to put in the work, but there's a lot I'd have to learn about windows IO and GHC IO handling.  One question to get started: are threadWaitRead/threadWaitWrite even possible to implement on Windows, or might Windows assign overlapping HANDLE numbers to sockets and regular files?

This issue spans both GHC and the network package, but I'd like to collect information about it in one place.  Related issues:

 * http://trac.haskell.org/network/ticket/2

 * https://github.com/haskell/network/issues/36

 * http://hackage.haskell.org/trac/ghc/ticket/3937

 * http://hackage.haskell.org/trac/ghc/ticket/5797"	joeyadams
3	7897	MakeTypeRep fingerprints be proper, robust fingerprints	Compiler	7.6.3	normal				new	2013-05-08T07:44:33-0700	2013-05-09T00:22:56-0700	"A `TypeRep` currently looks like this:
{{{
data TypeRep = TypeRep Fingerprint TyCon [TypeRep]
data TyCon = TyCon {
   tyConHash    :: Fingerprint,
   tyConPackage :: String,
   tyConModule  :: String,
   tyConName    :: String }
}}}
If two `TypeRep`s have the same fingerprint they should really describe identical types.  

But that's not really true today, becuase today the fingerprint for a `TyCon` is obtained by hashing the ''name'' of the type constructor (e.g.  `base:Data.Maybe.Maybe`), but not its ''structure''.  To see how this is non-robust, imagine that 
{{{
module M where
data T = MkT S deriving( Typeable )
data S = S1 Int | S2 Bool deriving( Typeable )
}}}
Now I do this:
 * Write a program that costructs a value `v::T`, and serialises into a file (a) the `TypeRep` for `v`, and (b) `v` itself.
 * Now I alter the data type declaration for `S`
 * Now I recompile and run the program again, which attempts to read the value back in from the file.  It carefully compares `TypeRep`s to be sure that the types are the same... yes, still ""M.T"". 
 * But alas the de-serialisation fails because `S` has been changed.

What we really want is for the fingerprint in a `TypeRep` to really be a hash of the definition of `T` (not just its name), including transitively the fingerprints of all the types mentioned in that definition. 

In effect, a `TypeRep` is a dynamic type check, and it should jolly well be a robust dynamic type check.  This might also matter in a Cloud Haskell application with different components upgraded at different times.

As it happens, GHC already computes these fingerprints, to put in interface files.  But they aren't used when making the `Typeable` instances for `T`.  I think it should be.

"	simonpj
3	5522	mc03 -O -fliberate-case -fspec-constr runs out of memory	Compiler	7.3	normal		7.6.2	simonpj	new	2011-09-28T19:32:47-0700	2012-09-12T04:12:04-0700	"I noticed that test mc03 runs out of memory compiled with -O -fliberate-case -fspec-constr.

-O + either extra option on its own isn't enough to trigger the issue..

stage2 --info output:

{{{
$ ../inplace/bin/ghc-stage2.exe --info
 [(""Project name"",""The Glorious Glasgow Haskell Compilation System"")
 ,(""GCC extra via C opts"","" -fwrapv"")
 ,(""C compiler command"",""$topdir/../mingw/bin/gcc.exe"")
 ,(""C compiler flags"","""")
 ,(""ar command"",""C:/MinGW/msys/1.0/home/bill/ghc-HEAD-github/inplace/mingw/bin/ar.exe"")
 ,(""ar flags"",""q"")
 ,(""ar supports at file"",""YES"")
 ,(""touch command"",""$topdir/touchy.exe"")
 ,(""dllwrap command"",""$topdir/../mingw/bin/dllwrap.exe"")
 ,(""windres command"",""$topdir/../mingw/bin/windres.exe"")
 ,(""perl command"",""$topdir/../perl/perl.exe"")
 ,(""Project version"",""7.3.20110927"")
 ,(""Booter version"",""7.0.2"")
 ,(""Stage"",""2"")
 ,(""Build platform"",""i386-unknown-mingw32"")
 ,(""Host platform"",""i386-unknown-mingw32"")
 ,(""Target platform"",""i386-unknown-mingw32"")
 ,(""Have interpreter"",""YES"")
 ,(""Object splitting supported"",""YES"")
 ,(""Have native code generator"",""YES"")
 ,(""Support SMP"",""YES"")
 ,(""Unregisterised"",""NO"")
 ,(""Tables next to code"",""YES"")
 ,(""RTS ways"",""l debug  thr thr_debug thr_l thr_p  dyn debug_dyn thr_dyn thr_debug_dyn"")
 ,(""Leading underscore"",""YES"")
 ,(""Debug on"",""False"")
 ,(""LibDir"",""C:\\MinGW\\msys\\1.0\\home\\bill\\ghc-HEAD-github\\inplace\\lib"")
 ,(""Global Package DB"",""C:\\MinGW\\msys\\1.0\\home\\bill\\ghc-HEAD-github\\inplace\\lib\\package.conf.d"")
 ,(""Gcc Linker flags"",""[]"")
 ,(""Ld Linker flags"",""[]"")
 ]
}}}

ghc-HEAD was built with !BuildFlavor=perf

"	btutt
3	7634	MD5 collision could lead to SafeHaskell violation	libraries/base	7.6.1	normal		7.8.1		new	2013-01-28T00:55:55-0800	2013-04-12T16:34:15-0700	"The current scheme for computing `TypeRep` fingerprints is: `md5sum (encodeUTF32BE (unwords [moduleName, packageName, typeName]))`. `SafeHaskell` doesn't allow custom-written `Typeable` instances, but this is more or less the code that `deriving Typeable` generates.

MD5 is broken and not collision-resistant. If someone can make an MD5 collision, they could use it to derive `unsafeCoerce` and execute arbitrary code. The constraints (UTF-32, names being alphanumeric, etc.) make it pretty tricky to find a valid collision by the standard methods, but I don't know enough about this to say how feasible it is.

It seems to me that, especially with `new-typeable`, it might not be necessary to use hashing at all, if GHC can figure out fingerprints statically. Or maybe separate compilation requirements make that unworkable (in which case maybe using a hash of the package/module name along with a separate per-module counter, or something along those lines, might be better, since people are less likely to control those? I'm not sure). Maybe the solution is just switching to another hash function, or something else. At any rate, the issue should be considered -- using MD5 isn't a good idea in cases where collisions could have security implications."	shachaf
3	7702	Memory Leak in CoreM (CoreWriter)	Compiler	7.6.2	normal		7.8.1	igloo	patch	2013-02-18T01:27:49-0800	2013-04-12T17:09:51-0700	"While running HERMIT on extended examples, we noticed that the CoreWriter component of CoreM is building up unevaluated SimplCount expressions. Attached is a one line patch to make the field in the CoreWriter record strict, which fixes the leak.

Also attached are heap profiles before and after to verify the fix. (You'll notice we have other memory leaks in HERMIT to address, the important bit being the big CoreWriter peak is gone in after.pdf.) These were generated by running a large number of HERMIT transformations in a batch, with HERMIT calling ghc with +RTS -hT -RTS.

I'm not sure how this affects compilation time or allocation when SimplCount is not the VerySimplCount constructor. Would the nofib suite answer these questions?"	afarmer
4	4800	Memory Leak when Compiling qtHaskell	Compiler	6.12.3	low		7.6.2		new	2010-11-29T00:48:08-0800	2012-09-12T04:12:33-0700	"I get an out-of-memory error about two thirds of the way through building qtHaskell (latest version, 1.1.4). If I start again, the remaining modules are compiled successfully, although GHC's memory usage creeps up to about 1.5Gb by the time it's finished.

This is on Win7 x64 with 4Gb RAM."	gidyn
4	3697	Method selectors aren't floated out of loops	Compiler	6.13	low		7.6.2		new	2009-11-26T16:21:54-0800	2012-09-12T04:12:19-0700	"Here is a small example:
{{{
foo :: Num a => [a] -> [a]
foo as = filter (/=0) (map (\x -> x-x) as)
}}}
Here is the code that the current HEAD generates for the loop:
{{{
go_smy =
  \ (ds_akN :: [a_aiw]) ->
    case ds_akN of _ {
      [] -> GHC.Types.[] @ a_aiw;
      : y_akS ys_akT ->
        let {
          x_smA :: a_aiw
          x_smA = GHC.Num.- @ a_aiw $dNum_ajk y_akS y_akS } in
        case GHC.Classes./= @ a_aiw lvl_smu x_smA lit_smw of _ {
          GHC.Bool.False -> go_smy ys_akT;
          GHC.Bool.True -> GHC.Types.: @ a_aiw x_smA (go_smy ys_akT)
        }
}}}
Note that the `Eq` dictionary is inspected by `(/=)` in every loop iteration. Floating out `GHC.Classes./= @ a_aiw lvl_smu` (and, perhaps, `GHC.Num.- @ a_aiw $dNum_ajk`) should solve this. In fact, I wonder why that isn't happening already. Do method selectors have a wrong arity?

FWIW, in GHC 6.10 `LiberateCase` moves the method selection out of the loop (not ideal, but it gets the job done) so !NoSlow shows this as a slight performance regression."	rl
2	7289	Mingw FPU init not Windows compatible.	Runtime System	7.2.2	high		7.8.1		new	2012-10-02T04:35:09-0700	2013-04-12T07:56:05-0700	"Mingw initializes the FPU top 80 bit precision instead of MSVC's 53 bits (which is the standard).  I suggest ghc linking on Windows should be changed to that it uses 53 bits instead.  This will make programs more Windows compatible (and possibly faster).

Here's a comment from Mingw's Float.h:

/*
MSVCRT.dll _fpreset initializes the control register to 0x27f,
the status register to zero and the tag word to 0FFFFh.
This differs from asm instruction finit/fninit which set control
word to 0x37f (64 bit mantissa precison rather than 53 bit).
By default, the mingw version of _fpreset sets fp control as
per fninit. To use the MSVCRT.dll _fpreset, include CRT_fp8.o when
building your application.	
*/"	Lennart
3	149	missed CSE opportunity	Compiler	5.04.2	normal	minor	_|_		new	2003-06-12T02:29:46-0700	2013-05-02T08:49:01-0700	"Don't know if this is a bug, but it was at least
_surprising_ to find that

{{{
playerMostOccur [a] = a
playerMostOccur (x:xs)
 | numOccur x (x:xs) > numOccur (playerMostOccur xs) xs = x
 | otherwise = playerMostOccur xs
}}}

was exponentially slower when compiled with ghc-5.04.2
-O than:

{{{
playerMostOccur [a] = a
playerMostOccur (x:xs)
 | numOccur x (x:xs) > numOccur pmo xs = x
 | otherwise = pmo
 where pmo = playerMostOccur xs
}}}

Although the student responsible for the code couldn't
spot the
obvious optimisation, I was expecting that GHC's
optimiser would. :)
If it's not a bug, could you explain it to me?

-Greg(gregm.at.cs.uwa.edu.au)
"	nobody
3	1216	Missed opportunity for let-no-esape	Compiler	6.6	normal	normal	7.6.2	simonpj	new	2007-03-12T09:57:04-0700	2012-09-12T04:11:56-0700	"readArray/writeArray call GHC.Arr.index, which seems inexplicably slow
for 2d arrays. inexplicably, because simply copying the default implementation
of index from GHC.Arr into the local module can speed things up considerably.

originally raised in this thread:
http://www.haskell.org/pipermail/haskell-cafe/2007-March/023394.html

shortened example or matrix/vector-multiplication attached. comment out
the first line of myindex to use the local copy. this results in a speedup
from 20s to 13s (time ./Index 100000) on my system, not to mention the
difference in space usage (a factor of 1000 in allocation, according to
+RTS -sstderr..)."	claus
5	2439	Missed optimisation with dictionaries and loops	Compiler	6.9	lowest	normal	7.6.2	simonpj	new	2008-07-11T08:55:39-0700	2013-04-06T13:51:36-0700	"{{{
{-# LANGUAGE BangPatterns #-}
module Foo (sum') where

foldl' :: (a -> b -> a) -> a -> [b] -> a
{-# INLINE foldl' #-}
foldl' f !z xs = loop z xs
  where
    loop !z [] = z
    loop !z (x:xs) = loop (f z x) xs

sum' :: Num a => [a] -> a
sum' xs = foldl' (+) 0 xs
}}}

This is the code before !LiberateCase:

{{{
Foo.sum' =
  \ (@ a_a9T) ($dNum_aa1 [ALWAYS Just L] :: GHC.Num.Num a_a9T) ->
    let {
      lit_scm [ALWAYS Just L] :: a_a9T
      [Str: DmdType]
      lit_scm =
        case $dNum_aa1
        of tpl_B1 [ALWAYS Just A]
        { GHC.Num.:DNum tpl_B2 [ALWAYS Just A]
                        tpl_B3 [ALWAYS Just A]
                        tpl_B4 [ALWAYS Just A]
                        tpl_B5 [ALWAYS Just A]
                        tpl_B6 [ALWAYS Just A]
                        tpl_B7 [ALWAYS Just A]
                        tpl_B8 [ALWAYS Just A]
                        tpl_B9 [ALWAYS Just A]
                        tpl_Ba [ALWAYS Just C(S)] ->
        tpl_Ba lvl_sbH
        } } in
    letrec {
      loop_sck [ALWAYS LoopBreaker Nothing] :: a_a9T -> [a_a9T] -> a_a9T
      [Arity 2
       Str: DmdType SS]
      loop_sck =
        \ (z_a6Y :: a_a9T) (ds_db7 :: [a_a9T]) ->
          case z_a6Y of z_X7h [ALWAYS Just L] { __DEFAULT ->
          case ds_db7 of wild_B1 [ALWAYS Just A] {
            [] -> z_a6Y;
            : x_a72 [ALWAYS Just L] xs_a74 [ALWAYS Just S] ->
              case $dNum_aa1
              of tpl_Xl [ALWAYS Just A]
              { GHC.Num.:DNum tpl_B2 [ALWAYS Just A]
                              tpl_B3 [ALWAYS Just A]
                              tpl_B4 [ALWAYS Just C(C(S))]
                              tpl_B5 [ALWAYS Just A]
                              tpl_B6 [ALWAYS Just A]
                              tpl_B7 [ALWAYS Just A]
                              tpl_B8 [ALWAYS Just A]
                              tpl_B9 [ALWAYS Just A]
                              tpl_Ba [ALWAYS Just A] ->
              loop_sck (tpl_B4 z_a6Y x_a72) xs_a74
              }
          }
          }; } in
    \ (xs_a76 :: [a_a9T]) -> loop_sck lit_scm xs_a76
}}}

Note that the Num dictionary is scrutinised in the loop even though sum' is actually strict in the dictionary (by virtue of being strict in lit_scm) and it would make sense to take it apart before entering the loop. !LiberateCase does nail this but only if the loop is small enough and at the expense of code size.
"	rl
3	7116	Missing optimisation: strength reduction of floating-point multiplication	Compiler	7.4.2	normal		7.8.1	pcapriotti	new	2012-08-03T08:32:35-0700	2012-09-18T02:33:46-0700	"e.g. `x * 2.0` should turn into `x + x`.  See #2253 (program 6) for an example.

Whether this is best done as a builtin RULE or in `cmmMachOpFold`, or possibly both, I don't know.
"	simonmar
3	7912	Missing symbols from termios.h when linking on Android	libraries/unix	7.7	normal				new	2013-05-15T04:15:14-0700	2013-05-15T04:15:14-0700	The Bionic libc that is used on Android defines the symbols in termios.h inline.	neurocyte
4	5267	Missing type checks for arrow command combinators	Compiler (Type checker)	7.0.3	low		7.6.2	ross	new	2011-06-22T01:44:02-0700	2012-09-12T04:13:30-0700	"Is this expected to work?

{{{
{-# LANGUAGE Arrows #-}
module T where

import Prelude
import Control.Arrow

t = proc () ->
     do rec x <- arr id <<< (| (arr id) (returnA -< x) |)
        returnA -< x

t' = proc x ->
     do x <- arr id <<< (| (arr id) (returnA -< x) |)
        returnA -< x

t'' = proc x ->
     do x <- arr id <<< (| (arr id) (returnA -< 3) |)
        returnA -< x

t''' = proc x -> arr id <<< (| (arr id) (returnA -< 3) |)
}}}

I get:

{{{
/tmp/T.hs:8:18:
    The type of the first argument of a command form has the wrong shape
      Argument type: t_tX
    In the command: (arr id) <<< ((|(arr id) ((returnA -< x))|))
    In a stmt of a 'do' expression:
        x <- (arr id) <<< ((|(arr id) ((returnA -< x))|))
    In a stmt of a 'do' expression:
        rec {x <- (arr id) <<< ((|(arr id) ((returnA -< x))|))}

/tmp/T.hs:12:14:
    The type of the first argument of a command form has the wrong shape
      Argument type: t_tG
    In the command: (arr id) <<< ((|(arr id) ((returnA -< x))|))
    In a stmt of a 'do' expression:
        x <- (arr id) <<< ((|(arr id) ((returnA -< x))|))
    In the expression:
      proc x -> do { x <- (arr id) <<< ((|(arr id) ((returnA -< x))|));
                     returnA -< x }

/tmp/T.hs:16:14:
    The type of the first argument of a command form has the wrong shape
      Argument type: t_tq
    In the command: (arr id) <<< ((|(arr id) ((returnA -< 3))|))
    In a stmt of a 'do' expression:
        x <- (arr id) <<< ((|(arr id) ((returnA -< 3))|))
    In the expression:
      proc x -> do { x <- (arr id) <<< ((|(arr id) ((returnA -< 3))|));
                     returnA -< x }

/tmp/T.hs:19:18:
    The type of the first argument of a command form has the wrong shape
      Argument type: t_k
    In the command: (arr id) <<< ((|(arr id) ((returnA -< 3))|))
    In the expression:
      proc x -> (arr id) <<< ((|(arr id) ((returnA -< 3))|))
    In an equation for `t'''':
        t''' = proc x -> (arr id) <<< ((|(arr id) ((returnA -< 3))|))
}}}
"	peteg
3	3575	mkStdGen and split conspire to make some programs predictable	libraries/random	6.10.1	normal	normal	_|_	rrnewton	new	2009-10-11T21:45:04-0700	2011-06-26T18:28:10-0700	"The following program `random.hs` is intended to produce a line containing 30 random 0s or 1s.  It is not an example of the best way to use System.Random, but it looks innocuous enough.

{{{
import Control.Monad
import System.Random

print0or1 = do
  g <- newStdGen
  putStr . show . fst $ randomR (0, 1 :: Int) g

main = replicateM_ 30 print0or1 >> putStrLn """"
}}}

Let's try running it a thousand times:

{{{
rwbarton@functor:/tmp$ ghc-6.10.1 -O2 --make random
[1 of 1] Compiling Main             ( random.hs, random.o )
Linking random ...
rwbarton@functor:/tmp$ for i in `seq 1 1000` ; do ./random >> random.out ; done
rwbarton@functor:/tmp$ sort random.out | uniq | wc -l
60
}}}

That's odd... there are 2^30^ possible output lines, but when I tried to generate 1000 random ones, I only got 60 distinct outputs.  Why did that happen?

One might think this is due to poor initial seeding of the random number generator (due to the time not changing very much during the test), but this is not the case.  Attached is a fancier version of the program which reads an initial seed from `/dev/urandom`; it exhibits the same behavior.

This phenomenon is not too hard to explain.  It is ultimately due to a poor interaction between `mkStdGen` and `split`.  First, we need to know a bit about the design of System.Random (some statements simplified slightly for this discussion).

 * The state of the RNG consists of two `Int32`s, `s1` and `s2`.

 * The initial state produced by mkStdGen almost always has `s2` equal to 1.  (Extremely rarely, it might have `s2` equal to 2.  We'll ignore this as it doesn't affect the argument.)

 * To generate a random 0 or 1, we first generate a new state using some simple functions `s1' = next1(s1)`, `s2' = next2(s2)`.  (Note that `s1` and `s2` ""evolve"" independently.)  The random value returned is the lowest bit of `s1'` minus `s2'`.

 * Splitting the generator `(s1, s2)` yields the two generators `(s1+1, next2(s2))` and `(next1(s1), s2-1)`.

Our program functions as follows.

 * Initialize the generator stored in `theStdGen` (`s1` is some varying value `a`, `s2` is 1).

 * Repeatedly split the generator, replacing it with the first output, and use the second output to generate a 0 or 1.

If we watch `theStdGen` while our program runs, we will see that `s1` is incremented by 1 at each step, while `s2` follows the fixed sequence `1`, `next2(1)`, `next2(next2(1))`, etc.  The 0 or 1 we output at the `k`th step is thus the lowest bit of `next1(next1(a+k-1))` minus `b`,,k,,, where `b`,,k,, is some fixed sequence.  And as `k` varies, `next1(next1(a+k-1))` turns out to be just an arithmetic sequence with fixed difference modulo a fixed prime so its lowest bits are extremely predictable even without knowing `a`.

This issue can be fixed to some extent, without breaking backwards compatibility, by adding another method (besides `mkStdGen`) to create a generator, which does not have predictable `s2`, and using it to initialize the system RNG."	rwbarton
2	7787	modifyMVar does not restore value if callback returns error value	libraries/base	7.7	high		7.8.1		new	2013-03-22T21:09:11-0700	2013-04-13T06:50:38-0700	"`modifyMVar` is currently implemented as follows:

{{{
modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b
modifyMVar m io =
  mask $ \restore -> do
    a      <- takeMVar m
    (a',b) <- restore (io a) `onException` putMVar m a
    putMVar m a'
    return b
}}}

The problem is that it forces the `(a',b)` outside of the exception handler.  If forcing this throws an exception, `putMVar` will not be called, and a subsequent `withMVar` or similar will hang.  Example:

{{{
> import Control.Concurrent.MVar
> mv <- newMVar 'x'
> modifyMVar mv $ \_ -> return undefined
*** Exception: Prelude.undefined
> withMVar mv print
-- hang --
}}}

Perhaps we can fix it like this:

{{{
-     (a',b) <- restore (io a) `onException` putMVar m a
+     (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a
}}}"	joeyadams
3	7785	Module-local function not specialized with ConstraintKinds	Compiler	7.6.2	normal		7.8.1		new	2013-03-21T23:04:19-0700	2013-04-13T06:42:14-0700	In the attached program, 'shared' is not exported and only used with f = [], but it doesn't get specialized in the core. On the other hand, shared', which does not involve !ConstraintKinds, gets correctly specialized.	akio
3	7783	MultiWayIf should start a new layout	Compiler (Parser)	7.6.2	normal		7.8.1		new	2013-03-21T07:55:31-0700	2013-04-13T06:37:02-0700	"Currently, `MultiWayIf` doesn't fully replace old {{{case () of _}}} form. This outputs 3:

{{{
{-# LANGUAGE MultiWayIf #-}
x = case () of
    _ | False -> case () of
                _ | False -> 1
                  | False -> 2
      | True -> 3

main = print (x :: Int)
}}}

but this errors out:

{{{
{-# LANGUAGE MultiWayIf #-}
x = if | False -> if | False -> 1
                     | False -> 2
       | True -> 3

main = print (x :: Int)
}}}
because it parses like this:
{{{
x = if | False -> if | False -> 1
                     | False -> 2
                     | True -> 3
}}}
Every other syntax introducing guards starts a layout; `MultiWayIf`'s current behavior leads to subtle logic bugs for those unaware that `MultiWayIf` is special."	exbb2
5	2374	MutableByteArray# is slower than Addr#	Compiler (NCG)	6.8.2	lowest	minor	7.6.2		new	2008-06-17T23:55:58-0700	2012-09-12T04:13:58-0700	"I've filed this against the native code generator, even thought it still occurs in my experience with the via-C path. It is significantly more pronounced with the NCG path, and so, I imagine, is likely to be fixed by working on that. However, feel free to reclassify if appropriate.

When attempting to rewrite the fannkuch benchmark of the computer language benchmarks game to use more realistic code, I discovered that I am currently unable to do so. At least one piece of the puzzle is that the current entry uses Ptr and Addr# for arrays, while the current mutable array libraries (ST arrays and uvector) use MutableByteArray# underneath, and it happens that reads/writes on the latter are slower than the former.

After some discussion on the glasgow-haskell-users list, I believe I've worked the kinks out of my (even more micro) benchmark programs, and will attach them here. They accept two numbers, k and n, and reverse an array of size-n k times. The larger fannkuch benchmark works on small arrays (reversing, shifting and copying), so using small arrays with a very large number of iterations is more representative of it. However, my benchmark doesn't show terribly much variation when one varies the parameters by corresponding factors (although there is a drop in performance when the size of the array nears the size of the CPU cache, naturally).

I've test machine is an AMD Athlon 64 3000+ running in 64-bit mode with 2 GB of ram. My operating system is Linux, kernel 2.6.24.

I've mainly done runs where n * k = 2.5 billion, as that takes approximately as much time as the MutableByteArray# version of the fannkuch benchmark, around 11 seconds for 250 million iterations with an array size of 10. The Addr# version of the benchmark runs with the same parameters in around 7 seconds (which is faster than the actual fannkuch benchmark, but I digress).

I'll attach my two micro benchmarks. ByteArr.hs is the MutableByteArray# reversal benchmark. Ptr.hs is the Addr#/Ptr version. I may also attach full fannkuch implementations as another data point (the original is already Addr#/Ptr, and I've written a MutableByteArray# implementation; I just need to do some proofreading of the latter to make sure it doesn't have any discrepancies).

I've also not done much investigation as to the source of the problem, besides looking at the core of various higher level programs to track things down this far. I'll attempt to delve further into the issue, investigating the C-- and assembly if my abilities allow, and update here as I find things."	dolio
3	7475	Mysterious Data.Word Segmentation Fault in GHCi	Compiler	7.6.1	normal		7.8.1		new	2012-12-03T09:14:43-0800	2013-01-09T14:47:12-0800	"So, this happens:
{{{
GHCi, version 7.6.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m + Data.Word
Prelude Data.Word> ((fromIntegral . floor) $ -5.467881373802522) :: Word8
Segmentation fault
}}}"	VKS
5	2289	Needless reboxing of values when returning from a tight loop	Compiler	6.8.2	lowest	normal	7.6.2		new	2008-05-16T17:58:47-0700	2013-01-31T21:03:04-0800	"GHC wants to box up strict values when returning from tight inner loops, even when they're
immediately taken apart. This leads to redundant instructions in the bodies of tight loops,
and more code. 

It affects, in particular, loops that result from fusion, which need to be tight, but often return multiple values via unlifted pairs.

Consider this program:

{{{
{-# OPTIONS -fexcess-precision #-}
{-# LANGUAGE TypeOperators #-}

import System.Environment
import Text.Printf
import Data.Array.Vector

mean :: UArr Double -> Double
mean arr = s / fromIntegral l
  where
    s :*: l = foldlU k (0 :*: 0) arr :: (Double :*: Int)
    k (s :*: n) x = s+x :*: n+1

main = do
    [d] <- map read `fmap` getArgs
    printf ""%f\n"" (mean (enumFromToFracU 1 d))
}}}

It generates this rather good Core (ghc 6.8.2):

{{{
$s$wfold_s1rB :: Double#
               -> Int#
               -> Double#
               -> (# Double, Int #)

$s$wfold_s1rB =
\ (sc_s1rr :: Double#)
  (sc1_s1rs :: Int#)
  (sc2_s1rt :: Double#) ->
  case >## sc_s1rr y_a1pr of wild4_X1no {
    False ->
      $s$wfold_s1rB
        (+## sc_s1rr 1.0)
        (+# sc1_s1rs 1)
        (+## sc2_s1rt sc_s1rr);
    True -> (# D# sc2_s1rt, I# sc1_s1rs #)
  };
} in 
case $s$wfold_s1rB 2.0 1 1.0 of ww_s1qg { (# ww1_s1qi, ww2_s1qj #) ->
case ww1_s1qi of wild4_a1mC { D# x_a1mE ->
case ww2_s1qj of wild5_aP6 { I# x1_aP8 ->
case /## x_a1mE (int2Double# x1_aP8)
of wild21_a1mK { __DEFAULT ->
D# wild21_a1mK
}}}

But note, what's this?

{{{
    True -> (# D# sc2_s1rt, I# sc1_s1rs #)
  };
} in 
case $s$wfold_s1rB 2.0 1 1.0 of ww_s1qg { (# ww1_s1qi, ww2_s1qj #) ->
case ww1_s1qi of wild4_a1mC { D# x_a1mE ->
case ww2_s1qj of wild5_aP6 { I# x1_aP8 ->
case /## x_a1mE (int2Double# x1_aP8)

}}}

The return values of what was a strict pair are boxed, placed in an unboxed tuple,
and then immediately unboxed and the division takes place.

Ok, let's isolate this. Here, the boxed return, from the inner loop:

{{{
mean_s19V :: Double#
           -> Int#
           -> Double#
           -> (# Double, Int #)

mean_s19V =
\ (ds1_dD3 :: Double#)
  (ds2_dD4 :: Int#)
  (ds3_dD5 :: Double#) ->
  case >## ds1_dD3 d#_aoG of wild4_Xw {
    False ->
      mean_s19V
        (+## ds1_dD3 1.0)
        (+# ds2_dD4 1)
        (+## ds3_dD5 ds1_dD3);
    True -> (# D# ds3_dD5, I# ds2_dD4 #)
  };
} in 
case mean_s19V 2.0 1 1.0 of wild4_Xr { (# ds1_dCV, ds2_dCW #) ->
case ds1_dCV of wild5_Xv { D# x_aoR ->
case ds2_dCW of wild6_Xy { I# y_aoS ->
case /## x_aoR (int2Double# y_aoS) of wild7_XB { __DEFAULT ->
D# wild7_XB
}}}

And the inner loop and exit:

{{{
s1bd_info:

  -- what's this stuff?
  leaq        32(%r12), %rax
  cmpq        %r15, %rax
  movq        %rax, %r12
  ja  .L17

  -- ok, to business:
  ucomisd     5(%rbx), %xmm5
  ja  .L19
  movapd      %xmm6, %xmm0
  leaq        -32(%rax), %r12
  incq        %rsi
  addsd       %xmm5, %xmm0
  addsd       .LC1(%rip), %xmm5
  movapd      %xmm0, %xmm6
  jmp s1bd_info


.L19:
  movq        %rsi, -16(%rax)
  movq        $base_GHCziBase_Izh_con_info, -24(%rax)
  movq        $base_GHCziFloat_Dzh_con_info, -8(%rax)
  movsd       %xmm6, (%rax)
  leaq        -7(%rax), %rbx
  leaq        -23(%rax), %rsi
  jmp *(%rbp)
}}}

Now, I can avoid the reboxing manually:

{{{
mean_s19R :: Double#
           -> Int#
           -> Double#
           -> (# Double#, Int# #)

mean_s19R =
\ (ds1_dCZ :: Double#)
  (ds2_dD0 :: Int#)
  (ds3_dD1 :: Double#) ->
  case >## ds1_dCZ d#_aoG of wild4_Xw {
    False ->
      mean_s19R
        (+## ds1_dCZ 1.0)
        (+# ds2_dD0 1)
        (+## ds3_dD1 ds1_dCZ);
    True -> (# ds3_dD1, ds2_dD0 #)
  };
} in 
case mean_s19R 2.0 1 1.0 of wild4_Xr { (# x_aoR, y_aoS #) ->
case /## x_aoR (int2Double# y_aoS) of wild5_Xv { __DEFAULT ->
D# wild5_Xv
}}}

And we get:

{{{
s1b9_info:
  -- hey , our junk is gone!

  ucomisd     5(%rbx), %xmm5
  ja  .L17
  movapd      %xmm6, %xmm0
  incq        %rsi
  addsd       %xmm5, %xmm0
  addsd       .LC1(%rip), %xmm5
  movapd      %xmm0, %xmm6
  jmp s1b9_info

-- cool, that was it, let's go home:
.L17:
  movapd      %xmm6, %xmm5
  movq        %rsi, %rbx
  jmp *(%rbp)

}}}

Which is a much better result. The loop is tighter.

What can be done here?"	dons
2	7198	New codegen more than doubles compile time of T3294	Compiler	7.4.2	high		7.8.1	simonmar	new	2012-08-29T05:44:49-0700	2012-08-29T05:44:49-0700	"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
3	3872	New way to make the simplifier diverge	Compiler	6.12.1	normal		_|_		new	2010-02-10T07:24:30-0800	2011-08-10T08:32:06-0700	"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
4	4846	Newtype derving used wrongly	Compiler	7.0.1	low		7.6.2		new	2010-12-17T00:39:28-0800	2012-09-12T04:13:23-0700	"Emil Axelsson reports: I attach a program `Test.hs` which I suspect demonstrates a bug in GHC. The important lines are:
{{{
   showType :: forall a . Expr a -> String
   showType (Lit _) = show (typeOf (undefined :: a))

   test1 = showType (mk     :: Expr BOOL) -- Prints ""Bool"" (wrong?)
   test2 = showType (Lit mk :: Expr BOOL) -- Prints ""Main.BOOL"" (correct)
}}}
`test1` and `test2` give different results, even though showType shouldn't be able to tell them apart. It seems that the `Typeable` context packed with the Lit constructor is wrong in `test2`.

"	simonpj
3	1496	Newtypes and type families combine to produce inconsistent FC(X) axiom sets	Compiler (Type checker)	6.7	normal	critical	7.6.2	simonpj	new	2007-07-04T15:27:01-0700	2013-03-14T01:24:30-0700	"Given:

{{{
{-# OPTIONS_GHC -ftype-families #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
data family Z :: * -> *

newtype Moo = Moo Int

newtype instance Z Int = ZI Double
newtype instance Z Moo = ZM (Int,Int)
}}}

We generate the axioms:

{{{
(from the instances)
Z Int ~ Double
Z Moo ~ (Int,Int)

(from the newtype)
Moo ~ Int
}}}

And can prove:

{{{
(production REFL in the FC(X) paper)
Z ~ Z

(production COMP)
Z Moo ~ Z Int

(production TRANS)
Z Moo ~ Double

(production SYM)
Double ~ Z Moo

(production TRANS)
Double ~ (Int,Int)
}}}

Tickling this seems to require the newtype cheat, but the inconsistant axioms
allow code to pass Core Lint and still crash:

{{{
newtype Moo = Moo Int deriving(IsInt)
class IsInt t where
    isInt :: c Int -> c t
instance IsInt Int where isInt = id
main = case isInt (ZI 4.0) of ZM tu -> print tu
}}}

{{{
stefan@stefans:/tmp$ ghc -dcore-lint Z.hs
stefan@stefans:/tmp$ ./a.out
Segmentation fault
stefan@stefans:/tmp$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 6.7.20070612
stefan@stefans:/tmp$
}}}"	sorear
5	2260	Non-ideal error message for misplaced LANGUAGE pragma	Compiler (Parser)	6.8.2	lowest	trivial	7.6.2		new	2008-05-03T13:22:44-0700	2013-01-28T03:16:43-0800	"Placing the LANGUAGE pragma anywhere besides the top results in it not being accepted - thus this should result in an error message.

Trivially:
{{{
import Data.Maybe

{-# LANGUAGE EmptyDataDecls #-}

data A
}}}

This would be minorly more annoying for TypeFamilies, who's error doesn't mention language extentions:
""Data/Queue.hs:30:0: parse error (possibly incorrect indentation)"""	TomMD
4	4899	"Non-standard compile plus Template Haskell produces spurious ""unknown symbol"" linker error"	Compiler	7.0.1	low		7.6.2	simonmar	new	2011-01-17T16:44:27-0800	2012-09-12T04:13:23-0700	"Programs that use Template Haskell fail to link when doing a ""non-standard"" compile. Specifically, compilations with -prof and -dynamic produce this bug, although other flags may as well; it seems that compilations that require the two-stage -osuf flag produce this bug. The error message is always ""unknown symbol"" but the specific symbol that is allegedly missing varies. Removing the TH block from the code makes the problem go away.

I've provided a minimal example of a program that can reproduce this bug, in the enclosed files Bug1.hs and Main.hs. A typescript demonstrating the error message is also included.

Tested on GHC 7.0.1 and 6.12.1, running under Ubuntu 10.04, both 64-bit and 32-bit. Also tested with 6.12.3 under 32-bit Windows 7."	jepst
3	7727	Nonsense evaluation: sequence [] = []	GHCi	7.6.2	normal		7.8.1	igloo	new	2013-02-27T16:16:04-0800	2013-04-12T17:00:53-0700	"{{{
$ ghci-7.6.2
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.
>>> sequence []
[]
>>> :t it
it :: [()]
>>> sequence [] :: [()]

<interactive>:4:1:
    Couldn't match type `[a0]' with `()'
    Expected type: [()]
      Actual type: [[a0]]
    In the return type of a call of `sequence'
    In the expression: sequence [] :: [()]
    In an equation for `it': it = sequence [] :: [()]

}}}


Wat. Where on earth did ghci get the idea that {{{ sequence [] = [] }}}?"	drb226
3	2528	nub not as reliable as nubBy	libraries/base	6.8.2	normal	minor	6.10.1		new	2008-08-20T19:48:22-0700	2011-09-28T04:10:52-0700	"While working on a fun math/programming exercise I discovered a peculiar behavior in ""nub"".  While it worked the vast majority of the time, there were a few cases where it failed to purge all duplicates as defined by (==).  Replacing the use of ""nub"" with ""nubBy (==)"" correctly purged all cases.

I have linked a codepad evaluation that outputs the strange behavior:
http://codepad.org/VNauTAam

I would have isolated the bug better for you, but like I say nub works by far the majority of the time.  This must be a peculiar clash with my custom data structures and strange definition of (==).

Cheers."	jdressel
5	2370	num009 fails on OS X 10.5?	Compiler	6.9	lowest	normal	7.6.2		new	2008-06-17T01:59:14-0700	2013-01-31T13:27:31-0800	"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  </dev/null >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
3	7765	Odd error message for `runghc` with missing `main` function.	Compiler	7.6.1	normal		7.8.1	igloo	new	2013-03-12T17:54:28-0700	2013-04-13T06:15:12-0700	"{{{
% cat what.hs
module Main where {}

% runghc what.hs
what.hs:1:33:
    Not in scope: `main'
    Perhaps you meant `min' (imported from Prelude)
}}}

'`ghc what.hs`' gives a rather more sensible message."	isaacdupree
3	6016	On Windows, runhaskell hits an error on UTF-8 files with a BOM	Compiler (Parser)	7.0.4	normal		7.6.2		new	2012-04-18T01:03:29-0700	2013-03-02T21:16:00-0800	"The file

{{{
#!/usr/bin/env runhaskell
main = putStrLn ""Hello, world!""
}}}
works on Windows as expected:

{{{
C:\Temp>runhaskell hello.hs
Hello, world!
}}}
However, if the file is saved as UTF-8 with a BOM (Windows Notepad, for example, sometimes adds this BOM to files), an error occurs:

{{{
C:\Temp>runhaskell hello2.hs

hello2.hs:1:1: parse error on input `#!/'
}}}

I'm using the Haskell Platform 2011.4.0.0.

I believe that runhaskell/runghc should handle the presence of a BOM correctly; some Windows programs insert a BOM unbeknownst to the user.

This behaviour was observed on Windows XP (32-bit) and Windows 7 (32-bit and 64-bit).
"	vsajip
3	7725	Operators without colons	Compiler	7.6.2	normal		7.8.1		new	2013-02-26T13:08:11-0800	2013-04-13T05:23:27-0700	"This code is accepted:

{{{
data A x y = (&) x y
}}}

but it's wrong - as far as I know operators on the value level are constructors iff they start with a colon `(:&)`. (In fact {{{a = (&)}}} reports ""Not in scope: (&)"".)"	monoidal
3	7596	Opportunity to improve CSE	Compiler	7.6.1	normal		7.8.1	simonpj	new	2013-01-16T08:30:13-0800	2013-04-12T15:37:43-0700	"In `nofib/spectral/mandel2`, the function `check_perim` calls `point_colour` on various arguments.  After inlining `point_colour` there is the opportunity to CSE among the sub-expressions the inlinings create.

In GHC 7.6, the join point didn't have a ""one-shot"" flag, so the full laziness pass floated these sub-expressions out, and they got CSEd.

As part of Ilya's new demand analyser changes, we get the ""one-shot"" flag right, so don't MFE those sub-expressions, so they aren't CSEd.  As a result, allocation on `mandel2` increases slightly (4.2%).

The solution is, I think, to do something a bit like like `CorePrep` before CSE.  At the moment if we have
{{{
case f (I# y) of { (a,b) ->
case g (I# y) of { (p,q) -> ... }}
}}}
we stuipdly don't CSE that `(I# y)` even though it is manifestly sharable.  Somehow we should.
"	simonpj
3	1168	Optimisation sometimes decreases sharing in IO code	Compiler	6.6	normal	normal	_|_		new	2007-02-23T06:42:14-0800	2013-01-27T13:44:41-0800	The simplifier is losing sharing in spectral/calendar, probably because we're being a bit fast-and-loose with eta-expanding State# lambdas.  A quick look at the Core shows that `calFor year` is not shared across multiple executions.	simonmar
4	1498	Optimisation: eliminate unnecessary heap check in recursive function	Compiler	6.6.1	low	normal	7.6.2		new	2007-07-06T01:47:42-0700	2013-01-22T11:41:47-0800	"See [http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html]

In a basic block consisting of some primitive cases, in which only some branches require heap, we could push the heap check into the branches as long as the primitive operations are safe to repeat, and the stack has not been modified.  This might save a heap check in the common recursive case, which could be a significant win."	simonmar
4	4301	Optimisations give bad core for foldl' (flip seq) ()	Compiler	6.12.3	low		7.6.2		new	2010-09-10T11:34:41-0700	2012-09-12T04:12:30-0700	"I'm not sure whether it's one freak case or a symptom of a problem that occurs more often. Compiled with optimisations, the code
{{{
foo :: [a] -> ()
foo = foldl' (flip seq) ()
}}}
produces the core
{{{
Rec {
FSeq.foo1 :: forall a_af0. [a_af0] -> (##)
GblId
[Arity 1
 NoCafRefs
 Str: DmdType S]
FSeq.foo1 =
  \ (@ a_af0) (w_sg9 :: [a_af0]) ->
    case case w_sg9 of _ {
           [] -> GHC.Unit.();
           : x_afz xs_afA ->
             case x_afz of _ { __DEFAULT ->
             case FSeq.foo1 @ a_af0 xs_afA of _ { (# #) -> GHC.Unit.() }
             }
         }
    of _ { () ->
    GHC.Prim.(##)
    }
end Rec }
}}}
for the worker (ghc-6.12.3, similar core from HEAD). Due to the boxing and unboxing between (##) and (), there's a case on the recursive call, hence it produces a stack overflow on long enough lists.

The problem was reported in http://www.haskell.org/pipermail/beginners/2010-September/005287.html, my attempt at understanding it here: http://www.haskell.org/pipermail/beginners/2010-September/005293.html.

So far, I've only managed to produce it for the very special combination of foldl' (flip seq) and a single (non-bottom) value datatype; any other function to be folded or a multiple value type produce a tail-recursive two-argument worker.

Nevertheless, on the off chance that it's a symptom of a real problem, I'm reporting it."	daniel.is.fischer
3	2132	Optimise nested comparisons	Compiler	6.8.2	normal	normal	_|_		new	2008-02-28T04:23:42-0800	2013-04-21T10:38:16-0700	"GHC isn't capable of this optimisation:
{{{
  case (x ># y) of             ==>    case (x ># y) of
    True -> ...(x ==# y)...               True -> ...False...
    False -> ...                          False -> ...
}}}
That is, knowing that (x>y) we know that the two are not equal.

Also, consider this:
{{{
  case (x ># y) of               ==>   case (x >=# y) of
     True -> e                           True -> e
     False -> case (x ==# y) of          False -> e'
                True -> e
                False -> e'
}}}
Again this needs special knowlege about comparison operators.  However, it ''does'' arise.  Consider this:
{{{
  data T = MkT Int deriving( Eq, Ord )
}}}
The derived `(>)` operation looks like this:
{{{
Foo.$dm> =
  \ (eta_a8q :: Foo.T) (eta1_a8r :: Foo.T) ->
    case eta_a8q of wild_B1 { Foo.MkT a1_a60 ->
    case eta1_a8r of wild1_XO { Foo.MkT b1_a62 ->
    case a1_a60 of wild2_a9I { GHC.Base.I# x#_a9K ->
    case b1_a62 of wild11_a9M { GHC.Base.I# y#_a9O ->
    case GHC.Prim.<# x#_a9K y#_a9O of wild3_a9W {
      GHC.Base.False ->
        case GHC.Prim.==# x#_a9K y#_a9O of wild12_a9Z {
          GHC.Base.False -> GHC.Base.True; GHC.Base.True -> GHC.Base.False
        };
      GHC.Base.True -> GHC.Base.False
}}}
See also #2130"	simonpj
3	7367	Optimiser / Linker Problem on amd64	Build System	7.6.1	normal		7.8.1		new	2012-10-25T14:39:40-0700	2013-04-12T09:57:53-0700	"
The Haskell fannkuchredux contribution of Louis Wasserman to ""The Computer Language Benchmarks Game"" at shootout.alioth.debian.org times out on the amd64 machines, but not on the i386. I can reproduce it on my Debian amd64 machine. 

It turns out that compiling without optimisation or with a simple -O produces a fast program, but with enourmously large heap space allocated (10G compared with 67k on a virtual i386 machine) and also more garbage collector activity.

The source is below (because I don't find a way to attach the file). At the end  of the source I copied my make command line, run command line and output produced with option -sstderr.

---------------------


{{{
{-  The Computer Language Benchmarks Game
    http://shootout.alioth.debian.org/
    contributed by Louis Wasserman
    
    This should be compiled with:
    	-threaded -O2 -fexcess-precision -fasm
    and run with:
    	+RTS -N<number of cores> -RTS <input>
-}

import Control.Concurrent
import Control.Monad
import System.Environment
import Foreign hiding (rotate)
import Data.Monoid

type Perm = Ptr Word8

data F = F {-# UNPACK #-} !Int {-# UNPACK #-} !Int

instance Monoid F where
	mempty = F 0 0
	F s1 m1 `mappend` F s2 m2 = F (s1 + s2) (max m1 m2)

incPtr = (`advancePtr` 1)
decPtr = (`advancePtr` (-1))

flop :: Int -> Perm -> IO ()
flop k xs = flopp xs (xs `advancePtr` k)
 where flopp i j = when (i < j) $ swap i j >> flopp (incPtr i) (decPtr j)
       swap i j = do
	a <- peek i
	b <- peek j
	poke j a
	poke i b

flopS :: Perm -> (Int -> IO a) -> IO a
flopS !xs f = do
	let go !acc = do
		k <- peekElemOff xs 0
		if k == 0 then f acc else flop (fromIntegral k) xs >> go (acc+1)
	go 0

increment :: Ptr Word8 -> Ptr Word8 -> IO ()
increment !p !ct = do
	first <- peekElemOff p 1
	pokeElemOff p 1 =<< peekElemOff p 0
	pokeElemOff p 0 first
	
	let go !i !first = do
		ci <- peekElemOff ct i
		if fromIntegral ci < i then pokeElemOff ct i (ci+1) else do
			pokeElemOff ct i 0
			let !i' = i + 1
			moveArray p (incPtr p) i'
			pokeElemOff p i' first
			go i' =<< peekElemOff p 0
	go 1 first  

genPermutations :: Int -> Int -> Int -> Ptr Word8 -> Ptr Word8 -> IO F
genPermutations !n !l !r !perm !count = allocaArray n $ \ destF -> do
	let upd j !f run = do
		p0 <- peekElemOff perm 0
		if p0 == 0 then increment perm count >> run f else do
			copyArray destF perm n
			increment perm count
			flopS destF $ \ flops -> 
				run (f `mappend` F (checksum j flops) flops)
	let go j !f = if j >= r then return f else upd j f (go (j+1))
	go l mempty
 where checksum i f = if i .&. 1 == 0 then f else -f

facts :: [Int]
facts = scanl (*) 1 [1..12]

unrank :: Int -> Int -> (Ptr Word8 -> Ptr Word8 -> IO a) -> IO a
unrank !idx !n f = allocaArray n $ \ p -> allocaArray n $ \ count ->
  allocaArray n $ \ pp -> do
	mapM_ (\ i -> pokeElemOff p i (fromIntegral i)) [0..n-1]
	let go i !idx = when (i >= 0) $ do
		let fi = facts !! i
		let (q, r) = idx `quotRem` fi
		pokeElemOff count i (fromIntegral q)
		copyArray pp p (i+1)
		let go' j = when (j <= i) $ do
			let jq = j + q
			pokeElemOff p j =<< peekElemOff pp (if jq <= i then jq else jq - i - 1)
			go' (j+1)
		go' 0
		go (i-1) r
	go (n-1) idx
	f p count

main = do
   n <- fmap (read.head) getArgs
   let fact = product [1..n]
   let bk = fact `quot` 4
   vars <- forM [0,bk..fact-1] $ \ ix -> do
   	var <- newEmptyMVar
   	forkIO (unrank ix n $ \ p -> genPermutations n ix (min fact (ix + bk)) p >=> putMVar var)
   	return var
   F chksm mflops <- liftM mconcat (mapM takeMVar vars)
   putStrLn $ (show chksm) ++ ""\nPfannkuchen("" ++ (show n) ++ "") = "" ++ (show $ mflops)


{-

wurmli@noah-nofen:~/hpw/haskell/work/fannkuch$ ghc  --make
 -XBangPatterns -O -threaded -fllvm -rtsopts fannkuchredux.ghc-3.hs 
[1 of 1] Compiling Main             ( fannkuchredux.ghc-3.hs, fannkuchredux.ghc-3.o )
Linking fannkuchredux.ghc-3 ...
wurmli@noah-nofen:~/hpw/haskell/work/fannkuch$ ./fannkuchredux.ghc-3 +RTS -N4 -sstderr   -RTS 12
3968050
Pfannkuchen(12) = 65
  10,538,122,952 bytes allocated in the heap
         359,512 bytes copied during GC
          47,184 bytes maximum residency (2 sample(s))
          51,120 bytes maximum slop
               4 MB total memory in use (1 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      6053 colls,  6053 par    0.16s    0.04s     0.0000s    0.0001s
  Gen  1         2 colls,     1 par    0.00s    0.00s     0.0001s    0.0001s

  Parallel GC work balance: 40.82% (serial 0%, perfect 100%)

  TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   44.73s  ( 11.51s elapsed)
  GC      time    0.16s  (  0.04s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time   44.89s  ( 11.55s elapsed)

  Alloc rate    235,589,887 bytes per MUT second

  Productivity  99.6% of total user, 387.3% of total elapsed

gc_alloc_block_sync: 31024
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0

-}
}}}
"	wurmli
5	2387	Optimizer misses unboxing opportunity	Compiler	6.8.2	lowest	minor	7.6.2		new	2008-06-19T15:08:30-0700	2013-01-27T11:17:22-0800	"In my studying of the fannkuch benchmark, I've discovered (I think) another missed optimization. A scaled down illustration goes as follows:

{{{
{-# LANGUAGE TypeOperators, BangPatterns #-}

module Main (main) where

import Control.Monad.ST

import System.Environment

data (:*:) a b = !a :*: !b

whileLoop :: Int -> ST s Int
whileLoop = go 0
 where
 go !n k
   | k == 0    = return n
   | otherwise = go (n+1) (k-1)
{-# INLINE whileLoop #-}

iter :: Int -> Int -> ST s (Bool :*: Int)
iter k n = do
  k' <- whileLoop 40 >>= \k' -> return $! max k k'
  b <- return (n == 0)
  
  return $! b :*: k'
{-# INLINE iter #-}

mainLoop :: Int -> Int -> ST s Int
mainLoop k n = do
  done :*: k' <- iter k n
  
  if done
    then return k'
    else mainLoop k' (n - 1)

main = print =<< stToIO . mainLoop 0 . read . head =<< getArgs
}}}

If we look at the core for whileLoop's worker, we see:

{{{
$wpoly_go_r1aE :: forall s_aem.
                  Int# -> Int# -> STRep s_aem Int

$wpoly_go_r1aE =
  \ (@ s_aem)
    (ww_s18Y :: Int#)
    (ww1_s192 :: Int#)
    (eta_s19w :: State# s_aem) ->
    case ww1_s192 of wild_XF {
      __DEFAULT ->
        $wpoly_go_r1aE @ s_aem (+# ww_s18Y 1) (-# wild_XF 1) eta_s19w;
      0 -> (# eta_s19w, I# ww_s18Y #)
    }
}}}

Note, the return type is a boxed Int. The function is only used once, like so:

{{{
    ...
    case $wpoly_go_r1aE @ s_aem 0 40 w_s19f of wild_aFw { (# new_s_aFB, r_aFC #) ->
    case r_aFC of wild1_aG9 { I# y_aGb ->
    case <=# ww_s199 y_aGb of wild2_aGd {
      False ->
    ...
}}}

In other words, go boxes its results at the end of the loop, and the function that uses it immediately looks inside the box for the value. In this particular micro-benchmark, the boxed value (wild1_aG9 above) is actually used in the case where mainLoop returns the boxed value. However, in the larger benchmark I pulled this from, that is not the case in several areas (only the unboxed value is used, but it still goes through a box). Either way, the boxed value is only used at the end of the loop (and not every time there), and on every other iteration, this results in superfluous allocation.

I'll attach a manually unboxed version I wrote (it also has iter and max manually inlined to mainLoop, since that makes it easier to write; the core for the above shows that they are getting inlined properly, so I assume that isn't the issue). Using +RTS -sstderr shows that (running 100 million iterations here), the manually unboxed version allocates 50 kilobytes on the heap, and runs in around 15 seconds, whereas the version above that doesn't get unboxed does 1.6 gigabytes of heap allocation, and takes 18 seconds (in the larger benchmark, such extra boxing would happen perhaps 40 million times over the course of the program).

Thanks for your help."	dolio
4	5316	Orphan instances strike again: ghc rejects a program at first but will accept it if you repeat the same compilation command	Compiler	7.0.4	low		_|_		new	2011-07-11T13:24:10-0700	2011-07-26T09:48:55-0700	"Consider these two modules (boiled down example from the checkers package):

{{{
{-# LANGUAGE ScopedTypeVariables, FlexibleContexts #-}

module T1

where

import Test.QuickCheck
import Text.Show.Functions ()


f :: forall m a b.  ( Arbitrary (a->b) ) => m (a,b) -> Property
f = const $ property (undefined :: (a->b) -> Bool)
}}}

{{{
module T2  where

import Control.Concurrent

g = threadDelay maxBound
}}}

I see the following interaction:

{{{
$ rm *hi *.o
$ ghc --make -c -O  T1 T2
[1 of 2] Compiling T2               ( T2.hs, T2.o )
[2 of 2] Compiling T1               ( T1.hs, T1.o )

T1.hs:12:13:
    Overlapping instances for Show (a -> b)
      arising from a use of `property'
    Matching instances:
      instance Show (a -> b) -- Defined in Text.Show.Functions
      instance Show base:System.Event.Manager.IOCallback
        -- Defined in base:System.Event.Manager
    (The choice depends on the instantiation of `a, b'
     To pick the first instance above, use -XIncoherentInstances
     when compiling the other instance declarations)
    In the second argument of `($)', namely
      `property (undefined :: (a -> b) -> Bool)'
    In the expression: const $ property (undefined :: (a -> b) -> Bool)
    In an equation for `f':
        f = const $ property (undefined :: (a -> b) -> Bool)
$ ghc --make -c -O  T1 T2
[2 of 2] Compiling T1               ( T1.hs, T1.o )
$ ghc --make -c -O  T1 T2
$ ls
T1.hi T1.hs T1.o  T2.hi T2.hs T2.o
}}}

I see this consistent behaviour in versions 7.0.{1,2,3,4} but not with 6.12.1
"	jcpetruzza
2	5019	OS X: ld: warning: could not create compact unwind for _ffi_call_unix64	Compiler	7.1	high		7.8.1		new	2011-03-12T17:37:36-0800	2012-11-17T07:49:45-0800	"The OS X 10.6 linker now defaults to creating compact unwinds, which is a good thing, however the unwind info for `_ffi_call_unix64` can't be represented in the compact format. This warning is issued any time ghc links, and many tests in the test suite fail due to the extra output:

{{{
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame
}}}

Possible solutions:
 * suppress the warning in ld; unfortunately this does not seem to be possible, since the only applicable option is `-warn_compact_unwind` which enables the already enabled-by-default warnings
 * suppress the warning in ghc; I haven't really looked into this, but one could filter the text output from the linker to remove the warning
 * entirely disable compact unwinds using `-no_compact_unwind`; this flag is undocumented, so I'm not certain about what it really does
 * patch `_ffi_call_unix64` in libffi to make it compatible with compact unwinds

Info about compact unwinds in OS X 10.6 is somewhat scarce, but `man unwinddump` has a bit:
{{{
When a C++ (or x86_64 Objective-C) exception is thrown, the runtime must unwind the
stack looking for some function to catch the exception.  Traditionally, the unwind
information is stored in the __TEXT/__eh_frame section of each executable as Dwarf
CFI (call frame information).  Beginning in Mac OS X 10.6, the unwind information is
also encoded in the __TEXT/__unwind_info section using a two-level lookup table of
compact unwind encodings.

The unwinddump tool displays the content of the __TEXT/__unwind_info section.
}}}

Relevant discussions:

[http://groups.google.com/group/llvm-dev/browse_thread/thread/8baba4531a9feb07/139c9eba3525ebe]
[http://groups.google.com/group/darwin-dev/browse_thread/thread/962f74bde0efaae4/cfb63dfb3ac34ce1]
"	altaic
5	3470	OSX installer should give an informative error message when XCode is missing	Build System	6.10.4	lowest	normal	7.6.2		new	2009-08-28T14:52:41-0700	2012-09-12T04:14:11-0700	"A bug was reported on the haskell-platform trac about this: when Xcode is not installed, the OSX installer shows a blank screen with a greyed-out ""Install"" button. An informative message should be displayed instead.

More details (incl. screenshots) here:

http://trac.haskell.org/haskell-platform/ticket/67"	GregoryCollins
5	3107	Over-eager GC when blocked on a signal in the non-threaded runtime	Runtime System	6.10.1	lowest	normal	7.6.2		new	2009-03-17T09:47:20-0700	2012-09-12T04:14:08-0700	"Right now, in the non-threaded runtime, if you have the situation where all the threads are blocked on MVars, the deadlock detection / avoidance code runs a GC. This is fine, generally, but if they're blocked on MVars held by signal handlers, it has a profoundly bad effect on performance. In short, the runtime starts collection (blocking signals?), and we're stuck waiting for it to finish before handling signals. Or, if the signal doesn't come in, we sit waiting in a loop, garbage collecting.

It would be nice if the runtime either didn't trigger collection if signal handlers are in place, or, at the very least, held off on doing so for a nontrivial period of time."	awick
4	3184	package.conf should be under /var, not /usr	Package system	6.10.2	low	normal	7.6.2		new	2009-04-21T11:16:43-0700	2012-09-12T04:12:16-0700	"fhs-2.3 says:
{{{
/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between various
FHS-compliant hosts and must not be written to. Any information that is
host-specific or varies with time is stored elsewhere.
}}}
`package.conf` is not shareable, as different machines may have different packages installed, so we should put it under /var instead.
"	igloo
2	7814	panic in PPC NCG	Compiler	7.7	high		7.8.1	heisenbug	new	2013-04-05T04:44:01-0700	2013-05-10T13:25:03-0700	"I get panics in the NCG PPC register allocator while compiling these files:
{{{
  rts_dist_HC rts/dist/build/StgStdThunks.dyn_o
  rts_dist_HC rts/dist/build/StgStdThunks.thr_dyn_o
  rts_dist_HC rts/dist/build/StgStdThunks.l_dyn_o
  rts_dist_HC rts/dist/build/StgStdThunks.thr_l_dyn_o
  HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Classes.o
  HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/CString.o
  HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o
}}}
The panic message is like this:
{{{
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20130405 for powerpc-montavista-linux):
        allocateRegsAndSpill: Cannot read from uninitialized register
    %vI_nff

}}}

This makes the bootstapping of PPC cross compiler, ehm, delicate.

There is a comment in compiler/nativeGen/RegAlloc/Linear/Main.hs:756
{{{
                Nothing | reading   ->
                   pprPanic ""allocateRegsAndSpill: Cannot read from uninitialized register"" (ppr r)
                   -- NOTE: if the input to the NCG contains some
                   -- unreachable blocks with junk code, this panic
                   -- might be triggered.  Make sure you only feed
                   -- sensible code into the NCG.  In CmmPipeline we
                   -- call removeUnreachableBlocks at the end for this
                   -- reason.
}}}
So we have a 'junk code' issue here.

Any hints how I can debug this?"	heisenbug
3	5844	Panic on generating Core code	External Core	7.4.1	normal		7.6.2		new	2012-02-04T16:29:32-0800	2012-09-12T04:12:10-0700	"STEPS TO REPRODUCE

1. Create the file ""Panic.hs"" with the contents:

{{{
module Main where
main = print 1
}}}

2. Compile with ""ghc -fext-core Panic.hs""


EXPECTED BEHAVIOR

Generation of the Core file ""Panic.hcr"".


ACTUAL BEHAVIOR

{{{
$ ghc -fext-core Panic.hs
[1 of 1] Compiling Main             ( Panic.hs, Panic.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for x86_64-unknown-linux):
	MkExternalCore died: make_lit

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

$
}}}

As it states, I am using GHC version 7.4.1 for x86_64 Linux, on an x86-64 Linux box running Ubuntu 11.10 an Linux kernel 3.0.0-14-generic."	JamesFisher
1	7540	Panic on type inference with vectorised parallel arrays	Compiler	7.6.1	highest		7.8.1	chak	new	2013-01-01T05:05:33-0800	2013-01-01T10:45:14-0800	"{{{
#!hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE ParallelArrays #-}
module Y where

import Data.Array.Parallel

#ifndef BUG
func :: Bool -> [: [: a :] :]
#endif
func True = [: [: :] :]
func False = [: j | j <- func True :]
}}}

Result of `ghc --make -fvectorise Y.hs`:
{{{
[1 of 1] Compiling Y                ( C:\tmp\Y.hs, C:\tmp\Y.o )
exprType TYPE [:a{tv b} [tv]:]
exprType TYPE a{tv b} [tv]
exprType TYPE [:a{tv b} [tv]:]
exprType TYPE a{tv b} [tv]
exprType TYPE [:a{tv b} [tv]:]
exprType TYPE a{tv b} [tv]
exprType TYPE [:a{tv b} [tv]:]
exprType TYPE a{tv b} [tv]
Warning: vectorisation failure: identityConv: quantified type changes under vectorisation
  Could NOT call vectorised from original version Y.func
}}}

Result of `ghc --make -fvectorise -DBUG Y.hs`:
{{{
[1 of 1] Compiling Y                ( C:\tmp\Y.hs, C:\tmp\Y.o )
exprType TYPE [:t{tv a30W} [tv]:]
exprType TYPE t{tv a30W} [tv]
exprType TYPE [:t{tv a30W} [tv]:]
exprType TYPE t{tv a30W} [tv]
exprType TYPE [:t{tv a30W} [tv]:]
exprType TYPE t{tv a30W} [tv]
exprType TYPE [:t{tv a30W} [tv]:]
exprType TYPE t{tv a30W} [tv]
Warning: vectorisation failure: identityConv: quantified type changes under vectorisation
  Could NOT call vectorised from original version func
exprType TYPE t{tv a30W} [tv]
Warning: vectorisation failure: identityConv: quantified type changes under vectorisation
  Could NOT call vectorised from original version Y.func
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.1 for x86_64-unknown-mingw32):
        nameModule func1{v r3ap}

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}

And so I did."	tinctorius
3	7078	Panic using mixing list with parallel arrays incorrectly	Compiler	7.4.1	normal		7.8.1	chak	new	2012-07-16T00:48:55-0700	2012-10-14T10:41:05-0700	"{{{
ghc: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for i386-unknown-linux):
	DsMonad: uninitialised ds_parr_bi

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}"	NeilJ
3	7713	Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core	External Core	7.6.2	normal		7.8.1		new	2013-02-23T00:04:17-0800	2013-04-16T08:51:50-0700	"An attempt to compile the attached file with 7.6.2 (and 7.4.2) with ""-O2 -fext-core"" leads to:
{{{
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.2 for x86_64-unknown-linux):
    make_exp (App _ (Coercion _))
}}}
"	EduardSergeev
3	7380	Panic: mkNoTick: Breakpoint loading modules with -O2 via API	GHC API	7.4.1	normal		7.8.1		new	2012-11-01T02:37:33-0700	2012-11-05T08:35:13-0800	"I load a trivial module via the API. I get a panic:
GHCBugs.exe: GHCBugs.exe: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for i386-unknown-mingw32):
	mkNoTick: Breakpoint

If I pass -O2 in the options. Without -O2 the module loads.

I attach the source code using the API to the ticket. The module I try to load just says:
module Main where

main::IO()
main = print ""Hello Fay"""	JeanPhilippeMoresmau
3	7736	Parallel array enumeration causes compiler panic (enumFromToP)	Compiler	7.7	normal		7.8.1	chak	new	2013-03-03T16:16:31-0800	2013-04-13T05:39:38-0700	"Enumeration doesn't work in parallel array comprehensions:

{{{
nums = [: 0 .. 100 :]
}}}

causes a compiler panic. Interestingly, the panic seems to happen before typechecking because if we add some nonsense:

{{{
other = 5 / ""bad""
nums = [: 0 .. 100 :]
}}}

it still panics.
"	amosrobinson
4	6034	Parse error when using ' with promoted kinds	Compiler (Parser)	7.5	low		_|_		new	2012-04-23T08:48:30-0700	2012-04-23T09:32:39-0700	"The following code generates a parse error:

{{{
{-# LANGUAGE DataKinds #-}

data Proxy a = Proxy
foo :: Proxy '['[True, False],'[False]]
foo = Proxy
}}}

The problem is that the {{{'['}}} prefix to the type index is parsed as a character. Rewriting that string as {{{'[ '}}} fixes the problem.

This is admittedly a very low priority problem, but it seemed to be enough of an infelicity to be worth reporting.

This was tested on 7.5.20120420."	goldfire
2	7807	"Parse error with ""where"" and file-ending comment"	Compiler (Parser)	7.7	high		7.8.1		new	2013-04-02T08:02:04-0700	2013-04-13T08:16:35-0700	"Consider the following file:

{{{
{-# LANGUAGE TypeFamilies #-}

type family F a
type instance where
  F Int = Bool

{-

-}
}}}

If there is a file-ending newline, after the comment, the file parses. If there is not a file-ending newline, I get a parse error.

I wrote the code dealing with {{{type instance where}}} notation, but this seems more related to parsing issues (which I know little about) than {{{type instance where}}}. Please correct me if I'm wrong."	goldfire
3	4043	Parsing of guards, and type signatures	Compiler (Parser)	6.12.2	normal		_|_		new	2010-05-04T04:47:35-0700	2010-07-31T12:02:57-0700	"According to the report, this:
{{{
foo
 | True :: Bool
    = 'a'
}}}
shouldn't be accepted, but GHC accepts it.

Discussion here: http://www.haskell.org/pipermail/haskell-prime/2010-May/003183.html
"	igloo
4	3766	Parsing of lambdas is not consistent with Haskell'98 report.	Compiler (Parser)	6.10.4	low		7.6.2		new	2009-12-16T08:05:09-0800	2012-09-12T04:12:20-0700	"Consider the following expression:

{{{  (\x -> x :: Int . id)}}}

GHC (without any -X flags) currently reports a parse error:

    Illegal operator `.' in type `Int . id'[[br]]      Use -XTypeOperators to allow operators in types

However, I think this expression is legal in Haskell'98 (and indeed still legal in Haskell 2010). The report gives an (ambiguous) expression grammar, which (unambiguously) parses the above as (\x -> (x :: Int)) . id. The report further says that lambdas extend as far as possible to the right, but the parse which GHC is using is not a possible parse according to the grammar, since infix operators (other than ""->"") are not allowed in the construction 'type'.

That said, I'd much rather see this fixed in the Haskell 2011 report than in GHC :)"	lilac
2	7481	Partially promoted data types	Compiler	7.6.1	high		7.8.1		new	2012-12-05T03:29:39-0800	2012-12-05T07:26:48-0800	"Consider
{{{
{-# LANGUAGE DataKinds, PolyKinds #-}

data D a where
  D1 :: a -> D a
  D2 :: (a~Int) => D a
  D3 :: forall (a:k). Proxy a -> D b

}}}
Is `D` a promoted type? 

Well, `D1` is promotable, but `D2` is not because of constraints in its type, and neither is `D3` because it uses kind polymorphism.  It's a bit odd to promote only one of the three constructors, but that is what happens right now.

We should probably check for promotability of all data constructors, and promote all or none.  A bit of fiddling around is need to do this, so I'm opening a ticket.  It's not terribly pressing.
"	simonpj
4	5062	Patch: Debug output for OS X linker and coding standard upgrades	Runtime System	7.0.3	low		7.6.2		new	2011-03-29T10:20:56-0700	2012-09-12T04:13:26-0700	"This ticket is to track this patch:
{{{
Mon Mar 21 17:02:34 EDT 2011  gwright at antiope.com
  * Debug output for OS X linker and coding standard upgrades
  
  This long an invasive patch tidies up the OS X linker and
  adds copious debugging output.  If ghci is invoked with +RTS -Dl -RTS,
  the result of every relocation and external symbol lookup is
  dumped in gory detail.  The resulting output is long, more than
  60 MB when starting ghci, even if no programs or packages are
  specified, but is very useful when hunting linker bugs.
  
  The coding standard changes are mostly to impose uniform whitespace
  convertions and to use curly braces even for one line if/else statement
  bodies.  I've been burned by lack of those a few times.
}}}

http://www.haskell.org/pipermail/cvs-ghc/2011-March/060538.html
"	igloo
3	7437	peculiar behaviour with default instances and type variables	Compiler	7.6.1	normal		7.8.1	simonpj	new	2012-11-21T16:15:09-0800	2013-04-12T12:39:08-0700	"Here is a small module that has perplexing behaviour under GHC 7.6.1.

In its current form, it compiles and behaves correctly.

There are two lines commented out in the module.

Uncomment the first type signature for ""default put"", comment out the second one, and recompile. You'll get an ""ambiguous constraint"" error.

Now uncomment the {{{FlexibleInstances}}} pragma. The error changes to ""no instance for (Put a0)"", and moves to the bottom of the file.

I encountered this problem earlier today, in a module (in the binary package) that had {{{FlexibleInstances}}} and a default signature where the name of the type variable did not match the name of the class's type variable.

In that module, I did not have an instance like the one at the bottom of the file, so the module compiled cleanly and without error.

It was not until I tried to compile the module that depended on it that the error occurred. It took me three hours of poking around at random before I accidentally figured out what was wrong.

It would be very helpful if GHC either accepted default signatures with non-matching type variables (which seems correct to me) or rejected them, but did one or the other consistently. Finding a mysterious type error in a downstream module because of a very hard-to-spot error in an upstream module turned out to be extremely difficult.

{{{
{-# LANGUAGE DefaultSignatures, FlexibleContexts, DeriveGeneric #-}
-- {-# LANGUAGE FlexibleInstances #-}

module Whee where

import GHC.Generics

class GPut f where
    gput :: f a -> [()]

class Put a where
    put :: a -> [()]

    -- default put :: (Generic t, GPut (Rep t)) => t -> [()]
    default put :: (Generic a, GPut (Rep a)) => a -> [()]
    put = gput . from

instance GPut U1 where
    gput U1 = []

instance GPut a => GPut (M1 i c a) where
    gput = gput . unM1

data Foo = Foo
         deriving (Generic)

instance Put Foo
}}}"	bos
2	5954	Performance regression 7.0 -> 7.2 (still in 7.4)	Compiler	7.4.1	high		7.6.2	simonpj	new	2012-03-20T04:51:11-0700	2012-10-07T18:24:33-0700	"The program in `nofib/parallel/blackscholes` regressed quite badly in performance between 7.0.x and 7.2.1.  This is just sequential performance, no parallelism.

With 7.0:

{{{
   3,084,786,008 bytes allocated in the heap
       5,150,592 bytes copied during GC
      33,741,048 bytes maximum residency (7 sample(s))
       1,541,904 bytes maximum slop
              64 MB total memory in use (2 MB lost due to fragmentation)

  Generation 0:  5760 collections,     0 parallel,  0.08s,  0.08s elapsed
  Generation 1:     7 collections,     0 parallel,  0.01s,  0.01s elapsed

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time   17.43s  ( 17.47s elapsed)
  GC    time    0.09s  (  0.09s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time   17.53s  ( 17.56s elapsed)
}}}

With 7.2.2:

{{{
   3,062,127,752 bytes allocated in the heap
       4,714,784 bytes copied during GC
      34,370,232 bytes maximum residency (7 sample(s))
       1,553,968 bytes maximum slop
              64 MB total memory in use (2 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      5781 colls,     0 par    0.08s    0.08s     0.0000s    0.0006s
  Gen  1         7 colls,     0 par    0.01s    0.01s     0.0014s    0.0017s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   23.93s  ( 23.93s elapsed)
  GC      time    0.09s  (  0.09s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time   24.02s  ( 24.03s elapsed)
}}}

and with 7.4.1:

{{{
   3,061,924,144 bytes allocated in the heap
       4,733,760 bytes copied during GC
      34,210,896 bytes maximum residency (7 sample(s))
       1,552,640 bytes maximum slop
              64 MB total memory in use (2 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      5781 colls,     0 par    0.08s    0.08s     0.0000s    0.0007s
  Gen  1         7 colls,     0 par    0.01s    0.01s     0.0015s    0.0017s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   23.90s  ( 23.91s elapsed)
  GC      time    0.09s  (  0.09s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time   24.00s  ( 24.00s elapsed)
}}}
"	simonmar
2	6166	Performance regression in mwc-random since 7.0.x	Compiler	7.4.2	high		7.6.2		new	2012-06-15T16:25:16-0700	2012-09-12T04:11:55-0700	"I've had a report that the performance of the mwc-random package has regressed seriously after upgrading from GHC 7.0 to 7.4. It turns out that 7.2 also has the regression.

Here's a sample program.

{{{
import qualified Data.Vector.Unboxed as U

import qualified System.Random.MWC as R
import System.Random.MWC.Distributions (standard)

count = 1000 * 1000

fast gen = standard gen

slow gen = standard gen >>= return

-- Edit this to choose fast or slow.
which gen = slow gen

main = do
  gen <- R.create
  v <- U.replicateM count (which gen)
  print (U.last v)
}}} 

With GHC 7.0.3 -O2, this runs in 0.294 sec, regardless of whether `fast` or `slow` is used.

Under 7.4, `fast` runs in 0.062 sec (a nice speedup!), but `slow` now takes 9.2 sec (yikes!).

Roman suggested compiling the `slow` version with `-fno-state-hack`, which brings performance back up to 0.062 sec."	bos
3	3231	Permission denied error with runProcess/openFile	libraries/base	6.10.4	normal	normal	7.6.2	simonmar	new	2009-05-15T03:07:55-0700	2012-09-12T04:11:58-0700	"Given this program:

{{{
module Main() where

import Control.Concurrent
import System.IO
import System.Process

main = do
    hSetBuffering stdout NoBuffering
    forkIO $ f ""foo1.txt""
    forkIO $ f ""foo2.txt""
    threadDelay $ 100*1000000
    putStrLn ""Finished successfully""

f file = do
    h <- openFile file AppendMode
    hPutStrLn h ""fakdjsklj""
    putChar '.'
    pid <- runProcess ""sh"" [""-c"",""sleep 0.1s""] Nothing Nothing Nothing (Just h) (Just h)
    waitForProcess pid
    f file
}}}

Running under Cygwin, in GHC 6.10.2, I get:

{{{
$ runhaskell Test.hs
..Test.hs: foo1.txt: openFile: permission denied (Permission denied)
}}}

It shouldn't - the {{{openFile}}} calls should always succeed. This bug is a reduced test case from a real system, which I papered over with:

{{{
retryIO :: IO a -> IO a
retryIO act = catchIO act $ \x -> do
    threadDelay $ 1 * 1000000 -- 1 second
    performGC
    act
}}}

Now calling {{{retryIO $ openFile ...}}} works reliably. These problems are occurring sufficiently often that {{{retryIO}}} is about to go in to our standard library :-)

This may be related to #2924, but has the advantage of replicating easily."	NeilMitchell
3	7916	PolyKinds without type signatures	Compiler (Type checker)	7.7	normal				new	2013-05-16T10:30:35-0700	2013-05-17T09:30:00-0700	"Consider

{{{
{-# LANGUAGE PolyKinds, ExplicitForAll #-}
f :: forall (m :: k -> *) (a :: k). m a -> m a
f = id

g = f
}}}

I would expect GHC to infer the same type for `g` as for `f`. However, it gives the AnyK kind, and `g` is not possible to use:

{{{
ghci -Wall X.hs

...

X.hs:5:1: Warning:
    Top-level binding with no type signature:
      g :: forall (m :: AnyK -> *) (a :: AnyK). m a -> m a
Ok, modules loaded: Main.
*Main> g ""a""

<interactive>:2:1:
    Kind incompatibility when matching types:
      a0 :: AnyK
      Char :: *
    In the first argument of ‛print’, namely ‛it’
    In a stmt of an interactive GHCi command: print it
}}}"	monoidal
4	5326	Polymorphic instances aren't automatically specialised	Compiler	7.0.3	low		7.6.2	simonpj	new	2011-07-15T00:47:42-0700	2012-09-12T04:13:32-0700	"Related to #255. Given (roughly) the example from that ticket:

{{{
f :: (Storable a, Eq a) => T a

g :: T (Ptr a)
g = f
}}}
we find that g is not specialised. Adding a SPECIALISE pragma fixes this, but it ought not to be necessary.

The following module is a complete example:

{{{
module C where

class C a where f :: a -> a

newtype Id a = Id a
instance C (Id a) where f = id

g :: C a => Int -> a -> a
g 0 a = a
g n a = g (n-1) (f a)

h :: Int -> Id a -> Id a
h = g

j :: Int -> Id Int -> Id Int
j = g
}}}

We find that h passes a dictionary to g:

{{{
C.h =
  \ (@ a_alq) (w_smq :: Int) (w1_smu :: C.Id a_alq) ->
    case w_smq of _ { I# ww_sms ->
    C.$wg @ (C.Id a_alq) (C.$fCId @ a_alq) ww_sms w1_smu
    }
}}}

whereas j is specialised as desired, getting its own worker and no dictionaries:

{{{
C.j =
  \ (w_smg :: Int) (w1_smk :: C.Id Int) ->
    case w_smg of _ { I# ww_smi ->
    (C.$wj ww_smi w1_smk)
    `cast` (sym (C.NTCo:Id Int)
            :: Int ~ C.Id Int)
    }
}}}

If we add

{{{
{-# SPECIALISE g :: Int -> Id a -> Id a #-}
}}}

then h is specialised as desired."	reinerp
4	4288	Poor -fspec-constr-count=n warning messages	Compiler	6.13	low		7.6.2		new	2010-09-04T06:27:14-0700	2012-09-12T04:12:29-0700	"The attached file, compiled with
{{{
ghc -O2 -fspec-constr-count=5 -c q.hs
}}}
gives a number of messages like
{{{
SpecConstr
    Function `$j_X1BO{v} [lid]'
      has one call pattern, but the limit is 0
    Use -fspec-constr-count=n to set the bound
    Use -dppr-debug to see specialisations
SpecConstr
    Function `$j_X1BR{v} [lid]'
      has two call patterns, but the limit is 1
    Use -fspec-constr-count=n to set the bound
    Use -dppr-debug to see specialisations
}}}
Note that the limit doesn't match the `spec-constr-count` we set.

The ""limit"" given is `sc_count`, but `decreaseSpecCount` changes `sc_count` from its default of `specConstrCount dflags`. However, if this was fixed then we would get even stranger messages like
{{{
      has two call patterns, but the limit is 5
}}}
"	igloo
2	3472	Porting through .hc files broken	Build System	6.12.1 RC1	high	normal	7.8.1		new	2009-08-28T22:49:31-0700	2012-09-12T03:30:53-0700	"I've been trying repeatedly over the past week or two to get an x86_64 build of GHC for OS X, by going through the procedure described at [http://hackage.haskell.org/trac/ghc/wiki/Building/Porting]. 

I've encountered several problems, and the process is huge and daunting so it's hard to say exactly what's a real error and what causes the breakage, but I'll try to describe what I've seen so far.

I've been treating the x86_64 unregistered build as a .hc port, so I effectively partitioned my box into two machines, one with a gcc that compiles to i386 by default and the other with one for x86_64. I follow the instructions on the page above and first generate the headers describing the 64-bit machine with the 64-bit compiler, then I copy them into another ghc tree, switch the gcc to i386 default, and do a build that keeps its .hc files. Most of it goes fine, and then I start getting massive errors about the assembly output being incorrect (which should be fine because all I want are the .hc files). So I follow the make -k and ignore the errors (although this is rather nerve-wracking as instructions saying ""just ignore any errors"" seem rather fragile). I then build the tarball with all the .hc files in it and unpack it in the other tree.

Now, I switch the gcc back to default x86_64, and go through the rest of the process described. My first issue is that the FB_ macro is inserting --- BEGIN --- explicitly into my assembly. This feels odd, as I'm doing an unregistered build. It seems that somehow the MINI_INTERPRETER macro and NO_REGS aren't getting defined, so the pre-mangler stuff is getting inserted into my assembly. I add -Ds for those to my build.mk and resume.

This goes smoothly for a while, and then I encounter an error:
{{{
make[1]: *** No rule to make target `rts/dist/build/Apply.o', needed by `rts/dist/build/libHSrts.a'.  Stop.
}}}
I check the rts directory and indeed there is an Apply.hc file in there. So I guess the build system forgot that .hc files produce .o files in the case of the rts. Maybe it's missing a .hc.o rule or something, so I tried to figure out the build system files but wasn't able to convince it to build the .hc files. I then emulated the gcc parameters used for other rts .c and .s files and compiled all the .hc files in the RTS myself. So I resume the make and it seems satisfied until it tries to build the rts in a different way (v, instead of l). Again, I compile all the .hc files by hand, and set the make on its merry way again.

Now I run into my real problem. It goes to build genprimopcode and doesn't know how to do it. I check utils/genprimopcode and indeed there are no .hc files in there. I jump back to my other tree (the one that produced the .hc files) and manually (guessing on the ghc command-line) ask it to produce all the .hc files for me, first calling alex and happy for the grammar. I copy these .hc files over and resume the build. It happily accepts my .hc files, but then when it goes to link genprimopcode, I get a ''massive'' list of missing symbols. These included things like:
{{{
_base_GHCziShow_showSignedInt1_closure
_stg_CAF_BLACKHOLE_info
_integerzmgmp_GHCziIntegerziType_Szh_static_info
}}}
So this seems to imply that it's trying to build an executable for genprimopcode, and it wants the rts (surprise), base, and integer-gmp linked to it. However, the command-line used to link genprimopcode is:
{{{
""gcc"" -o utils/genprimopcode/dist/build/tmp/genprimopcode  -O -m64 -g -O0 -DNO_REGS -DUSE_MINIINTERPRETER            utils/genprimopcode/dist/build/Lexer.o utils/genprimopcode/dist/build/Main.o utils/genprimopcode/dist/build/ParserM.o utils/genprimopcode/dist/build/Parser.o utils/genprimopcode/dist/build/Syntax.o 
}}}
... no linker flags at all, beyond the .o files! I'm not sure how this is supposed to ever link correctly with no rts or libraries. So I take that command-line for gcc and add to it from my 64-bit build tree until I get it to link (it ended up being a massive command-line, so I won't include it here). My built `genprimopcode` seemed to work, and displayed the help message when I ran it, but when I actually piped real primop specs into it, it segfaulted (in iconv, somehow).

I gave up on making my own `genprimopcode`, and under the assumption that it wasn't excessively platform-dependent, I asked someone to give me the various `genprimopcode` from their linux x86_64 platform. This may have been misguided but I don't know enough about the process to know better. Anyway, with these files, it gave up on trying to build `genprimopcode` and went along happily through the build.

In the final linkage step for stage2, producing the final ghc binary, I got another massive linker error. Again, I tinkered with its command-line until I got it to link correctly (lots of strange things missing there too, including the `PrelIOUtils.o` which I had to link in myself for some reason, and something defining `__hscore_long_path_size`, which I wrote a simple c file for). 

So anyway, the resulting ghc, somewhat unsurprisingly, segfaulted immediately (in Data.List.last, for what it's worth). `ghc +RTS --info` did work however, and printed out the expected stuff, so not everything was broken.

So anyway, I'm sorry for this rambling ""bug report"" but I'm not sure what to do, and I've been through the above process (with minor variations and experiments) about 5 times so far, so I'm pretty sure I'm following the instructions correctly."	pumpkin
3	487	powerpc/linux segfaulting binaries	Compiler	6.4.1	normal	normal	_|_		new	2005-11-29T18:35:12-0800	2009-12-18T08:55:33-0800	"(Just so we don't forget) On powerpc/linux both yi and
hmp3 segfault immediately when built the -fvia-C or
-fasm ways, with (in the case of hmp3):

{{{
(gdb) where
#0  0x100529d4 in __stginit_Binary_ ()
#1  0x1046ed78 in StgRun ()
#2  0x104671e0 in hs_add_root ()
#3  0x10467128 in startupHaskell ()
#4  0x10464f18 in main ()
}}}

and in __stginit_Main_() with yi.

They die before any code in Main.main is executed.
Not much other info seems available. Both these
applications are built with the ncurses binding, and
this appears to be the same problem repored to the
lists back in June 05 by J. Bobbio:

http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg07478.html

A test case is attached to that mail.
To reproduce the hmp3 crash:
  $ darcs get --partial
http://www.cse.unsw.edu.au/~dons/code/hmp3

And follow the cabalised build process. Both
applications work on apple/powerpc, interestingly enough.

-- Don"	dons
5	1727	Precedence and associativity rules ignored when mixing infix type and data constructors in a single expression	Compiler (Parser)	6.6.1	lowest	minor	7.6.2		new	2007-09-21T18:18:30-0700	2013-01-26T14:35:16-0800	"The following code:

{{{
infixr 5 `Foo`
infixr 6 `Bar`

data a `Foo` b = a `FOO` a `Bar` b
data a `Bar` b = a `BAR` b
}}}

fails to compile, ignoring the fixity declarations. It should be parsed as a `FOO` (a `Bar` b) but currently the parentheses are required, which misses the point of fixity annotations."	pat@…
4	4101	Primitive constant unfolding	Compiler	6.12.2	low		7.6.2		new	2010-05-28T06:50:50-0700	2013-04-21T10:38:01-0700	"Examining the core generated by ghc with -O2 on a numerical code, I saw things like :
{{{
case GHC.Prim.<## x_aB9 (GHC.Prim.**## 2.0 -1021.0) of _  {...
}}}
This code being executed each time my code performs an addition ! GHC does not seem to unfold the constants right with at least **##. By the way, it should definitely be possible to specify a Double# constant in hexadecimal."	malosh
2	7326	print035(ghci) fails when ghci is dynamic	GHCi	7.6.1	high		7.8.1	igloo	new	2012-10-13T09:36:03-0700	2012-10-13T09:36:03-0700	"`print035(ghci)` fails when ghci is dynamic:
{{{
=====> print035(ghci) 36 of 75 [0, 0, 0]
cd . && HC='/home/ian/ghc/git/ghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/ian/ghc/git/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history  -ignore-dot-ghci   <print035.script >print035.run.stdout 2>print035.run.stderr
Actual stdout output differs from expected:
--- ./print035.stdout   2012-06-06 22:37:21.000000000 +0100
+++ ./print035.run.stdout       2012-10-13 17:34:45.000000000 +0100
@@ -1,5 +1,5 @@
 o1 = (_t1::Unboxed1)
 o2 = (_t2::Unboxed2)
 23
-o1 = Unboxed1 ((#,#) 5 True)
-o2 = Unboxed2 ((#,#) 6 ((#,#) 7 False))
+o1 = (_t3::Unboxed1)
+o2 = (_t4::Unboxed2)
*** unexpected failure for print035(ghci)
}}}
"	igloo
5	1158	Problem with GADTs and explicit type signatures	Compiler	6.6	lowest	normal	_|_	simonpj	new	2007-02-20T04:32:46-0800	2013-01-21T08:50:51-0800	"{{{

{-# OPTIONS_GHC -fglasgow-exts #-}

module Main where

data Exp a where
    Val :: a -> Exp b
    App :: Exp a -> Exp b

instance Show (Exp a) where
    show (Val _) = ""Val""
    show (App _) = ""App""

class LiftToExp a b where
    liftToExp :: a -> Exp b

instance LiftToExp (Exp a) a where
    liftToExp = id

instance Floating a => LiftToExp a b where
    liftToExp v = Val v :: Exp b

{-

Uncommenting the type signature below causes GHCi to fail to load the file:

test.hs:45:14:
    Overlapping instances for LiftToExp a a11
      arising from use of `liftToExp' at test.hs:45:14-24
    Matching instances:
      instance (Floating a) => LiftToExp a b -- Defined at test.hs:19:0
      instance LiftToExp (Exp a) a -- Defined at test.hs:16:0
    (The choice depends on the instantiation of `a, a11'
     Use -fallow-incoherent-instances to use the first choice above)
    In the first argument of `App', namely `(liftToExp x)'
    In the expression: App (liftToExp x)
    In the definition of `test': test x = App (liftToExp x)

However typing :t test at the GHCi prompt gives this exact signature.

Tested with GHC 6.6 (compiler and interpreter) under OS X 10.4.8 on an iMac G5.

-}

--test :: (LiftToExp a a1) => a -> Exp b
test x = App (liftToExp x)

main = putStrLn $ show (test (3.0::Float)::Exp Int)

}}}"	guest
5	2064	problems with duplicate modules	Package system	6.8.2	lowest	normal	7.6.2		new	2008-01-25T07:21:30-0800	2012-09-12T04:13:44-0700	"Hello, I just noticed the following minor issue. I have a cabal file which isn't seen by cabal except for the configuration step and to install the package, which I do as:

{{{
runhaskell Setup.hs -v register --gen-pkg-config=.package-config
ghc-pkg update .package-config --user
}}}

If I duplicate a module in the Exposed-modules list then

1. cabal doesn't complain

2. ghc-pkg doesn't complain

3. ghci gives a very misleading message, e.g.:

{{{
Could not find module `Vector.Sparse':
  it was found in multiple packages: vectro-0.2 vectro-0.2
}}}
"	Frederik
5	3859	Problems with toClockTime on NetBSD	Compiler	6.12.1	lowest		7.6.2		new	2010-02-03T11:07:58-0800	2012-09-12T04:14:14-0700	"http://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:
{{{
Got it: reproducing the crash (tough on such a slow machine where rebuilding 
these things is quite the process, yay me):

<patch author='zooko@zooko.com' date='20090308025039' local_date='Making 
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, 
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = 
""GMT"", ctTZ = 0, ctIsDST = False}

Plugging that into your first requested program:

import System.Time

-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 50 39 0 Sunday 0 ""GMT"" 
0 False

... returns:

t: user error (Time.toClockTime: invalid input)

So..  This suggests to me there are two problems. First, the toClockTime 
function has trouble with certain input.

This fails:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 59 59 1000 Thursday 
280 ""BST"" 3600 True

This succeeds:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 3 0 0 0 Thursday 280 
""BST"" 3600 True

Weird huh?

And then clearly, the second problem appears to be the conversion of the 
datestamp in the following partial log entry:

<patch author='zooko@zooko.com' date='20090308025039' local_date='Making 
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, 
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = 
""GMT"", ctTZ = 0, ctIsDST = False}

(This is with a modified darcs with the printf-equivalent in it.)

This is suspiciously near to the DST switchover. If you need a zdump of my 
current DST timings, I can provide the pre-zic entries.

Is there perhaps a DST switchover assumption in that logic?

Let me know if you'd like me to delve further. Hopefully this is enough to make 
the problem clear to you darcs folks.
}}}

This really needs to be looked at by someone with access to NetBSD (or perhaps some similar OS).
"	igloo
3	7186	problems with typelits  and typenats	Compiler (Type checker)	7.6.1-rc1	normal		7.8.1		new	2012-08-24T09:48:26-0700	2012-10-30T10:38:43-0700	"in this test case
https://gist.github.com/3445419
in this case, the type errors seem to indicate SingI has two parameters,
but the documentation and the error free usage both point to one parameter


likewise in 
https://gist.github.com/3445456
the type checker can't seem to deduce that 1<=2
which should be ""trivial"" :)



"	carter
3	7753	Profiling report broken with foreign exported functions	Profiling	7.6.2	normal		7.8.1		new	2013-03-07T21:46:23-0800	2013-04-13T05:58:32-0700	"Save the following Haskell source as wrapper.hs:

{{{
import Foreign.Ptr
import Control.Monad

main = do
  fptr <- wrap wrapped
  replicateM 100 $ (return$!) =<< dyn fptr 4 

wrapped :: Double -> IO Double
wrapped x = return $ f 10000 x

f :: Int -> Double -> Double
f 0 u = u
f n u = (u / fromIntegral n) * f (n-1) u

foreign import ccall ""wrapper"" wrap :: (Double -> IO Double) -> IO (FunPtr (Double -> IO Double))
foreign import ccall ""dynamic"" dyn :: FunPtr (Double -> IO Double) -> Double -> IO Double
}}}

Then compile and run it with:

{{{
$ ghc -O2 wrapper.hs -fprof-auto -prof
$ ./wrapper +RTS -p
}}}

It generates wrapper.prof (attached). The file contains the following lines:

{{{
 CAF        GHC.IO.Encoding.Iconv    58           0    0.0    0.2     0.0    0.2
  wrapped   Main                     80         100    0.0    1.1     0.0    0.0
   f        Main                     81     1000100  100.0    0.0     0.0    0.0
}}}

I see two problems here, (1) the inherited column is 0 for 'wrapped' and 'f' but this is incorrect, and (2) 'wrapped' and 'f' belongs to the wrong cost center, 'GHC.IO.Encoding.Iconv'."	akio
4	5654	Profiling semantics bug	Profiling	7.2.1	low		7.6.2	simonmar	new	2011-11-23T03:47:52-0800	2013-03-11T12:58:00-0700	"GHC doesn't quite implement the new cost-centre stack semantics correctly. e.g.

{{{
{-# NOINLINE f #-}
f :: Int -> Int
f = {-# SCC f #-} g

{-# NOINLINE g #-}
g :: Int -> Int
g x = {-# SCC g #-} x + 1

main = print (f 3)
}}}

What we want is

{{{
 CAF        Main                    106           0    0.0    0.7     0.0   21.7
  f         Main                    201           1    0.0    0.0     0.0    0.0
  main      Main                    200           1    0.0   20.9     0.0   21.0
   f        Main                    202           0    0.0    0.0     0.0    0.1
    g       Main                    203           1    0.0    0.1     0.0    0.1
}}}

but we get

{{{
 CAF        Main                    106           0    0.0    0.7     0.0   21.6
  f         Main                    201           1    0.0    0.0     0.0    0.0
  main      Main                    200           1    0.0   20.9     0.0   20.9
   g        Main                    202           1    0.0    0.0     0.0    0.0
}}}

The original flat CC profiler used to use `IND_PERM` indirections to handle this kind of thing, but we aren't doing that now."	simonmar
3	6113	Profiling with -p not written if killed with SIGTERM	Profiling	7.4.1	normal		7.6.2		new	2012-05-18T21:43:57-0700	2012-09-12T04:12:14-0700	Just like it says in the title; -p profiling seems to only get written if the binary gets killed with a SIGINT, not QUIT or TERM. Haven't tested the others, but it seems reasonable that -p profiling data should always be written on exit.	Veinor
3	2301	Proper handling of SIGINT/SIGQUIT	libraries/process	6.12.3	normal	normal	7.6.2		new	2008-05-21T04:19:35-0700	2013-01-27T10:55:19-0800	"This guide http://www.cons.org/cracauer/sigint.html suggests a couple things that we should do that we do not currently do.

It comes in two parts.
 1. how we respond to our own calling process when we terminate due to `^C`
 1. how we respond to process that we call terminating due to `^C`

The first part is easier. If we decide that we want to terminate in response to a `^C` signal then it is important that our calling process knows that. We must kill ourselves using `SIGINT` and not just terminate via `exit()` otherwise our calling process must assume that we decided to ignore the `^C`. We should use `killpid(getpid(),SIGINT)`.

Of course we may well want to catch `^C` and do cleanup work by unwinding all exception handlers etc. It is therefore important to distinguish `^C` from other exceptions so that when the `^C` exception propagates to the top level exception handler we have enough information to know to use `killpid(getpid(),SIGINT)` rather than just `exit(1)`. So we should add an `Interrupted` case to the `Exception` type.

How we respond to `^C` while running sub-processes is more subtle. If we are delegating interaction with the user via the controlling terminal then we should also delegate the decision about how to respond to `^C`. Some child processes will also want to take cleanup action on `^C` or ignore it completely (eg ghci) so it is not right for us the parent process to catch `^C` and decide what to do. So where we are delegating the decision we should ignore `^C`.

When we wait for a child process to terminate and discover that it exited due to `SIGINT` then at that moment we should respond in the same way as if we ourselves had received a `^C`. A sensible default might be to send the `Interrupted` exception to every thread in the system, or at least to the main thread. A haskell program can always change the response to `^C` by using `installHandler` (eg for an interactive REPL program like ghci)."	duncan
4	5682	Properly parse kind operators (from promoted type operators)	Compiler	7.3	low		7.6.2	dreixel	new	2011-12-05T11:04:47-0800	2013-04-22T17:48:41-0700	"{{{
% ghci -XPolyKinds -XTypeOperators
GHCi, version 7.3.20111204: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :k (:)

<interactive>:1:2: parse error on input `:'
Prelude> :k '(:)

<interactive>:1:3: parse error on input `:'
Prelude> :k (':)

<interactive>:1:3: parse error on input `:'
Prelude> :k (Int ': '[Bool])
(Int ': '[Bool]) :: [*]
}}}"	lunaris
3	1147	Quadratic behaviour in the compacting GC	Runtime System	6.6	normal	normal	_|_		new	2007-02-14T04:40:39-0800	2013-01-22T08:54:16-0800	"Run the following program under GHCi with `+RTS -c -RTS`:

{{{
module Main where

break2 p (x:xs) = if p x then 
                    ([],x:xs)
                  else
                    let (b1,b2) = break2 p xs
                    in  (x : b1, b2)
break2 p []     = ([],[])

surprise xs = b1 ++ ""\n surprise "" ++ b2
               where
               (b1,b2) = break2 (=='\n') xs

test n = length $ surprise $ [head (show i) | i <-[1..n] ] ++ ""\n the end""

main = print $ test 1000000
}}}

Notice how it hangs.

This is because of the call to `get_threaded_info()` in `thread_PAP_payload()` in the compacting GC.  We have a lot of APs pointing to the same BCO, so the thread gets really long, and needs to be unravelled for every AP.  One partial fix would be to cache the fun's info table in the spare field of an AP during the mark phase; this fixes the problem for APs, but not for PAPs (which don't have a spare field).

Related to this is the `get_threaded_info()` call in `update_fwd_compact()`, which is inefficient, but not quadratic.  It would be nice to fix this too."	simonmar
4	5376	Quotation in System.Process.system for Windows	libraries/process	7.0.4	low		7.6.2		new	2011-08-03T23:58:28-0700	2012-09-12T04:13:32-0700	"Wagnerdm writes: I had a bit of fun recently tracking down quoting issues with the ""`system`"" command in Windows. For the examples below, I'll consistently use ""`Windows> `"" as the beginning of some text sent to the Windows command prompt cmd.exe, and use ""`GHC> `"" as the beginning of some text sent to a ghci session running in cmd.exe with `System.Cmd` imported.

The situation is this: I want to hand off a command line which has both a possibly-quoted command name and a (definitely) quoted argument. For concreteness, let's use ""more"" as the command and ""foo.txt"" as the argument, so that you can follow along at home on your favorite Windows system.
{{{
Windows> echo foo > foo.txt
Windows> ""more"" ""foo.txt""
foo
}}}
All good so far. But:
{{{
GHC> system ""\""more\"" \""foo.txt\""""
'more"" ""foo.txt' is not recognized as an internal or external command, operable program or batch file.
ExitFailure 1
}}}
After some digging, I discovered that system is shipping out to cmd /c, and indeed:
{{{
Windows> cmd /c ""more"" ""foo.txt""
'more"" ""foo.txt' is not recognized as an internal or external command, operable program or batch file.
}}}
I don't know what the *right* fix is. However, after a bit of playing around, I discovered the following:
{{{
Windows> cmd /c """"more"" ""foo.txt""""
foo
GHC> system ""\""\""more\"" \""foo.txt\""\""""
foo
ExitSuccess
}}}
Wrapping commands with an extra pair of double-quotes this way seemed to give behavior matching the bare cmd.exe for all the examples I could think of, even ones I thought it would break. For example:
{{{
GHC> system ""\""more foo.txt\""""
foo
ExitSuccess
}}}
If this turns out to be the right thing to do, it's pretty easy to implement. In the `commandToProcess` function, at `libraries/process/System/Process/Internals.hs:455`, the change is just
{{{
-   return (cmd, translate cmd ++ ""/c "" ++ string)
+   return (cmd, translate cmd ++ ""/c \"""" ++ string ++ ""\"""")
}}}
(And in any case, the examples above should answer this amusing comment, immediately following those lines:
{{{
	-- We don't want to put the cmd into a single
	-- argument, because cmd.exe will not try to split it up.  Instead,
	-- we just tack the command on the end of the cmd.exe command line,
	-- which partly works.  There seem to be some quoting issues, but
	-- I don't have the energy to find+fix them right now (ToDo). --SDM
	-- (later) Now I don't know what the above comment means.  sigh.
}}}
Later, Brandon comments: What that comment means is that how CMD.EXE handles spaces is Windows-version-dependent.  On the other hand, I ''think'' it's mostly consistent between XP and Windows 7 --- and I feel sorry for anyone forced to use an older version. 
"	simonpj
3	427	Random.StdGen slowness	libraries/random		normal	normal	_|_	rrnewton	new	2005-07-27T01:32:05-0700	2013-04-06T13:58:13-0700	"{{{
Two (performance) problems in one:

{-# OPTIONS -fffi #-}
module Main (main) where

import Control.Monad
import Random

foreign import ccall unsafe ""random"" _crandom :: IO Int

randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = do
    n <- _crandom
    return $ min + n `rem` range
    where
        range = max - min + 1

main = replicateM_ (5*10^6) $ do
    x <- randomRIO (0::Int,1000) :: IO Int
    x `seq` return ()
    return ()

First, without the ""seq"" at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
  Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
  Does help in this example, but also changes behaviour
of the library:
  x <- randomRIO undefined
  currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.

Second, even _with_ the ""seq"", replacing ""randomRIO"" by
""randomInt"" speeds the thing up with a factor of about
30. (2 to 3.6, in a ""real world"" university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(
}}}"	remit
3	2280	randomR too slow	libraries/random	6.8.2	normal	normal	_|_	rrnewton	new	2008-05-13T06:00:42-0700	2013-01-27T10:02:55-0800	"randomR is considerably slower than implementing it manually. Maybe I have not re-implemented it precisely, maybe it is just not inlined.

{{{
module Main (main) where

import System.Random (RandomGen(..), randomR, )
import qualified Data.ByteString as B

newtype KnuthRandomGen = KnuthRandomGen Int

{-# INLINE knuthFactor #-}
knuthFactor :: Int
knuthFactor = 40692

{-# INLINE knuthModulus #-}
knuthModulus :: Int
knuthModulus = 2^(31::Int)-249

-- we have to split the 32 bit integer in order to avoid overflow on multiplication
knuthSplit :: Int
knuthSplit = succ $ div knuthModulus knuthFactor

knuthSplitRem :: Int
knuthSplitRem = knuthSplit * knuthFactor - knuthModulus

instance RandomGen KnuthRandomGen where
   {-# INLINE next #-}
   next (KnuthRandomGen s) =
      -- efficient computation of @mod (s*knuthFactor) knuthModulus@ without Integer
      let (sHigh, sLow) = divMod s knuthSplit
      in  (s, KnuthRandomGen $ flip mod knuthModulus $
                   knuthSplitRem*sHigh + knuthFactor*sLow)
   {-# INLINE split #-}
   split (KnuthRandomGen s) =
      (KnuthRandomGen (s*s), KnuthRandomGen (13+s))
   {-# INLINE genRange #-}
   genRange _ = (1, pred knuthModulus)


main :: IO ()
main =
   do 
      -- for comparison: that's very fast
      putStrLn ""constant""
      B.writeFile ""random.out"" $ fst $
          B.unfoldrN 10000000
             (\g0@(KnuthRandomGen s) -> Just (fromIntegral s, g0))
             (KnuthRandomGen 1)

      -- 3 seconds on my machine
      putStrLn ""immediate""
      B.writeFile ""random.out"" $ fst $
          B.unfoldrN 10000000
             (\g0 -> let (w,g1) = next g0
                     in  Just (fromIntegral (mod w 256), g1))
             (KnuthRandomGen 1)

      -- 10 seconds on my machine
      putStrLn ""randomR""
      B.writeFile ""random.out"" $ fst $
          B.unfoldrN 10000000
             (\g0 -> Just (let (w,g1) = randomR (0,255) g0
                           in  (fromIntegral (w::Int), g1)))
             (KnuthRandomGen 1)


{-
ghc -o dist/build/randomtest -O -Wall -package bytestring-0.9.0.5 -ddump-simpl-iterations speedtest/RandomTest.hs
-}
{-
bytestring-0.9.0.1 as shipped with GHC-6.8.2 does not inline Data.ByteString.unfoldrN
-}

}}}

Is this related to Ticket 427?
"	guest
3	7379	rangeTest test fails on Windows	libraries/random	7.6.1	normal		7.8.1		new	2012-10-31T09:02:41-0700	2013-04-12T10:40:49-0700	"The `CWchar` type on Win32 is unsigned:
{{{
Prelude> minBound :: Foreign.C.Types.CWchar
0
Prelude> (-100) :: Foreign.C.Types.CWchar
65436
}}}
This causes the `rangeTest` test to fail:
{{{
CWchar R:  
Stderr:
rangeTest.exe: broke lower bound: 100
}}}

Ryan, could you take a look please?
"	igloo
3	7797	re-enable the defun RULE from a SPECIALISE instance pragma	Compiler	7.6.2	normal		7.8.1		new	2013-03-26T13:59:29-0700	2013-04-13T07:21:42-0700	"As of commit [https://github.com/ghc/ghc/commit/51d89a55c3 51d89a55c3], `SPECIALISE instance` pragmas do not result in a RULE for the dictionary function.

For example, consider this `Eq` instance for `List`.

{{{
module M where

data List a = Nil | Cons a (List a)

instance (Eq a) => Eq (List a) where
    {-# SPECIALISE instance Eq (List Char) #-}
    Nil     == Nil     = True
    (Cons x xs) == (Cons y ys) = x == y && xs == ys
    _xs    == _ys    = False
}}}

With ghc-7.4.2, we get:

{{{
==================== Tidy Core rules ====================
""SPEC $c/="" [ALWAYS]
    forall ($dEq :: GHC.Classes.Eq GHC.Types.Char).
      M.$fEqList_$c/=1 @ GHC.Types.Char $dEq
      = M.$fEqList_$c/=
""SPEC $c=="" [ALWAYS]
    forall ($dEq :: GHC.Classes.Eq GHC.Types.Char).
      M.$fEqList_$c==1 @ GHC.Types.Char $dEq
      = M.$fEqList_$c==
""SPEC M.$fEqList"" [ALWAYS]
    forall ($dEq :: GHC.Classes.Eq GHC.Types.Char).
      M.$fEqList @ GHC.Types.Char $dEq
      = M.$fEqList_$fEqList
}}}

Note the last rule: it specializes the normal defun `M.$fEqList` when applied at type `Char`.

With anything after 7.4.2 -- eg if you download the binary sources for 7.4.2 and make  [https://github.com/ghc/ghc/commit/51d89a55c3#L0L779 the change at line 779] from that commit --- you instead get this:

{{{
==================== Tidy Core rules ====================
""SPEC $c/="" [ALWAYS]
    forall ($dEq :: GHC.Classes.Eq GHC.Types.Char).
      M.$fEqList_$c/=1 @ GHC.Types.Char $dEq
      = M.$fEqList_$c/=
""SPEC $c=="" [ALWAYS]
    forall ($dEq :: GHC.Classes.Eq GHC.Types.Char).
      M.$fEqList_$c==1 @ GHC.Types.Char $dEq
      = M.$fEqList_$c==
}}}

(Actually, after some patch the /= RULE disappears too, but I don't know which/why.)

If the dictionary is used at the relevant type in the same module, the specializer will automatically create the omitted rule. That will not, however, currently happen across module boundaries.

In my contrived example, omitting this defun specialization increases runtime by a factor of 2 at -O1.

{{{
{-# LANGUAGE ExistentialQuantification #-}

module Main where

import M

data Box = forall a. Eq a => Box a a

box = Box (go 10000000) (go 10000000) where
  go :: Int -> List Char
  go 0 = Nil
  go n = Cons 'c' $ go (n - 1)
{-# NOINLINE box #-}

main = print $ case box of
  Box l r -> l == r
}}}

(-O2 squashes the runtime difference; I haven't investigated in detail.)"	nfrisby
3	4451	Re-linking avoidance is too aggressive	Compiler	7.1	normal		7.6.2	simonmar	new	2010-10-29T04:33:19-0700	2012-09-12T04:12:00-0700	"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
3	5797	readRawBufferPtr cannot be interrupted by exception on Windows with -threaded	libraries/base	7.2.2	normal		_|_		new	2012-01-18T03:17:52-0800	2012-01-31T15:45:52-0800	"On Windows, in a program compiled with -threaded, if a thread receives from a Handle created by the network package (e.g. with hGetLine), it cannot be interrupted by an asynchronous exception.

I've traced it down to readRawBufferPtr, which is used by Network.Socket.recv.  Although I haven't tested readRawBufferPtr directly, my test case (attached) tests Network.Socket.recv.

For Windows, base 4.4.1.0 implements it as:

{{{
readRawBufferPtr :: String -> FD -> Ptr Word8 -> Int -> CSize -> IO CInt
readRawBufferPtr loc !fd buf off len
  | threaded  = blockingReadRawBufferPtr loc fd buf off len
  | otherwise = asyncReadRawBufferPtr    loc fd buf off len

...

blockingReadRawBufferPtr :: String -> FD -> Ptr Word8 -> Int -> CSize -> IO CInt
blockingReadRawBufferPtr loc fd buf off len
  = fmap fromIntegral $ throwErrnoIfMinus1Retry loc $
        if fdIsSocket fd
           then c_safe_recv (fdFD fd) (buf `plusPtr` off) len 0
           else c_safe_read (fdFD fd) (buf `plusPtr` off) len

...

-- NOTE: ""safe"" versions of the read/write calls for use by the threaded RTS.
-- These calls may block, but that's ok.

foreign import stdcall safe ""recv""
   c_safe_recv :: CInt -> Ptr Word8 -> CSize -> CInt{-flags-} -> IO CSsize

foreign import stdcall safe ""send""
   c_safe_send :: CInt -> Ptr Word8 -> CSize -> CInt{-flags-} -> IO CSsize
}}}

If I understand correctly, safe foreign calls cannot be interrupted by asynchronous exceptions.

Is this a bug in readRawBufferPtr, or a bug in the network package?  Can a caller expect readRawBufferPtr to be interruptible by an exception?"	joeyadams
3	3676	realToFrac doesn't sanely convert between floating types	libraries (other)	6.12.1	normal		_|_		new	2009-11-18T19:46:40-0800	2011-07-29T16:39:37-0700	"As far as I can tell, the only way to convert between floating types in Haskell is to use realToFrac.  Unfortunately, this function does some insane mangling of values when converting.  Some examples:
{{{
realToFrac (0/0 :: Double) :: Double
  --> -Infinity
realToFrac (-1/0 :: Float) :: Double
  --> -3.402823669209385e38
realToFrac (-0 :: Double) :: CDouble
  --> 0.0
}}}
The last item illustrates an important point:  it is impossible to convert a value from Double to CDouble without potentially changing it.  This makes it difficult or impossible to use the FFI to call any functions with floating point parameters/return values.

Using a combination of unsafeCoerce (to shoehorn Double values in/out of CDoubles) and some functions written in C (to perform float<=>double), I was able to work around these problems, but that hardly seems like a nice solution."	draconx
3	7828	RebindableSyntax and Arrow	Compiler (Type checker)	7.6.2	normal		7.8.1		new	2013-04-10T07:49:38-0700	2013-04-13T08:31:22-0700	"When trying to add constraints to the types of the arrow primitives I get a type error. I think that doing such a thing should be possible and I've attached the code I used to test this. The errors I get when using the arrow notation for the function test are as follows:

{{{
test :: Typeable a => R a a
test = proc n -> returnA -< n
}}}

{{{
bug-arrow.hs:15:8:
    Could not deduce (Typeable c) arising from a use of `arr'
    from the context (Typeable a)
      bound by the type signature for test :: Typeable a => R a a
      at bug-arrow.hs:14:9-27
    Possible fix:
      add (Typeable c) to the context of
        a type expected by the context: (b -> c) -> R b c
        or the type signature for test :: Typeable a => R a a
    In the expression: arr
    When checking that `arr' (needed by a syntactic construct)
      has the required type: forall b1 c1. (b1 -> c1) -> R b1 c1
      arising from a proc expression at bug-arrow.hs:15:8-29
    In the expression: proc n -> returnA -< n

bug-arrow.hs:15:8:
    Could not deduce (Typeable c) arising from a use of `>>>'
    from the context (Typeable a)
      bound by the type signature for test :: Typeable a => R a a
      at bug-arrow.hs:14:9-27
    Possible fix:
      add (Typeable c) to the context of
        a type expected by the context: R a1 b -> R b c -> R a1 c
        or the type signature for test :: Typeable a => R a a
    In the expression: (>>>)
    When checking that `(>>>)' (needed by a syntactic construct)
      has the required type: forall a2 b1 c1.
                             R a2 b1 -> R b1 c1 -> R a2 c1
      arising from a proc expression at bug-arrow.hs:15:8-29
    In the expression: proc n -> returnA -< n

bug-arrow.hs:15:8:
    Could not deduce (Typeable d) arising from a use of `first'
    from the context (Typeable a)
      bound by the type signature for test :: Typeable a => R a a
      at bug-arrow.hs:14:9-27
    Possible fix:
      add (Typeable d) to the context of
        a type expected by the context: R b c -> R (b, d) (c, d)
        or the type signature for test :: Typeable a => R a a
    In the expression: first
    When checking that `first' (needed by a syntactic construct)
      has the required type: forall b1 c1 d1.
                             R b1 c1 -> R (b1, d1) (c1, d1)
      arising from a proc expression at bug-arrow.hs:15:8-29
    In the expression: proc n -> returnA -< n
}}}

When I replace the definition with the translated core code (minus type applications and scoped type variables) the code compiles:

{{{
test :: Typeable a => R a a
test =
    (>>>)
      (arr (\ (n_apd) -> n_apd))
      ((>>>)
         (arr (\ (ds_dst) -> ds_dst))
         (returnA)
         )
}}}
"	AlessandroVermeulen
2	7277	Recompilation check fails for TH unless functions are inlined	Template Haskell	7.4.2	high		7.6.2		new	2012-09-28T07:27:02-0700	2013-03-25T18:22:53-0700	"Even though [http://hackage.haskell.org/trac/ghc/ticket/481 Issue 481] is marked as closed, the fix is only partial. If a function inside $( ... ) is not inlined, then the dependency check fails. Attached is a full example, built around the following code:

{{{
#ifdef NO_INLINE
{-# NOINLINE libraryFunction #-}
#endif

libraryFunction :: Q Exp
libraryFunction = [e| ""Return X"" |]
}}}

And the test:

{{{
case_library_function = $( libraryFunction ) @?= ""Return A""
}}}

Here is are the relevant parts of RUNME.LOG:

{{{
+ rm -rf dist
+ cabal configure --enable-tests
Resolving dependencies...
Configuring dependency-bug-0.0.1...
+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main             ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main             ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Main:
  library function: [Failed]
expected: ""Return A""
 but got: ""Return B""

         Test Cases  Total
 Passed  0           0
 Failed  1           1
 Total   1           1
Test suite Test: FAIL
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
0 of 1 test suites (0 of 1 test cases) passed.

}}}

This is as expected; we changed the source to ""Return B"" but the test expects the library to ""Return A"" so it fails. So far, so good. However:

{{{
+ rm -rf dist
+ cabal configure --enable-tests -fwithout-inline
Resolving dependencies...
Configuring dependency-bug-0.0.1...
+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main             ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package dependency-bug-0.0.1 ... linking ... done.
Loading package filepath-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package old-time-1.1.0.0 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package unix-2.5.1.1 ... linking ... done.
Loading package directory-1.1.0.2 ... linking ... done.
Loading package cpphs-1.14 ... linking ... done.
Loading package haskell-src-exts-1.13.5 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package regex-base-0.93.2 ... linking ... done.
Loading package regex-posix-0.95.2 ... linking ... done.
Loading package language-haskell-extract-0.2.1 ... linking ... done.
Loading package ansi-terminal-0.5.5 ... linking ... done.
Loading package ansi-wl-pprint-0.6.4 ... linking ... done.
Loading package extensible-exceptions-0.1.1.4 ... linking ... done.
Loading package hostname-1.0 ... linking ... done.
Loading package time-1.4 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package text-0.11.2.3 ... linking ... done.
Loading package xml-1.3.12 ... linking ... done.
Loading package test-framework-0.6.1 ... linking ... done.
Loading package test-framework-th-0.2.2 ... linking ... done.
Loading package HUnit-1.2.5.1 ... linking ... done.
Loading package test-framework-hunit-0.2.7 ... linking ... done.
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
}}}

As you can see, without-inline the 2nd build did not recompile the test, even though it should have. It only re-linked the test, so it kept seeing ""Return A"" even though the library actually does ""Return B"".

In my real code, there are no NO/INLINE pragmas; however, the TH code is complex enough that it is not inlined, which causes the same problem. I had to use the pragma to keep the example short."	orenbenkiki
3	7788	Recursive type family causes <<loop>>	Compiler (Type checker)	7.6.2	normal		7.8.1	simonpj	new	2013-03-22T21:18:09-0700	2013-04-13T06:55:00-0700	"This file:

{{{
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}

data Proxy a = Proxy

foo :: Proxy (F (Fix Id)) -> ()
foo = undefined

newtype Fix a = Fix (a (Fix a))
newtype Id a = Id a

type family F a
type instance F (Fix a) = F (a (Fix a))
type instance F (Id a) = F a

main :: IO ()
main = print $ foo Proxy
}}}

Dies with `<<loop>>`. The type family is recursive, of course:

{{{
*Main> :kind! F (Fix Id)
F (Fix Id) :: *^CInterrupted.
}}}

But `<<loop>>` is still not the behavior I'd expect. The actual value is just `undefined`.

In the file that this example came up, the situation was even worse -- there was a situation where

{{{
moldMapOf l f = runAccessor . l (Accessor . f)
main = print $ (flip appEndo [] . moldMapOf (ix 3) (Endo . (:)) $ testVal :: [Int]) -- <<loop>>
main = print $ (flip appEndo [] . runAccessor . (ix 3) (Accessor . Endo . (:)) $ testVal :: [Int]) -- undefined
}}}

I.e. substitution can turn one program (which happens to be ⊥ here, admittedly, but that's not fundamental) into another (`<<loop>>`). This makes it very tricky to track down the recursive type family. If necessary I can hunt down a working test case and post it here -- it's a bit tricky to get working, though."	shachaf
4	4121	Refactor the plumbing of CafInfo to make it more robust	Compiler	6.12.2	low		7.6.2		new	2010-06-07T08:31:17-0700	2012-09-12T04:12:25-0700	"While comping GHC Head using the devel1 flavour and ghc-6.12.2 as the bootstrap compiler, I get the following assertion failure:

{{{
""inplace/bin/ghc-stage1""   -H64m -O -fasm    -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.0 -package rts-1.0  -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O -dcore-lint -fno-warn-deprecated-flags     -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/base/./Control/Applicative.hs -o libraries/base/dist-install/build/Control/Applicative.o

WARNING: file compiler/simplCore/CSE.lhs line 349 a_aup
WARNING: file compiler/simplCore/CSE.lhs line 349 a_aup
WARNING: file compiler/stgSyn/CoreToStg.lhs line 220
Control.Applicative.$fAlternativeSTM
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 6.13 for i386-unknown-linux):
	ASSERT failed! file compiler/stgSyn/CoreToStg.lhs line 187
...blah...
base:Control.Applicative.$fAlternativeSTM{v rk} [gid[DFunId]] =
    [] \u srt:SRT:[] []
        let {
          sat_s1oj{v} [lid] =
              [] \r srt:SRT:[] [eta_B1{v} [lid]] retry#{v} [eta_B1{v} [lid]];
        } in 
          base:Control.Applicative.D:Alternative{d rra} [base:Control.Applicative.$fApplicativeSTM{v r2q} [gid[DFunId]]
                                                         sat_s1oj{v} [lid]
                                                         base:GHC.Conc.orElse1{v re9} [gid]
                                                         base:Control.Applicative.$fAlternativeSTM3{v r2n} [gid]
                                                         base:Control.Applicative.$fAlternativeSTM1{v r2l} [gid]];

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}

This is on the 32bit MSRC machine by the way. On my own laptop running Ubuntu 10.04 I don't get this (bootstrap compiler is 6.12.1 though)."	dterei
2	7574	Register allocator chokes on certain branches with literals	Compiler (NCG)	7.7	high		7.8.1	thoughtpolice	new	2013-01-13T02:25:46-0800	2013-05-04T15:26:08-0700	"
While running the test for #7571 (test is in #7573,) under '''WAY=normal''' instead of '''WAY=llvm''', I encountered this bug in the native backend:

{{{

=====> T7571(normal) 6 of 6 [0, 0, 0]
cd . && '/Users/a/code/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm   -no-hs-main   >T7571.comp.stderr 2>&1
Compile failed (status 256) errors were:
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.7.20130113 for x86_64-apple-darwin):
	allocateRegsAndSpill: Cannot read from uninitialized register
    %vI_c7

}}}

The test in question is:

{{{

#include ""Cmm.h""

testLiteralBranch (W_ dst, W_ src)
{
  if (1) {
    prim %memcpy(dst, src, 1024, 4);
  } else {
    prim %memcpy(dst, src, 512, 8);
  }
  return ();
}

}}}

If you comment out the branch conditionals, the test passes, so clearly something fishy is going on here. The test also fails if you change the condition to ```if (1 == 1)```

I have absolutely no idea how this did not trip the profiling-based build in StgStdThunks.cmm, like in the LLVM build c.f. #7571"	thoughtpolice
3	7063	Register allocators can't handle non-uniform register sets	Compiler (NCG)	7.4.2	normal		7.8.1	benl	new	2012-07-09T05:51:42-0700	2012-12-06T16:43:19-0800	"Neither the linear scan register allocator nor the graph-colouring allocator can properly handle the fact that some registers on x86 have 8 and 16-bit versions and some don't.  We got away with this until now because the only free registers on x86 were `%eax`, `%ecx` and `%edx`, but now we can also treat `%esi` as free when it isn't being used for R1 (see f857f0741515b9ebf186beb38fe64448de355817).  However, `%esi` doesn't have an 8-bit version, so we cannot treat it as allocatable because the register allocator will try to use it when an 8-bit register is needed (see 105754792adac0802a9a59b0df188b58fb53503f).

LLVM doesn't have this problem, so one workaround is to compile with `-fllvm` to get the extra register(s) on x86."	simonmar
3	2489	Registry keys are created in per-user HKCU instead of system-wide HKLM	None	6.8.3	normal	normal	_|_		new	2008-08-05T07:59:37-0700	2009-11-21T04:59:13-0800	"This bug is related to #1515. The installer shouldn't create any keys under HKCU, and should use system-wide HKLM instead.

Now, the registry key is accessible only to the user who installed the GHC. Other users don't have the installation path in the registry, and this breaks all tools which rely on getting the installation path from the registry."	nimnul
2	7679	Regression in -fregs-graph performance	Compiler (NCG)	7.6.2	high		7.8.1		new	2013-02-11T00:22:56-0800	2013-02-12T19:11:32-0800	"Likely due to a bad interaction with the new code generator, see #7192.

`-fregs-graph` used to be on by default with `-O2`, but is currently off due to this issue.

Results courtesy of @tibbe:

{{{
HEAD vs HEAD with -fregs-graph:

--------------------------------------------------------------------------------
        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
           anna          +0.1%     +0.0%      0.08      0.08     +0.0%
           ansi          +0.0%     +0.0%      0.00      0.00     +0.0%
           atom          +0.0%     +0.0%     +0.0%     -0.8%     +0.0%
         awards          -0.0%     +0.0%      0.00      0.00     +0.0%
         banner          -0.0%     +0.0%      0.00      0.00     +0.0%
     bernouilli          +0.0%     +0.0%      0.12      0.12     +0.0%
   binary-trees          +0.0%     +0.0%     +0.0%     +0.0%     +0.0%
          boyer          -0.0%     +0.0%      0.04      0.04     +0.0%
         boyer2          -0.0%     +0.0%      0.01      0.01     +0.0%
           bspt          -0.0%     +0.0%      0.02      0.02     +0.0%
      cacheprof          +0.0%     +0.0%     -3.1%     -3.1%     +0.0%
       calendar          -0.0%     +0.0%      0.00      0.00     +0.0%
       cichelli          +0.0%     +0.0%      0.05      0.05     +3.0%
        circsim          +0.0%     +0.0%     -0.3%     -0.3%     +0.0%
       clausify          -0.0%     +0.0%      0.03      0.03     +0.0%
  comp_lab_zift          -0.0%     +0.0%      0.14      0.14     +0.0%
       compress          +0.0%     +0.0%      0.11      0.11     +0.0%
      compress2          +0.0%     +0.0%      0.14      0.14     +0.0%
    constraints          +0.0%     +0.0%     -1.4%     -1.4%     +0.0%
   cryptarithm1          +0.0%     +0.0%     +1.6%     +1.0%     +0.0%
   cryptarithm2          +0.0%     +0.0%      0.01      0.01     +0.0%
            cse          +0.0%     +0.0%      0.00      0.00     +0.0%
          eliza          -0.0%     +0.0%      0.00      0.00     +0.0%
          event          +0.0%     +0.0%      0.10      0.10     +0.0%
         exp3_8          +0.0%     +0.0%      0.14      0.14     +0.0%
         expert          +0.0%     +0.0%      0.00      0.00     +0.0%
 fannkuch-redux          +0.0%     +0.0%    +10.6%    +10.4%     +0.0%
          fasta          -0.0%     +0.0%     -0.6%     -0.6%     +0.0%
            fem          +0.0%     +0.0%      0.03      0.03     +0.0%
            fft          -0.0%     +0.0%      0.03      0.03     +0.0%
           fft2          +0.0%     +0.0%      0.04      0.04     +0.0%
       fibheaps          -0.0%     +0.0%      0.03      0.03     +0.0%
           fish          +0.0%     +0.0%      0.01      0.01     +0.0%
          fluid          +0.0%     +0.0%      0.01      0.01     +0.0%
         fulsom          +0.1%     +0.0%     -5.9%     -5.9%     -5.3%
         gamteb          +0.0%     +0.0%      0.04      0.04     +0.0%
            gcd          +0.0%     +0.0%      0.03      0.03     +0.0%
    gen_regexps          +0.0%     +0.0%      0.00      0.00     +0.0%
         genfft          +0.0%     +0.0%      0.03      0.03     +0.0%
             gg          +0.0%     +0.0%      0.02      0.02     +0.0%
           grep          +0.1%     +0.0%      0.00      0.00     +0.0%
         hidden          +0.0%     +0.0%     +3.4%     +2.7%     +0.0%
            hpg          +0.0%     +0.0%      0.10      0.10     +0.0%
            ida          -0.0%     +0.0%      0.06      0.06     +0.0%
          infer          +0.0%     +0.0%      0.05      0.05     +0.0%
        integer          -0.0%     +0.0%     +3.0%     +2.9%     +0.0%
      integrate          +0.0%     +0.0%      0.13      0.13     +0.0%
   k-nucleotide          +0.4%     +0.0%     +3.4%     +3.5%     +0.0%
          kahan          +0.0%     +0.0%      0.18      0.18     +0.0%
        knights          -0.1%     +0.0%      0.01      0.01     +0.0%
           lcss          +0.0%     +0.0%     +0.7%     +0.7%     +0.0%
           life          -0.0%     +0.0%      0.16      0.16     +0.0%
           lift          +0.0%     +0.0%      0.00      0.00     +0.0%
      listcompr          -0.0%     +0.0%      0.06      0.06     +0.0%
       listcopy          -0.0%     +0.0%      0.06      0.06     +0.0%
       maillist          -0.0%     +0.0%      0.04      0.04    -11.2%
         mandel          +0.0%     +0.0%      0.05      0.05     +0.0%
        mandel2          -0.0%     +0.0%      0.00      0.00     +0.0%
        minimax          +0.0%     +0.0%      0.00      0.00     +0.0%
        mkhprog          +0.0%     +0.0%      0.00      0.00     +0.0%
     multiplier          -0.0%     +0.0%      0.08      0.08     +0.0%
         n-body          -0.0%     +0.0%    +28.2%    +28.2%     +0.0%
       nucleic2          +0.0%     +0.0%      0.05      0.05     +0.0%
           para          -0.1%     +0.0%     +1.0%     +1.0%     +0.0%
      paraffins          -0.0%     +0.0%      0.08      0.08     +0.0%
         parser          +0.0%     +0.0%      0.03      0.03     +0.0%
        parstof          -0.0%     +0.0%      0.00      0.00     +0.0%
            pic          -0.0%     +0.0%      0.00      0.00     +0.0%
       pidigits          -0.0%     +0.0%     -0.6%     +0.0%     +0.0%
          power          +0.0%     +0.0%     +1.9%     +1.9%     +0.0%
         pretty          +0.0%     +0.0%      0.00      0.00     +0.0%
         primes          -0.0%     +0.0%      0.05      0.05     +0.0%
      primetest          -0.0%     +0.0%      0.07      0.07     +0.0%
         prolog          +0.0%     +0.0%      0.00      0.00     +0.0%
         puzzle          -0.0%     +0.0%      0.10      0.10     +0.0%
         queens          +0.0%     +0.0%      0.02      0.02     +0.0%
        reptile          +0.0%     +0.0%      0.02      0.02     +0.0%
reverse-complem          -0.0%     +0.0%      0.08      0.08     +0.0%
        rewrite          +0.0%     +0.0%      0.02      0.02     +0.0%
           rfib          +0.0%     +0.0%      0.02      0.02     +0.0%
            rsa          +0.0%     +0.0%      0.03      0.03     +0.0%
            scc          -0.0%     +0.0%      0.00      0.00     +0.0%
          sched          -0.0%     +0.0%      0.02      0.02     +0.0%
            scs          -0.0%     +0.0%     -1.1%     -0.5%     +0.0%
         simple          -0.1%     +0.0%      0.16      0.16     +0.0%
          solid          -0.0%     +0.0%      0.10      0.10     +0.0%
        sorting          -0.0%     +0.0%      0.00      0.00     +0.0%
  spectral-norm          -0.0%     +0.0%     +0.0%     +0.0%     +0.0%
         sphere          +0.1%     +0.0%      0.03      0.03     +0.0%
         symalg          -0.0%     +0.0%      0.01      0.01     +0.0%
            tak          +0.0%     +0.0%      0.01      0.01     +0.0%
      transform          -0.0%     +0.0%     +0.0%     +0.0%     +0.0%
       treejoin          +0.0%     +0.0%      0.15      0.15     +0.0%
      typecheck          +0.0%     +0.0%      0.15      0.15     +0.0%
        veritas          +0.1%     +0.0%      0.00      0.00     +0.0%
           wang          +0.0%     +0.0%      0.08      0.08     +0.0%
      wave4main          +0.0%     +0.0%      0.19      0.19     +0.0%
   wheel-sieve1          -0.0%     +0.0%     -0.8%     -0.8%     +0.0%
   wheel-sieve2          -0.0%     +0.0%      0.13      0.13     +0.0%
           x2n1          -0.0%     +0.0%      0.01      0.01     +0.0%
--------------------------------------------------------------------------------
            Min          -0.1%     +0.0%     -5.9%     -5.9%    -11.2%
            Max          +0.4%     +0.0%    +28.2%    +28.2%     +3.0%
 Geometric Mean          +0.0%     -0.0%     +1.7%     +1.7%     -0.1%
}}}

"	simonmar
3	7450	Regression in optimisation time of functions with many patterns (6.12 to 7.4)?	Compiler	7.6.1	normal		7.8.1		new	2012-11-26T03:15:45-0800	2013-04-12T12:56:41-0700	"In our project, we build (via TH) some not-trivial data structures, including custom serialisation. After growing the number of constructors significantly, compiling same code with ghc 7.4/7.6 is about 10 times slower than with ghc 6.12.

Narrowing this down on a simpler test case, it turns out that TH is not the cause, just the optimisation of the generated code.

The attached Generator.hs file generates a simple data structure (our project is using a much smaller number of constructors, but with more complex data types, and the result is the same):

{{{
data F
  = F1 {fldF1 :: Int} |
    F2 {fldF2 :: Int} |
    F3 {fldF3 :: Int} |
    F4 {fldF4 :: Int} |
    F5 {fldF5 :: Int} |
  … deriving (Eq, Show, Read)

prettyF :: F -> String
prettyF (F1 v) = show v
prettyF (F2 v) = show v
…
}}}

The main.hs file just calls this splice and then does a trivial use of prettyF.

Compiling this with a variable number of constructors, with -O:

||Constructors||6.12||7.6||
||50||2.45s||4.10s||
||100||4.40s||10.60s||
||200||8.45s||33.30s||
||400||16.90s||121.00s||
||800||35.95s||514.50s||

As you can see, 6.12 looks liniar in the number of constructors, whereas 7.6 is not anymore (at least above 100 constructors).

Compiling without -O makes things sane again:
||Constructors||6.12||7.6||
||50||1.40s||1.97s||
||100||2.45s||2.70s||
||200||4.50s||4.95s||
||400||8.95s||9.55s||
||800||18.25s||19.10s||

After some more investigation, it turns out that just our function function (prettyF) with no automatic instances is cheap, compiling/deriving Eq/Show is also cheap, but Read is very expensive (all numbers with ghc 7.6):

||Constructors||No instances||Eq||Show||Read||
||50||0.75s||0.90s||1.20s||2.95s||
||100||0.85s||1.00s||1.70s||6.80s||
||200||1.20s||1.45s||2.85s||19.15s||
||400||2.05s||2.50s||5.40s||64.45s||
||800||4.30s||5.40s||11.65s||259.40s||

So I believe this is about optimisation of complex functions with many patterns/case statements. 6.12 seems nicely liniar, whereas 7.4/7.6 exhibit a much worse behaviour.

This might be a known issue, or even a non-issue (""Don't use Read for complex types""), but I thought it's better to report it. I don't have the skills to look at the core result, and see if it's different or not between 6.12/7.6, sorry."	iustin
3	7243	regression: acceptable foreign result types	Compiler (FFI)	7.6.1	normal		7.6.2	igloo	new	2012-09-16T19:55:46-0700	2012-09-18T01:47:50-0700	"The following short file is rejected:

{{{
import Foreign.Ptr
foreign import ccall ""wrapper"" foo :: IO (FunPtr ())
}}}

The error is:

{{{
test.hs:2:1:
    Unacceptable type in foreign declaration: IO (FunPtr ())
    When checking declaration:
      foreign import ccall safe ""wrapper"" foo :: IO (FunPtr ())
}}}

However, my reading of the 2010 Report suggests this should be acceptable. Specifically:

* Prelude.IO t is a marshallable foreign result type when t is a marshallable foreign type,[[BR]]
* all basic foreign types are marshallable foreign types, and[[BR]]
* FunPtr a is a basic foreign type for all a.

(Political note: I include this chain of reasoning not because I think others too stupid to recreate it, but because I think it likely that I am not reading the Report correctly, and want to make it easy to detect and correct any misconceptions I have.)"	dmwit
2	5361	regSpill: out of spill slots!	Compiler	7.1	high		7.8.1		new	2011-07-30T06:48:06-0700	2013-05-10T13:36:06-0700	"{{{
runghc ./Setup.hs build
Building SHA-1.5.0.0...
Preprocessing library SHA-1.5.0.0...
[1 of 1] Compiling Data.Digest.Pure.SHA ( Data/Digest/Pure/SHA.hs, dist/build/Data/Digest/Pure/SHA.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.2.0.20110728 for x86_64-unknown-linux):
	regSpill: out of spill slots!
       regs to spill = 2479
       slots left    = 2040

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
"	markwright
3	1831	reify never provides the declaration of variables	Template Haskell	6.8.1	normal	normal	_|_		new	2007-11-04T14:32:32-0800	2013-01-26T19:59:44-0800	"The information returned by reify when provided a variable Name is

{{{
VarI Name Type (Maybe Dec) Fixity
}}}

The Dec part, due to be nested in Maybe, is clearly optional. In fact, according to Language.Haskell.TH.Syntax:

{{{
-- Nothing for lambda-bound variables, and
-- for anything else TH can't figure out
-- E.g. [| let x = 1 in $(do { d <- reify 'x; .. }) |]
}}}

However, the typechecker (TcSplice module) always returns Nothing. So it's simply not implemented.


I suggest either implementing the feature or removing the Dec part of VarI. Either way, the type should be consistent with the features offered in TH.
"	guest
3	7477	reifyInstances can't deal with polykinded type families	Compiler	7.7	normal		7.8.1		new	2012-12-03T20:02:27-0800	2013-04-12T13:54:31-0700	"When I run the following code

{{{
{-# LANGUAGE DataKinds, KindSignatures, PolyKinds, TypeFamilies, TemplateHaskell #-}

import Language.Haskell.TH

type family F (a :: k)
type instance F Int = Bool

$( do { info <- reifyInstances ''F [ConT ''Int]
      ; reportWarning (pprint info)
      ; return [] })
}}}

I get this error:

{{{
    Wrong number of types (expected 2)
    In the argument of reifyInstances: Main.F GHC.Types.Int
}}}

I assumed that TH wanted me to supply the kind parameter, so I tried this:

{{{
...
$( do { info <- reifyInstances ''F [StarT, ConT ''Int]
...
}}}

I got this response:

{{{
    `F' is applied to too many type arguments
    In the argument of reifyInstances: Main.F * GHC.Types.Int
}}}

I poked around in the code to see what might be causing it. I found a couple of interesting things:

 * {{{reifyInstances}}} uses {{{tyConArity}}} to get the arity of a type family. For my {{{F}}}, {{{tyConArity}}} reported 3. So, I wrote some code to go through the kind and count only non-superkind arguments. This didn't fix the problem, because ...
 * {{{reifyInstances}}} passes control off, through a handful of other functions, to {{{matchExpectedFunKind}}}, which works only with {{{FunTy}}}, not {{{ForAllTy}}}. So, my {{{F}}}, whose kind is headed by {{{ForAllTy}}}, looks like it takes no arguments at all.

I could try to fix this, but I'm worried about upsetting the apple cart here. If a knowledgeable individual could give some pointers about what's safe and what's not safe to change in this code, I'm happy to write the fix.

This was all tested on 7.7.20121130.
"	goldfire
3	5369	Reinstate VECTORISE pragmas with expressions as right-hand sides	Data Parallel Haskell	7.0.4	normal		7.6.2	chak	new	2011-08-02T01:23:47-0700	2012-09-12T04:12:02-0700	"The current vectoriser depends in a very fragile way on the order in which the constraint solver generates constraints.  This ticket is just to track this known problem.

Manifestation:
{{{
*** Vectorisation error ***
    Type mismatch in vectorisation pragma for Data.Array.Parallel.unzipP
        Expected type forall a_a1SF b_a1SG.
                      (Data.Array.Parallel.PArray.PRepr.PA a_a1SF,
                       Data.Array.Parallel.PArray.PRepr.PA b_a1SG) =>
                      Data.Array.Parallel.PArray.Base.PArray (a_a1SF, b_a1SG)
                      Data.Array.Parallel.Lifted.Closure.:-> (Data.Array.Parallel.PArray.Base.PArray
                                                                a_a1SF,
                                                              Data.Array.Parallel.PArray.Base.PArray
                                                                b_a1SG)
        Inferred type forall a_a21g b_a21h.
                      (Data.Array.Parallel.PArray.PRepr.PA b_a21h,
                       Data.Array.Parallel.PArray.PRepr.PA a_a21g) =>
                      Data.Array.Parallel.PArray.Base.PArray (a_a21g, b_a21h)
                      Data.Array.Parallel.Lifted.Closure.:-> (Data.Array.Parallel.PArray.Base.PArray
                                                                a_a21g,
                                                              Data.Array.Parallel.PArray.Base.PArray
                                                                b_a21h)
}}}
Reason: the compilation of VECTORISE pragmas depends on the order of constraints in an inferred type.  This isn't trivial to fix.  As Manuel writes, the problem here is that we do not know what wrapper w we need *until* the vectoriser runs.  Why is that?  Given
{{{
  f :: ty
  f = e
  {-# VECTORISE f = e_v #-}
}}}
where the type *inferred* for `e_v` is `ty_v`, we need to mediate between `ty_v` and `V[[ty]]`.  (Here `V[[ty]]` is the transformation that maps a regular type to a vectorised type.)

It is `V[[ty]]` that we cannot determine until the vectoriser runs.  If we could compute `V[ty]]` in the type checker, we could use it together with `ty_v` to compute a wrapper w as you propose.  

Alas, given the current implementation of `V[[..]]` in the vectoriser (it is implemented in `Vectorise.Type.vectType`), we cannot call it in the type checker, because it runs in the `VM` monad, which is a variant of the 'DsM' monad.  In particular, 'VM' uses some tables of names of types and functions defined in the DPH library that are not available during type checking.  (I briefly considered duplicating the code for `vectType` as a stop gap measure in `TcM`, but that didn't seem to be so easy.)

I believe that the Right Thing to do is to change the 'VM' monad and the implementation of `vectType`, so that it is more flexible and can be called from `TcM`.  The changes that I am making at the moment (i.e., cutting down these tables of magic, built-in things) will make it easier to improve `vectType`. 

"	simonpj
3	7044	reject reading rationals with exponent notation	Compiler	7.4.2	normal		7.8.1		new	2012-07-03T01:10:23-0700	2012-10-14T09:24:51-0700	"The program

{{{
main = print (1E1000000000 :: Rational)
}}}

fails in the same way as for doubles currently. This should not happen at compile time! Therefore I suggest to forbid using the e-notation for rationals, it is not legal for integers either.

(An alternative would be to evaluate the rational only at run-time)"	maeder
4	4176	reject unary minus in infix left hand side function bindings that resolve differently as expressions	Compiler	7.2.1	low		7.6.2		new	2010-07-07T02:27:52-0700	2012-09-12T04:12:26-0700	"a program like:

{{{
infix 7 ##

(##) :: Int -> Int -> Int
- 1 ## 0 = 0
_ ## _ = 1
}}}

evaluates (unexpectedly) as
{{{
*Main> - 1 ## 0
-1
}}}
"	maeder
3	2031	relocation overflow	Compiler	6.8.2	normal	normal	_|_		new	2008-01-10T04:05:08-0800	2009-12-15T00:05:40-0800	"I've created a statically linked ghc-6.8.2 for PPC Mac OS 10.4 (Tiger).
http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin-static-libs.tar.bz2

When linking our big hets binary after compilation with optimization I get millions (actually 34999 lines) of entries like:

{{{
/usr/bin/ld: PGIP/XMLparsing.o relocation overflow for relocation entry 63 in section (__TEXT,__text) (displacement too large)
...
/usr/bin/ld: SoftFOL/Sign.o relocation overflow for relocation entry 45280 in section (__TEXT,__text) (displacement too large)
collect2: ld returned 1 exit status
make: *** [hets] Error 1
}}}

I had such messages before and got rid of them by rearranging code and imports (just by wild guesses, a strategy would be helpful). It is sort of a known (Apple PPC) deficiency (and I misuse this ticket to document it here).

Linking works fine after compilation without optimization or when linking against GMP and GNUreadline frameworks using my other binary distribution.
"	maeder
2	2725	Remove Hack in compiler/nativeGen/MachCodeGen.hs	Compiler (NCG)	6.11	high	minor	7.8.1	clemens	new	2008-10-26T12:41:13-0700	2012-12-06T09:18:03-0800	"Remove the hack around Line 3914 labeled with:
{{{
    -- HACK: On x86_64 binutils<2.17 is only able to generate PC32
    -- relocations, hence we only get 32-bit offsets in the jump
    -- table. As these offsets are always negative we need to properly
    -- sign extend them to 64-bit. This hack should be removed in
    -- conjunction with the hack in PprMach.hs/pprDataItem once
    -- binutils 2.17 is standard.
}}}
This bug is intended for house keeping."	clemens
5	3065	Reorder tests in quot to improve code	libraries/base	6.10.1	lowest	normal	7.6.2		new	2009-03-03T06:57:31-0800	2012-09-12T04:14:08-0700	"[SLPJ: capturing an email thread in a ticket]

Krasimir Angelov found that this function:
{{{
a `quot` b
    | b == 0                     = divZeroError
    | a == minBound && b == (-1) = overflowError
    | otherwise                  =  a `quotInt` b
}}}
is expanded to:
{{{
a `quot` b =
   if b == 0
     then divZeroError
     else if a == minBound
              then if b == (-1)
                       then overflowError
                       else a `quotInt` b
              else a `quotInt` b
}}}
Then the compiler sees that b is a constant and computes that b == 0
is False and b == (-1) is also False so it could eliminate two If
statements. The result is:
{{{
a `quot` b =
   if a == minBound
     then a `quotInt` b
     else a `quotInt` b
}}}
and this is exactly what we get. I bet that if the original function was:
{{{
a `quot` b
    | b == 0                     = divZeroError
    | b == (-1) && a == minBound = overflowError   -- Note the changed order here
    | otherwise                  =  a `quotInt` b
}}}
then we would get what we want. I think that it is much more often to
have division where the divisor is known so we will get the best code
in this case.

Shortly afterwards, Bertram Felgenhauer tried it out.  It works, and it has the desired effect. It's not always a win though; the nofib prime sieve benchmark suffers.

For a patch, see
  http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch
(SLPJ: I've attached it to the ticket too)

Nofib results extract:
{{{
------------------------------------------------------------------------
        Program           Size    Allocs   Runtime   Elapsed
------------------------------------------------------------------------
           fish          -0.7%     -5.3%      0.05      0.04
         primes          -0.0%    +28.5%    +25.6%    +25.5%
   wheel-sieve2          -0.0%     -0.3%    -17.9%    -18.6%
------------------------------------------------------------------------
            Min          -0.9%     -5.3%    -17.9%    -18.6%
            Max          +0.1%    +28.5%    +25.6%    +25.5%
 Geometric Mean          -0.2%     +0.2%     -0.0%     +0.2%
}}}
'primes' is an outlier - the other slowdowns are below 3%

What happens in 'primes' is that 'mod' no longer gets inlined;
apparently it now looks bigger to the compiler than before.

Using -funfolding-use-threshold=10 brings the benchmark back to its
original speed, despite the extra comparison before doing the
division.

In 'wheel-sieve2', the first different optimization choice I see is
again a 'mod' that is no longer inlined; this leads to a change in other
inlining choices that result in a speedup for reasons that I have not
investigated.


"	simonpj
3	7880	"Require ""forall"" in definitions of polymorphic types"	Compiler	7.6.3	normal				new	2013-05-02T09:21:57-0700	2013-05-03T10:43:57-0700	"With rank-n-types, we can write

{{{
data T1 = T (() => a)
type T2 = () => a
}}}

but

{{{
data T1' = T' a
type T2' = a
}}}

gives an error.

I think this behavior is very odd. I propose the following simple rule: such variables in type and data declarations should never be implicitly quantified; i.e. they have to be introduced using ""forall"". Since above types require RankNTypes anyway, there is little harm in requiring ""forall"", and in my opinion it's good to inform the reader that a type uses universal quantification. More complicated example, from lens:

{{{
type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t
}}}

By the way, GHC's documentation is outdated regarding this issue: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type-extensions.html point 7.12.5.1. states that
{{{
data T a = MkT (Either a b)           (b -> b)
data T a = MkT (forall b. Either a b) (forall b. b -> b)
}}}
are equipvalent, but since at least GHC 7.2 the former gives an error."	monoidal
2	7646	resource busy (file is locked) with multi-threaded file ops	libraries/base	7.6.2	high		7.6.3	simonmar	merge	2013-01-31T13:30:01-0800	2013-02-04T04:28:11-0800	"The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use *strict IO*.

When compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages.

But with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`.

Tested under Mac OSX 10.8.2 and Linux.
Tested with both GHC 7.6.1 and 7.6.2.

I could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs  +RTS -N2 -RTS to reproduce the bug."	StefanWehr
5	3138	Returning a known constructor: GHC generates terrible code for cmonad	Compiler	6.10.1	lowest	normal	7.6.2		new	2009-04-02T05:08:19-0700	2012-09-12T04:14:09-0700	"Lennart reports that GHC generates very poor code for his cmonad package. 
If you want to look at a simple example, look at the Inf.hs example
included in package `cmonad-0.1.1`.
It's very simple, and ghc generates fantastically bad code for it.

It would be great if you could nail down why it's so amazingly unoptimal.
Even with everything inlined and no overloading left, ghc seems to
ignore the INLINE directives and use dictionaries left and right.
When I looked at it a year ago or so, it was a return of one
constructor in a sum.  That is, a function always returns the same constructor, so the case
analysis of the return value is not needed; it should be returned as
an unboxed tuple instead

Another unrelated problem, I think, is that ghc needs to promote
in-memory variables to registers when possible.
Perhaps the new code generator has such a transformation?
"	simonpj
3	4295	Review higher-rank and impredicative types	Compiler	6.12.3	normal		7.6.2	simonpj	new	2010-09-07T04:39:42-0700	2012-09-12T04:11:59-0700	"The ticket is a placeholder to remind me to work through the test cases for impredicative and higher rank types in the new typechecker.  For now, I'm marking many of them as `expect_broken` on this ticket, although I think many of them really should fail.
 * tc150
 * tc194
 * tcfail198
 * tcfail174
 * tcfail165
 * tcfail145
 * tcfail104
 * tc211
 * indexed-types/should_compile/T4120
 * simpl017
 * Many tests in `boxy/` (see also #1330 for Church2)
 * #2193
 * #2846
 * #4347
 * [http://augustss.blogspot.com/2011/07/impredicative-polymorphism-use-case-in.html Lennart's blog post] has an interesting use case of impredicative polymorphism; it worked in 7.0, but alas not in the new typechecker.
"	simonpj
3	7611	Rewrite rules application prevented by type variable application (map id vs. map (\x -> x))	Compiler	7.6.2	normal		7.8.1		new	2013-01-21T00:30:39-0800	2013-04-12T15:57:34-0700	"I’m moving the discussion from 
http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023522.html (with reply at http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023531.html) here, as a reminder for myself to work on it someday:

Short summary: a rule ""map (\x -> x) = id"" will not match ""map id"" because the latter has (in Core) an application of a type variable, despite the matcher looking through the definition of id. Doing beta-reduction (of type applications) in the matcher could fix this.

I’ll attach a test case."	nomeata
3	7511	Room for GHC runtime improvement >~5%, inlining related	Compiler	7.6.1	normal		7.8.1		new	2012-12-19T08:50:25-0800	2013-04-12T14:34:41-0700	"I compare running nofib under GHC with default optimization flags vs. with somewhat extreme settings to inlining aggressiveness.

1. Many programs are unaffected, but some are improved significantly. Geometric mean: -6.5% allocs, -5.9% runtime.

2. Some regress significantly, beyond what the obvious code size growth would explain.
{{{
circsim          +0.7%     -4.5%     -0.7%     -0.9%     +2.1%
comp_lab_zift    +0.5%     -0.1%     -3.3%     -3.3%    +28.6%
fulsom          +13.8%     -2.6%     +4.3%     +4.3%    +10.8%
mandel2          +0.4%     +4.5%      0.01      0.01     +0.0%
paraffins        +0.5%     +0.0%     +4.0%     +2.9%     +0.0%
rewrite          +0.4%    +15.9%      0.03      0.03     +0.0%
tak              +0.1%     +4.0%      0.02      0.02     +0.0%
treejoin         -0.1%     -0.0%     +2.2%     +1.7%     +0.0%
wave4main        +1.6%    +29.4%    +19.9%    +19.9%    +30.8%
}}}

This presents two opportunities:

1. Find better default flags settings (maybe not quite as extreme) and make them the default.

2. Find the reasons behind the regressions, and fix them in GHC. In addition to improving the performance we perceive through GHC, hopefully performance will become more predictable to users: Simon PJ has told me he expects (paraphrasing) ""more inlining should make things better, except for/through code size"", which would be a very useful invariant; the data here clearly show some cases where it does not hold.

Included are a complete report, an extract of the highlights (significantly improved or any regressed benchmarks) and the script to reproduce given a ghc7.6 devel2 build."	danielv
3	7189	RTS Assertion Crash	Runtime System	7.4.2	normal		7.8.1	simonmar	new	2012-08-26T10:51:57-0700	2012-10-16T11:50:12-0700	"I occasionally get the following crash when I compile with -debug:
{{{
internal error: ASSERTION FAILED: file rts/Schedule.c, line 1268

    (GHC version 7.4.2 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
If the application is not compiled with -debug this does not seem to happen. Usually I just don't link in the debug runtime however I have been trying to rundown an IO that never completes. I can't post the app but I am happy to collect information to attach to this ticket."	sseverance
3	7771	RTS should provide stg_sel_n_noupd_closure	Compiler	7.6.2	normal		7.8.1	simonpj	new	2013-03-14T06:36:26-0700	2013-04-13T06:26:38-0700	"In `StgStdThunks.cmm` we define info tables `stg_sel_1_upd_info`, etc, for ""selector thunks"", thus:
{{{
#define SELECTOR_CODE_UPD(offset)                                       \
  INFO_TABLE_SELECTOR(stg_sel_##offset##_upd, offset, THUNK_SELECTOR, ""stg_sel_upd"", ""stg_sel_upd"") \
      (P_ node)                                                         \
...etc...
}}}
But we should ALSO define info tables for ''non-updatable'' selector thunks, thus `stg_sel_1_nonupd_info` etc.  We didn't generate any such selectors before, but now I'm implementing cardinality analysis, we are.

Would it be possible to beef up this macro to to generate both info tables?  Simply omit the update for the `nonupd` version.  (It wasn't quite obvious to me how to do this.)

That would allow me to get rid of this hack in `CLabel`
{{{
pprCLbl (RtsLabel (RtsSelectorInfoTable _upd_reqd offset))
  = hcat [ptext (sLit ""stg_sel_""), text (show offset),
                  ptext (sLit ""_upd_info"")
-- RTS only has updatable selector thunks at the moment
-- so we use just them
--                ptext (if upd_reqd
--                        then (sLit ""_upd_info"")
--                        else (sLit ""_noupd_info""))
        ]
}}}
Thanks"	simonpj
3	7374	rule not firing	Compiler	7.6.1	normal		7.8.1		new	2012-10-28T14:22:24-0700	2012-11-19T17:37:00-0800	"In the code below, the rule appears not to fire.

Based on the bytestring rules, reported as broken here:
http://www.haskell.org/pipermail/glasgow-haskell-users/2012-August/022775.html

{{{
ghc -O --make h.hs -ddump-simpl -fforce-recomp -Wall
}}}
{{{
module Q (f) where

{-# NOINLINE f #-}
f :: Bool -> String
f c = g ((==) c)

{-# NOINLINE g #-}
g :: (Bool -> Bool) -> String
g _ = ""g""

h :: Bool -> String
h _ = ""h""

{-# RULES ""MyRule"" forall x . g ((==) x) = h x #-}
}}}
{{{
==================== Tidy Core ====================
Result size of Tidy Core = {terms: 25, types: 21, coercions: 0}

lvl_rkK :: GHC.Types.Char
[GblId, Caf=NoCafRefs, Str=DmdType m]
lvl_rkK = GHC.Types.C# 'h'

lvl1_rkL :: [GHC.Types.Char]
[GblId, Caf=NoCafRefs, Str=DmdType]
lvl1_rkL =
  GHC.Types.:
    @ GHC.Types.Char lvl_rkK (GHC.Types.[] @ GHC.Types.Char)

h_reA :: GHC.Types.Bool -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
h_reA = \ _ -> lvl1_rkL

lvl2_rkM :: GHC.Types.Char
[GblId, Caf=NoCafRefs, Str=DmdType m]
lvl2_rkM = GHC.Types.C# 'g'

lvl3_rkN :: [GHC.Types.Char]
[GblId, Caf=NoCafRefs, Str=DmdType]
lvl3_rkN =
  GHC.Types.:
    @ GHC.Types.Char lvl2_rkM (GHC.Types.[] @ GHC.Types.Char)

g_rez :: (GHC.Types.Bool -> GHC.Types.Bool) -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
g_rez = \ _ -> lvl3_rkN

Q.f [InlPrag=NOINLINE] :: GHC.Types.Bool -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
Q.f =
  \ (c_aeC :: GHC.Types.Bool) ->
    g_rez (GHC.Classes.$fEqBool_$c== c_aeC)
}}}
"	igloo
3	7398	RULES don't apply to a newtype constructor	Compiler	7.6.1	normal		7.8.1		new	2012-11-08T01:09:59-0800	2013-04-12T11:20:10-0700	"For some reason, RULES that involve a newtype constructor never seem to fire. The following program demonstrates the problem:

{{{
module Main where

newtype Foo a = Foo { unFoo :: a }
  deriving Show

foo :: a -> Foo a
foo = Foo

{-# RULES ""rule Foo""  forall v.  Foo v = error ""Foo"" #-}
{-# RULES ""rule foo""  forall v.  foo v = error ""foo"" #-}

main :: IO ()
main = do
    print (Foo ())
    print (foo ())
}}}

""rule foo"" fires, but ""rule Foo"" doesn't. The program prints

{{{
Foo {unFoo = ()}
D: foo
}}}

Note that this doesn't seem to affect selectors, only constructors."	shachaf
3	3765	"Rules should ""look through"" case binders too"	Compiler	6.12.1	normal		_|_		new	2009-12-16T03:51:58-0800	2009-12-16T03:51:58-0800	"Here's a program suggested by Roman
{{{
inc :: Int -> Int
{-# INLINE CONLIKE [1] inc #-}
inc n = n+1

dec :: Int -> Int
{-# INLINE [1] dec #-}
dec n = n-1

{-# RULES  ""dec/inc"" forall n. dec (inc n) = n   #-}

data T = T !Int    -- The bang here prevents the rule firing

foo :: T -> Int
{-# INLINE foo #-}
foo (T n) = dec n + n

bar :: Int -> Int
bar n = foo (T (inc n))
}}}
The rule doesn't fire with the bang in the definition of T. If I  
remove the bang, it fires. It should fire in both cases.

The trouble is that, with the bang, we see something like this (in the output of phase 2 of the simplifier):
{{{
Roman.bar =
  \ (n_aat :: GHC.Types.Int) ->
    case Roman.inc n_aat of tpl_X3 { GHC.Types.I# ipv_skx ->
    case Roman.dec tpl_X3 of _ { GHC.Types.I# x_ak2 ->
    GHC.Types.I# (GHC.Prim.+# x_ak2 ipv_skx)
    }
}}}
but `tpl_X3` is bound to `(I# ipv_skx)`, not to `(inc n_aat)`.  Somehow we need ''both'' unfoldings for `tpl_X3`.   That seems like a big step, so I'm just capturing the ticket but not actually doing anything about it yet.
"	simonpj
3	3195	runghc failing sometimes	None	6.10.2	normal	normal	_|_		new	2009-04-28T01:04:07-0700	2010-06-19T11:24:34-0700	"ghc-6.10.2 runghc fails on ppc sometimes:

http://koji.fedoraproject.org/koji/getfile?taskID=1320158&name=build.log (haddock)

http://koji.fedoraproject.org/koji/getfile?taskID=1319083&name=build.log (HTTP)

Also reproduced first-hand on a ppc box.

Furthermore (may be a different issue) runghc fails for me with
recent ghc-6.11 snapshots I have built on x86_64."	juhpetersen
3	7859	runghc should give an error when the path to ghc is invalid	None	7.6.3	normal		7.8.1		new	2013-04-23T14:11:38-0700	2013-05-10T15:05:08-0700	"runghc has a -f option which allows to specify the path to GHC. However, it uses `rawSystem` and if the path is incorrect, we only get a nonzero exit code. For example, attempting to use ""ghc -fdefer-type-errors X.hs"" gives absolutely no output.

Attached patch uses `findExecutable` and gives an error message if the executable is not found. This is not the ideal solution, but I think it's better than the current state."	monoidal
3	5916	runST isn't free	Compiler	7.4.1	normal		7.6.2		new	2012-03-05T08:23:25-0800	2013-04-05T22:34:20-0700	"While optimizing some code I discovered that `runST` isn't free. I had a function on the form:

{{{
f ... = ...let x = runST in (f x)...
}}}

Manually transforming it into

{{{
f ... = runST (g ...)
 where g ... = do
    ...
    x <- ...
    g x
    ...
}}}

(The real example is at https://github.com/tibbe/unordered-containers/commit/58b7815a057b3575c58b746d5971d59d806b1333)

improved performance quite a bit on this, already highly tuned, function. Unfortunately, combining all the calls to `runST` into one and pulling them ""up"" is not all good. The code is now less modular, has a somewhat over specified evaluation order, and generally looks more imperative.

The cause of the decrease in performance is that `runSTRep` cannot be inlined, which causes allocation of closures inline in the code (where none should be necessary.)

The comment next to `runSTRep` explains why it's implemented the way it is, but I wonder if matters could be improved by making it a primop. If we create a fresh state token every time, instead of reusing `realWorld#`, it should be impossible for mutable structures to let-float and become CAFs (which is what `runSTRep` tries to avoid.)"	tibbe
4	5188	Runtime error when allocating lots of memory	GHCi	6.12.1	low		7.6.2		new	2011-05-10T07:12:30-0700	2012-09-12T04:13:28-0700	"In GHCI execute
{{{
let powers = 2:map (2^) powers
powers
}}}
When calculating the fourth element of the list, you get the following error message:
{{{
<interactive>: internal error: getMBlock: mmap: Invalid argument
    (GHC version 6.12.1 for i386_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
If you have trouble reproducing the bug, try substituting an other number for 2 in the code, e.g. I have also got that error message when I defined powers as:
{{{
let powers = 4:map (4^) powers
}}}
and
{{{
let powers = 13:map (13^) powers
}}}
"	knyblad
3	7836	Runtime failure profiling with +RTS -hc -hbdrag,void	Profiling	7.4.2	normal				infoneeded	2013-04-14T06:26:40-0700	2013-04-23T02:13:29-0700	"Running the attached program, compiled with ""-threaded -Wall -auto-all -caf-all -fforce-recomp -fprof-auto-top -fprof-auto-calls"" - with the following flags: +RTS -hc -hbdrag,void -RTS

The output is as follows:

leaks: internal error: Invalid object in processHeapClosureForDead(): 60
    (GHC version 7.4.2 for i386_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort trap: 6
"	hyperthunk
4	3881	section parse errors, e.g. ( let x=1 in x + )	Compiler (Parser)	6.12.1	low		7.6.2		new	2010-02-14T09:04:17-0800	2012-09-12T04:12:21-0700	"These parse errors were brought up on the Haskell' list: http://www.haskell.org/pipermail/haskell-prime/2010-February/003093.html
{{{
Prelude> :t ( let x=1 in x + )

<interactive>:1:18: parse error on input `)'
}}}
{{{
Prelude> :t ( if True then 1 else 2 + )

<interactive>:1:27: parse error on input `)'
}}}
Milestoned for 6.16.1, as it sounds like the language definition may get changed in H'.
"	igloo
3	5841	seg fault in ghci but not ghc when using chart-gtk code	Compiler	7.4.1	normal		7.6.2		new	2012-02-03T08:44:50-0800	2012-09-12T04:12:10-0700	"I don't know if this is os x lion specific,
but when running  (attached .hs file) after compiling with (attached .txt) directions,
the program compiled with ghc to a binary will work when set to generate 
either a pdf or a x11 window. In contrast, the same program when run via ghci and set to render to an x11 window, it segfaults. The ghci run when set to output to pdf works fine though. So I think the problem (perhaps, but perhaps not) might be with how the gtk package uses the ffi when run via ghci vs ghc? (so perhaps is a static vs dynamic linking issue). 

it does seem like this might in some way related to another linking bug on mac 
http://hackage.haskell.org/trac/ghc/ticket/5816#comment:4"	carter
3	7874	segfault 11 on mac os x when building compiler for ghc 7.7.20130430	Compiler	7.7	normal				new	2013-04-30T12:04:30-0700	2013-05-10T01:52:20-0700	"I'm trying to build ghc head from the repo head as of today,
and i'm getting the following error in the stage 2 build 
{{{
carter repoScratcher/ghc ‹master› » make
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for `phase_1_builds'.
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all
""inplace/bin/ghc-stage2"" -hisuf hi -osuf  o -hcsuf hc -static  -H64m -O0 -fllvm    -package-name old-time-1.1.0.1 -hide-all-packages -i -ilibraries/old-time/. -ilibraries/old-time/dist-install/build -ilibraries/old-time/dist-install/build/autogen -Ilibraries/old-time/dist-install/build -Ilibraries/old-time/dist-install/build/autogen -Ilibraries/old-time/include    -optP-include -optPlibraries/old-time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package old-locale-1.0.0.5 -XHaskell98 -XCPP -XForeignFunctionInterface -O -fllvm  -no-user-package-db -rtsopts      -odir libraries/old-time/dist-install/build -hidir libraries/old-time/dist-install/build -stubdir libraries/old-time/dist-install/build  -dynamic-too -c libraries/old-time/dist-install/build/System/Time.hs -o libraries/old-time/dist-install/build/System/Time.o -dyno libraries/old-time/dist-install/build/System/Time.dyn_o
make[1]: *** [libraries/old-time/dist-install/build/System/Time.o] Segmentation fault: 11
}}}
"	carter
2	5909	Segfault with multi-threaded retainer profiling	Runtime System	7.4.1	high		7.6.2	simonmar	merge	2012-03-01T21:46:51-0800	2013-02-19T07:58:42-0800	"I see the following program often segfaults when compiled and run like this:

{{{
% ghc -threaded -O2 -prof -fprof-auto segfault.hs -rtsopts
[1 of 1] Compiling Main             ( segfault.hs, segfault.o )
Linking segfault ...
% ./segfault aaaaaaaaaaaaaaaaaaaaaaa +RTS -hr -N5 -V -A512K
# Segfaults, often within a minute.
}}}

It also seems to me that it segfaults more often/quickly when some other process is actively running on the same machine. I kept ""ghc -e 'last [1..]' +RTS -A13G"" running while making the test case. The machine I used has 4 cores, 8 HT threads and 16GB RAM."	akio
3	3266	Segment fault with WxHaskell and GHC 6.10.2	Compiler	6.10.2	normal	normal	_|_		new	2009-05-30T07:49:00-0700	2009-07-12T09:23:41-0700	"When i compile this very simple program  :
{{{
module Main where

 import Graphics.UI.WX

 main :: IO ()
 main = start gui

 gui :: IO ()
 gui = do
  frame [text := ""Hello World!""]
  return ()
}}}
and that I run it with DOS, I get the error : ""Segment fault/access violation in generated code"" as soon as the mouse passes over the displayed window.

When I compile it and run it with GHCI, under Windows,  I get the extra informations :
{{{
Signature du problème :
  Nom d’événement de problème:	APPCRASH
  Nom de l’application:	ghc.exe
  Version de l’application:	0.0.0.0
  Horodatage de l'application:	49d14878
  Nom du module par défaut:	comctl32.dll_unloaded
  Version du module par défaut:	0.0.0.0
  Horodateur du module par défaut:	4549bcb0
  Code de l’exception:	c0000005
  Décalage de l’exception:	73828219
  Version du système:	6.0.6000.2.0.0.768.3
  Identificateur de paramètres régionaux:	1036
  Information supplémentaire n° 1:	916f
  Information supplémentaire n° 2:	5a80fd0e43273a8de02792153de3009a
  Information supplémentaire n° 3:	3cbc
  Information supplémentaire n° 4:	a7ba763d72dae8d739732c4202cd60ca
}}}

I get the same error with almost all the demo programs delivered with WxHaskell.

I have Windows Vista, GHC 6.10.2, wxHaskell 0.11.1.2 et WxWidgets 2.8.9.

"	mcastellazzi
4	4505	Segmentation fault on long input (list of pairs)	Compiler	7.0.1	low		7.6.2		new	2010-11-17T06:58:37-0800	2012-09-12T04:12:32-0700	"When compiling LongList.hs with
{{{
ghc --make LongList.hs
}}}
then running the output gives a segfault:
{{{
$ ./LongList
8595
Segmentation fault
}}}
It also segfaults with ghc 6.12.1 (without printing 8595) and with ghc 6.12.3.

On ghc 6.12.3 running on Mac OS 10.5, no segfault is seen. (I haven't tried much longer input, since it already eats up approx. 1.2 GB of RAM.)"	cathper
3	6079	SEH exception handler not implemented on Win64	Runtime System	7.5	normal		7.6.2		new	2012-05-05T06:07:04-0700	2012-09-12T04:12:14-0700	"In `RtsMain.c` we only enable `BEGIN_CATCH`/`END_CATCH` on Win32. I think we need a completely different implementation for Win64.
"	igloo
3	7625	Semicolon is not handled between imports at the ghci command prompt	GHCi	7.4.2	normal		7.8.1		new	2013-01-25T05:56:54-0800	2013-04-12T16:05:38-0700	"You cannot use ""import Data.List ; import Control.Monad"" at the ghci command prompt.  It gives:

    <no location info>: parse error in import declaration
"	JohnWiegley
3	7307	Share top-level code for strings	Compiler	7.6.1	normal		7.8.1		new	2012-10-08T06:16:26-0700	2013-04-12T08:01:24-0700	"A string constant in GHC turns into
{{{
foo :: String
foo = unpackCString# ""the-string'
}}}
This is a top-level thunk, and it expands into rather a lot of code like this
{{{
.text
	.align 4,0x90
	.long	0
	.long	22
.globl _Foo_zdfTypeableTzuds1_info
_Foo_zdfTypeableTzuds1_info:
.LcvI:
	movl %esi,%eax
	leal -12(%ebp),%ecx
	cmpl 84(%ebx),%ecx
	jb .LcvQ
	addl $8,%edi
	cmpl 92(%ebx),%edi
	ja .LcvS
	movl $_stg_CAF_BLACKHOLE_info,-4(%edi)
	movl 100(%ebx),%ecx
	movl %ecx,0(%edi)
	leal -4(%edi),%ecx
	pushl %ecx
	pushl %eax
	pushl %ebx
	movl %eax,76(%esp)
	call _newCAF
	addl $12,%esp
	testl %eax,%eax
	je .LcvL
	movl $_stg_bh_upd_frame_info,-8(%ebp)
	leal -4(%edi),%eax
	movl %eax,-4(%ebp)
	movl $_cvJ_str,-12(%ebp)
	addl $-12,%ebp
	jmp _ghczmprim_GHCziCString_unpackCStringzh_info
.LcvL:
	movl 64(%esp),%eax
	jmp *(%eax)
.LcvS:
	movl $8,116(%ebx)
.LcvQ:
	movl %eax,%esi
	jmp *-12(%ebx)
}}}
That's rather a lot of goop for one thunk!  Of course we can share this, by making a 2-word thunk like this:
{{{
------------------------------
| TopUnpack_info  |   -------|-----> ""the-string""#
------------------------------
}}}
where `TopUnpack_info` is a shared RTS info-table and code that embodies the code fragment above.

This would save useless code bloat for every constant string.  (This came up when looking at the code generated by `deriving(Typeable)`.)"	simonpj
3	5645	Sharing across functions causing space leak	Compiler	7.2.1	normal		7.6.2		new	2011-11-17T09:20:35-0800	2012-09-12T04:12:06-0700	"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
3	6101	Show instance for integer-simple is not lazy enough	libraries (other)	7.4.1	normal		7.8.1		new	2012-05-16T17:22:19-0700	2012-10-12T03:38:20-0700	I run out of memory, after 31 GB, when trying to show an Integer (using integer-simple) that is in the ballpark of 200K digits.  I assume this is due to the entire string being generated at once and not lazily.	tommd
4	5957	signatures are too permissive	Compiler (Type checker)	7.4.1	low		_|_		new	2012-03-22T03:22:54-0700	2012-12-19T04:52:15-0800	"ghc should reject the following (accidentally mistyped) signature, unless `-XFlexibleContexts` is used.

{{{
flex :: Int -> Show a => a -> String
flex i a = show a ++ show i
}}}

hugs and ghc version below 7 rejected this correctly:

{{{
    All of the type variables in the constraint `Show a'
    are already in scope (at least one must be universally quantified here)
        (Use -XFlexibleContexts to lift this restriction)
    In the type signature for `flex':
      flex :: Int -> (Show a) => a -> String
}}}

It is not Haskell98 nor Haskell2010 (I believe).
"	maeder
3	7809	Silly error message suggesting LiberalTypeSynonyms	Compiler (Type checker)	7.7	normal		7.8.1		new	2013-04-03T09:18:58-0700	2013-04-13T08:18:18-0700	"The following code (rightly) does not compile:

{{{
{-# LANGUAGE RankNTypes, TypeFamilies, LiberalTypeSynonyms #-}

type PolyId = (forall a. a -> a)

type family F a

foo :: F PolyId
foo = undefined
}}}

The error message is

{{{
    Illegal polymorphic or qualified type: PolyId
    Perhaps you intended to use -XLiberalTypeSynonyms
    In the type signature for `foo': foo :: F PolyId
}}}

The code doesn't compile because we can't apply a type family to a polytype. The first line of the error message says this well enough, though more information might be helpful here. However, the second line of the error message is silly: I've turned on {{{LiberalTypeSynonyms}}}!"	goldfire
4	5495	simple program fails with -shared on mac	Compiler	7.2.1	low		7.6.2		new	2011-09-16T19:14:10-0700	2012-09-12T04:13:33-0700	"{{{
sleipnir ➜  ~  ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.2.1
sleipnir ➜  ~  ghc --make foo.hs -shared
[1 of 1] Compiling Main             ( foo.hs, foo.o )
Linking foo ...
collect2: ld terminated with signal 11 [Segmentation fault]
sleipnir ➜  ~  cat foo.hs
main = putStrLn ""hi""
}}}

This happened on both of the two systems I tried it on. Package installed from
http://www.haskell.org/ghc/dist/7.2.1/GHC-7.2.1-x86_64.pkg
"	mwotton
3	7057	Simplifier infinite loop regression	Compiler	7.4.2	normal		7.8.1	simonpj	new	2012-07-07T14:06:15-0700	2012-10-14T09:35:12-0700	"GHC gets stuck in the simplifier when compiling the attached file, eventually exhausting all ram.
Compiling gives:
{{{
$ ghc -v3 -O --make ghcloop.hs 
Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.0.3
...
*** Simplifier:
^C*** Deleting temp files:
...
}}}

Running with with all the dump flags suggests the fault is pddlDocExpr's.  I'm finding it hard to create a smaller example, as even silly things like removing the container (or not using Data.Generics) restore termination."	ronwalf
2	7521	Simplifier ticks exhausted when compiling Accelerate example.	Compiler	7.6.1	high		7.8.1		new	2012-12-21T13:51:40-0800	2013-04-12T14:43:51-0700	"When doing $ `cabal build` for: http://github.com/AccelerateHS/accelerate-examples (commit def2495a1e7bd88e444540c3494b8674da99e201):
{{{
[31 of 36] Compiling SMVM.Matrix      ( examples/tests/simple/SMVM/Matrix.hs, dist_accelerate/build/accelerate-examples/accelerate-examples-tmp/SMVM/Matrix.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.1 for x86_64-unknown-linux):
	Simplifier ticks exhausted
    When trying UnfoldingDone base:GHC.Base.returnIO1{v r5g} [gid]
    To increase the limit, use -fsimpl-tick-factor=N (default 100)
    If you need to do this, let GHC HQ know, and what factor you needed
    To see detailed counts use -ddump-simpl-stats
    Total ticks: 27960
}}}
"	eamsden
3	5444	Slow 64-bit primops on 32 bit system	Compiler	7.2.1	normal		7.6.2		new	2011-08-31T04:05:30-0700	2012-09-12T04:12:03-0700	"GHC primops for 64-bit arithmetic are implemented as FFI calls. It leads to serious performance penalty for 32 bit code which heavily uses 64-bit arithmetics.

I found this while investigating poor performance of mwc-random on 32-bit systems. 32-bit build runs 3-4 times slower than 64-bit build on the same hardware. It's difficult to estimate how faster would run optimal implementation since it doesn't exist. But it's probably at least 2x slowdown.


Here is simple program to demonstrate issue
{{{
sqr64 :: Int32 -> Int64
sqr64 x = y * y where y = fromIntegral x
}}}

Here is optimized core
{{{
$wsqr64 :: Int# -> Int64
$wsqr64 =
  \ (ww_sGO :: Int#) ->
    case {__pkg_ccall ghc-prim hs_intToInt64 Int#
                                    -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aFY
           ww_sGO realWorld#
    of _ { (# _, ds2_aG2 #) ->
    case {__pkg_ccall ghc-prim hs_timesInt64 Int64#
                                    -> Int64# -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aGc
           ds2_aG2 ds2_aG2 realWorld#
    of _ { (# _, ds4_aGi #) ->
    I64# ds4_aGi
    }
    }

sqr64 :: Int32 -> Int64
sqr64 = \ (w_sGM :: Int32) ->
    case w_sGM of _ { I32# ww_sGO -> $wsqr64 ww_sGO }
}}}"	Khudyakov
2	7501	Some GHCi options are undocummented	Documentation	7.6.1	high		7.8.1		new	2012-12-14T11:28:41-0800	2013-04-12T14:22:19-0700	"The following commands are missing from the list found in [http://www.haskell.org/ghc/dist/current/docs/html/users_guide/ghci-commands.html GHCi documentation]:

:check, :issafe, :showi, :list, :steplocal, :stepmodule

At least last three are documented [http://www.haskell.org/ghc/dist/current/docs/html/users_guide/ghci-debugger.html in debugger documentation], but a link would be nice."	monoidal
3	5692	Source code with large floating constants in exponential notation cannot be compiled	Compiler	7.2.1	normal		7.6.2	pcapriotti	new	2011-12-12T07:32:52-0800	2012-09-12T04:12:07-0700	"
Source code cannot be compiled:

{{{
main = do
    print (123e124124124 :: Double)
}}}

where this one can be and will work after #5688 is fixed:

{{{
main = do
    print (read ""123e124124124"" :: Double)
}}}

Haskell Report forces Float and Double to go through Rational:

http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1360006.4.1

When exponent is big it produces very large Rational numbers. That takes a lot of time and usually ends in out of memory condition.

This is similar to #5688, but at compile time.
"	gracjan
3	7898	SpecConstr explodes when compiling module BSP of frag-1.1.2	Compiler	7.6.3	normal				new	2013-05-08T08:11:40-0700	2013-05-17T00:46:41-0700	"GHC will get stuck when trying to compile [http://www.haskell.org/haskellwiki/Frag Frag]. Steps to reproduce:

 1. Get Frag 1.1.2 from the Darcs repository (`darcs get http://code.haskell.org/frag`), or from snowmantw's !GitHub fork (`git clone https://github.com/snowmantw/Frag.git`).
 1. Fix the code so it'll actually compile:
    {{{
diff --git a/src/Textures.hs b/src/Textures.hs
index 7383fd8..b5516a5 100644
--- a/src/Textures.hs
+++ b/src/Textures.hs
@@ -10,6 +10,7 @@ import Graphics.UI.GLUT
 import TGA (readTga)
 import Data.Word (Word8)
 import Foreign.Marshal.Alloc (free)
+import Control.Exception (catch, SomeException)
 
 
 -- read a list of images and returns a list of textures
@@ -32,7 +33,8 @@ getAndCreateTexture fileName = do
 
 -- read the image data
 readImageC :: String -> IO (Maybe (Size, PixelData Word8))
-readImageC path = catch (readTga path) (\_ -> do print (""missing texture: ""++path)
+readImageC path = catch (readTga path) (\e -> do print (e :: SomeException)
+                                                 print (""missing texture: ""++path)
                                                  return Nothing)
 
    }}}
 1. `cabal configure`
 1. `cabal build`

GHC will get stuck on the module `BSP` and consume memory until it crashes. According to [https://github.com/snowmantw/Frag/issues/1 this ticket on the GitHub fork mentioned earlier], this problem only occurs with `-O2`.

When I split the reading part of the module (`readBSP` and all functions it depends on), it crashed on that part. Will investigate further."	tinctorius
4	3767	SpecConstr for join points	Compiler	6.12.1	low		7.6.2		new	2009-12-16T08:13:59-0800	2012-09-12T04:12:20-0700	"The attached file `Spec.hs` has a case (from Roman's fusion code) where `SpecConstr` is not doing the right thing.  Let's look at one of the mutually recursive loops that `SpecConstr` generates for foo:
{{{
lvl_rzY :: GHC.Types.Int
lvl_rzY = GHC.Types.I# 2147483647

lvl1_rA0 :: Data.Either.Either GHC.Types.Int GHC.Types.Int
lvl1_rA0 = Data.Either.Left @ GHC.Types.Int @ GHC.Types.Int lvl_rzY

$s$wgo_szT :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int#
$s$wgo_szT =
  \ (sc_sz6 :: GHC.Prim.Int#) (sc1_sz7 :: GHC.Prim.Int#) ->
    let {
      $w$j_syG
        :: GHC.Prim.Int#
           -> Data.Either.Either GHC.Types.Int GHC.Types.Int
           -> GHC.Prim.Int#
      [LclId, Arity=2, Str=DmdType LS]
      $w$j_syG =
        \ (ww_sy6 :: GHC.Prim.Int#)
          (w2_sy8 :: Data.Either.Either GHC.Types.Int GHC.Types.Int) ->
          case GHC.Prim.<=# ww_sy6 0 of _ {
            GHC.Bool.False -> $wgo_syE (GHC.Prim.+# sc_sz6 ww_sy6) w2_sy8;
            GHC.Bool.True -> $wgo_syE sc_sz6 w2_sy8
          } } in
    case GHC.Prim.># sc1_sz7 0 of _ {
      GHC.Bool.False -> $s$wgo1_szS sc_sz6 ipv_swo;
      GHC.Bool.True ->
        case sc1_sz7 of wild1_awb {
          __DEFAULT ->
            case GHC.Prim.remInt# wild1_awb 2 of _ {
              __DEFAULT -> $s$wgo_szT sc_sz6 (GHC.Prim.-# wild1_awb 1);
              0 ->
                case w1_syr of _ { GHC.Types.I# ww_sy6 ->
                $w$j_syG
                  ww_sy6
                  (Data.Either.Left
                     @ GHC.Types.Int
                     @ GHC.Types.Int
                     (GHC.Types.I# (GHC.Prim.-# wild1_awb 1)))
                }
            };
          (-2147483648) ->
            case w1_syr of _ { GHC.Types.I# ww_sy6 ->
            $w$j_syG ww_sy6 lvl1_rA0
            }
        }
    };
}}}
Note that the join point has an argument of type `(Either Int Int)` but it is always called with `(Left (I# <n>))`. This means that the recursive call in the join point is always of the form `($wgo_syE <m> (Left (I# <n>)))` and we have a specialisation for that.  However the join point itself doesn't scrutinse its argument, and that means that GHC ignores the potential specialisation.  

Simon 

"	simonpj
2	3831	SpecConstr should exploit cases where there is exactly one call pattern	Compiler	6.13	high		7.8.1	simonpj	new	2010-01-20T05:05:58-0800	2012-11-17T06:50:31-0800	"On x86/Linux, with this `mk/build.mk`:
{{{
GhcLibWays = v p dyn
SRC_HC_OPTS     = -O -H64m -Rghc-timing
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -O2 -fasm
GhcHcOpts       = -Rghc-timing
GhcLibHcOpts    = -O2 -XGenerics

#SplitObjs          = YES
SplitObjs          = NO
HADDOCK_DOCS       = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS   = NO
BUILD_DOCBOOK_PDF  = NO

# -----------------------------------------------------------------------------
# Other settings that might be useful

# profiled RTS
#GhcRtsCcOpts =  -pg -g

# Optimised/profiled RTS
#GhcRtsCcOpts = -O2 -pg

#GhcRtsWithFrontPanel = YES
#SRC_HC_OPTS += `gtk-config --libs`

# NoFib settings
NoFibWays =
STRIP=:
}}}
and these commands:
{{{
$ sh boot
$ ./configure --prefix=/opt/ghc-6.13
$ make
}}}
and a 1GB memory limit (`ulimit -v 1024000`), the build fails with:
{{{
""inplace/bin/ghc-stage1""   -O -H64m -Rghc-timing    -package-name terminfo-0.3.1.1 -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-install/build -ilibraries/terminfo/dist-install/build/autogen -Ilibraries/terminfo/dist-install/build -Ilibraries/terminfo/dist-install/build/autogen -Ilibraries/terminfo/.    -optP-include -optPlibraries/terminfo/dist-install/build/autogen/cabal_macros.h -package base-4.2.0.0 -package extensible-exceptions-0.1.1.1  -Wall -XForeignFunctionInterface -XDeriveDataTypeable -XEmptyDataDecls -XScopedTypeVariables -XFlexibleInstances -O2 -XGenerics -fno-warn-deprecated-flags     -odir libraries/terminfo/dist-install/build -hidir libraries/terminfo/dist-install/build -stubdir libraries/terminfo/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/terminfo/./System/Console/Terminfo/Effects.hs -o libraries/terminfo/dist-install/build/System/Console/Terminfo/Effects.o
ghc-stage1: out of memory (requested 1048576 bytes)
make[1]: *** [libraries/terminfo/dist-install/build/System/Console/Terminfo/Effects.o] Error 1
make: *** [all] Error 2
}}}
With `-v`:
{{{
Glasgow Haskell Compiler, Version 6.13.20100120, for Haskell 98, stage 1 booted 
by GHC version 6.8.2
Using binary package database: /home/ian/qq/ghc/inplace/lib/package.conf.d/packa
ge.cache
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-inplace
wired-in package integer-gmp mapped to integer-gmp-0.2.0.0-inplace
wired-in package base mapped to base-4.2.0.0-inplace
wired-in package rts mapped to builtin_rts
wired-in package haskell98 mapped to haskell98-1.0.1.1-inplace
wired-in package template-haskell mapped to template-haskell-2.4.0.0-inplace
wired-in package dph-seq mapped to dph-seq-0.4.0-inplace
wired-in package dph-par mapped to dph-par-0.4.0-inplace
Hsc static flags: -static
Created temporary directory: /tmp/ghc1791_0
*** Checking old interface for terminfo-0.3.1.1:System.Console.Terminfo.Effects:
*** Parser:
*** Renamer/typechecker:
*** Desugar:
    Result size = 1076
*** Simplifier gentle[rules,no inline] max-iterations=4:
    Result size = 802
    Result size = 758
    Result size = 758
*** Specialise:
    Result size = 758
*** Float out(not lambdas, constants):
    Result size = 826
*** Float inwards:
    Result size = 826
*** Simplifier Phase 2 [main] max-iterations=4:
    Result size = 1499
    Result size = 2190
    Result size = 2994
    Result size = 2380
    Result size = 2380
*** Simplifier Phase 1 [main] max-iterations=4:
    Result size = 2145
    Result size = 2115
*** Simplifier Phase 0 [main] max-iterations=4:
    Result size = 2115
*** Demand analysis:
    Result size = 2115
*** Worker Wrapper binds:
    Result size = 2115
*** Glom binds:
*** GlomBinds:
    Result size = 2115
*** Simplifier Phase 0 [post-worker-wrapper] max-iterations=4:
    Result size = 2115
*** Float out(not lambdas, constants):
    Result size = 2121
*** Common sub-expression:
    Result size = 2102
*** Float inwards:
    Result size = 2102
*** Liberate case:
    Result size = 2102
*** Simplifier Phase 0 [post-liberate-case] max-iterations=4:
    Result size = 2082
    Result size = 2082
*** SpecConstr:
ghc-stage1: out of memory (requested 1048576 bytes)
}}}
"	igloo
3	5821	SPECIALISE fails with a cryptic warning	Compiler	7.5	normal		7.6.2		new	2012-01-27T15:26:36-0800	2012-09-12T04:12:09-0700	"Example:

{{{
type family T a
type instance T Int = Bool

foo :: Num a => a -> T a
foo = undefined

{-# SPECIALISE foo :: Int -> Bool #-}
}}}

GHC produces this warning:

{{{
    RULE left-hand side too complicated to desugar
      case cobox of _ { GHC.Types.Eq# cobox ->
      (foo @ Int $dNum)
      `cast` (<Int> -> cobox :: (Int -> T Int) ~# (Int -> Bool))
      }
}}}

Given that rewrite rules don't reliably work in the presence of type families, I somewhat suspect that GHC won't be able to generate a sensible specialisation here but it should produce a better diagnostic."	rl
3	5463	SPECIALISE pragmas generated from Template Haskell are ignored	Template Haskell	7.2.1	normal		7.6.2		new	2011-09-05T11:56:10-0700	2012-09-12T04:12:04-0700	"Hi,

I have the following program which contains a SPECIALISE pragma:
{{{
module Test(threeList) where

{-# NOINLINE three #-}
three :: Monad m => m Int
three = return 3
{-# SPECIALISE three :: [Int] #-}

threeList :: [Int]
threeList = three
}}}

The specialisation works and -ddump-simpl gives me the following:
{{{
a :: Int
[GblId, Caf=NoCafRefs, Str=DmdType m]
a = I# 3

threeList [InlPrag=NOINLINE] :: [Int]
[GblId, Caf=NoCafRefs, Str=DmdType]
threeList = : @ Int a ([] @ Int)
}}}

Suppose now I alter my program so that it uses Template Haskell to generate the SPECIALISE pragma:
{{{
{-# LANGUAGE TemplateHaskell #-}
module TestTH(threeList) where

import TH

{-# NOINLINE three #-}
three :: Monad m => m Int
three = return 3
$(specialise 'three)

threeList :: [Int]
threeList = three

{-# LANGUAGE TemplateHaskell #-}
module TH where

import Language.Haskell.TH

specialise :: Name -> DecsQ
specialise x = do
  listInt <- [t| [Int] |]
  return [ PragmaD (SpecialiseP x listInt Nothing) ]
}}}

The specialisation should work just as before. However, if I compile with -ddump-splices -ddump-simpl, I see that the correct pragma was spliced in but no specialisation happened and GHC generated icky code:
{{{
TestTH.hs:1:1: Splicing declarations
    specialise 'three
  ======>
    TestTH.hs:9:3-19
    {-# SPECIALIZE three :: [Int] #-}

==================== Tidy Core ====================
lvl :: Int
[GblId, Caf=NoCafRefs, Str=DmdType m]
lvl = I# 3

three [InlPrag=NOINLINE] :: forall (m :: * -> *). Monad m => m Int
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType U(AASA)]
three =
  \ (@ m::* -> *) ($dMonad :: Monad m) ->
    return @ m $dMonad @ Int lvl

threeList :: [Int]
[GblId,
 Str=DmdType,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False,
         ConLike=False, Cheap=False, Expandable=True,
         Guidance=IF_ARGS [] 2 0}]
threeList = three @ [] $fMonad[]
}}}

This happens on at least GHC 7.0.4 and 7.2.1."	NickSmallbone
4	5013	sporadic failures during compilation under solaris	Compiler	7.0.4	low		7.6.2		new	2011-03-11T01:27:34-0800	2013-04-27T12:19:40-0700	"from time to time my compilations fail with errors like

{{{
    Failed to load interface for `Data.Map':
      There are files missing in the `containers-0.4.0.0' package,
      try running 'ghc-pkg check'.
      Use -v to see a list of the files searched for.
}}}

""ghc-pkg check"" reports no problem and simply repeating the compilation fixes the problem. May this be a timing problem over nfs?
"	maeder
3	4139	Spurious non-exhaustive pattern match warnings are given using GADTs	Compiler	7.4.1	normal		7.0.1		new	2010-06-16T09:23:51-0700	2013-03-22T03:18:40-0700	"When using slightly complicated GADTs, GHC gives me erroneous non-exhaustive pattern match warnings.  I have attached an example.  I have observed this behavior in the four versions of ghc that I tried (6.10.4, and 6.12.{1,2,3}).
"	blarsen
3	6124	Spurious non-exhaustive warning with GADT and newtypes	Compiler (Type checker)	7.4.1	normal		7.8.1		new	2012-05-24T21:09:30-0700	2012-10-12T12:38:18-0700	"This may be related to #3927 or similar, but here's another case where the compiler produces a ""Pattern match(es) are non-exhaustive"" warning for patterns on a GADT that are impossible to implement:

{{{
newtype A = MkA Int
newtype B = MkB Char

data T a where
    A :: T A
    B :: T B

f :: T A -> A
f A = undefined
}}}

This produces the following warning:

{{{
    Warning: Pattern match(es) are non-exhaustive
             In an equation for `f': Patterns not matched: B
}}}

It is impossible to write a pattern for {{{B}}} because {{{B :: T B}}} does not match {{{T A}}}.

If I replace {{{newtype}}} with {{{data}}} for both {{{A}}} and {{{B}}}, the warning goes away.  If I replace only one instance of either {{{newtype}}}, it will still produce the warning."	joeyadams
3	7918	SrcSpan's associated with expanded quasi-quotes are inconsistent	Compiler	7.4.2	normal				new	2013-05-17T07:24:23-0700	2013-05-17T07:24:23-0700	"Consider

{{{
{-# LANGUAGE TemplateHaskell #-}
module A where
import Language.Haskell.TH.Quote
qq = QuasiQuoter {
         quoteExp  = \str -> case str of
                                ""a"" -> [| True |]
                                ""b"" -> [| id True |]
                                ""c"" -> [| True || False |]
                                ""d"" -> [| False |]
       , quotePat  = undefined
       , quoteType = undefined
       , quoteDec  = undefined
       }


{-# LANGUAGE QuasiQuotes #-}
module B where
import A
ex1 = [qq|a|]
ex2 = [qq|b|]
ex3 = [qq|c|]
ex4 = [qq|d|]
}}}

In the expansion of `[qq|a|]` the source span for `True` is reported as 4:7-4:14 and 7:7-7:14 respectively -- i.e., the span of the entire quasi-quote. However, for the expansion of `[qq|b|]` and `[qq|c|]` the source span for `id`, `True`, `False`, and `(||)` are all reported as 5:11-5:14 / 6:11-6:14, i.e., starting at the ""contents"" of the quasi-quote. 
"	edsko
3	7670	StablePtrs should be organized by generation for efficient minor collections	Runtime System	7.7	normal		7.8.1		new	2013-02-06T16:21:42-0800	2013-04-13T04:20:26-0700	Currently, stable pointers are all in one giant pointer table (see markStablePtrTable); this results in pretty bad GC behavior when you create a lot of stable pointers (Peaker has a test-case which he thinks is suffering due to repeated traversal of the stable pointers list.) We should partition them up into generations like we do for mutable lists. There might be some trickiness keeping the table up-to-date after GCs.	ezyang
3	1466	Stack check for AP_STACK	Compiler	6.6.1	normal	normal	7.6.2	simonmar	new	2007-06-28T02:43:51-0700	2013-01-22T08:16:53-0800	"This is a bug I uncovered in the interpreter, that I think is also present in the compiler.

When compiling code for a function or thunk, we aggregate the stack usage from case continuations up to the top of the function/thunk and perform a single stack check.  This normally works fine: we know the maximum amount of stack that will be required in the evaluation of this function/thunk, and we check for it up front.

However, this goes wrong if the evaluation is suspended by an asynchronous exception: the stack is broken into chunks and stored in `AP_STACK` objects, which may later be resumed.  On resumption, we might not have enough stack any more: the code might now be running on another stack entirely, even.

Our proposed solution is as follows:

 * Continuations that require more than a certain amount of stack (say 4k)
   do their own stack checks.

 * an AP_STACK object records the amount of stack available at the time it
   was suspended, if the amount is <4k.  On resumption of an AP_STACK, we
   ensure that at least this amount of stack is available.  (there's a
   spare half-word field in AP_STACK that we can use for this).

The 4k limit is important: it puts a bound on the amount of stack growth due to evaluating an AP_STACK.  Essentially the 4k limit is large enough that it almost never happens."	simonmar
3	7240	Stack trace truncated too much with indirect recursion	Profiling	7.4.1	normal		7.8.1	nomeata	new	2012-09-14T14:02:53-0700	2012-10-16T05:44:04-0700	"This is to write down the improvements suggestions for the stack trace that I had after the HIW talk. Consider:

{{{
$ cat truncstack.hs 
import System.Environment
import Debug.Trace

runThisTwice x y = x y >> x y
main = getArgs >>= runThisTwice go1 . head
go1 l = runThisTwice go2 l
go2 l = runThisTwice go l
go x = traceStack x (error ""done"")
$ ghc --make -prof -fprof-auto truncstack.hs && ./truncstack x
[1 of 1] Compiling Main             ( truncstack.hs, truncstack.o )
Linking truncstack ...
x
Stack trace:
  Main.go (truncstack.hs:8:1-34)
  Main.runThisTwice (truncstack.hs:4:1-29)
  Main.main (truncstack.hs:5:1-42)
  Main.CAF (<entire-module>)
truncstack: done
}}}

Clearly. the programer would want go1 and go2 to be mentioned as well.

I think it would not be too hard to keep the stacktrace more complete and only truncate “real” recursion (i.e. repeating sublists in the stack), or even annotate them with the number of loops. Simon Marlow told me that one need to ensure that a change in the stack does not have unwanted effects on the profiling attributions.

I plan to look into this issue (unless someone shouts “no no don’t do that”)."	nomeata
3	7033	stale .tix files can cause programs built with -fhpc to segfault	Code Coverage	7.4.2	normal		7.8.1		new	2012-06-27T20:09:38-0700	2012-10-14T09:15:22-0700	"In some circumstances, programs built with -fhpc will segfault when old .tix files reference modules that no longer exist.

foo.hs
{{{
import Bar

main = print ""Hello World""
}}}

Bar.hs
{{{
module Bar where

something = 1 :: Int
}}}

{{{
jwlato@compy:~/explorations$ ghc -O -fhpc foo.hs 
[1 of 2] Compiling Bar              ( Bar.hs, Bar.o )
[2 of 2] Compiling Main             ( foo.hs, foo.o )
Linking foo ...
jwlato@compy:~/explorations$ ./foo 
""Hello world""
jwlato@compy:~/explorations$ mv Bar.hs Bar.hs.orig
jwlato@compy:~/explorations$ sed -e 's/import/-- import/' -i.bak foo.hs 
jwlato@compy:~/explorations$ rm *.hi; rm *.o
jwlato@compy:~/explorations$ ghc -O -fhpc foo.hs 
[1 of 1] Compiling Main             ( foo.hs, foo.o )
Linking foo ...
jwlato@compy:~/explorations$ ./foo 
Segmentation fault
}}}

If ""foo.hs"" has a 'module Main where' declaration, instead of a segfault the program exits with a message that 'foo.tix' should be deleted."	jwlato
5	2028	STM slightly conservative on write-only transactions	Compiler	6.8.1	lowest	normal	7.6.2		new	2008-01-09T08:26:12-0800	2012-09-12T04:13:44-0700	"The STM appears to be slightly too conservative on write-only transactions.

It will store a copy of the current (that is, old) value on a writeTVar, even if it was never read from. This can cause a spurious retry.

E.g. {{{atomically $ writeTVar tv 0}}} really has no reason to ever retry. Neither, in fact, does {{{atomically $ mapM (\tv -> writeTVar tv 0) [tv1,tv2,tv3,tv4]}}}.

My suggestion is to instead indicate ""no prior value"" for that TVar, and then make no consistency checks on TVars marked as no prior value...

Jules

"	JulesBean
3	3998	strace breaks System.Process(?)	libraries/process	6.12.1	normal		_|_		new	2010-04-21T02:40:44-0700	2010-05-05T05:54:52-0700	"See http://markmail.org/message/hbf5pf5puvxnxmxo#query:strace%20greenrd%20ghc+page:1+mid:nfzfholb5gbrsyqm+state:results

Still an issue in 6.12.1."	greenrd
3	7786	strange errors when deducing constraints	Compiler	7.7	normal		7.8.1	simonpj	new	2013-03-22T04:08:47-0700	2013-04-22T05:12:19-0700	"Please load attached file in ghci and observe the resulting error message. I have added my commentaries inline to what appears fishy to me. All may technically be ok, but look quite confusing.

{{{
[1 of 1] Compiling Main             ( pr7786.hs, interpreted )

pr7786.hs:74:22:
    Couldn't match type `Intersect
                           [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv'
                  with 'Empty [KeySegment]
    Inaccessible code in
      a pattern with constructor
        Nil :: forall (k :: BOX). Sing (Inventory k) ('Empty k),
      in a pattern binding in
           'do' block
}}}

Yes, ok, (Nil :: Sing Empty) does not unify with (forall xxx. Nil :: Sing xxx).


{{{
    Relevant bindings include
      addSub :: Database inv
                -> Sing [KeySegment] k
                -> Database sub
                -> Maybe (Database (BuriedUnder sub k inv))
        (bound at pr7786.hs:74:1)
      db :: Database inv (bound at pr7786.hs:74:8)
      k :: Sing [KeySegment] k (bound at pr7786.hs:74:11)
      sub :: Database sub (bound at pr7786.hs:74:13)
    In the pattern: Nil
    In the pattern: Nil :: Sing xxx
    In a stmt of a 'do' block:
      Nil :: Sing xxx <- return
                           (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db)

pr7786.hs:78:31:
    Could not deduce (Intersect
                        [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv
                      ~ 'Empty [KeySegment])
    from the context (Intersect
                        [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv
                      ~ 'Empty [KeySegment])
}}}

This one is highly disturbing. I think the user should never see such a message. Scary. ''This is the reason for the ticket''.


{{{
      bound by a pattern with constructor
                 Nil :: forall (k :: BOX). Sing (Inventory k) ('Empty k),
               in a pattern binding in
                    'do' block
      at pr7786.hs:74:22-24
    Relevant bindings include
      addSub :: Database inv
                -> Sing [KeySegment] k
                -> Database sub
                -> Maybe (Database (BuriedUnder sub k inv))
        (bound at pr7786.hs:74:1)
      db :: Database inv (bound at pr7786.hs:74:8)
      k :: Sing [KeySegment] k (bound at pr7786.hs:74:11)
      sub :: Database sub (bound at pr7786.hs:74:13)
    In the second argument of `($)', namely `Sub db k sub'
    In a stmt of a 'do' block: return $ Sub db k sub
    In the expression:
      do { Nil :: Sing xxx <- return
                                (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db);
           return $ Sub db k sub }
Failed, modules loaded: none.
}}}

'''Now comment line 74 and uncomment l. 75 and reload:'''



{{{
pr7786.hs:75:22:
    Couldn't match type `Intersect
                           [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv'
                  with `Intersect
                          [KeySegment] (BuriedUnder sub1 k1 ('Empty [KeySegment])) inv1'
}}}
Hmm, I vaguely understand why those new degrees of freedom arise.


{{{
    NB: `Intersect' is a type function, and may not be injective
}}}

Probably irrelevant, no need to backwards guess here, as we have -XScopedTypeVariables turned on.


{{{
    The type variables `sub', `k', `inv' are ambiguous
    Expected type: Sing
                     (Inventory [KeySegment])
                     (Intersect
                        [KeySegment] (BuriedUnder sub1 k1 ('Empty [KeySegment])) inv1)
      Actual type: Sing
                     (Inventory [KeySegment])
                     (Intersect
                        [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv)
    Relevant bindings include
      addSub :: Database inv1
                -> Sing [KeySegment] k1
                -> Database sub1
                -> Maybe (Database (BuriedUnder sub1 k1 inv1))
        (bound at pr7786.hs:74:1)
      db :: Database inv1 (bound at pr7786.hs:74:8)
      k :: Sing [KeySegment] k1 (bound at pr7786.hs:74:11)
      sub :: Database sub1 (bound at pr7786.hs:74:13)
    In the pattern:
      Nil :: Sing ((sub `BuriedUnder` k) Empty `Intersect` inv)
    In a stmt of a 'do' block:
      Nil :: Sing ((sub `BuriedUnder` k) Empty `Intersect` inv) <- return
                                                                     (buryUnder (dbKeys sub) k Nil
                                                                      `intersectPaths` dbKeys db)
    In the expression:
      do { Nil :: Sing ((sub `BuriedUnder` k) Empty
                        `Intersect` inv) <- return
                                              (buryUnder (dbKeys sub) k Nil
                                               `intersectPaths` dbKeys db);
           return $ Sub db k sub }
Failed, modules loaded: none.
}}}


'''Now comment line 75 and uncomment l. 76 and reload:'''


{{{
[1 of 1] Compiling Main             ( pr7786.hs, interpreted )


pr7786.hs:76:51:
    Couldn't match type `Intersect
                           [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv'
                  with 'Empty [KeySegment]
    Expected type: Sing (Inventory [KeySegment]) ('Empty [KeySegment])
      Actual type: Sing
                     (Inventory [KeySegment])
                     (Intersect
                        [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv)
}}}

Err... But (Nil :: Sing Empty) is ''exactly'' the annotation on the Nil constructor in the GADT definition!

{{{
    Relevant bindings include
      addSub :: Database inv
                -> Sing [KeySegment] k
                -> Database sub
                -> Maybe (Database (BuriedUnder sub k inv))
        (bound at pr7786.hs:74:1)
      db :: Database inv (bound at pr7786.hs:74:8)
      k :: Sing [KeySegment] k (bound at pr7786.hs:74:11)
      sub :: Database sub (bound at pr7786.hs:74:13)
    In the first argument of `return', namely
      `(buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db)'
    In a stmt of a 'do' block:
      Nil :: Sing Empty <- return
                             (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db)
    In the expression:
      do { Nil :: Sing Empty <- return
                                  (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db);
           return $ Sub db k sub }
Failed, modules loaded: none.
}}}

'''Now comment line 76 and uncomment l. 77 and reload:'''

All is dandy!

"	heisenbug
3	7850	Strangely high memory usage on optimized Ackermann function	Compiler	7.6.2	normal		7.6.3		patch	2013-04-20T00:26:50-0700	2013-04-30T03:28:26-0700	"Greetings.

The following post on stack overflow demonstrates some strange behavior in, at least, recent GHC versions (7.4.2 on):

[http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with-haskell-ghc]

The program in question is simple:

{{{
main = print $ ack 4 1

ack :: Int -> Int -> Int
ack 0 !n = n+1
ack m  0 = ack (m-1) 1
ack m  n = ack (m-1) $ ack m (n-1)
}}}

Here are the properties I've been able to deduce so far:

1) When compiled without optimizations, the program uses almost no memory, but of course takes a while.

2) When compiled with optimizations (-O and above), the program eats memory at a staggering rate. It easily freezes my machine in a matter of seconds.

3) -ddump-simpl reveals that the loop is completely unboxed, operating only on Int#. -ddump-prep also shows no lets where allocation would presumably happen.

4) Setting a maximum heap size typically seems to have no effect. When I set it to the minimum heap size with -M4096, even the optimized program seems to run in constant space most of the time. However, using something like -M1000000 seems to result in the outrageous memory usage, and the RTS never catches that far more than 1 megabyte of memory is being used. I had to convince myself that the flag actually does something with another test program.

5) The standard bounded stack also does nothing.

So, we seem to have a program that is allocating vast amounts of (ostensibly) non-heap, non-stack memory; but only when optimized.

I believe I once set the maximum heap to 40960B, and killed the program before it killed my machine. On exiting, I got a heap overflow error. So, my initial stab would be that the completely unboxed loop somehow ''is'' allocating in the heap, but somehow not in a way that ever allows the garbage collector or heap overflow check to run (similar to how a non-allocating loop can block any thread preemption). That's a wild guess, though.

I'm unable to easily investigate the behavior on older GHC versions, unfortunately. So I'm unsure how far back this behavior goes. If I've missed something obvious, I apologize, but this seems like very odd behavior to me."	dolio
4	4081	Strict constructor fields inspected in loop	Compiler	6.13	low		7.6.2	benl	new	2010-05-19T05:21:26-0700	2013-03-05T12:04:31-0800	"Here is a small example to illustrate the problem:

{{{
module T where

data S a b = S !a !b

class C a where
 make :: a -> S a a

instance C Int where
 {-# NOINLINE make #-}
 make n = S n n

foo :: (C a, Num a) => a -> Int -> a
{-# INLINE foo #-}
foo x k = k `seq` m `seq` go k 0
 where
   S m n = make x

   go 0 i = i
   go k i = go (k-1) (i + m)
}}}

{{{
module U where

import T

bar :: Int -> Int -> Int
bar s k = foo s k + 1
}}}

Relying on !LiberateCase seems to be the only way to unbox `m` outside of the loop in `bar`. The seq in `foo` doesn't help because it gets eliminated immediately.

GHC does have enough information to do this:

{{{
U.bar =
 \ (s_aaw [Dmd=Just S(A)] :: GHC.Types.Int)
   (k_aax [Dmd=Just U(L)] :: GHC.Types.Int) ->
   case k_aax
   of k1_ajh [Dmd=Just U(L)] { GHC.Types.I# ipv_ajj [Dmd=Just A] ->
   case T.$fCInt_$cmake s_aaw of _ { T.S m_ajy [Dmd=Just U(T)] _ ->
   ...
}}}

Note the demand on `m`. If it was an argument instead of a local binding, it would be unboxed by w/w.

Also, the seq does help if we use lazy pairs instead of strict ones.
"	rl
4	4267	Strictness analyser is to conservative about passing a boxed parameter	Compiler	6.13	low		7.6.2		new	2010-08-22T15:19:16-0700	2012-09-12T04:12:29-0700	"Given the following two modules:

`Fold.hs`:

{{{
module Fold (Tree, fold') where

data Tree a = Leaf | Node a !(Tree a) !(Tree a)

-- Strict, pre-order fold.
fold' :: (a -> b -> a) -> a -> Tree b -> a
fold' f = go
  where
    go z Leaf = z
    go z (Node a l r) = let z'  = go z l
                            z'' = f z' a
                        in z' `seq` z'' `seq` go z'' r
{-# INLINE fold' #-}
}}}

`FoldTest.hs`:

{{{
module FoldTest (sumTree) where

import Fold

sumTree :: Tree Int -> Int
sumTree = fold' (+) 0
}}}

I'd expect that the accumulator `z` used in `go` to be an unboxed
`Int#`.  However, it's boxed:

{{{
sumTree1 :: Int
sumTree1 = I# 0

sumTree_go :: Int -> Fold.Tree Int -> Int
sumTree_go =
  \ (z :: Int) (ds_ddX :: Fold.Tree Int) ->
    case ds_ddX of _ {
      Fold.Leaf -> z;
      Fold.Node a l r ->
        case sumTree_go z l of _ { I# z' ->
        case a of _ { I# a# ->
        sumTree_go (I# (+# z' a#)) r
        }
        }
    }

sumTree :: Fold.Tree Int -> Int
sumTree =
  \ (eta1_B1 :: Fold.Tree Int) ->
    sumTree_go sumTree1 eta1_B1
}}}

Given this definition of `fold'`

{{{
fold' :: (a -> b -> a) -> a -> Tree b -> a
fold' f = go
  where
    go z _ | z `seq` False = undefined
    go z Leaf = z
    go z (Node a l r) = go (f (go z l) a) r
{-# INLINE fold' #-}
}}}

I get the core I want.  However, this version isn't explicit in that
the left branch (i.e. `go z l`) should be evaluated before `f` is
called on the result.  In other words, I think my first definition is
the one that correctly expresses the evaluation order, yet it results
in worse core.
"	tibbe
4	3924	Strictness analyser missing useful strictness	Compiler	6.12.1	low		7.6.2		new	2010-03-17T02:02:35-0700	2012-09-12T04:12:22-0700	"Roman Beslik (beroal@ukr.net) writes: I provide a sample program which causes a strange behavior of strictness 
analyzer.

'''variant 1'''
{{{
module StrictUnusedArg (main) where
f2 :: Int -> Int -> Int
f2 x1 = if x1 == 0 then (\x0 -> x0) else let
     y = x1 - 1
     in f3 y y
f3 :: Int -> Int -> Int -> Int
f3 x2 = if x2 == 0 then f2 else let
     y = x2 - 1
     in f4 y y
f4 :: Int -> Int -> Int -> Int -> Int
f4 x3 = if x3 == 0 then f3 else let
     y = x3 - 1
     in \x2 x1 x0 -> f4 y x2 x1 (y + x0)
main = print (f2 100 0)
}}}
I expect that all arguments will be unboxed. ""-ddump-simpl"" reveals that actually types are
{{{
f2 :: Int# -> Int -> Int
f3 :: Int# -> Int -> Int -> Int
}}}
So when ""f3"" calls ""f2"" it unboxes the argument named ""x1"" and when ""f2"" calls ""f3"" it boxes the argument named ""x1"". ""-ddump-stranal"" knows strictness only for the ""x2"" of ""f3"" and ""x1"" of ""f2"".
{{{
f2:
[Arity 1
  Str: DmdType U(L)]
f3:
[Arity 1
  Str: DmdType U(L)]
}}}
I also can force the analyzer to think that ""x1"" and ""x0"" are strict by 
eta-expanding ""f3"":
'''variant 2'''
{{{
f3 x2 x1 x0 = if x2 == 0 then f2 x1 x0 else let
     y = x2 - 1
     in f4 y y x1 x0
}}}
""-ddump-stranal"" yields:
{{{
f3:
[Arity 3
  Str: DmdType U(L)U(L)U(L)m]
f2:
[Arity 2
  Str: DmdType U(L)U(L)m]
}}}
I even do not use ($!).
So, the questions: Is it possible to change the strictness analyzer so 
it will treat ""variant 1"" as ""variant 2""? Are these changes big?

Compiled with options:
{{{
$ ghc --make -fstrictness -fPIC -O3 -fforce-recomp blah-blah-blah
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
}}}
"	simonpj
3	457	Strictness problem	Compiler	6.4.1	normal	minor	_|_		new	2005-09-15T03:21:38-0700	2010-10-16T12:38:22-0700	"{{{
As requested, this is a resubmission (and update) of a
previously reported bug, to get it into the bug tracker.

The following program should output something involving
Correct:

> module Main where

> f x = case x of
>   x@True  -> \y -> x && y
>   x@False -> \y -> x && y

> main = putStrLn $ f (error ""Correct"") `seq` ""Error""

However, whether it does so is a non-trivial function
of the GHC version and optimisation settings:

GHC version     -O2?  Correct?
------------------------------
4.08.1          No    Yes
4.08.1          Yes   No
5.04.2          No    No
5.04.2          Yes   Yes
6.0.1           _     No
6.2.2           _     No
6.4             _     No
6.4.1.20050820  _     No

All tests were run on a Solaris system.

Different fs give different behaviour, at least for
6.0.1. Try e.g.

> f x = case x of
>   True  -> id
>   False -> id

}}}"	nilsanders
4	5142	stub header files don't work with the MS C compiler	Compiler	7.0.3	low		7.6.2	simonmar	new	2011-04-20T01:17:17-0700	2012-09-12T04:13:28-0700	"Specifically we need to conditionalise the stdcall annotation, using `__attribute__((__stdcall__))` for gcc and and `__stdcall` for Microsoft's compiler.

See [http://blogs.msdn.com/b/satnam_singh/archive/2011/04/19/creating-a-windows-dll-from-a-haskell-program-and-calling-it-from-c.aspx]"	simonmar
3	6065	Suggested type signature causes a type error (even though it appears correct)	Compiler (Type checker)	7.4.1	normal		_|_		new	2012-04-30T11:02:24-0700	2012-06-05T06:12:36-0700	The attached file, MWE.hs, contains an experiment attempting a rudimentary encoding of extensible ASTs in Haskell (without using compdata or a similar package relying upon OverlappingInstances and so forth).  The definition of the upcast function appears to be correct.  Compiling without a type signature produces a warning and the suggestion to include a type signature.  Including the suggested type signature (which appears to be the correct one) causes a type error.	tvynr
3	7803	Superclass methods are left unspecialized	Compiler	7.6.2	normal		7.8.1		new	2013-04-01T18:14:30-0700	2013-04-13T07:31:07-0700	"In the attached code, Foo.foo1 gets compiled (by ghc -O2) into a call to the unspecialized version of Lib.exp5Tail, even though all the related functions are marked INLINE or SPECIALIZE.

The problem seems to be that GHC creates a top-level overloaded function after the specialization pass, so the function never gets specialized.

This might be the same issue as #7785, but the workaround I posted there does not work here."	akio
4	4049	Support for ABI versioning of C libraries	Build System	6.12.2	low		7.6.2		new	2010-05-05T09:52:50-0700	2012-09-12T04:12:24-0700	"Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.

Also it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.

More informations:
http://bugs.gentoo.org/show_bug.cgi?id=290974
http://bugs.gentoo.org/show_bug.cgi?id=311361"	uzytkownik
3	7604	"System.Directory.canonicalizePath """" behaviour differs between platforms"	libraries/directory	7.6.1	normal		7.8.1		new	2013-01-17T17:30:38-0800	2013-04-12T15:48:22-0700	"On Linux, `System.Directory.canonicalizePath """"` gives an exception. On i386 OS X, it returns the current directory.

In a `System.Directory` function, we should consistently do one or the other.
"	igloo
3	5280	System.Random commits (rand `mod` base) error.	libraries/random	7.0.3	normal		_|_	rrnewton	new	2011-06-26T19:41:22-0700	2011-11-08T13:00:35-0800	"You have probably at some point come across the C code ""{{{rand() % base}}}""'.  It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine {{{rand()}}} producing numbers in say `[0,15)` and base being `10`.

In the function `System.Random.randomIvalInteger` you can see the same thing happening.  

The only way I know how to deal with it and generate uniform integers within a range is to artificially restrict the range of the source of randomness to be a multiple of the desired base.  It can be done simply by throwing out some random results.

This strategy appears to be used by GMP's mpz_urandomm function:

    http://gmplib.org/manual/Integer-Random-Numbers.html#Integer-Random-Numbers

The file `urandomm.c` has the code.
"	rrnewton
4	4218	System.Random is way too lazy	Compiler	6.12.3	low		7.6.2	rrnewton	new	2010-07-24T04:53:15-0700	2012-09-12T04:12:28-0700	"randomRs is too lazy, generates lists of large lazy-state thunks, rather than lists of strict values.

Test program is attached.

Also, randomIO is too lazy, and builds up huge thunks. Using (randomIO >>= evaluate) is fine, however.

Fails with stack overflow:
{{{
  rs <- replicateM 1000000 evaluate :: IO [Int]
  print $ last rs
}}}
Works:
{{{
  rs <- replicateM 1000000 (evaluate =<< randomIO) :: IO [Int]
  print $ last rs
}}}
"	EyalLotem
3	5278	System.Random.randomIvalInteger makes invalid assumptions about RandomGen	libraries/random	7.0.3	normal		_|_	rrnewton	new	2011-06-26T18:46:31-0700	2011-11-08T13:00:41-0800	"The existing API for `System.Random.RandomGen` allows a random number generator (RNG) to produce Ints within an arbitrary range specified by `genRange`.  

For example, the following `RandomGen` produces only zeros and ones, but should be legitimate:

{{{
import System.Random

data BinRNG = BinRNG StdGen
instance RandomGen BinRNG where 
  next (BinRNG g) = (x `mod` 2, BinRNG g')
    where (x,g') = next g
  split (BinRNG g) = (BinRNG g1, BinRNG g2)
    where (g1,g2) = split g
  genRange _ = (0,1)

ls :: [Int]
ls = randoms (BinRNG$ mkStdGen 38388)

main = print $ take 20 ls
}}}

But `System.Random.randomIvalInteger` makes invalid assumptions about the amount of randomness produced by `next`.  (Specifically, assuming that it creates the same amount as `StdGen`.)  Thus, the above program will create an output with only a couple of unique ints (rather than 2^64). 

For example:

{{{
[4611734781337924537,4611734781337924537,-9223323645458902796,
-9223323645458902797,4611734783485408099,4611734783485408098,
-9223323645458902796,-9223323647606386357,4611734781337924538,
-9223323645458902796,-9223323645458902797,
-9223323647606386357,4611734783485408098,4611734783485408098,
-9223323647606386357,4611734781337924538,4611734781337924537,
-9223323645458902796,4611734783485408099,4611734781337924538]
}}}
"	rrnewton
3	7774	T5313 fails	GHC API	7.7	normal		7.8.1		new	2013-03-16T16:50:42-0700	2013-04-13T06:26:52-0700	"T5313 fails
{{{
=====> T5313(normal) 76 of 104 [0, 0, 0]
cd . && '/home/ian/ghc/git/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T5313 T5313.hs  -package ghc  >T5313.comp.stderr 2>&1
cd . && ./T5313 ""/home/ian/ghc/git/ghc/inplace/lib""   </dev/null >T5313.run.stdout 2>T5313.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:

Stderr:
T5313: <command line>: can't load .so/.DLL for: /home/ian/ghc/git/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130316.so (/home/ian/ghc/git/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130316.so: undefined symbol: stg_newByteArrayzh)

*** unexpected failure for T5313(normal)
}}}
"	igloo
3	7305	T5975a is broken on Windows	Test Suite	7.6.1	normal		7.8.1		new	2012-10-08T05:26:11-0700	2012-10-08T05:26:11-0700	"{{{
=====> T5975a(ghci) 84 of 91 [0, 0, 0]
cd . && touch föøbàr1.hs
cd . && HC='c:/simonmar/ghc-validate/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'c:/simonmar/ghc-validate/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history     <T5975a.script >T5975a.run.stdout 2>T5975a.run.stderr
Actual stderr output differs from expected:
--- /dev/null   2012-10-08 13:22:40 +0100
+++ ./T5975a.run.stderr 2012-10-08 13:22:40 +0100
@@ -0,0 +1,2 @@
+
+<no location info>: can't find file: föøbàr1.hs
}}}

I've spent a bit of time looking at this, but I'm lost in a maze of Unicode encodings.  So I'll just mark the test broken on Windows for now.
"	simonmar
3	7484	Template Haskell allows building invalid record fields/names	Template Haskell	7.6.1	normal		7.8.1		new	2012-12-06T05:31:12-0800	2013-04-13T04:15:51-0700	"This is not really a bug, more like a unintuitive behaviour.

Due to a bug in my definitions, I was passing a name like `""opTestDelay ""` (note extra space) to a TH splice builder, which ended up with:

{{{
data OpCode
  = OpTestDelay {opDelayDuration  :: Double,
                 opDelayOnMaster :: Bool,
                 opDelayOnNodes :: [Ganeti.Types.NonEmptyString],
                 opDelayRepeat :: Ganeti.Types.NonNegative Int}
}}}

Note the double space around the first record field. This results in the actual accessor functions having the space in the name, which makes them unusable from normal code.

This seems to be allowed as well in other TH constructs:

{{{
λ> runQ $ return (ValD (VarP (mkName ""a "") ) (NormalB (LitE (IntegerL 5))) [])
ValD (VarP a ) (NormalB (LitE (IntegerL 5))) []
}}}

I think that names should not be allowed to contain invalid identifiers (that would make them non-usable in normal Haskell code), but I'm not sure - maybe TH is designed to allow you to shoot yourself in the foot indeed. Anyway, opening this bug just in case.

Tested and behaves the same both on 6.12 and 7.6."	iustin
4	4837	Template Haskell does not work in a profiled compiler.	Profiling	7.0.1	low		7.6.2		new	2010-12-12T18:02:59-0800	2013-03-20T22:39:59-0700	"Template Haskell does not work if the compiler itself is built profiles.  Because of this we cannot debug GHC compile time performance problems when compiling Data.Vector and DPH as they use Template Haskell. #4172 is related.

Trying to use Template Haskell in a profiled compiler currently triggers the assertion at {{{main/HscMain.hs:1245}}}

Supporting this would also mean that we can run GHCi with profiled code!"	benl
3	7667	Template Haskell fails to recognize type operator/function +	Template Haskell	7.6.2	normal		7.8.1		new	2013-02-06T07:46:07-0800	2013-04-13T04:16:03-0700	"The following message is issued for a valid TH program.

{{{
Main.hs:7:1:
    Illegal type constructor or class name: `+'
    When splicing a TH declaration:
      type instance GHC.TypeLits.+ 1 2 = 3
Failed, modules loaded: Test1.
}}}

Code attached. 

The program is attempting to capture the name +,
as used by Nat at the type level.

The problem appears to be in Convert.hs

{{{
 -- Convert.hs

     okOcc :: OccName.NameSpace -> String -> Bool
     okOcc _ [] = False 
     okOcc ns str@(c:_) | OccName.isVarNameSpace ns = startsVarId c || startsVarSym c
                        | otherwise = startsConId c || startsConSym c || str == ""[]""

}}}

+ is rejected, by okOcc, even though it is acceptable, the symbol neither starts with upper-case, or ':'.


I have tried using reify to extract the *actual* name from other sources (rather than use mkNameG_tc), and it fails in the same way.

"	andygill
2	4364	Template Haskell: Cycle in type synonym declarations	Compiler (Type checker)	7.1	high		7.8.1	simonpj	new	2010-10-04T10:27:24-0700	2013-03-22T11:32:01-0700	"`type-level-numbers-0.1` doesn't build with 7.0.1 RC 1. Here's the essence:

{{{
{-# LANGUAGE TemplateHaskell #-}
module Q where

data Z

type N0 = $( [t| Z |] )
type N1 = $( [t| Z |] )
}}}

{{{
$ ghc --make m.hs
[1 of 1] Compiling Q                ( m.hs, m.o )

m.hs:7:1:
    Cycle in type synonym declarations:
      m.hs:7:1-23: type N0 = $([t| Z |])
      m.hs:8:1-23: type N1 = $([t| Z |])
}}}
"	igloo
4	1476	Template Haskell: splicing types and patterns	Template Haskell	6.6.1	low	normal	_|_		new	2007-07-01T04:53:44-0700	2013-01-22T08:18:59-0800	"In http://www.haskell.org/pipermail/template-haskell/2003-February/000021.html Simon Peyton Jones writes:
{{{
We claim to allow you to write splices in (a) types and (b) patterns.
I'm very dubious about (b). Consider]
    x = 4
      
    y :: Patt 
    y = [p| ... |]

    f $y = x

Question: where is x bound?  It looks as though x can be bound by the
spliced-in pattern or by the top-level binding.  You can't tell without
knowing what $y expands to.  We argue in our paper against non-top-level
declaration splices because that would lead to ambiguity of exactly this
sort.

It turns out that it's very inconvenient to implement pattern splices in
GHC, for exactly this reason.  We can't figure out the binding structure
till we expand the splice.  We can't expand the splice till typechecking
time.  But the renamer currently fixes the binding structure before type
checking.    Changing this would be a big upheaval.

Conclusion: pattern splices are hard to implement, and dubious from a
programming point of view.  I propose to drop them, for now at least.


Type splices have some similar echoes.  Consider
      
    y :: Type 
    y = [t| a -> a |]

    f :: $y

What is f polymorphic in?   The trouble concerns Haskell's implicit
quantification.  I guess there are three possibilities:

a) $y expands to ""a -> a"", and that is implicitly universally quantified
to ""forall a. a->a"".
b) The implicit quantification happens at the [t| ...|] brackets, so
that $y expands to
    ""forall a. a->a""
c) $y expands to ""a -> a"" with no implicit quantification anywhere.

I'm pretty sure that we should adopt (b).  After all, we want a
lexical-scoping rule for TH, so we have to say where 'a' is bound.

That would still in principle allow
      
    y :: Type
    y = return (Tvar ""a"" `Arrow` Tvar ""a"")

Since it's the renamer that does implicit quantification, it'd be quite
awkward to make the implicit quantification at the splice site ""see"" the
free variables 'a'.

The link with the pattern stuff is this.  If you see
    f :: $y -> b

then what are the implicit for-alls?  My answer: the implicit for-alls
are just for ""b"", not for any free vars of $y.
}}}

Since then, the only solution for pattern splices I recall seeing is
{{{
f ${x,z}y = x
}}}
which asserts that the splice introduces the set of identifiers `{x,z}`."	igloo
2	7200	template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma	Template Haskell	7.0.4	high		7.8.1	duncan	new	2012-08-29T08:19:57-0700	2012-10-14T17:14:06-0700	"It looks like there's a missing pragma:

{{{
[1 of 7] Compiling Language.Haskell.TH.Syntax.Internals ( Language/Haskell/TH/Syntax/Internals.hs, dist/build/Language/Haskell/TH/Syntax/Internals.o )
[2 of 7] Compiling Language.Haskell.TH.Syntax ( Language/Haskell/TH/Syntax.hs, dist/build/Language/Haskell/TH/Syntax.o )
[3 of 7] Compiling Language.Haskell.TH.PprLib ( Language/Haskell/TH/PprLib.hs, dist/build/Language/Haskell/TH/PprLib.o )

Language/Haskell/TH/PprLib.hs:55:10:
    Illegal instance declaration for `Show Doc'
      (All instance types must be of the form (T t1 ... tn)
       where T is not a synonym.
       Use -XTypeSynonymInstances if you want to disable this.)
    In the instance declaration for `Show Doc'
}}}
"	tibbe
3	7558	Terrible error message when given and wanted are both insoluble	Compiler	7.6.1	normal		7.8.1	simonpj	new	2013-01-08T00:47:50-0800	2013-04-12T15:15:19-0700	"In fixing the ambiguity check I came across this tricky program
{{{
data T a b where
  MkT :: (a~Maybe b) => a -> Maybe b -> T a b

f :: T a a -> Bool
f (MkT x y) = [x,y] `seq` True
}}}
We get an error message 
{{{
Frozen2.hs:12:18:
    Could not deduce (a ~ Maybe a)
    from the context (a ~ Maybe a)
      bound by a pattern with constructor
                 MkT :: forall a b. a ~ Maybe b => a -> Maybe b -> T a b,
               in an equation for `f'
      at Frozen2.hs:12:4-10
      `a' is a rigid type variable bound by
          the type signature for f :: T a a -> Bool at Frozen2.hs:11:6
    Relevant bindings include
      f :: T a a -> Bool (bound at Frozen2.hs:12:1)
      x :: a (bound at Frozen2.hs:12:8)
      y :: Maybe a (bound at Frozen2.hs:12:10)
    In the expression: y
    In the first argument of `seq', namely `[x, y]'
    In the expression: [x, y] `seq` True
}}}
This error message is nonsense!  It arises becuase the ""insolubles"" get both a ""given"" insoluble `(a~T a)` and a ""wanted"" insoluble with the same type.

This can also arise, rather more easily, with the new ambiguity check, via an inaccessible context
{{{
foo :: forall a. (a ~ T a) => a -> a 
}}}
It's a bit obscure, but it needs fixing."	simonpj
2	7298	Test 2228 fails with dynamic-by-default	GHCi	7.6.1	high		7.8.1	igloo	new	2012-10-04T18:08:22-0700	2012-10-04T18:08:22-0700	"{{{
=====> 2228(normal) 6 of 8 [0, 0, 0]
cd . && $MAKE --no-print-directory -s 2228    </dev/null >2228.run.stdout 2>2228.run.stderr
Actual stdout output differs from expected:
--- ./2228.stdout       2011-07-21 12:03:54.000000000 +0100
+++ ./2228.run.stdout   2012-10-05 02:07:04.000000000 +0100
@@ -1,2 +1,2 @@
 BlockBuffering Nothing
-BlockBuffering Nothing
+NoBuffering
*** unexpected failure for 2228(normal)
}}}
"	igloo
5	2805	Test ffi009(ghci) fails on PPC Mac OS X	GHCi	6.11	lowest	normal	7.6.2		new	2008-11-24T01:57:07-0800	2012-09-12T04:14:04-0700	"The test ffi009(ghci) has failed for a while on PPC Msc OS X (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/156/steps/runtestsuite/logs/unexpected):
{{{
=====> ffi009(ghci)
cd ./ffi/should_run && '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin  -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci  -fglasgow-exts <ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 98633 Illegal instruction     '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 132 )
Stdout:
Testing 5 Int arguments...
True
True
True
True
True
True
True
True
True
True
Testing 11 Double arguments...

Stderr:

*** unexpected failure for ffi009(ghci)
}}}
An extract from the so-called crash report indicates a jump into the wild:
{{{
Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000002, 0x00000000027ffd04
Crashed Thread:  2
...
Thread 2 Crashed:
0   ???                                 0x027ffd04 0 + 41942276
1   ghc                                 0x012da320 setThreadLocalVar + 16
2   ghc                                 0x012fa87c ffi_call_DARWIN + 204 (darwin.S:131)
3   ghc                                 0x012fa3a0 ffi_call + 208 (ffi_darwin.c:457)
4   ghc                                 0x012cacb8 interpretBCO + 4984
5   ghc                                 0x012d46d0 schedule + 1024
6   ghc                                 0x012d4d84 workerStart + 84
7   libSystem.B.dylib                   0x9292f658 _pthread_start + 316
}}}
When the test is run with a ghc built with {{{GhcDebugged=YES}}} (see http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking and {{{mk/config.mk}}}), an assertion failure is reported instead:
{{{
=====> ffi009(ghci)
cd . && '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin  -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci  -fglasgow-exts <ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 43988 Abort trap              '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 134 )
Stdout:

Stderr:
ffi009: internal error: ASSERTION FAILED: file Linker.c, line 4380

    (GHC version 6.11.20081121 for powerpc_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

*** unexpected failure for ffi009(ghci)
}}}
The assertion failure is reported from this context in {{{Linker.c}}}:
{{{
                    if(reloc->r_pcrel)
                    {
#ifdef powerpc_HOST_ARCH
                            // In the .o file, this should be a relative jump to NULL
                            // and we'll change it to a relative jump to the symbol
                        ASSERT(word + reloc->r_address == 0);
                        jumpIsland = (unsigned long)
                                        &makeSymbolExtra(oc,
                                                         reloc->r_symbolnum,
                                                         (unsigned long) symbolAddress)
                                         -> jumpIsland;
                        if(jumpIsland != 0)
                        {
                            offsetToJumpIsland = word + jumpIsland
                                - (((long)image) + sect->offset - sect->addr);
                        }
#endif
                        word += (unsigned long) symbolAddress
                                - (((long)image) + sect->offset - sect->addr);
                    }
}}}
The relocations leading to the assertion failure are required by branch instructions generated by {{{gcc}}} for {{{ffi009_stub.c}}} that contains expressions of the form {{{symbol+constant}}} (where {{{symbol}}} is an external symbol) whose distance to the instruction needs to be packed into a 24-bit field. An example is
{{{
        bl saveFP+56 ; save f28-f31
}}}
and there are actually 4 cases like this in the code generated by {{{gcc}}} for {{{ffi009_stub.c}}}.

This problem does not appear particularly easy to solve: The mechanism used when such a branch needs to address code that cannot be addressed using a 24-bit relative address is to create so-called jump islands, which are small, close-by pieces of code that (hopefully, but see #1845) *can* be reached using 24-bit relative addressing. The branch is changed to address the jump island which, in turn, constructs the actual 32-bit address and branches to it. Currently, however, this mechanism, for the PPC Mac OS X architecture, is limited to a single jump island per external symbol and is not capable of handling the addressing of external symbols with constants added to them. Handling the adding of a constant is doable, I believe, but the problem is that the same external symbol may appear multiple times with different constants added. For example, in addition to the above case, the code for {{{ffi009_stub.c}}} also includes
{{{
        bl saveFP+28 ; save f21-f31
}}}
which would require creating two jump islands for the single symbol {{{saveFP}}}.

Possible solutions:

 1. Make a special case out of the specific symbols concerned here. This would involve creating a limited list of different jump islands for these symbols, to be used when different constants were added.
 1. Generalize, somehow, the present jump island mechanism to allow more flexibility. It is undoubtably possible to do this, but it does not seem to be particularly easy to do.
 1. The {{{-mlongjump}}} option actually causes {{{gcc}}} to replace the critical relative brach instructions by inline code, at the expense of generating longer and potentially slower code for all calls and possibly other branches as well. And if we try this, we get:
{{{
ffi009: internal error: 
unknown relocation 13
    (GHC version 6.11.20081121 for powerpc_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
 (relocation type 13 is PPC_RELOC_JBSR) so Linker.c needs to be extended to handle this type also.

Any advice on how to proceed in this matter, additional ideas and views, would be most welcome.

Best regards
Thorkil"	thorkilnaur
3	7399	Test Posix004 fails in test-suite	libraries/unix	7.6.1	normal		7.8.1		new	2012-11-08T04:55:39-0800	2013-04-12T11:22:50-0700	"After a standard build of ghc-7.6.1 on debian wheezy, the test-suite fails on the test posix004. 

The error given is: 
{{{
Wrong exit code (expected 0 , actual 1 )
Stdout:

Stderr:
posix004: unexpected termination cause

*** unexpected failure for posix004(normal)
}}}
"	paulh
3	7738	Testsuite failures for ghci tests normalising stderr output for .exe	Test Suite		normal		7.8.1		patch	2013-03-04T14:36:22-0800	2013-04-12T17:16:12-0700	"On GHC-Head:

Tests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr. 

Here's an example of what happens currently:
{{{
--- ./getDirContents002.stderr-mingw32  2013-02-09 21:09:27 -0500
+++ ./getDirContents002.run.stderr      2013-03-04 17:29:34 -0500
@@ -1 +1 @@
-getDirContents002.exe: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)
+getDirContents002: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)
*** unexpected failure for getDirContents002(ghci)
}}}
"	rassilon
3	7739	Testsuite failures for HPC way tests on Windows	Test Suite		normal		7.8.1		patch	2013-03-04T15:03:52-0800	2013-04-12T17:16:23-0700	"Here's what happens on GHC-HEAD:

{{{
=====> annrun01(hpc) 15 of 3566 [0, 0, 6]
cd ./annotations/should_run && $MAKE -s --no-print-directory config
Creating Config.hs ...
cd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --make -o annrun01 annrun01 -O -fhpc -hpcdir .hpc.annrun01 -package ghc  >annrun01.comp.stderr 2>&1
cd ./annotations/should_run && ./annrun01    </dev/null >annrun01.run.stdout 2>annrun01.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:

Stderr:
in module 'Config'
Hpc failure: module mismatch with .tix/.mix file hash number
(perhaps remove annrun01.exe.tix file?)

*** unexpected failure for annrun01(hpc)
}}}

The cause appears to be due to not cleaning up .exe.tix files.
After deleting the files the tests pass again.
"	rassilon
4	4863	TH crashes if you reify the Name of a dfun	Template Haskell	7.0.1	low		_|_	simonpj	new	2010-12-26T04:39:14-0800	2011-01-13T04:06:21-0800	"{{{
Prelude Language.Haskell.TH Language.Haskell.TH.Syntax> $(fmap show (classInstances ''Eq [ConT ''Int] >>= reify . head) >>= lift)

<interactive>:1:3:
    Exception when trying to run compile-time code:
      <interactive>: panic! (the 'impossible' happened)
  (GHC version 7.0.1 for x86_64-unknown-linux):
	reifyType PredTy
    <pred>base:GHC.Classes.Eq{tc 23} ghc-prim:GHC.Types.Int{(w) tc 3J}

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

      Code: (>>=)
              fmap
                (show)
                ((>>=)
                   classInstances 'Eq [Language.Haskell.TH.Syntax.ConT 'Int]
                   (.) reify head)
              lift
    In the expression:
      $(fmap show (classInstances 'Eq [ConT 'Int] >>= reify . head)
      >>=
        lift)
    In an equation for `it':
        it
          = $(fmap show (classInstances 'Eq [ConT 'Int] >>= reify . head)
            >>=
              lift)
}}}
The same thing happens when compiling with ghc rather than using GHCi.  Also, it looks like the pretty printer is displaying {{{ ''Eq }}} and {{{ ''Int }}} incorrectly."	guest
3	6062	TH treats non-functions in function position inconsistently	Compiler	7.5	normal		7.8.1	simonpj	new	2012-04-30T07:39:58-0700	2012-10-07T10:25:26-0700	"I start GHCi like this:
{{{
~/bin/ghci -XTemplateHaskell
}}}

My aim is to use TH to rewrite certain application-looking (syntactically) constructs to semantically valid haskell code, that passes the type-checker (c.f. Conor McBride's ""idiom brackets"").

But I already fail at very simple things, because GHC seems to type-check the TH quotation's innards...

This works:
{{{
Prelude> :t [| id id |]
[| id id |]
  :: Language.Haskell.TH.Syntax.Q Language.Haskell.TH.Syntax.Exp
}}}

This is also accepted, though it is clearly not typeable:
{{{
Prelude> :t [| 1 1 |]
[| 1 1 |]
  :: Language.Haskell.TH.Syntax.Q Language.Haskell.TH.Syntax.Exp
}}}

Encouraged by this I try:
{{{
Prelude> :t [| False True |]
<interactive>:1:4:
    Couldn't match expected type `Bool -> t0' with actual type `Bool'
    The function `False' is applied to one argument,
    but its type `Bool' has none
    In the Template Haskell quotation [| False True |]
    In the expression: [| False True |]
}}}

Bummer! Somehow the type-checker does get into business with ""expressions"" inside quotations.

I believe this is a bug, and a quotation should be built for {{{[| False True |]}}} in spite of {{{False True}}} not being typeable.

I know that using quasi-quotations I can build my own parser and rewrite engine around this, but that is a tad heavyweight for me and I'd like to understand the root of the above inconsistency and why the type checker gets active in some cases above, but not in others."	heisenbug
3	5641	The -L flag should not exist	Profiling	7.2.1	normal		7.6.2		new	2011-11-16T05:11:03-0800	2012-10-05T07:35:49-0700	Why does the -L flag exist?  The .hp file should contain untruncated strings, and any truncation of the names should be done in hp2ps.	augustss
3	7045	The `Read` instance of `Rational` does not support decimal notation	libraries/base	7.4.2	normal		7.6.2		new	2012-07-03T01:17:13-0700	2012-09-12T04:12:15-0700	"{{{
main = print (1.10 :: Rational)
}}}

is legal whereas

{{{
main = print (read ""1.10"" :: Rational)
}}}
fails at runtime with ""Prelude.read: no parse""

The same applies to ""1E10"", but the e-notation should be rejected in both cases (see #7044)
"	maeder
3	5470	The DPH library needs to support PData and PRepr instances for more than 15-tuples	Data Parallel Haskell	7.3	normal		7.6.2	chak	new	2011-09-08T00:35:15-0700	2012-09-12T04:12:04-0700	"Currently, `Data.Array.Parallel.PArray.PDataInstances` only generates tuple instances up to 6-tuple.  This is not sufficient as these instances are used for environments of closures by the vectoriser — i.e., once a closures has more than 15 free variables, the compiler fails with `VectMonad.lookupFamInst: not found`.

"	chak
4	4296	The dreaded SkolemOccurs problem	Compiler	6.12.3	low		7.6.2	simonpj	new	2010-09-07T06:35:20-0700	2012-09-12T04:12:29-0700	"The ""!SkolemOccurs"" problem is a celebrated difficulty with combining (a) termination and (b) completeness, in this example:
{{{
type instance F [a] = [F a]
f :: (F [a] ~ a) => ...
}}}
Currently we err on the side of completeness, and lose termination:
{{{
Simple20.hs:9:1:
    Context reduction stack overflow; size = 21
    Use -fcontext-stack=N to increase stack size to N
      co :: F [F (F (F (F (F (F (F (F (F (F a)))))))))]
              ~
            F (F (F (F (F (F (F (F (F (F a)))))))))
      co :: F (F (F (F (F (F (F (F (F a))))))))
              ~
            [F (F (F (F (F (F (F (F (F (F a)))))))))]
      co :: F [F (F (F (F (F (F (F (F (F a))))))))]
              ~
            F (F (F (F (F (F (F (F (F a))))))))
      co :: F (F (F (F (F (F (F (F a)))))))
              ~
            [F (F (F (F (F (F (F (F (F a))))))))]
      co :: F [F (F (F (F (F (F (F (F a)))))))]
              ~
            F (F (F (F (F (F (F (F a)))))))
      co :: F (F (F (F (F (F (F a))))))
              ~
            [F (F (F (F (F (F (F (F a)))))))]
      co :: F [F (F (F (F (F (F (F a))))))] ~ F (F (F (F (F (F (F a))))))
      co :: F (F (F (F (F (F a))))) ~ [F (F (F (F (F (F (F a))))))]
      co :: F [F (F (F (F (F (F a)))))] ~ F (F (F (F (F (F a)))))
      co :: F (F (F (F (F a)))) ~ [F (F (F (F (F (F a)))))]
      co :: F [F (F (F (F (F a))))] ~ F (F (F (F (F a))))
      co :: F (F (F (F a))) ~ [F (F (F (F (F a))))]
      co :: F [F (F (F (F a)))] ~ F (F (F (F a)))
      co :: F (F (F a)) ~ [F (F (F (F a)))]
      co :: F [F (F (F a))] ~ F (F (F a))
      co :: F (F a) ~ [F (F (F a))]
      co :: F [F (F a)] ~ F (F a)
      co :: F a ~ [F (F a)]
      co :: F [F a] ~ F a
      co :: a ~ [F a]
      co :: F [a] ~ a
}}}
"	simonpj
3	7309	The Ix instance for (,) leaks space in range	libraries (other)	7.6.1	normal		_|_		new	2012-10-08T06:55:17-0700	2013-04-12T08:05:04-0700	"(at least if you take leak to mean unexpected space behaviour).

This was brought to my attention via http://stackoverflow.com/questions/12780497/puzzling-memory-behavior-in-haskell where someone created a `6×10^6`-array and was surprised that showing the array caused an additional `(3+2)*8*10^6` bytes to be used. The reason (as far as I could tell) was this code:

{{{
instance (Ix a, Ix b) => Ix (a, b) where
    range ((l1,l2),(u1,u2)) = [ (i1,i2) | i1 <- range (l1,u1), i2 <- range (l2,u2) ]
}}}
in Arr.GHC. The result of {{{range (l2,u2)}}} is shared between every step in the first component of the index.

I guess it is reasonable to expect that the result of range is never worth sharing (is it?). I am not entirely sure what the best, cleanest, alternative implementation is, though. (At least not without a working ```dontshare``` annotation ;-))"	nomeata
5	3606	The Ord instance for unboxed arrays is very inefficient	libraries (other)	6.10.4	lowest	normal	7.6.2		new	2009-10-22T13:48:50-0700	2012-09-12T04:14:13-0700	"The Ord instance for unboxed arrays defined in Data.Array.Base results in code that makes lots of heap allocations and is very slow.

For the record, the Ord instance is defined as so in Data.Array.Base:


{{{
instance (Ix ix, Ord e, IArray UArray e) => Ord (UArray ix e) where
    compare = cmpUArray

{-# INLINE cmpUArray #-}
cmpUArray :: (IArray UArray e, Ix i, Ord e) => UArray i e -> UArray i e -> Ordering
cmpUArray arr1 arr2 = compare (assocs arr1) (assocs arr2)
}}}

The 'assocs' calls don't appear to be deforested away, and hence, when using the Ord functions on unboxed arrays, the performance is bad to the point of making them unusable.

It seems reasonable to me that 'compare' for unboxed arrays could be implemented strictly, in a tight loop, without any heap allocations at all.
"	blarsen
3	3620	The seeds generated by split are not independent	libraries/random	6.11	normal	normal	_|_	rrnewton	new	2009-10-28T08:07:41-0700	2011-06-26T18:23:58-0700	"Suppose we split a seed into two like this:
{{{
split' :: StdGen -> (StdGen, StdGen)
split' g = (g12, g21)
  where (_, g12) = split g1
        (g21, _) = split g2
        (g1, g2) = split g
}}}
Since g1 and g2 are independent, g12 and g21 ought to be too. But they're not! If we use both of g12 and g21 to generate a random number in the range [0..10], then the two numbers ought to be equal 1/11 of the time. In fact, they're never equal.
Here is a test program that ought to return True 1/11 of the time but
actually always returns False:
{{{
sample :: StdGen -> (Int, Int)
sample g = (fst (randomR (0, 10) g1),
            fst (randomR (0, 10) g2))
   where (g1, g2) = split' g
test :: StdGen -> Bool
test g = fst (sample g) == snd (sample g)
}}}

I attached a program that prints the distribution of values from
{{{test}}} for other ranges than [0..10]. The distribution is
always quite bad no matter what the range is.

The upshot of all this is that the following QuickCheck (version 2)
property always passes, even though it's false:
{{{
import Test.QuickCheck
import Text.Show.Functions

newtype Eleven = Eleven Int deriving Eq

instance Arbitrary Eleven where
  arbitrary = fmap Eleven (choose (0, 10))

prop :: (Int -> Eleven) -> Bool
prop f = f 5 /= f 6
}}}"	NickSmallbone
3	7714	The type of the second argument of poll() in GHC/Event/Poll.hsc is invalid	Compiler	7.7	normal		7.6.3		merge	2013-02-24T05:22:17-0800	2013-04-12T17:12:14-0700	"poll() is used in GHC/Event/Poll.hsc. The type of its second argument is nfds_t. nfds_t is defined unsigned long on Linux and unsigned int on Mac/FreeBSD. FFI in Poll.hsc uses CULong instead of (#type nfds_t).
So, this may cause a problem on Mac/FreeBSD.

Actually, a web server compiled by GHC head on FreeBSD sometime causes the following error:

{{{
mighty-head: c_poll: invalid argument (Invalid argument)
mighty-head: sendWakeup: invalid argument (Bad file descriptor)
mighty-head: sendWakeup: invalid argument (Bad file descriptor)
mighty-head: sendWakeup: invalid argument (Bad file descriptor)
}}}

poll() on FreeBSD returns EINVAL when the specified time limit is negative.
"	kazu-yamamoto
3	7698	thread blocked indefinitely in an MVar operation	GHCi	7.0.4	normal		7.8.1	igloo	new	2013-02-16T06:55:27-0800	2013-04-13T05:19:28-0700	This error occures after wake up from hibernation	guest
2	7715	threadDelay causes segfault on Mac if compiled by 32bit GHC	Compiler	7.7	high		7.8.1		new	2013-02-24T05:34:23-0800	2013-05-11T07:25:52-0700	"The following code causes segfault
{{{
main :: IO ()
main = do
    replicateM_ 100 $ forkIO $ do
        threadDelay 1000000 
        putStrLn ""Hello, world!""
    threadDelay 5000000
}}}
if compiled with 32bit GHC head on Mac.

64bit GHC head does not cause this problem. 32bit GHC 7.4.2 does not, either. I don't see this bug both on FreeBSD and Linux.

""gdb"" caught the following on each run:

{{{
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000005
[Switching to process 51076 thread 0x20b]
0x00000005 in ?? ()
}}}

{{{
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000019
[Switching to process 50933 thread 0x20b]
0x00000019 in ?? ()
}}}

{{{
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x40e40348
[Switching to process 51004 thread 0x20b]
0x00f28aa5 in base_GHCziEventziPSQ_atMostzuzdszdwatMosts_info ()
}}}"	kazu-yamamoto
2	7325	threadDelay mistreats minBound and maxBound in some configurations	Runtime System	7.6.1	high		7.6.2		new	2012-10-13T04:31:38-0700	2012-10-22T08:11:49-0700	"threadDelay currently treats minBound and maxBound incorrectly in some cases.  This breaks the following idiom ([http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async.html#Concurrently as seen in the async package]):

{{{
forever (threadDelay maxBound)
}}}

On Linux (Ubuntu 10.04 64-bit) without -threaded, {{{threadDelay maxBound}}} returns immediately.  For lower numbers on the same order of magnitude, it behaves non-deterministically.  For example, given this program:

{{{
import Control.Concurrent
import Control.Monad

main = forM_ [6244222868950683224..] $ \i -> do
    print i
    threadDelay i
}}}

threadDelay returns immediately in some cases but not in others.  If I compile and run it in bash like this:

{{{
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound
}}}

The bug usually appears, but if I run it like this:

{{{
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs
./threadDelay-maxBound
}}}

The bug does not appear (threadDelay blocks like it should).  Thus, the program is affected by a very subtle difference in how it is invoked.  Perhaps it is sensitive to file descriptor numbers.

On Windows without -threaded, {{{threadDelay maxBound}}} seems to work, but {{{threadDelay minBound}}} blocks rather than returning immediately."	joeyadams
3	7602	Threaded RTS performing badly on recent OS X (10.8?)	Runtime System	7.7	normal		_|_	thoughtpolice	new	2013-01-17T09:05:19-0800	2013-02-10T19:50:04-0800	"This ticket is to remind us about the following problem: OS X is now using llvm-gcc, and as a result GHC's garbage collector with -threaded is much slower than it should be (approx 30% slower overall runtime).  Some results here: [http://www.haskell.org/pipermail/cvs-ghc/2011-July/063552.html]

This is because the GC code relies on having fast access to thread-local state.  It uses one of two methods: either a register variable (gcc only) or `__thread` variables (which aren't supported on OS X).  To make things work on OS X, we use calls to `pthread_getspecific` instead (see #5634), which is quite slow, even though it compiles to inline assembly.

I don't recall which OS X / XCode versions are affected, maybe a Mac expert could fill in the details.

We have tried other fixes, such as passing around the thread-local state as extra arguments, but performance wasn't good. Ideally Apple will implement TLS in OS X at some point and we can start to use it.

A workaround is to install a real gcc (using homebrew?) and use that to compile GHC.  Whoever builds the GHC distributions for OS X should probably do it that way, so everyone benefits.
"	simonmar
2	7636	threadStackUnderflow: not enough space for return values	Compiler	7.6.2	high		7.6.2	simonmar	merge	2013-01-28T14:58:40-0800	2013-02-07T02:26:21-0800	"While filling a {{{Control.Concurrent.STM.TBQueue}}} (stm-2.4) with values the system crashes with the following message:

{{{
internal error: threadStackUnderflow: not enough space for return values
    (GHC version 7.4.2 for x86_64_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort trap: 6
}}}"	mojojojo
3	4934	threadWaitRead works incorrectly on nonthreaded RTS	Runtime System	7.0.1	normal		_|_		new	2011-01-29T07:48:21-0800	2011-06-01T07:37:55-0700	"I found out it in xmobar on ghc-7.0.1.
When I ran it I got the following message:
{{{
xmobar: file descriptor 8954336 out of range for select (0--1024).
Recompile with -threaded to work around this.
}}}
'''-threaded''' option works, but the message is absolutely misleading.

I've decided to track where so large descriptor could come,
but there was no such place.

All xmobar does is:
{{{
    do x11connection_fd <- connectionNumber d
       threadWaitRead (Fd fd) -- here we die
}}}

'''x11connection_fd''' has value '''3''' at the time of call.
This value comes from '''libX11''' (via FFI, so I suspect it's a problem).

Another example (might be unrelated):
{{{
-- a.hs 
import Control.Concurrent

-- 12 is picked at random as guaranteed to be invalid FD
main = threadWaitRead 12 >> print ""yet input!""
}}}

Building:
{{{
$ ghc --make -fforce-recomp a.hs -o a
[1 of 1] Compiling Main             ( a.hs, a.o )
Linking a ...

$ ghc --make -fforce-recomp a.hs -threaded -o a.threaded
[1 of 1] Compiling Main             ( a.hs, a.o )
Linking a.threaded ...
}}}

Running:
{{{
$ ./a.threaded 
a.threaded: epollControl: invalid argument (Bad file descriptor)
}}}

Looks good.

And nonthreaded:
{{{
$ ./a
""yet input!""
}}}

According to strace there was an error but it was not reported.
{{{
sf tmp # strace -etrace='select,write' ./a >/dev/null
select(13, [12], [], NULL, {134, 217727}) = -1 EBADF (Bad file descriptor) # this one

select(2, [], [1], NULL, {0, 0})        = 1 (out [1], left {0, 0})
write(1, ""\""yet input!\""\n"", 13)        = 13
}}}

Side note: Haskeline seems to workaround this problem on it's own way.

'''libraries/haskeline/System/Console/Haskeline/Backend/Posix.hsc'''
{{{
-- Different versions of ghc work better using different functions.
blockUntilInput :: Handle -> IO ()
#if __GLASGOW_HASKELL__ >= 611
-- threadWaitRead doesn't work with the new ghc IO library,
-- because it keeps a buffer even when NoBuffering is set.
blockUntilInput h = hWaitForInput h (-1) >> return ()
#else
-- hWaitForInput doesn't work with -threaded on ghc < 6.10
-- (#2363 in ghc's trac)
blockUntilInput h = unsafeHandleToFd h >>= threadWaitRead
#endif
}}}"	slyfox
5	418	throwTo to a thread inside 'block'	Runtime System	6.4.1	lowest	normal	_|_		new	2005-07-10T15:41:36-0700	2009-11-27T08:48:11-0800	"[copy-pasting my original mail
(http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-June/005235.html)]

Good evening,

I just stumbled across a segfault caused when running the
following small program. (During an attempt to implement
single-assignment variables.)

{{{
> module Main where
> 
> import Control.Concurrent
> import System.IO.Unsafe (unsafeInterleaveIO)
> 
> main = do
>     v <- newEmptyMVar
>     a <- unsafeInterleaveIO (readMVar v)
>     t <- forkIO (print a)
>     threadDelay (1000*1000)
>     killThread t
>     forkIO (print a)
>     putMVar v ()
}}}

The crucial part about it seems to be the interruption
of the
lazy IO. Typing Ctl-c while running the first ""print a""
by hand
from ghci instead of the forkIO+killThread doesn't change
behaviour:

{{{
 Prelude System.IO.Unsafe Control.Concurrent> v <- newEmptyMVar
 Prelude System.IO.Unsafe Control.Concurrent> a <- unsafeInterleaveIO (readMVar v)
 Prelude System.IO.Unsafe Control.Concurrent> print a
 Interrupted.
 Prelude System.IO.Unsafe Control.Concurrent> forkIO (print a)
 Prelude System.IO.Unsafe Control.Concurrent> putMVar v ()
 zsh: segmentation fault (core dumped)  ghci
}}}

Both 6.4 and 6.2.1 crash when running main from ghci.
When running it as a compiled executable everything is
fine.

Although I'm pretty sure I've seen 6.2.1 crashing 
on it when run with -e main, I cannot reproduce it
anymore. 6.4
certainly happily runs it with -e main. (A serious lack
of sleep
the last week may play a role too.. :-/)

Whether the module is compiled before being loaded into
ghci has
no effect.

Core-dumps etc can of course be sent if necessary.

Good night,
Remi"	remit
4	4440	time004 fails depending on the date	Test Suite	7.1	low		7.6.2		new	2010-10-25T12:30:28-0700	2012-09-12T04:12:31-0700	"Since the change between DST and reasonable time does not take place on a fixed date, the same date may be DST in one year but not the next (or previous). The Show instance for !ClockTime takes DST into account, so the length of the display String can differ by one, giving raise to a spurious unexpected failure in the testsuite.

Is the test important or could it be removed?"	daniel.is.fischer
4	5190	TinyCoreLinux extension	Build System	7.0.3	low		7.6.2		new	2011-05-10T14:04:15-0700	2012-09-12T04:13:28-0700	"I am trying to create a GHC package for TinyCoreLinux http://www.tinycorelinux.com (this is a 10Mbytes linux distribution)

I have downloaded the general binary:
http://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-unknown-linux.tar.bz2

When I execute: ./configure, I get:
checking for path to top of build tree... ghc-pwd: mkTextEncoding: invalid argument (Invalid argument)
configure: error: cannot determine current directory

As a disclaimer, I am not a developer!"	josemaria.alkala
4	4831	Too many specialisations in SpecConstr	Data Parallel Haskell	7.0.1	low		7.6.2	rl	new	2010-12-10T01:05:28-0800	2012-09-12T04:12:33-0700	"Ben reports that `SpecConstr` can loop:
{{{
{-# LANGUAGE PArr #-}
{-# OPTIONS -fvectorise #-}

module Loop where
import Data.Array.Parallel.Prelude
import Data.Array.Parallel.Prelude.Double
import qualified Prelude

loop :: [:Double:] -> [:Double:]
loop xs 
    | 0 == 0    = xs
    | otherwise     = ([::] !: 0) +:+ [::] +:+ ([::] !: 0)
}}}
Compile with
{{{
~/devel/ghc/ghc-head-incoming/inplace/bin/ghc-stage2 -c -Odph -fdph-seq -package dph-seq -package dph-prim-seq -c Loop.hs
}}}
(You need to build the DPH libraries first, of course.)  This causes `SpecConstr` to loop for at least 5 mins on my machine. Removing the middle `[::]` in the last line gets it though SpecConstr, but the result size is 1501143 and it then runs out of memory in the simplifier.

Building with `-dph-par` runs fine.

This is probably also why the `dph-words` benchmark in the testsuite is failing due to using too much memory during compilation.
"	simonpj
4	5959	Top level splice in Template Haskell has over-ambitious lexical scope?	Compiler	7.5	low		7.6.2		new	2012-03-22T15:31:31-0700	2012-09-12T04:13:34-0700	"ghc: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for x86_64-unknown-linux):
        nameModule b_a2PR{tv}

While working on this project https://github.com/mightybyte/snaplet-postgresql-simple I encountered a GHC panic.  To reproduce, check out revision 6573d4359c5cb7699c931c44ebf1bf135099f83b (currently HEAD of the master branch), cabal install it, then go to the example directory and build with ""ghc --make Site.hs"".

This has caused the crash for me on two different Linux systems with GHC 7.4.1.  I realize it requires building a large number of package dependencies, but I have no idea of how to construct a smaller test case.  It should be pretty easy to build these dependencies with cabal or cabal-dev."	mightybyte
5	2840	Top level string literals	Compiler	6.10.1	lowest	normal	7.6.2		new	2008-12-04T06:23:38-0800	2012-09-12T04:14:05-0700	"At the moment GHC's internal language does not allow any top-level definitions of unlifted type, and for the most part rightly so.  But consider this:
{{{
f :: Int -> String
f n = let a::Addr# = ""foo""
      in let g y = ...a...g...
      in g n
}}}
Here we'd like to float the definitions out thus:
{{{
a::Addr# = ""foo""
g y = ...a...g...
f n = g n
}}}
This is much better.  Usually this happens, but not here, because we don't allow a top-level binding for an `Addr#`.  But really perhaps we should allow an exception for ''literals'', which can safely be bound at top level.

For literals other than strings, this doesn't make any difference, because we inline them freely.  But for literal strings we don't want to make lots of copies of them; on the contrary we'd like to CSE identical strings.  So it'd help to be able to bind them at top level.

Simon"	simonpj
3	1614	Type checker does not use functional dependency to avoid ambiguity	Compiler (Type checker)	6.7	normal	normal	_|_		new	2007-08-14T14:59:39-0700	2013-01-27T06:46:24-0800	"Compiling the following module gives an error
{{{
module X where

class C a | -> a
instance C Int

unC :: (C a) => a -> Int
unC i = undefined

test :: Int
test = unC undefined
}}}
Error message:
{{{
X.hs:13:7:
    Ambiguous type variable `a' in the constraint:
      `C a' arising from a use of `unC' at X.hs:13:7-19
    Probable fix: add a type signature that fixes these type variable(s)
}}}

But that is just plain wrong.  The functional dependency in the definition of C forces a to be Int.  No other type is possible.  So what's ambiguous about that?"	guest
3	5985	Type operators are not accepted as variables in contexts	Compiler	7.5	normal		7.6.2		new	2012-04-02T07:52:05-0700	2012-09-12T04:12:13-0700	"The following code is accepted by 7.4.1 (and 7.2/7.0/6.12), but rejected by HEAD:
{{{
$ ghci-7.5.20120402 -XTypeOperators
GHCi, version 7.5.20120402: 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 Control.Category
λ> let f :: Category (->>) => (a ->> b); f = undefined

<interactive>:3:19: Not in scope: type constructor or class `->>'

<interactive>:3:31: Not in scope: type constructor or class `->>'
}}}"	mikhail.vorozhtsov
3	1308	Type signature in warning is wrong	Compiler	6.7	normal	normal	_|_		new	2007-04-27T05:32:49-0700	2009-04-11T14:01:02-0700	"Here's some source:
{{{
autoChart = do
    xchart Nothing Nothing Nothing Nothing Nothing Nothing
xchart lbl lgd xmin xmax ymin ymax = do
  ...
}}}
And the warnings related to these:
{{{
    Warning: Definition but no type signature for `autoChart'
             Inferred type: autoChart :: t View
    Warning: Definition but no type signature for `autoChart'
             Inferred type: autoChart :: t View
             Inferred type: xchart :: forall (m :: * -> *).
                                      (Monad m) =>
                                      Maybe EString
                                      -> Maybe Position
                                      -> Maybe (E Double)
                                      -> Maybe (E Double)
                                      -> Maybe (E Double)
                                      -> Maybe (E Double)
                                      -> m View
}}}
The warning for autoChart is clearly wrong since there should be a context 'Monad t'.

  -- Lennart"	guest
2	5051	Typechecker behaviour change	Compiler	7.0.2	high		7.2.1		new	2011-03-26T10:57:58-0700	2012-05-21T15:43:48-0700	"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
3	7593	Unable to print exceptions of unicode identifiers	Compiler	7.6.1	normal		7.8.1		new	2013-01-15T22:05:29-0800	2013-04-12T15:35:56-0700	"I suspect this is windows specific but I'm not certain (I couldn't reproduce it with an older ghc on osx).

Here is an example of the problem:
{{{
$ ghcii.sh
GHCi, version 7.6.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude λ> ⇒

<interactive>:2:1: parse error on input `*** Exception: <stderr>: hPutChar: invalid argument (invalid character)
}}}

On other platforms the message looks more like: parse error on input `=>'

(not the automatic translation from ⇒ to =>, I think that's a separate bug related to the unicode symbols extension)

On windows my ghc is version 7.6.1. On OSX (where I could NOT reproduce the exception), my ghc is 7.4.1. I don't know if the GHC version matters. I strongly suspect this is a windows unicode issue.

GHC gives similar behavior to ghci, for example on this input:
{{{
⇒ = 1
}}}

ghc tries to give an error message but throws an exception printing ⇒."	dagit
4	3844	Undeprecate #include (in at least some circumstances)	Compiler (FFI)	6.12.1	low		7.6.2		new	2010-01-27T23:27:13-0800	2012-09-12T04:12:21-0700	"The attached program generates a warning: ""Warning: -#include is deprecated: No longer has any effect"". However, if I remove the #include, it fails to compile with:


{{{
Fixes.hsc: In function ‘main’:
Fixes.hsc:29: error: ‘SOL_SOCKET’ undeclared (first use in this function)
Fixes.hsc:29: error: (Each undeclared identifier is reported only once
Fixes.hsc:29: error: for each function it appears in.)
Fixes.hsc:29: error: ‘SO_LINGER’ undeclared (first use in this function)
Fixes.hsc:37: error: invalid application of ‘sizeof’ to incomplete type ‘struct linger’ 
Fixes.hsc:40: error: invalid use of undefined type ‘struct linger’
Fixes.hsc:41: error: invalid use of undefined type ‘struct linger’
}}}

Evidently it's not quite true that #include no longer has any effect."	cjs
4	2625	Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields	Compiler	6.8.3	low	normal	_|_		new	2008-09-23T21:58:05-0700	2008-10-31T03:23:00-0700	"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
5	2147	unhelpful error message for a misplaced DEPRECATED pragma	Compiler	6.8.2	lowest	minor	7.6.2		new	2008-03-11T08:48:56-0700	2012-09-12T04:13:46-0700	"The error message on a misplaced DEPRECATED pragma is less than helpful.  Note that it was the latter of these that bit me.

'''% cat Main.hs''' 
{{{
module Main where

import Foo.Bar

main = return ()
}}}

'''% cat Foo/Bar.hs'''
{{{
{-# DEPRECATED foo ""bar"" #-}

module Foo.Bar (foo) where

foo = undefined
}}}
'''% ghc -c Foo/Bar.hs'''

  Foo/Bar.hs:4:0: parse error on input `module'

'''% ghc --make Main.hs''' 

  Foo/Bar.hs:1:0: file name does not match module name `Main'
"	guest
5	4017	Unhelpful error message in GHCi	Compiler	6.12.2	lowest		7.6.2		new	2010-04-26T03:16:31-0700	2012-09-12T04:14:15-0700	"John Launchbury encountered an unhelpful error message in GHCi.  Try this:
{{{
*Test> :i GHC.Integer.Type.Integer

Top level:
    Failed to load interface for `GHC.Integer.Type':
      it is a hidden module in the package `integer-gmp'
      Use -v to see a list of the files searched for.
*Test> 
}}}
Two points
 * The ""-v"" suggestion is no help at at all: a straightforward response is to try
{{{
*Test> :i -v GHC.Integer.Type.Integer
}}}
  But that does not work.  Either it should work, or the error message should say ""Try `:set -v` to see a list...""

 * In any case, since we know it's a hidden module, it'd be more helpful to suggest ""Possible fix: use `:set -package integer-gmp`.

It's also confusing that if you instead say: 
{{{
*Test> :i Integer
data Integer
  = integer-gmp:GHC.Integer.Type.S# GHC.Prim.Int#
  | integer-gmp:GHC.Integer.Type.J# GHC.Prim.Int# GHC.Prim.ByteArray#
  	-- Defined in integer-gmp:GHC.Integer.Type
instance Enum Integer -- Defined in GHC.Num
instance Eq Integer -- Defined in GHC.Num
instance Integral Integer -- Defined in GHC.Real
instance Num Integer -- Defined in GHC.Num
instance Ord Integer -- Defined in GHC.Num
instance Read Integer -- Defined in GHC.Read
instance Real Integer -- Defined in GHC.Real
instance Show Integer -- Defined in GHC.Num
*Test> 
}}}
you get the info.  So specifying the full name doesn't work (saying it can't load an interface) but the unqualified one does (which presumably involves loading the interface).  Strange.

All in 6.12.


Simon
"	simonpj
4	5063	unix package has untracked dependency on libbsd	libraries/unix	7.0.3	low		7.6.2		new	2011-03-29T11:00:25-0700	2012-09-12T04:13:26-0700	"See ticket #4974 about unix-compat failing to build.

That is just a symptom. The real problem is that the unix package installs a HsUnix.h file which is broken on some target platforms, standard linux platforms.

HsUnix.h contains:
{{{
#ifdef HAVE_LIBUTIL_H
#include <libutil.h>
#endif
}}}

If the system that the package is built on has libbsd installed then it'll use it. But if the target system does not have this C lib then the HsUnix.h header is broken on such systems.

Why does the unix package optionally depend on libbsd? Is it really needed?

If it is needed then the distro packages need to be modified so that the unix package has dependency on libbsd-dev.

This raises another issue: we should be able to check that all the headers we install on a target actually work on that target. This check should be run as part of the ghc and HP release testing process."	duncan
5	1487	unix package: test needed for getLoginName	libraries/unix	6.6.1	lowest	normal	7.6.2	adrien	new	2007-07-03T03:51:27-0700	2013-01-22T09:06:02-0800	I disabled the test for `getLoginName` in unix/tests/user001 because `getLoginName` cannot be called unless stdin is a terminal, which it isn't during an unattended build.  Perhaps we can test this by setting up a pseudoterminal first, but that requires the pty patches which aren't in yet.	simonmar
1	7359	unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)	libraries/unix	7.4.1	highest		7.6.3	igloo	new	2012-10-22T10:51:06-0700	2013-04-23T20:09:37-0700	"Some package I am trying to build with cabal causes cabal to try to install unix-2.6.0.0 . This fails with the following errors: 


{{{
[35 of 38] Compiling System.Posix.Signals ( dist/build/System/Posix/Signals.hs, dist/build/System/Posix/Signals.o )
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUw_sigismember’:

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:8:0:
     warning: dereferencing ‘void *’ pointer

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:8:0:
     error: void value not ignored as it ought to be
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUF_sigfillset’:

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:10:0:
     warning: dereferencing ‘void *’ pointer

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:10:0:
     error: invalid use of void expression
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUR_sigdelset’:

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:12:0:
     warning: dereferencing ‘void *’ pointer

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:12:0:
     error: invalid use of void expression
Failed to install unix-2.6.0.0
}}}

This seems to be a recent problem for me, so it may be due to some software updates for mac os x. I am running os x version 10.8.2 build 12c60.  I have XCode version 4.5.1 with the ""Command Line Tools"" installed.  I installed ghc from the haskell-platform after updating the os x and xcode (and command line tools). "	AndreasVoellmy
3	3549	unlit does not follow H98 spec	Compiler	6.10.4	normal	normal	_|_		new	2009-09-28T09:20:31-0700	2011-09-13T08:51:32-0700	"The Haskell 98 spec has this to say about the [http://haskell.org/onlinereport/syntax-iso.html Latex \begin{code} \end{code}] style:

    An alternative style of literate programming is particularly suitable for use with the LaTeX text processing system. In this convention, only those parts of the literate program that are entirely enclosed between \begin{code}...\end{code} delimiters are treated as program text; all other lines are comment. More precisely:

    * Program code begins on the first line following a line that begins \begin{code}.
    * Program code ends just before a subsequent line that begins \end{code} (ignoring string literals, of course).

The key phrases are ""a line that begins \begin{code}"" and ""line that begins \end{code}"". This means the semantics is something like:

{{{
classifyLine s
  | ""\\begin{code}"" `isPrefixOf` s = BeginCode
  | ""\\end{code}""   `isPrefixOf` s = EndCode
}}}

GHC's `unlit` C program uses:

{{{
    if (strcmp(buf, ""\\begin{code}"") == 0)
        return BEGIN;
}}}

The equivalent semantics in the style above would be:
{{{
classifyLine s
  | ""\\begin{code}"" == s = BeginCode
  | ""\\end{code}""   == s = EndCode
}}}

It seems fairly clear from the spec that GHC's unlit program is wrong in this respect.

The practical consequence is that Cabal's unlit and GHC's one do not match and this [http://haskell.org/pipermail/haskell-cafe/2009-September/066780.html catches people out]. There is [http://www.haskell.org/haskellwiki/Literate_programming#Hiding_code_from_Haskell explicit advice on the Haskell wiki] recommending that people take advantage of this GHC bug."	duncan
4	3990	UNPACK doesn't unbox data families	Compiler	7.0.3	low		7.6.2		new	2010-04-14T06:29:07-0700	2013-02-06T02:26:06-0800	"Here is an example:

{{{
data family Complex a
data instance Complex Double = CD {-# UNPACK #-} !Double
                                  {-# UNPACK #-} !Double

data T = T {-# UNPACK #-} !(Complex Double)
}}}

We would like T to just store two Double# but that doesn't happen. Contrast this with

{{{
data Complex_Double = CD {-# UNPACK #-} !Double
                         {-# UNPACK #-} !Double

data T = T {-# UNPACK #-} !Complex_Double
}}}
"	rl
4	5378	unreg compiler: warning: conflicting types for built-in function ‘memcpy’	Compiler	7.3	low		7.6.2		new	2011-08-04T06:31:37-0700	2012-09-12T04:13:32-0700	"T3736 fails with an unreg compiler due to printing a warning about conflicting types for `memcpy`:
{{{
$ ghc -dno-debug-output  -v0 -O --make T3736 -rtsopts -keep-tmp-files
/tmp/ghc4352_0/ghc4352_0.hc: In function ‘s2E3_ret’:

/tmp/ghc4352_0/ghc4352_0.hc:1494:0:
     warning: conflicting types for built-in function ‘memcpy’
}}}


Line 1494 is
{{{
;EF_(memcpy);
}}}
in:
{{{
if ((W_)((W_)Hp > (W_)HpLim)) goto _c2MC;
_s2yO = (Sp[4]) + 0x10UL;
_s2Ed = Sp[2];
_s2yS = (*((P_)(R1.w+7))) * 0x4UL;
_s2Ee = (Sp[5]) + _s2yS;
;EF_(memcpy);
{void * (*ghcFunPtr)(void *, void *, W_);
ghcFunPtr = ((void * (*)(void *, void *, W_))(W_)&memcpy);
_s2Eg = (W_)ghcFunPtr((void *)_s2yO, (void *)_s2Ee, _s2Ed);;}
Hp[-12] = (W_)&base_GHCziSTRef_STRef_con_info;
Hp[-11] = Sp[1];
Hp[-10] = (W_)&base_GHCziForeignPtr_MallocPtr_con_info;
Hp[-9] = Sp[4];
Hp[-8] = (W_)Hp-95;
}}}
"	igloo
2	5859	unsafeInterleaveIO duplicates computation when evaluated by multiple threads	libraries/base	7.2.2	high		7.6.2	simonpj	new	2012-02-08T09:38:42-0800	2013-03-25T19:09:53-0700	"When the following code is compiled with -O1 or -O2, the interleaved computation (putStrLn ""eval"") is performed 1000 times, rather than once:

{{{
import Control.Concurrent
import Control.Exception (evaluate)
import Control.Monad
import System.IO.Unsafe

main :: IO ()
main = do
    x <- unsafeInterleaveIO $ putStrLn ""eval""
    replicateM_ 1000 $ forkIO $ evaluate x >> return ()
    threadDelay 1000000
}}}

Taking a look at the source to unsafeInterleaveIO:

{{{
{-# INLINE unsafeInterleaveIO #-}
unsafeInterleaveIO :: IO a -> IO a
unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m)

-- We believe that INLINE on unsafeInterleaveIO is safe, because the
-- state from this IO thread is passed explicitly to the interleaved
-- IO, so it cannot be floated out and shared.
}}}

It seems the comment about INLINE is not true.  If I define the following function:

{{{
interleave :: IO a -> IO a
interleave = unsafeInterleaveIO
{-# NOINLINE interleave #-}
}}}

and replace unsafeInterleaveIO with interleave, ""eval"" is printed only once.  If I change NOINLINE to INLINE, or if I remove the pragma altogether, ""eval"" is printed 1000 times.

I believe unsafeInterleaveIO should ''guarantee'' that computations are not repeated.  Otherwise, we end up with strangeness like this:

{{{
import Control.Applicative
import Control.Concurrent
import Control.Monad

main :: IO ()
main = do
    chan <- newChan :: IO (Chan Int)
    mapM_ (writeChan chan) [0..999]
    items <- take 10 <$> getChanContents chan
    replicateM_ 5 $ forkIO $ putStrLn $ ""items = "" ++ show items
    threadDelay 1000000
}}}

which prints:

{{{
items = [0,1,2,3,4,5,6,7,8,9]
items = [10,11,12,13,14,15,16,17,18,19]
items = [20,21,22,23,24,25,26,27,28,29]
items = [30,31,32,33,34,35,36,37,38,39]
items = [40,41,42,43,44,45,46,47,48,49]
}}}

For the time being, programs can work around this by using a NOINLINE wrapper:

{{{
getChanContents' :: Chan a -> IO [a]
getChanContents' = getChanContents
{-# NOINLINE getChanContents' #-}
}}}

I tested this on Linux 64-bit with GHC 7.2.2 and ghc-7.4.0.20120111, and on Windows 32-bit with GHC 7.0.3 and 7.2.2.  All of these platforms and versions exhibit the same behavior.  The bug goes away when the program is compiled with -O0, or when functions returning interleaved computations are marked NOINLINE (e.g. getChanContents')."	joeyadams
4	5302	Unused arguments in join points	Compiler	7.0.3	low		7.6.2	simonpj	new	2011-07-04T22:21:56-0700	2013-03-20T16:00:29-0700	"Sometimes GHC produces join points with unused parameters. In the example attached, we get join points like the following (when compiled with -O2):

{{{
...
    $j1_XHI
      :: GHC.Prim.Int#
         -> GHC.Types.Int
         -> (# Unboxed.FingerTree
                 Unboxed.Size (Unboxed.Node Unboxed.Size b_ahY),
               Unboxed.Node Unboxed.Size b_ahY,
               Unboxed.FingerTree
                 Unboxed.Size (Unboxed.Node Unboxed.Size b_ahY) #)
    [LclId, Arity=2, Str=DmdType LL]
    $j1_XHI =
      \ (x2_XE8 :: GHC.Prim.Int#) _ ->
...
}}}
which is always called as follows:

{{{
...
    $j1_XHI x2_XE2 (GHC.Types.I# x2_XE2)
...
}}}

i.e. where the second argument is a boxed version of the first. GHC should remove the dead parameter from the join point, to avoid unnecessary boxing.

I get this Core with 7.0.3 and with 7.1.20110629.

I've attached a self-contained example, as small as I can make it. (Making it smaller lets GHC do more unfolding and the problem disappears.) These join points occur inside the 'Deep' case of '$wsplitTree'."	reinerp
5	2159	Use a more efficient representation than [DynFlag]	Compiler	6.8.2	lowest	normal	7.6.2		new	2008-03-15T11:13:57-0700	2012-09-12T04:13:46-0700	"In `compiler/typecheck/TcRnMonad.lhs`, if I replace the existing definitions with
{{{
traceOptIf _ _ = return ()
traceOptTcRn _ _ = return ()
dumpTcRn _ = return ()
}}}
then we see an improvement in nofib's ""Compile Times"" sections:
{{{
-1 s.d.		-----	-8.5%
+1 s.d.		-----	+1.8%
Average		-----	-3.5%
}}}
By using some sort of bitmap representation, we ought to see a modest compile time improvement from all the checks that the trace functions make, as well as various other checks that are made (do we need to warn about missing sigs, are overlapping instances allowed, etc).

The tricky bit is designing it so that it is hard to shoot yourself in the foot. `Lexer.x` already has a bitmap (`genericsBit`, `ffiBit` etc) but the mapping of feature to bit number is done by hand, which isn't ideal. Perhaps this is even important enough to deserve a language extension?
"	igloo
4	3704	Using -shared without -dynamic should be rejected on linux	Compiler		low		7.6.2		new	2009-11-29T04:26:21-0800	2012-09-12T04:12:19-0700	"When trying to link with ghc -shared

{{{
$ ghc -v -fPIC -shared -o TestF.so TestF.hs
}}}

it adds a bunch of arguments of the form -lHSbase-4.2.0.0 to the linker command line

{{{
*** Linker:
/usr/bin/gcc -v -o TestF.so TestF.o -shared -Wl,-Bsymbolic -Wl,-soname,TestF.so
 -L/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0 -L/usr/lib/ghc-6.12.0.20091126/integer-gmp-0.2.0.0
 -L/usr/lib/ghc-6.12.0.20091126/ghc-prim-0.2.0.0 -L/usr/lib/ghc-6.12.0.20091126 -lHSbase-4.2.0.0
 -lHSinteger-gmp-0.2.0.0 -lgmp -lHSghc-prim-0.2.0.0 -lHSffi
}}}

Unfortunately:

{{{
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.0.20091126.so
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0_p.a
}}}

The name of the .so has been mangled to include the compiler version - presumably for ABI reasons. Obviously the bug is that name on the linker command line has not been suitably mangled to match, so the linker goes ahead and tries to use the .a library, which doesn't work at all.

{{{
/usr/bin/ld: /usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a(Base__76.o): 
relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile 
with -fPIC
}}}

Tested on linux/amd64, with HEAD and stable snapshot. It may work on linux/i386 due to compatibility hacks in glibc, I haven't checked; it shouldn't work on anything else."	asuffield
3	7535	Using -with-rtsopts=-N should fail unless -threaded is also specified	Compiler	7.6.1	normal		7.8.1		new	2012-12-28T08:13:46-0800	2013-04-12T15:07:29-0700	"If ghc can already tell at compile time that the specified
-with-rtsopts won't work it shouldn't allow compilation to
continue.

Otherwise the resulting binary will always yield the error

""the flag -N requires the program to be built with -threaded"""	mhoermann
3	7879	validate in build tree fails due to problem copying haddock resources to inplace	Build System		normal				patch	2013-05-02T07:43:25-0700	2013-05-02T07:51:21-0700	"I setup my build tree using the instructions here http://hackage.haskell.org/trac/ghc/wiki/Building/Using .  After booting and configuring, I ran ""sh validate"" which eventually halted on the following command with the following error: 

""/Users/andreas/repos/temp-ghc-3/ghc-build/inplace/bin/haddock"" --odir=""libraries/ghc-prim/dist-install/doc/html/ghc-prim"" --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title=""ghc-prim-0.3.1.0: GHC primitives"" --prologue=""libraries/ghc-prim/dist-install/haddock-prologue.txt""   --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-Werror --optghc=-Wall --optghc=-H64m --optghc=-O0 --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-O --optghc=-dcore-lint --optghc=-fno-warn-deprecated-flags --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build    libraries/ghc-prim/./GHC/Classes.hs  libraries/ghc-prim/./GHC/CString.hs  libraries/ghc-prim/./GHC/Debug.hs  libraries/ghc-prim/./GHC/Magic.hs  libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs  libraries/ghc-prim/./GHC/IntWord64.hs  libraries/ghc-prim/./GHC/Tuple.hs  libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable
Haddock coverage:
  78% (  7 /  9) in 'GHC.Types'
  17% (  1 /  6) in 'GHC.CString'
Warning: Couldn't find .haddock for export GHC.Prim.Int64#
Warning: Couldn't find .haddock for export GHC.Prim.Word64#
   3% (  1 / 38) in 'GHC.IntWord64'
   3% (  2 / 63) in 'GHC.Tuple'
   0% (  0 /  3) in 'GHC.Debug'
   0% (  0 /342) in 'GHC.PrimopWrappers'
  31% (164 /537) in 'GHC.Prim'
 100% (  3 /  3) in 'GHC.Magic'
  38% (  6 / 16) in 'GHC.Classes'
haddock: internal error: /Users/andreas/repos/temp-ghc-3/ghc-build/inplace/lib/html/Ocean.std-theme/hslogo-16.png: copyFile: does not exist (No such file or directory)

Apparently it can't find /Users/andreas/repos/temp-ghc-3/ghc-build/inplace/lib/html/Ocean.std-theme/hslogo-16.png. That file is in fact there, but it is linked to another file: 

ls -lh /Users/andreas/repos/temp-ghc-3/ghc-build/inplace/lib/html/Ocean.std-theme
total 40
lrwxr-xr-x  1 andreas  staff    80B Apr 28 13:13 hslogo-16.png -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std-theme/hslogo-16.png
lrwxr-xr-x  1 andreas  staff    76B Apr 28 13:13 minus.gif -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std-theme/minus.gif
lrwxr-xr-x  1 andreas  staff    76B Apr 28 13:13 ocean.css -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std-theme/ocean.css
lrwxr-xr-x  1 andreas  staff    75B Apr 28 13:13 plus.gif -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std-theme/plus.gif
lrwxr-xr-x  1 andreas  staff    79B Apr 28 13:13 synopsis.png -> ../../../../../../ghc/utils/haddock/resources/html/Ocean.std-theme/synopsis.png
piz-sardona:ghc-build andreas$ cd /Users/andreas/repos/temp-ghc-3/ghc-build/inplace/lib/html/Ocean.std-theme

It seems to be trying to link to utils/haddock/resources/html/Ocean.std-theme/hslogo-16.png in my source tree.  But the problem is that there is one too many "".."" in the links.  If there were one fewer "".."" in the path, then it would work fine. 

"	AndreasVoellmy
4	589	Various poor type error messages	Compiler (Type checker)	6.4.1	low	minor	_|_		new	2005-12-07T03:40:23-0800	2010-01-02T12:23:55-0800	"Hello,

I read the summary of the survey and noticed you wanted feedback on
where error messages could be improved. I looked up some (simple)
examples of type errors and ran them through ghc. I do not make any
claims to be an HCI expert, just a mere mortal with an opinion.

'''Type error 1'''

Code:
{{{
1 module Test2 where
2
3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2))
4 k = fib 's'
}}}
Error message:
{{{
Test2.hs:4:
    No instance for (Num Char)
      arising from use of `fib' at Test2.hs:4
    In the definition of `k': k = fib 's'
}}}

This isn't a bad error message in my humble opinion, it does pinpoint
that I'm doing something wrong in line 4, and that there isn't an
instance for Num Char doesn't come as a surprise. However I think it
could have been more helpful by telling me that I tried to pass a Char
to a function which expected an (Ord a, Num a) => a as its parameter.

'''Type error 2'''

Code:
{{{
1 module Test4 where
2 
3 k :: Int -> Int
4 k l = 2.0*l
}}}
Error message:
{{{
Test4.hs:4:
    No instance for (Fractional Int)
      arising from the literal `2.0' at Test4.hs:4
    In the first argument of `(*)', namely `2.0'
    In the definition of `k': k l = 2.0 * l
}}}
One reason this kind of error could happen is an inexperienced user
declaring the wrong type for his function, or not knowing that 2.0
would be interpreted as a Fractional.

'''Type error 3'''

Code:
{{{
1 module Test7 where
2
3 len' xs = head (xs) + (length xs)
4 o = len' ""GH""
}}}
Error message:
{{{
Test7.hs:4:
    Couldn't match `Int' against `Char'
        Expected type: [Int]
        Inferred type: [Char]
    In the first argument of `len'', namely `""GH""'
    In the definition of `o': o = len' ""GH""
}}}
I ran this through Hugs version November 2002 and got this error
message:
{{{
ERROR ""Test7.hs"":4 - Type error in application
*** Expression     : len' ""GH""
*** Term           : ""GH""
*** Type           : String
*** Does not match : [Int]
}}}
I find the Hugs message more clear, but that might be my background.

'''Type error 4'''

Code:
{{{
1 module Test8 where
2
3 f = head 3
}}}
Error message:
{{{
Test8.hs:3:
    No instance for (Num [a])
      arising from the literal `3' at Test8.hs:3
    Possible cause: the monomorphism restriction applied to the following:
      f :: a (bound at Test8.hs:3)
    Probable fix: give these definition(s) an explicit type signature
    In the first argument of `head', namely `3'
    In the definition of `f': f = head 3
}}}
This one I find outright scary. For ""wrong = div 3 8 + 1/2"" it gives
an error message that somewhat helps me guess the error, but the above
doesn't even come close to helping me.

/ Peter
"	Peter A Jonsson [pj@…
4	2465	View + Pattern Match not fused sufficiently	Compiler	6.8.2	low	normal	_|_		new	2008-07-24T13:58:32-0700	2009-11-16T05:28:47-0800	"This came up while playing with the ICFP2007 task.

I have a function {{{dnaView :: DNA -> [D]}}}; DNA is a {{{[ByteString]}}} and D is just the enum {{{I|C|F|P}}}.  When I call a function that just pattern matches on the result, I think the pattern matching function should be fused with the view -- the view should run as a coroutine.

I've attached an example."	ryani
3	7773	Waiting on non-kqueue supported files on OS X	libraries/base	7.7	normal		7.8.1	AndreasVoellmy	merge	2013-03-16T14:22:31-0700	2013-05-05T20:14:39-0700	"Neither the old IO manager nor the new ""parallel"" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000798.html.

Here is the gist of it: the IO manager uses kqueue to wait on files on OS X. kqueue does not support all files. For example, on older versions of OS X (10.5.8) it cannot wait on tty devices and on even on 10.8.2 it cannot wait on /dev/random. 

Both the old and parallel IO managers suffered from the problem, but the consequences were slightly different. With the old IO manager the situation was treated as the file being ready, which would just cause the waiting thread to run again. The parallel IO manager changed things slightly and now it just throws an exception and terminates the program. So the behavior when this happens in the parallel IO manager is not acceptable.

"	AndreasVoellmy
5	1307	Warning refers to code not in the source	Compiler	6.7	lowest	normal	_|_		new	2007-04-27T05:17:51-0700	2013-01-22T08:40:05-0800	"Here's some source:
{{{
toXML = toXMLEx (Just . cap)
  where cap ('_':cs) = cap cs
        cap (c:cs) = toUpper c : cs
        cap """" = """"
}}}
And here's a warning that refers to notElem which I've not used:
{{{
../Gmag/Paradise/Addins/XML/Prim.hs:47:8:
    Warning: Pattern match(es) are non-exhaustive
             In the definition of `cap':
                 Patterns not matched: #x with #x `notElem` [""""#]
}}}
  -- Lennart"	guest
3	7660	warning: conflicting types when compiling via-C	Compiler	7.7	normal		7.8.1	igloo	new	2013-02-04T20:05:31-0800	2013-04-13T04:22:52-0700	"I don't think this is actually a problem per-se, but usually these warnings are indicative of unsafe assumptions being made:

{{{
when making flags consistent: Warning:
    Compiler unregisterised, so compiling via C

/tmp/ghc7162_0/ghc7162_0.hc:1164:1:
     warning: conflicting types for built-in function 'memchr' [enabled by default]

/tmp/ghc7162_0/ghc7162_0.hc:6885:1:
     warning: conflicting types for built-in function 'memset' [enabled by default]

/tmp/ghc7162_0/ghc7162_0.hc:8594:1:
     warning: conflicting types for built-in function 'memcpy' [enabled by default]

/tmp/ghc7162_0/ghc7162_0.hc:11521:1:
     warning: conflicting types for built-in function 'free' [enabled by default]

/tmp/ghc7162_0/ghc7162_0.hc:11522:1:
     warning: conflicting types for built-in function 'realloc' [enabled by default]

/tmp/ghc7162_0/ghc7162_0.hc:12038:1:
     warning: conflicting types for built-in function 'malloc' [enabled by default]

/tmp/ghc7162_0/ghc7162_0.hc:13583:1:
     warning: conflicting types for built-in function 'strlen' [enabled by default]

/tmp/ghc7162_0/ghc7162_0.hc:13994:1:
     warning: conflicting types for built-in function 'memcmp' [enabled by default]
}}}"	singpolyma
3	5728	Warnings from -fwarn-incomplete-record-updates even with all constructors matched	Compiler	7.4.1	normal		_|_		new	2011-12-26T18:20:05-0800	2012-03-08T08:27:04-0800	"I don't think that the following should be considered an incomplete record update, since I match on the other constructor before the record update:

{{{
data Foo = None | Bar { baz :: Int }

quux :: Foo -> Foo
quux None = None
quux x = x { baz = 2 }

main :: IO ()
main = return ()
}}}

But it still throws a warning:

{{{
$ ghc -fwarn-incomplete-record-updates test.hs
[1 of 1] Compiling Main             ( test.hs, test.o )

test.hs:6:10:
    Warning: Pattern match(es) are non-exhaustive
             In a record-update construct: Patterns not matched: None
Linking test ...
}}}
"	mjo
3	816	Weird fundep behavior (with -fallow-undecidable-instances)	Compiler (Type checker)	6.4.2	normal	normal	_|_		new	2006-07-06T12:04:37-0700	2010-09-07T06:23:34-0700	"I encounter a strange behavior with functional dependencies. Consider this program
{{{
class Foo x y | x -> y where
 foo :: x -> y

class Bar x y where
 bar :: x -> y -> Int

instance (Foo x y, Bar y z) => Bar x z where
 bar x z = bar (foo x) z
}}}
Compiling (with 6.4.2, -fallow-undecidable-instances and -fglasgow-exts) I get the following error message:
{{{
Foo.hs:12:0:
    Context reduction stack overflow; size = 21
    Use -fcontext-stack20 to increase stack size to (e.g.) 20
        `$dBar :: Bar y z' arising from use of `bar' at Foo.hs:13:11-13
        [... same thing 20 times ...]
        `$dBar :: Bar y z' arising from use of `bar' at Foo.hs:13:11-13
        `bar :: {bar at [y z]}' arising from use of `bar' at Foo.hs:13:11-13
    When trying to generalise the type inferred for `bar'
      Signature type:     forall x y z. (Foo x y, Bar y z) => x -> z -> Int
      Type to generalise: x -> z -> Int
    In the instance declaration for `Bar x z'
}}}

The declaration requires undecidable instances, but I doubt that the problem comes from that. What makes it even more weird is that I can get this to compile, and behave as expected, if I do one of a) declare an instance of Bar for any type, or
b) add an explicit type signature (foo x :: y) in the definition of Bar. The first seems weird since how could a different, unrelated instance affect the typeability of the second instance? The second, b), is weird since by the FD x -> y we should already know that foo x :: y.

Same behavior in GHC 6.4.1. Hugs (with -98 +O) accepts the code."	nibro
3	7373	When building GHC: Failed to load interface for `GHC.Fingerprint'	libraries/base	7.6.1	normal		7.8.1		new	2012-10-28T12:56:34-0700	2013-05-10T11:48:10-0700	"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
3	7762	when using lots of memory: internal error: evacuate(static): strange closure type 4	Runtime System	7.0.4	normal		7.8.1		new	2013-03-11T07:29:08-0700	2013-04-13T06:02:01-0700	"{{{
resample: internal error: evacuate(static): strange closure type 4
    (GHC version 7.0.4 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
Bug occurs reproducable after running the main program for around 8 minutes and consuming 25 GB of RAM.
{{{
ghc -rtsopts --make Main -o main
./main +RTS -K3000m -RTS > someFile.txt
}}}"	rthiemann
5	1820	Windows segfault-catching only works for the main thread	Runtime System	6.8.1	lowest	normal	7.6.2		new	2007-11-01T05:22:06-0700	2012-09-12T04:13:43-0700	On Windows, the RTS tries to catch segmentation faults and divide-by-zero exceptions using structured exception handling in `rts/Main.c`.  Unfortunately this only works for the main thread, so if the exception occurs in another thread it won't be caught.  GHCi runs all its computations in a separate thread, hence `derefnull(ghci)` and `divbyzero(ghci)` are failing.	simonmar
4	4824	Windows: Dynamic linking doesn't work out-of-the-box	Runtime System	7.0.1	low		7.6.2		new	2010-12-08T02:53:22-0800	2012-09-12T04:12:33-0700	"I did this:

1. Download and install GHC 7.0.1

2. Compile `HelloWorld.hs` with the ""-dynamic"" flag.

3. Run the resulting binary.

When I run the program, I get a dialog box telling me that the program can't find the RTS DLL.

If I move the necessary DLLs to somewhere in the search path, the binary runs just fine. The bug is that the Windows installer for GHC does not do this itself.

(I've classified this bug as ""runtime system"", but really it's an installer bug, not an RTS bug.)

Related to this are two complications:

1. The documentation fails to describe how GHC tries to find dynamic libraries on Windows. (Section 4.12.4 of the User Guide only explains how this is done for Unix and Mac OS.)

2. The DLLs are scattered all over the place. If they were all in one folder, I could just add that to the search path. But they aren't.
"	Orphi
2	2283	WIndows: loading objects that refer to DLL symbols	GHCi	6.8.2	high	normal	7.8.1		new	2008-05-14T02:48:51-0700	2013-01-27T11:48:36-0800	"This is a test case from #1288, distilled into a separate report so I can close #1288:

`test3b.c`:
{{{
#include <stdio.h>

__declspec(dllexport) void _stdcall test(int arg)
{
   printf(""The argument passed was %i\n"", arg );
}
}}}

`test_proxy_5a.c`:
{{{
__declspec(dllimport) void _stdcall test(int arg);

void test_proxy(int arg)
{
   test(arg);
}
}}}

To reproduce:
{{{
gcc -c test3b.c
ar -rv test3b.a test3b.o 
c:/mingw/bin/dllwrap --export-all-symbols --output-lib test3b.dll.a -o test3b.dll test3b.a
gcc -c test_proxy_5a.c
ghci -ltest3b test_proxy_5a.o
}}}

the error message we get:

{{{
GHCi, version 6.9.20080512: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) test_proxy_5a.o ... done
Loading object (dynamic) test3b ... done
ghc.exe:
test_proxy_5a.o: unknown symbol `__imp__test'
final link ... ghc.exe: linking extra libraries/objects failed
}}}

I'm not sure to what extent we need to support this, it's possible to link to the DLL by omitting the dllimport declaration.
"	simonmar
4	5578	write access permission of binary result different on OpenBSD	Test Suite	7.2.1	low		7.6.2	igloo	new	2011-10-24T08:39:19-0700	2012-09-16T20:07:22-0700	"Checking the write access of the binary itself gives a different result on OpenBSD. Therefore excluding the test case on OpenBSD host.

For reference comare the results of this program on OpenBSD:
#include<unistd.h>
int main() {
        printf(""%i\n"", access(""test"",W_OK) == 0);
}

"	ivdsangen
5	5340	wrong warning on incomplete case analysis in conjunction with empty data declarations	Compiler	6.12.3	lowest		_|_		new	2011-07-22T09:36:35-0700	2011-07-22T09:59:45-0700	"I load the following code into GHCi with warnings enabled (-Wall)
{{{
{-# LANGUAGE EmptyDataDecls #-}

data Empty

data EitherStrict a b = LeftStrict !a | RightStrict !b

test :: Char
test =
   case undefined :: EitherStrict Empty Char of
--      LeftStrict _ -> undefined
      RightStrict b -> b
}}}

I get the warning:
{{{
CaseOfEmptyData.hs:9:3:
    Warning: Pattern match(es) are non-exhaustive
             In a case alternative: Patterns not matched: LeftStrict _
}}}

I think this warning is wrong, since the LeftStrict case cannot happen. Am I right?

This may be related to #2431.

This problem is of minor priority for me. I found that in the original problem EmptyDataDecls would not helped me at all, and I found a better solution in this particular case.
"	Lemming