View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013194CMakeModulespublic2012-05-05 14:382016-06-10 14:31
ReporterJared Boone 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSMacOS XOS Version10.7.3
Product VersionCMake 2.8.7 
Target VersionFixed in Version 
Summary0013194: Clang compiler flag detection incorrectly reports "Success"
DescriptionI recently tried compiling GNU Radio (3.6.1-ish development branch) and ran into trouble when CMake was detecting compiler flags relating to instruction sets. It turns out that Clang reports "unused arguments" as warnings, and the message is not presently matched in Modules/CheckCXXCompilerFlag.cmake.
Steps To ReproduceThe command line executed by CheckCXXCompilerFlag:

   /usr/bin/c++ -Dhave_maltivec -maltivec -o CMakeFiles/cmTryCompileExec.dir/src.cxx.o -c /Users/jboone/tmp/gnuradio/build/volk/CMakeFiles/CMakeTmp/src.cxx

When I run the test on my Intel Mac using my own src.cxx ("int main() { return 0; }"), I get:

   clang: warning: argument unused during compilation: '-maltivec'

This warning will not be detected by the current CheckCXXCompilerFlags.cmake:

From http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CheckCXXCompilerFlag.cmake;hb=HEAD [^]

     # Some compilers do not fail with a bad flag
     FAIL_REGEX "command line option .* is valid for .* but not for C\\\\+\\\\+" # GNU
     FAIL_REGEX "unrecognized .*option" # GNU
     FAIL_REGEX "unknown .*option" # Clang
     FAIL_REGEX "ignoring unknown option" # MSVC
     FAIL_REGEX "warning D9002" # MSVC, any lang
     FAIL_REGEX "option.*not supported" # Intel
     FAIL_REGEX "invalid argument .*option" # Intel
     FAIL_REGEX "ignoring option .*argument required" # Intel
     FAIL_REGEX "[Uu]nknown option" # HP
     FAIL_REGEX "[Ww]arning: [Oo]ption" # SunPro
     FAIL_REGEX "command option .* is not recognized" # XL
     FAIL_REGEX "not supported in this configuration; ignored" # AIX
     FAIL_REGEX "File with unknown suffix passed to linker" # PGI
     FAIL_REGEX "WARNING: unknown flag:" # Open64

I was able to solve the problem by adding one line to the list of FAIL_REGEXs:

    FAIL_REGEX "argument unused during compilation" # Clang
Additional InformationI'm using MacOS X 10.7.3 with Xcode 4.3.2. I have MacPorts installed, but have removed all MacPorts gcc, llvm, and cctools packages, to ensure I'm working with the Xcode Clang.

$ /usr/bin/cc -v
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix

$ /usr/bin/c++ -v
Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix

$ ls -l /usr/bin/cc
lrwxr-xr-x 1 root wheel 5 Apr 18 22:05 /usr/bin/cc -> clang

$ ls -l /usr/bin/c++
lrwxr-xr-x 1 root wheel 7 Apr 18 22:05 /usr/bin/c++ -> clang++
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0029404)
Rolf Eike Beer (developer)
2012-05-05 17:24

 Fix pushed to next:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4eff024497062676f7ca82783f3a2df3e2781a9 [^]
(0029501)
David Cole (manager)
2012-05-17 13:58

 Sorry for the lateness of this comment, I should have added it here after we did not take this change at last week's merge to 'master' session on Tues. May 8, 2012...

The problem that Brad and I have with this change is that the function is supposed to identify whether or not the compiler knows about and accepts a given argument on its command line.

In the case of "warning: argument unused during compilation:" it's clearly indicating that the compiler does in fact recognize the option in question, and is simply informing the compiler caller that the argument was not in fact used during the compilation...

Perhaps clang is unintentionally accepting some bad strings that it shouldn't after its -m arguments...? (i.e., perhaps this call to clang should result in an error, but does not?)

So. Brad and I don't think it belongs in this function *in general* -- perhaps in this specific case, it does, but in general, I'm not yet convinced. I'm concerned that if we put this change in, it will cause some other negative consequences for folks depending on the current behavior. (I don't have a specific example of this, but I'm always concerned about this with all behavior changing changes...)

