program. These are:
<option>-fwarn-overlapping-patterns</option>,
<option>-fwarn-deprecations</option>,
+ <option>-fwarn-deprecated-flags</option>,
<option>-fwarn-duplicate-exports</option>,
<option>-fwarn-missing-fields</option>, and
<option>-fwarn-missing-methods</option>. The following flags are
</varlistentry>
<varlistentry>
+ <term><option>-fwarn-deprecated-flags</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-deprecated-flags</option></primary>
+ </indexterm>
+ <indexterm><primary>deprecated-flags</primary></indexterm>
+ <para>Causes a warning to be emitted when a deprecated
+ commandline flag is used.</para>
+
+ <para>This option is on by default.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-dodgy-imports</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-dodgy-imports</option></primary>
imported. This happens unless either the Prelude module is
explicitly imported with an <literal>import ... Prelude ...</literal>
line, or this implicit import is disabled (either by
- <option>-fno-implicit-prelude</option> or a
+ <option>-XNoImplicitPrelude</option> or a
<literal>LANGUAGE NoImplicitPrelude</literal> pragma).</para>
<para>Note that no warning is given for syntax that implicitly
- refers to the Prelude, even if <option>-fno-implicit-prelude</option>
+ refers to the Prelude, even if <option>-XNoImplicitPrelude</option>
would change whether it refers to the Prelude.
For example, no warning is given when
<literal>368</literal> means
<varlistentry>
<term>
- <option>-fno-state-hack</option>
- <indexterm><primary><option>-fno-state-hack</option></primary></indexterm>
+ <option>-fspec-constr</option>
+ <indexterm><primary><option>-fspec-constr</option></primary></indexterm>
</term>
<listitem>
- <para>Turn off the "state hack" whereby any lambda with a
- <literal>State#</literal> token as argument is considered to be
- single-entry, hence it is considered OK to inline things inside
- it. This can improve performance of IO and ST monad code, but it
- runs the risk of reducing sharing.</para>
+ <para>Turn on call-pattern specialisation.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fliberate-case</option>
+ <indexterm><primary><option>-fliberate-case</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Turn on the liberate-case transformation.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fstatic-argument-transformation</option>
+ <indexterm><primary><option>-fstatic-argument-transformation</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Turn on the static argument transformation.</para>
</listitem>
</varlistentry>
<sect2>
<title>Hints for using SMP parallelism</title>
- <para>Add the <literal>-sstderr</literal> RTS option when
+ <para>Add the <literal>-s</literal> RTS option when
running the program to see timing stats, which will help to tell you
whether your program got faster by using more CPUs or not. If the user
time is greater than
<indexterm><primary>intermediate code generation</primary></indexterm>
<para>GHC can dump its optimized intermediate code (said to be in “Core” format)
- to a file as a side-effect of compilation. Core files, which are given the suffix
- <filename>.hcr</filename>, can be read and processed by non-GHC back-end
- tools. The Core format is formally described in <ulink url="http://www.haskell.org/ghc/docs/papers/core.ps.gz">
+ to a file as a side-effect of compilation. Non-GHC back-end tools can read and process Core files; these files have the suffix
+ <filename>.hcr</filename>. The Core format is described in <ulink url="http://www.haskell.org/ghc/docs/papers/core.ps.gz">
<citetitle>An External Representation for the GHC Core Language</citetitle></ulink>,
- and sample tools (in Haskell)
- for manipulating Core files are available in the GHC source distribution
- directory <literal>/fptools/ghc/utils/ext-core</literal>.
+ and sample tools
+ for manipulating Core files (in Haskell) are in the GHC source distribution
+ directory under <literal>utils/ext-core</literal>.
Note that the format of <literal>.hcr</literal>
- files is <emphasis>different</emphasis> (though similar) to the Core output format generated
- for debugging purposes (<xref linkend="options-debugging"/>).</para>
+ files is <emphasis>different</emphasis> from the Core output format that GHC generates
+ for debugging purposes (<xref linkend="options-debugging"/>), though the two formats appear somewhat similar.</para>
<para>The Core format natively supports notes which you can add to
your source code using the <literal>CORE</literal> pragma (see <xref
</variablelist>
-<para>GHC can also read in External Core files as source; just give the <literal>.hcr</literal> file on
-the command line, instead of the <literal>.hs</literal> or <literal>.lhs</literal> Haskell source.
-A current infelicity is that you need to give the <literal>-fglasgow-exts</literal> flag too, because
-ordinary Haskell 98, when translated to External Core, uses things like rank-2 types.</para>
+<para>Currently (as of version 6.8.2), GHC does not have the ability to read in External Core files as source. If you would like GHC to have this ability, please <ulink url="http://hackage.haskell.org/trac/ghc/wiki/MailingListsAndIRC">make your wishes known to the GHC Team</ulink>.</para>
+
</sect1>
&debug;
projects / ghc-hetmet.git / blobdiff