[patch] Fix for automatic parallelization

Sebastian Pop sebpop@gmail.com
Thu Jan 17 07:36:00 GMT 2008


On Jan 16, 2008 5:35 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> This patch has the effect of adding -pthread (regardless of
> support) whenever -ftree-parallelize-loops=* is passed.
>
> Is that really intended?  Hm, looking at the documentation,
> perhaps.  If so, please fix the test-suite - and IMHO the
> documentation (it doesn't explicitly say "not supported for all
> targets" / "where supported, implies -pthread" which can
> actually be an important detail and otherwise missed).
> (You might want to add an effective target "pthread" if you
> don't want to list *-linux* et al in the target specifier.)
>
> See PR driver/34821.
>

Thanks for reporting this problem.

The -fopenmp flag is also adding the -pthread flag in exactly the same
way as the -ftree-parallelize-loops=*.  I'm thus proposing this patch
for fixing the documentation:

Index: invoke.texi
===================================================================
--- invoke.texi	(revision 131577)
+++ invoke.texi	(working copy)
@@ -1519,7 +1519,9 @@ freestanding and hosted environments.
 Enable handling of OpenMP directives @code{#pragma omp} in C/C++ and
 @code{!$omp} in Fortran.  When @option{-fopenmp} is specified, the
 compiler generates parallel code according to the OpenMP Application
-Program Interface v2.5 @w{@uref{http://www.openmp.org/}}.
+Program Interface v2.5 @w{@uref{http://www.openmp.org/}}.  This option
+implies @option{-pthread}, and thus is only supported on targets that
+have support for @option{-pthread}.

 @item -fms-extensions
 @opindex fms-extensions
@@ -5841,7 +5843,9 @@ Parallelize loops, i.e., split their ite
 This is only possible for loops whose iterations are independent
 and can be arbitrarily reordered.  The optimization is only
 profitable on multiprocessor machines, for loops that are CPU-intensive,
-rather than constrained e.g. by memory bandwidth.
+rather than constrained e.g. by memory bandwidth.  This option
+implies @option{-pthread}, and thus is only supported on targets
+that have support for @option{-pthread}.

 @item -ftree-sra
 @opindex ftree-sra


I don't know yet how GOMP is avoiding the problems in the testsuite,
(I suppose that there is some configury part for the libgomp)
but I will try to fix the testcases using something similar to what
GOMP does.

-- 
Sebastian
AMD - GNU Tools



More information about the Gcc-patches mailing list