On 15/05/2014 10:00, Reid Kleckner wrote:
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.
Neat. Making the standard clang driver do the right thing sounds like a
much better way forward.
I've taken a look and AddClangCLArgs() looks straightforward enough to
factor for use with the standard driver. Reid, how do you think this
would best be exposed?
In the meantime a platform-specific lit.site.cfg substitution of %clang
with clang.exe -D_MT -Xclang --dependent-lib=libcmt might get things
moving for compiler-rt..
Alp.
On Wed, May 14, 2014 at 11:36 PM, Timur Iskhodzhanov
<[email protected] <mailto:[email protected]>> wrote:
Can we just discourage the usage of -o in the --help output?
15 мая 2014 г. 4:04 пользователь "Alp Toker" <[email protected]
<mailto:[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]> <mailto:[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] <mailto:[email protected]>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
