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

[Reid Kleckner]

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.


On Wed, May 14, 2014 at 11:36 PM, Timur Iskhodzhanov <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> написал:
>
>>
>> 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
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140515/8dfb3d92/attachment.html>