libMesh / libmesh

libMesh github repository
http://libmesh.github.io
GNU Lesser General Public License v2.1
655 stars 286 forks source link

Wrong openmp flag when using clang compiler #30

Closed andrsd closed 11 years ago

andrsd commented 11 years ago

Using a clang compiler (3.1), ./configure script adds -fopenmp info CXXFLAGS and CFLAGS. It should be -openmp.

roystgnr commented 11 years ago

On Mon, 14 Jan 2013, David Andrs wrote:

Using a clang compiler (3.1), ./configure script adds -fopenmp info CXXFLAGS and CFLAGS. It should be -openmp.

We're using ax_openmp.m4 from the autoconf archive, which does try -fopenmp before trying -openmp. My clang++ 3.0 seems to be happy with either (at least it doesn't emit "argument unused during compilation" warnings like it does with -thiswontwork)... if clang 3.1 is getting more picky about its options, I'm not sure how to easily modify that m4 file, which seems to assume that compilers will return errors upon seeing unknown options, not just warnings.

jwpeterson commented 11 years ago

On Mon, Jan 14, 2013 at 3:22 PM, David Andrs notifications@github.comwrote:

Using a clang compiler (3.1), ./configure script adds -fopenmp info CXXFLAGS and CFLAGS. It should be -openmp.

I can take a look at this... it appears that because the AX_OPENMP script tries the options in the following order:

ax_openmp_flags="-fopenmp -openmp -mp -xopenmp -omp -qsmp=omp none"

And clang doesn't return 1 (it only warns) if it sees -fopenmp, that configure thinks it succeeds.

Easy fix: we could change the order in which the flags are tested, of course this might break another compiler in the same manner.

More complicated: we could re-order the options based on knowing what the compiler is. Seems to be a way of doing this through the $OPENMP_[]_AC_LANG_PREFIX[]FLAGS variable (though I don't understand this syntax).

Even more complicated: we could actually try to parse more detailed output from the compiler (and look for warnings) but I don't know how to do that in autoconf...

John

andrsd commented 11 years ago

Hmm. Tried it again today and I think I was wrong with the -openmp flag. If I use this switch, I do not get any error. However clang will interpret this switch as "-o penmp" and produces a file called penmp - which I did not notice before. Compiling from a command line with -fopenmp does not throw any warnings on my simple test C and C++ files. Thus, I am not quite sure why the libmesh build produces that " clang++: warning: argument unused during compilation: '-fopenmp' "... Feel free to mark this issue as wontfix or invalid unless you guys want to look at source of that unused flag warning...

benkirk commented 11 years ago

On Jan 15, 2013, at 9:42 AM, David Andrs notifications@github.com wrote:

" clang++: warning: argument unused during compilation: '-fopenmp'

The way I interpret that is that the argument was truly unused - e.g. the underlying file that was compiled had no OpenMP pragmas?

What happens if you try

./configure libmesh_CXXFLAGS="-Qunused-arguments" libmesh_CFLAGS="-Qunused-arguments"

?

-Ben

jwpeterson commented 11 years ago

On Tue, Jan 15, 2013 at 8:42 AM, David Andrs notifications@github.comwrote:

Hmm. Tried it again today and I think I was wrong with the -openmp flag. If I use this switch, I do not get any error. However clang will interpret this switch as "-o penmp" and produces a file called penmp - which I did not notice before. Compiling from a command line with -fopenmp does not throw any warnings on my simple test C and C++ files. Thus, I am not quite sure why the libmesh build produces that " clang++: warning: argument unused during compilation: '-fopenmp' "... Feel free to mark this issue as wontfix or invalid unless you guys want to look at source of that unused flag warning...

Looks like this may have been a compiler bug. Here it was discussed in October 2012:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/054459.html

Do you like the idea of adding -Qunused-arguments in compiler.m4 for all clang builds?

John

jwpeterson commented 11 years ago

On Tue, Jan 15, 2013 at 8:54 AM, John Peterson jwpeterson@gmail.com wrote:

On Tue, Jan 15, 2013 at 8:42 AM, David Andrs notifications@github.com wrote:

Hmm. Tried it again today and I think I was wrong with the -openmp flag. If I use this switch, I do not get any error. However clang will interpret this switch as "-o penmp" and produces a file called penmp - which I did not notice before. Compiling from a command line with -fopenmp does not throw any warnings on my simple test C and C++ files. Thus, I am not quite sure why the libmesh build produces that " clang++: warning: argument unused during compilation: '-fopenmp' "... Feel free to mark this issue as wontfix or invalid unless you guys want to look at source of that unused flag warning...

Looks like this may have been a compiler bug. Here it was discussed in October 2012:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/054459.html

Where by "bug" I mean "unsupported feature". I think David's clang (3.1) was released 22 May 2012

http://llvm.org/releases/

i.e. prior to the discussion cited above.

Do you like the idea of adding -Qunused-arguments in compiler.m4 for all clang builds?

If there's any desire for this, I will take a crack at adding it.

John

andrsd commented 11 years ago

On Tue, Jan 15, 2013 at 8:46 AM, Benjamin S. Kirk notifications@github.comwrote:

On Jan 15, 2013, at 9:42 AM, David Andrs notifications@github.com wrote:

" clang++: warning: argument unused during compilation: '-fopenmp'

The way I interpret that is that the argument was truly unused - e.g. the underlying file that was compiled had no OpenMP pragmas?

What happens if you try

./configure libmesh_CXXFLAGS="-Qunused-arguments" libmesh_CFLAGS="-Qunused-arguments"

This works, i.e. no warnings generated during the build.

?

-Ben

— Reply to this email directly or view it on GitHubhttps://github.com/libMesh/libmesh/issues/30#issuecomment-12273218.

David

benkirk commented 11 years ago

Resurrecting... John, I have no problem adding -Qunused-arguments

Looks like it is understood at least as far back as 2.8.