No, we should either add -o to clang-cl or not do it at all. Maybe we should just run these tests with the gcc driver frontend. clang and clang-cl are much more interchangeable since we made *-win32 imply the MSVC C++ ABI. The only interesting difference that comes to mind is the CRT. I think clang-cl inserts --dependent-lib= arguments that clang does not.
On Wed, May 14, 2014 at 11:36 PM, Timur Iskhodzhanov <[email protected]>wrote: > Can we just discourage the usage of -o in the --help output? > 15 мая 2014 г. 4:04 пользователь "Alp Toker" <[email protected]> написал: > >> >> 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 >> >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
