Commit 94a271cc authored by simonmar's avatar simonmar
Browse files

[project @ 2003-11-03 10:11:04 by simonmar]

merge rev. 1.9.6.1 to the HEAD (add overflown relocs bug)
parent 04e741db
......@@ -250,10 +250,13 @@ main = print (array (1,1) [(1,2), (1,3)])</programlisting>
listed above, GHC has the following known bugs or
infelicities.</para>
<sect2 id="bugs-ghc">
<title>Bugs in GHC</title>
<itemizedlist>
<listitem>
<para> GHC can warn about non-exhaustive or overlapping
patterns (see <xref linkend="options-sanity">, and usually
patterns (see <xref linkend="options-sanity">), and usually
does so correctly. But not always. It gets confused by
string patterns, and by guards, and can then emit bogus
warnings. The entire overlap-check code needs an overhaul
......@@ -299,6 +302,33 @@ main = print (array (1,1) [(1,2), (1,3)])</programlisting>
be among the type parameters of the data type.</para>
</listitem>
<listitem>
<para>GHC's inliner can be persuaded into non-termination
using the standard way to encode recursion via a data type:</para>
<programlisting>
data U = MkU (U -> Bool)
russel :: U -> Bool
russel u@(MkU p) = not $ p u
x :: Bool
x = russel (MkU russel)
</programlisting>
<para>We have never found another class of programs, other
than this contrived one, that makes GHC diverge, and fixing
the problem would impose an extra overhead on every
compilation. So the bug remains un-fixed. There is more
background in <ulink
url="http://research.microsoft.com/~simonpj/Papers/inlining">
Secrets of the GHC inliner</ulink>.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="bugs-ghci">
<title>Bugs in GHCi (the interactive GHC)</title>
<itemizedlist>
<listitem>
<para>GHCi does not respect the <literal>default</literal>
declaration in the module whose scope you are in. Instead,
......@@ -320,28 +350,25 @@ main = print (array (1,1) [(1,2), (1,3)])</programlisting>
expression.</para>
</listitem>
<listitem>
<para>GHC's inliner can be persuaded into non-termination
using the standard way to encode recursion via a data type:</para>
<listitem>
<para>On Windows, there's a GNU ld/BFD bug
whereby it emits bogus PE object files that have more than
0xffff relocations. When GHCi tries to load a package affected by this
bug, you get an error message of the form
<programlisting>
data U = MkU (U -> Bool)
russel :: U -> Bool
russel u@(MkU p) = not $ p u
x :: Bool
x = russel (MkU russel)
Loading package javavm ... linking ... Overflown relocs: 4
</programlisting>
<para>We have never found another class of programs, other
than this contrived one, that makes GHC diverge, and fixing
the problem would impose an extra overhead on every
compilation. So the bug remains un-fixed. There is more
background in <ulink
url="http://research.microsoft.com/~simonpj/Papers/inlining">
Secrets of the GHC inliner</ulink>.</para>
The last time we looked, this bug still
wasn't fixed in the BFD codebase, and there wasn't any
noticeable interest in fixing it when we reported the bug
back in 2001 or so.
</para>
<para>The workaround is to split up the .o files that make up
your package into two or more .o's, along the lines of
how the "base" package does it.</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
</chapter>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment