<option>-fwarn-deprecated-flags</option>,
<option>-fwarn-duplicate-exports</option>,
<option>-fwarn-missing-fields</option>,
- <option>-fwarn-missing-methods</option>, and
+ <option>-fwarn-missing-methods</option>,
+ <option>-fwarn-lazy-unlifted-bindings</option>,
+ <option>-fwarn-wrong-do-bind</option>, and
<option>-fwarn-dodgy-foreign-imports</option>. The following
flags are
simple ways to select standard “packages” of warnings:
<indexterm><primary>-W option</primary></indexterm>
<para>Provides the standard warnings plus
<option>-fwarn-incomplete-patterns</option>,
+ <option>-fwarn-dodgy-exports</option>,
<option>-fwarn-dodgy-imports</option>,
<option>-fwarn-unused-matches</option>,
<option>-fwarn-unused-imports</option>, and
<option>-fwarn-simple-patterns</option>,
<option>-fwarn-tabs</option>,
<option>-fwarn-incomplete-record-updates</option>,
- <option>-fwarn-monomorphism-restriction</option>, and
+ <option>-fwarn-monomorphism-restriction</option>,
+ <option>-fwarn-unused-do-bind</option>, and
<option>-fwarn-implicit-prelude</option>.</para>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
+ <term><option>-fwarn-dodgy-exports</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-dodgy-exports</option></primary>
+ </indexterm>
+ <para>Causes a warning to be emitted when a datatype
+ <literal>T</literal> is exported
+ with all constructors, i.e. <literal>T(..)</literal>, but is it
+ just a type synonym.</para>
+ <para>Also causes a warning to be emitted when a module is
+ re-exported, but that module exports nothing.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-dodgy-imports</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-dodgy-imports</option></primary>
</varlistentry>
<varlistentry>
+ <term><option>-fwarn-lazy-unlifted-bindings</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-lazy-unlifted-bindings</option></primary>
+ </indexterm>
+ <para>Causes a warning to be emitted when an unlifted type
+ is bound in a way that looks lazy, e.g.
+ <literal>where (I# x) = ...</literal>. Use
+ <literal>where !(I# x) = ...</literal> instead. This will be an
+ error, rather than a warning, in GHC 6.14.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-duplicate-exports</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-duplicate-exports</option></primary></indexterm>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term><option>-fwarn-unused-do-bind</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-unused-do-bind</option></primary></indexterm>
+ <indexterm><primary>unused do binding, warning</primary></indexterm>
+ <indexterm><primary>do binding, unused</primary></indexterm>
+
+ <para>Report expressions occuring in <literal>do</literal> and <literal>mdo</literal> blocks
+ that appear to silently throw information away.
+ For instance <literal>do { mapM popInt xs ; return 10 }</literal> would report
+ the first statement in the <literal>do</literal> block as suspicious,
+ as it has the type <literal>StackM [Int]</literal> and not <literal>StackM ()</literal>, but that
+ <literal>[Int]</literal> value is not bound to anything. The warning is suppressed by
+ explicitly mentioning in the source code that your program is throwing something away:
+ <programlisting>
+ do { _ <- mapM popInt xs ; return 10 }
+ </programlisting>
+ Of course, in this particular situation you can do even better:
+ <programlisting>
+ do { mapM_ popInt xs ; return 10 }
+ </programlisting>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>-fwarn-wrong-do-bind</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-wrong-do-bind</option></primary></indexterm>
+ <indexterm><primary>apparently erroneous do binding, warning</primary></indexterm>
+ <indexterm><primary>do binding, apparently erroneous</primary></indexterm>
+
+ <para>Report expressions occuring in <literal>do</literal> and <literal>mdo</literal> blocks
+ that appear to lack a binding.
+ For instance <literal>do { return (popInt 10) ; return 10 }</literal> would report
+ the first statement in the <literal>do</literal> block as suspicious,
+ as it has the type <literal>StackM (StackM Int)</literal> (which consists of two nested applications
+ of the same monad constructor), but which is not then "unpacked" by binding the result.
+ The warning is suppressed by explicitly mentioning in the source code that your program is throwing something away:
+ <programlisting>
+ do { _ <- return (popInt 10) ; return 10 }
+ </programlisting>
+ For almost all sensible programs this will indicate a bug, and you probably intended to write:
+ <programlisting>
+ do { popInt 10 ; return 10 }
+ </programlisting>
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
<para>If you're feeling really paranoid, the
<varlistentry>
<term>
+ <option>-fno-float-in</option>
+ <indexterm><primary><option>-fno-float-in</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Turns off the float-in transformation.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fno-specialise</option>
+ <indexterm><primary><option>-fno-specialise</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Turns off the automatic specialisation of overloaded functions.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
<option>-fspec-constr</option>
<indexterm><primary><option>-fspec-constr</option></primary></indexterm>
</term>
</sect1>
&phases;
-
+
+ &shared_libs;
+
<sect1 id="using-concurrent">
<title>Using Concurrent Haskell</title>
<indexterm><primary>Concurrent Haskell</primary><secondary>using</secondary></indexterm>
<para>There is no means (currently) by which this value
may vary after the program has started.</para>
+
+ <para>The current value of the <option>-N</option> option
+ is available to the Haskell program
+ via <literal>GHC.Conc.numCapabilities</literal>.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
+ <term><option>-qa</option></term>
+ <indexterm><primary><option>-qa</option></primary><secondary>RTS
+ option</secondary></indexterm>
+ <listitem>
+ <para>Use the OS's affinity facilities to try to pin OS
+ threads to CPU cores. This is an experimental feature,
+ and may or may not be useful. Please let us know
+ whether it helps for you!</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
<term><option>-qm</option></term>
<indexterm><primary><option>-qm</option></primary><secondary>RTS
option</secondary></indexterm>
<para>Disable automatic migration for load balancing.
Normally the runtime will automatically try to schedule
threads across the available CPUs to make use of idle
- CPUs; this option disables that behaviour. It is probably
- only of use if you are explicitly scheduling threads onto
- CPUs with <literal>GHC.Conc.forkOnIO</literal>.</para>
+ CPUs; this option disables that behaviour. Note that
+ migration only applies to threads; sparks created
+ by <literal>par</literal> are load-balanced separately
+ by work-stealing.</para>
+
+ <para>
+ This option is probably only of use for concurrent
+ programs that explicitly schedule threads onto CPUs
+ with <literal>GHC.Conc.forkOnIO</literal>.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
whether your program got faster by using more CPUs or not. If the user
time is greater than
the elapsed time, then the program used more than one CPU. You should
- also run the program without <literal>-N</literal> for comparison.</para>
-
- <para>GHC's parallelism support is new and experimental. It may make your
- program go faster, or it might slow it down - either way, we'd be
- interested to hear from you.</para>
-
- <para>One significant limitation with the current implementation is that
- the garbage collector is still single-threaded, and all execution must
- stop when GC takes place. This can be a significant bottleneck in a
- parallel program, especially if your program does a lot of GC. If this
- happens to you, then try reducing the cost of GC by tweaking the GC
- settings (<xref linkend="rts-options-gc" />): enlarging the heap or the
- allocation area size is a good start.</para>
+ also run the program without <literal>-N</literal> for
+ comparison.</para>
+
+ <para>The output of <literal>+RTS -s</literal> tells you how
+ many “sparks” were created and executed during the
+ run of the program (see <xref linkend="rts-options-gc" />), which
+ will give you an idea how well your <literal>par</literal>
+ annotations are working.</para>
+
+ <para>GHC's parallelism support has improved in 6.12.1 as a
+ result of much experimentation and tuning in the runtime
+ system. We'd still be interested to hear how well it works
+ for you, and we're also interested in collecting parallel
+ programs to add to our benchmarking suite.</para>
</sect2>
</sect1>
projects / ghc-hetmet.git / blobdiff