On 15/05/2014 02:45, Reid Kleckner wrote:
On Wed, May 14, 2014 at 4:23 PM, Alp Toker <[email protected]
<mailto:[email protected]>> 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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
