MantisBT - CMake
View Issue Details
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.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-05-05 14:38Jared BooneNew Issue
2012-05-05 17:24Rolf Eike BeerNote Added: 0029404
2012-05-05 17:24Rolf Eike BeerAssigned To => Rolf Eike Beer
2012-05-05 17:24Rolf Eike BeerStatusnew => resolved
2012-05-05 17:24Rolf Eike BeerResolutionopen => fixed
2012-05-05 17:24Rolf Eike BeerFixed in Version => CMake 2.8.9
2012-05-05 17:24Rolf Eike BeerTarget Version => CMake 2.8.9
2012-05-17 13:58David ColeNote Added: 0029501
2012-05-17 13:58David ColeStatusresolved => feedback
2012-05-17 13:58David ColeResolutionfixed => reopened
2012-05-17 14:08Jared BooneNote Added: 0029503
2012-05-17 14:08Jared BooneStatusfeedback => assigned
2012-05-17 14:10David ColeNote Added: 0029504
2012-06-04 15:32David ColeFixed in VersionCMake 2.8.9 =>
2012-06-05 14:36David ColeNote Added: 0029615
2012-06-16 08:23David ColeNote Added: 0029708
2012-07-09 07:13David ColeNote Added: 0029988
2012-07-09 07:21David ColeTarget VersionCMake 2.8.9 =>
2012-08-10 09:19Brad KingNote Added: 0030206
2012-09-03 17:04Rolf Eike BeerAssigned ToRolf Eike Beer =>
2012-09-03 17:04Rolf Eike BeerStatusassigned => backlog
2016-06-10 14:28Kitware RobotNote Added: 0042040
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionreopened => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0029404)
Rolf Eike Beer   
2012-05-05 17:24   
Fix pushed to next:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4eff024497062676f7ca82783f3a2df3e2781a9 [^]
(0029501)
David Cole   
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   
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   
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   
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   
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   
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   
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   
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.