On Wed, May 14, 2014 at 4:23 PM, Alp Toker <[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 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 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. 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
