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

[Timur Iskhodzhanov]

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/e67077df/attachment.html>