On Oct 24, 2011, at 11:04 AM, David Blaikie wrote:
>> -fms-extensions = allow Microsoft extensions without sacrificing language
>> conformance
>>
>> -fms-compatibility = do crazy non-standard things to try to eat the broken
>> code that Microsoft's compiler accepts. In other words, try to be as
>> MSVC-like as Clang can be.
>
> Well it means "eat the broken code that Microsoft's compiler accepts"
> but in some cases (I believe) the same code compiles with both
> compilers but may have different semantics, right?
Yes, it can happen.
> So if I'm ever
> compiling my code with MSVC I sort of want to compile/test it with
> -fms-compatibility to make sure I don't get subtle changes in behavior
> due to different name lookup, for example. Or is this perhaps a 3rd
> distinction that isn't explicitly captured by either of these flags (&
> instead is a subset of ms-compatibility)? Ideally I don't want to
> depend on those differences either way (in any case where standard C++
> would find a different name from MSVC I'd like a warning/error so I
> can avoid it) & then I wouldn't compile with -fms-compatibility, I
> suppose.
Standard C++ code usually works with Clang and MSVC. -fms-compatibility is only
there for those cases where you're stuck with a MSVC++ code base that you can't
change.
This "third case" isn't something that either -fms-extensions or
-fms-compatibility is designed for. Clang doesn't produce warnings such as
"MSVC would find a different name here", and I don't think we should go there:
it's not worth the extra complexity or computational overhead to produce such
warnings, because there's no way we could approximate MSVC's behavior in Clang
to a useful degree. If you have a code base that's meant to compile with MSVC
and Clang, compile and test with MSVC and Clang :)
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
