Paul Eggert asked:
> What are the consequences of compiling with -fopenmp etc.?
At compile time, the compiler understands some #pragmas and provides a
header file <omp.h>. At link time, a special library is linked in
(libgomp.so in the case of gcc, libmtsk.so in the case of SunPRO C etc.).
> Can you link modules compiled with -fopenmp, with modules that are not
> compiled with -fopenmp?
Yes, this works. But if at least one compilation unit is compiled with
-fopenmp, the linking process must also be done with -fopenmp. (Since
compiling with -fopenmp may introduce references to functions provided
by libgomp.)
> Does -fopenmp hurt performance for apps that don't need it?
When an app doesn't use OpenMP (i.e. contains no #pragma omp and no use of
<omp.h>), compiling with -fopenmp has no effect on the generated code.
When an app uses OpenMP, say, to parallelize a loop that would take 1 sec.,
and only one processor is available, the OpenMP overhead is negligible.
Of course, OpenMP can have an overhead, for example when you direct it
to parallelize a tiny loop like
for (int i = 0; i < 4; i++)
foo[i] = i;
That's not what OpenMP is made for.
> How would one use OPENMP_CFLAGS? Does -fopenmp need to be added to
> both CFLAGS and CPPFLAGS? Is that why it's not merely put into
> CFLAGS?
It's needed for compiling and for linking. As far as I can tell, it's not
needed for preprocessing, since <omp.h> is found in the compiler's search
path anyway. Therefore, either CFLAGS, or CPPFLAGS + LDFLAGS are the
appropriate places to put them.
> This is related to our more-general problem that compiler
> options like -m64 don't properly belong in either CFLAGS or CPPFLAGS,
> which means people typically work around the problem with "CC=gcc -m64".
It appears to be simpler in this case: OpenMP support is unrelated to
preprocessing.
Bruno
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
