<p dir="ltr">Can we just discourage the usage of -o in the --help output?</p>
<div class="gmail_quote">15 мая 2014 г. 4:04 пользователь "Alp Toker" <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> написал:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 15/05/2014 02:45, Reid Kleckner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, May 14, 2014 at 4:23 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br>
<br>
    One tidy way to deal with the problem described is to move the<br>
    __clang__ define here..<br>
<br>
      if (!LangOpts.MSVCCompat) {<br>
        // Currently claim to be compatible with GCC 4.2.1-5621, but<br>
    only if we're<br>
        // not compiling for MSVC compatibility<br>
        ...<br>
        Builder.defineMacro("__GNUC__"<u></u>, "4");<br>
        ...<br>
    }<br>
<br>
    This seems relatively harmless and clang's compiler feature check<br>
    macros will still work fine.<br>
<br>
    If/when the CMake detection problem gets resolved we can<br>
    re-evaluate defining __clang__ in the drop-in MSVC compatibility mode.<br>
<br>
    This feels more progressive to me than making clang-cl.exe look<br>
    like clang.exe with a -o option. What do you think?<br>
<br>
<br>
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:<br>

<a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ADT/DenseMapTest.cpp?view=markup#l122" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project/llvm/trunk/unittests/<u></u>ADT/DenseMapTest.cpp?view=<u></u>markup#l122</a><br>

</blockquote>
<br>
Okay, but if __GNUC__ is included in every other mode than MSVCCompat, also excluding __clang__ isn't a massive leap.<br>
<br>
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.<br>

<br>
Keep in mind we have that second option -- just tell CMake to override compiler detection -- does that satisfy your use case?<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, I'd rather keep defining __clang__.<br>
<br>
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:<br>
// RUN: %clangxx_asan %s -o %t && not %run %t 2>&1 | FileCheck %s<br>
</blockquote>
<br>
So this isn't really about CMake or anything else mentioned in the original patch submission? Bad Reid ;-)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote>
<br>
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?<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
</blockquote>
<br>
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.<br>
<br>
So let's put a hold on this until we find out why ASan tests are calling clang-cl.exe with -o.<br>
<br>
Alp.<br>
<br>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
______________________________<u></u>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a><br>
</blockquote></div>