<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 14, 2014 at 4:23 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><span style="color:rgb(34,34,34)">One tidy way to deal with the problem described is to move the __clang__ define here..</span><br></div></div>
<br>
  if (!LangOpts.MSVCCompat) {<br>
    // Currently claim to be compatible with GCC 4.2.1-5621, but 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 macros will still work fine.<br>
<br>
If/when the CMake detection problem gets resolved we can 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 like clang.exe with a -o option. What do you think?</blockquote><div><br></div><div>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">http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ADT/DenseMapTest.cpp?view=markup#l122</a><br></div><div><br>
</div><div>So, I'd rather keep defining __clang__.</div><div><br></div><div>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:</div><div><div>
// RUN: %clangxx_asan %s -o %t && not %run %t 2>&1 | FileCheck %s</div></div><div>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.</div>
<div><br></div><div>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.</div></div></div></div>