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

[Alp Toker]

On 15/05/2014 10:00, Reid Kleckner wrote:
> No, we should either add -o to clang-cl or not do it at all.
>
> Maybe we should just run these tests with the gcc driver frontend. 
>  clang and clang-cl are much more interchangeable since we made 
> *-win32 imply the MSVC C++ ABI.  The only interesting difference that 
> comes to mind is the CRT.  I think clang-cl inserts --dependent-lib= 
> arguments that clang does not.

Neat. Making the standard clang driver do the right thing sounds like a 
much better way forward.

I've taken a look and AddClangCLArgs() looks straightforward enough to 
factor for use with the standard driver. Reid, how do you think this 
would best be exposed?

In the meantime a platform-specific lit.site.cfg substitution of %clang 
with clang.exe -D_MT -Xclang --dependent-lib=libcmt might get things 
moving for compiler-rt..

Alp.



>
>
> On Wed, May 14, 2014 at 11:36 PM, Timur Iskhodzhanov 
> <timurrrr at google.com <mailto:timurrrr at google.com>> wrote:
>
>     Can we just discourage the usage of -o in the --help output?
>
>     15 мая 2014 г. 4:04 пользователь "Alp Toker" <alp at nuanti.com
>     <mailto:alp at nuanti.com>> написал:
>
>
>         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> <mailto: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
>
>         _______________________________________________
>         cfe-commits mailing list
>         cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>         http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>

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