Re: detection and support of OpenMP

[Bruno Haible]

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