autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: detection and support of OpenMP


From: Ralf Wildenhues
Subject: Re: detection and support of OpenMP
Date: Thu, 17 May 2007 20:48:21 +0200 (CEST)
User-agent: SquirrelMail/1.4.9a

Hi Bruno,

* Bruno Haible wrote on Thu, May 17, 2007 at 06:20:51PM CEST:
>
> A "small portable self-contained OpenMP program" looks like this:
[...]
> But such a program is useless for an autoconf test, because the
> program without the #pragma must be well-formed, and the #pragma can
> be ignored by any compiler.
>
> However, the test can be made a little sharper by testing for the
> presence of <omp.h> and one of the simplest library functions.

Yes.  Your updated test is much better that way, thanks.

> > What if I want to create Fortran or C++ code that uses OpenMP?
>
> For C++, the test should work the same. For Fortran, you have a
> separate macro. I named the macro 'AC_C_...' to make it clear that
> it does not apply to Fortran, Java, or Lisp.

This begs the question whether we can easily generalize it.
I've only now found this macro which seems to already have done this step:
<http://autoconf-archive.cryp.to/ax_openmp.html>.
Sorry it did not occur to me earlier, that approach looks like the
canonical way to generalize it to Fortran and C++.

> > While I understand why you choose to set OPENMP_CFLAGS rather
> > than amending CFLAGS, and it makes sense to me, too, it does not fit
> > the other modes of operation of Autoconf macros.  Not sure if this
> > inconsistency in Autoconf weighs less than the
> > advantage.  Intruding into users' namespace is always a
> > double-edged sword.
>
> OPENMP_CFLAGS seems like a natural name; other autoconf macros set the
> variable X_CFLAGS. I don't see an inconsistency.

I guess I should have added "(except X_CFLAGS)".  That's the only
other exception AFAICS, and I view it as a small inconsistency.  But in
this case it may be reasonable to do as well.

FYI, the potential downside of this is that one can easily forget to add
$OPENMP_CFLAGS to CFLAGS before the next compile test that may have a
different outcome depending on this.

> > Another way to address this would be to enter a subdir
> > `conftest' and ensure no file with such a name is created.
>
> This catches the case of -openmp, but does not the case of options
> that lead to a compiler warning at each compiler invocation.

Requiring absense of compiler warnings is a possibility (with a high
chance of false negatives in large, complex packages).  But with the link
test, we're much better already: the compiler warning is only an issue for
systems that require no flag at all.

> > > +         dnl   AIX IBM C            -qsmp=omp
> >
> > Doesn't AIX have a compiler for GNU/Linux as well?  Does it
> > support OpenMP?
>
> You mean, IBM?

Yes, sorry about that.

> Yes, they sell a port of XLC for Linux [1]. But I have no
> info about the command-line option for OpenMP in this compiler.
> [1]
http://www-306.ibm.com/software/info/ecatalog/en_US/products/Q860134T18351F02.html?&S_TACT=none&S_CMP=none

As per
<http://www-1.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&dc=DA410&uid=swg27007011&loc=en_US&cs=utf-8&lang=en>

it uses -qsmp=omp as well.  As per
<http://predef.sourceforge.net/precomp.html#sec17>,
you should be able to use __xlC__ or __IBMC__ / __IBMCPP__ I guess.

> > The Intel compiler can fool the $GCC test with suitable compiler options
>
> Does autoconf support this configuration? In the sense that all of
> autoconf so far works fine with an Intel icc that defines __GNUC__ ?

I remember testing this a long time ago, for Autoconf and Libtool, and a
now-outdated version of the compiler.  Given time, I'll do it again
eventually.  PathScale comes to mind as a candidate as well (and I did try
that one about half a year ago, with only two trivial failures in the
Autoconf test suite).

> > (no arms race between the Intel people making icc more like GCC and
> > Autoconf detecting non-GCC compilers, please; this holds for some
> > other compilers as well), but at least the version I just tried (8.1)
> > does not understand -fopenmp, warns about it, but
> > does not fail.  Dunno if that would be enough of a reason to try
> > Intel first?
>
> Yes, if a masqueraded Intel icc is supported, then feel free to
> move the Intel C test before the GNU C test.

I suppose that can wait until a test, too.

> > Please ensure that the generated test for this new macro
> > succeeds.  You can run it verbosely like this:
> >   make check TESTSUITEFLAGS='-k AC_C_OPENMP -v -d -x'
>
> I don't understand what you mean, as I'm not familiar with the
> autoconf test suite. Can you take over this part, please?

Sure I can, but the more systems are tried, the better.  All you need to
do is execute the above command in Autoconf's build tree: The Autoconf
package has means to create a standard test for your new macro, without
any further work you need to do.  If the test fails, there is a reason to
look into it.  In that case, just post the output, or
tests/testsuite.dir/XXX/testsuite.log (with XXX replaced by the test number).

Cheers,
Ralf





reply via email to

[Prev in Thread] Current Thread [Next in Thread]