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

[Alp Toker]

On 15/05/2014 02:45, Reid Kleckner wrote:
> On Wed, May 14, 2014 at 4:23 PM, Alp Toker <alp at nuanti.com 
> <mailto: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

Okay, but if __GNUC__ is included in every other mode than MSVCCompat, 
also excluding __clang__ isn't a massive leap.

On the other hand, as soon a patch adding "-o" lands CMake is left in an 
odd place where it's using clang-cl.exe as a kind of clang.exe with 
slightly different sematics which isn't a good place to be.

Keep in mind we have that second option -- just tell CMake to override 
compiler detection -- does that satisfy your use case?


>
> 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

So this isn't really about CMake or anything else mentioned in the 
original patch submission? Bad Reid ;-)

> 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.

It looks like those tests *should* work fine with clang.exe. Why are 
they using clang-cl.exe only to go ahead and pass through 
clang.exe-style flags?
>
> 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.

This feels like it'd be a misfeature. The only reason a test would 
legitimately use clang-cl.exe is to (a) test the MSVC drop-in driver 
itself or (b) permit the same tests to be run against both MSVC and clang.

So let's put a hold on this until we find out why ASan tests are calling 
clang-cl.exe with -o.

Alp.

-- 
http://www.nuanti.com
the browser experts