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
