[PATCH] clang-cl: Add support for -o

[Reid Kleckner]

On Wed, May 14, 2014 at 4:23 PM, Alp Toker <alp at nuanti.com> wrote:

> One tidy way to deal with the problem described is to move the __clang__
> define here..
>
>   if (!LangOpts.MSVCCompat) {
>     // Currently claim to be compatible with GCC 4.2.1-5621, but only if
> we're
>     // not compiling for MSVC compatibility
>     ...
>     Builder.defineMacro("__GNUC__", "4");
>     ...
> }
>
> This seems relatively harmless and clang's compiler feature check macros
> will still work fine.
>
> If/when the CMake detection problem gets resolved we can re-evaluate
> defining __clang__ in the drop-in MSVC compatibility mode.
>
> This feels more progressive to me than making clang-cl.exe look like
> clang.exe with a -o option. What do you think?


I agree, if we didn't define __clang__, it would force more users to use
the feature detection macros.  However, it seems inconsistent with what we
do in our default mode, where we define __clang__ and __GNUC__.  It also
makes it hard to isolate a hack that is intended only for MSVC, like we do
here:
http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ADT/DenseMapTest.cpp?view=markup#l122

So, I'd rather keep defining __clang__.

My immediate use case for adding -o to clang-cl is to get the asan lit test
suite passing.  They have a bunch of RUN lines like:
// RUN: %clangxx_asan %s -o %t && not %run %t 2>&1 | FileCheck %s
We want ASan to work with clang-cl.  All the relevant ASan enabling options
are being exposed there, so it makes sense to run these tests with the
clang-cl driver as well as the clang driver.  If clang-cl supports -o, then
this just works without adding more lit substitutions.

I also think it would be nice, just for regular command line use, to
support -o.  It doesn't conflict with anything, so I don't see much
downside.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140514/175823f1/attachment.html>