There is other discussion here:

  http://www.ruby-forum.com/topic/4216278 [^]
(0029503)
Jared Boone (reporter)
2012-05-17 14:08

 @David:

For what it's worth, I can do this in Clang (LLVM 3.0):

$ clang -mkasjhdaksjhdakj -c -o test.o test.cxx
clang: warning: argument unused during compilation: '-mkasjhdaksjhdakj'

...and even:

$ clang -kasjhdaksjhdakj -c -o test.o test.cxx
clang: warning: argument unused during compilation: '-kasjhdaksjhdakj'

So Clang is reporting an argument this way if it does not recognize it, which I think is different from your understanding.

From my comments in the GNU Radio discussion thread, I think the ideal solution is to tell Clang to report unused (and unrecognized) arguments as errors with a non-zero return code. The LLVM team has fixed the "-Werror" bug that prevents this, which will be available in LLVM 3.1. Until LLVM 3.1, it appears the only way to tell that Clang does not *recognize* a flag is to regex the warning. There's no flag combination I could determine that would yield an error with a non-zero return code.
(0029504)
David Cole (manager)
2012-05-17 14:10

 Thanks for the extra info, we'll take that into consideration. Please leave the change in 'next' for now, while we think on it for a bit.
(0029615)
David Cole (manager)
2012-06-05 14:36

 Posted a question on the clang developer's mailing list. Awaiting a response there... Hopefully a clang dev can at least give us some advice before we decide how to proceed here.

  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/021849.html [^]
(0029708)
David Cole (manager)
2012-06-16 08:23

 More discussion as replies to my original post on the clang dev list:

  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/thread.html#21849 [^]

And now there's a bug filed against llvm to tease apart the difference between "known/valid, but unused command line arguments" and "command line arguments that are not recognized"

  http://llvm.org/bugs/show_bug.cgi?id=13119 [^]
(0029988)
David Cole (manager)
2012-07-09 07:13

 Unset target version field; too late for a fix to go into 2.8.9; deferred until a future version.
(0030206)
Brad King (manager)
2012-08-10 09:19

 I've reverted the change mentioned in 0013194:0029404 from next:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2e9d307 [^]

The issues raised in discussion here have not been resolved. Upstream Clang must either be fixed or its experts need to tell us how to do this.
(0042040)
Kitware Robot (administrator)
2016-06-10 14:28

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2012-05-05 14:38 Jared Boone New Issue
2012-05-05 17:24 Rolf Eike Beer Note Added: 0029404
2012-05-05 17:24 Rolf Eike Beer Assigned To => Rolf Eike Beer
2012-05-05 17:24 Rolf Eike Beer Status new => resolved
2012-05-05 17:24 Rolf Eike Beer Resolution open => fixed
2012-05-05 17:24 Rolf Eike Beer Fixed in Version => CMake 2.8.9
2012-05-05 17:24 Rolf Eike Beer Target Version => CMake 2.8.9
2012-05-17 13:58 David Cole Note Added: 0029501
2012-05-17 13:58 David Cole Status resolved => feedback
2012-05-17 13:58 David Cole Resolution fixed => reopened
2012-05-17 14:08 Jared Boone Note Added: 0029503
2012-05-17 14:08 Jared Boone Status feedback => assigned
2012-05-17 14:10 David Cole Note Added: 0029504
2012-06-04 15:32 David Cole Fixed in Version CMake 2.8.9 =>
2012-06-05 14:36 David Cole Note Added: 0029615
2012-06-16 08:23 David Cole Note Added: 0029708
2012-07-09 07:13 David Cole Note Added: 0029988
2012-07-09 07:21 David Cole Target Version CMake 2.8.9 =>
2012-08-10 09:19 Brad King Note Added: 0030206
2012-09-03 17:04 Rolf Eike Beer Assigned To Rolf Eike Beer =>
2012-09-03 17:04 Rolf Eike Beer Status assigned => backlog
2016-06-10 14:28 Kitware Robot Note Added: 0042040
2016-06-10 14:28 Kitware Robot Status backlog => resolved
2016-06-10 14:28 Kitware Robot Resolution reopened => moved
2016-06-10 14:28 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team