[cfe-dev] Question: how to robustly detect available command line arguments

[David Cole]

On Fri, Jun 15, 2012 at 1:18 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Jun 13, 2012, at 4:30 PM, Michael Spencer wrote:
>
> > On Wed, Jun 13, 2012 at 2:38 PM, David Cole <david.cole at kitware.com>
> wrote:
> >> On Mon, Jun 4, 2012 at 2:29 PM, david.cole <david.cole at kitware.com>
> wrote:
> >>>
> >>> I'm one of the CMake developers. We have an issue in our bug tracker
> >>> that's
> >>> related to clang's command line argument parsing:
> >>> http://public.kitware.com/Bug/view.php?id=13194
> >>>
> >>> The bug reported is using this version of clang (MacOS X 10.7.3 with
> Xcode
> >>> 4.3.2):
> >>> $ /usr/bin/cc -v
> >>> Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM
> 3.1svn)
> >>>
> >>> In the bug report, the CMake script code is trying to run clang to
> test if
> >>> it recognizes a given command line argument. We expect to report that
> it
> >>> does not support an argument if there's an error when using the
> argument
> >>> trying to compile this snippet: "int main() { return 0;}"
> >>>
> >>> When given "-maltivec" it produces:
> >>> clang: warning: argument unused during compilation: '-maltivec'
> >>>
> >>> By giving us that output, clang indicates that it does recognize the -m
> >>> compiler argument, but warns us that -maltivec has not been used. (At
> >>> least,
> >>> that's how I read it.)
> >>>
> >>> So, here's the question: Can you recommend how to robustly detect
> whether
> >>> or
> >>> not clang supports a given command line argument? For both existing
> >>> versions
> >>> of clang in the wild, and future releases.
> >>>
> >>> The bug reporter in this case, wants us to recognize "argument unused
> >>> during
> >>> compilation" as an error, but I'm concerned that doing so will falsely
> >>> report other valid command line arguments as unavailable...
> >>>
> >>>
> >>> Thanks,
> >>> David Cole
> >>> Kitware, Inc.
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://clang-developers.42468.n3.nabble.com/Question-how-to-robustly-detect-available-command-line-arguments-tp4024269.html
> >>> Sent from the Clang Developers mailing list archive at Nabble.com.
> >>> _______________________________________________
> >>> cfe-dev mailing list
> >>> cfe-dev at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >>
> >>
> >> Not a lot of response on this one, so let me re-phrase:
> >>
> >>
> >> How can I tell what the output "clang: warning: argument unused during
> >> compilation" means?
> >>
> >> If I get it when using "-maltivec" does it mean that ANY -m argument
> would
> >> be unused?
> >>
> >>
> >> Or, what's the best way of knowing the set of valid possible values for
> -m?
> >>
> >>
> >> Thanks,
> >> David Cole
> >> Kitware, Inc.
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >
> > "warning: argument unused during compilation" means that the argument
> > did not effect the compilation at all. Removing it would not change
> > the output. It does not mean that all -m arguments would be unused. If
> > the code depends on the gcc behavior of this flag, then it is possible
> > that clang would not preserve that behavior. From my quick reading it
> > seems that -maltivec just allows the compiler to generate altivec
> > code, which clang allows if the target supports it.
> >
> > I agree with the reporter that this warning should indicate that clang
> > does not support the specific option given.
>
>
> I think what we're missing is that "argument unused during compilation"
> means either "I don't know what this argument is" or "I know what this
> argument is, and it has no impact". It would be preferable if the driver
> distinguished these cases: http://llvm.org/bugs/show_bug.cgi?id=13119
>
>        -Doug
>


Thanks for the replies -- I'm still not sure what we should do in our CMake
module, but this gives us better input for thinking about the problem. For
now, we'll leave it as is until we come up with an approach (if we can)
that will work with existing and future clang.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120616/5a9312e0/attachment.html>