[cfe-dev] MSVC /Za considered harmful

[Michael Spencer]

On Wed, Jun 6, 2012 at 4:22 PM, Stephan T. Lavavej
<stl at exchange.microsoft.com> wrote:
> [Nathan Ridge]
>> Instead of asking them to get rid of it, why don't you ask them to fix it?
>
> I did. When I'm elected World Controller in 2012, I'll actually get everything I ask for. Or else.
>
> [Chandler Carruth]
>> (I would encourage folks to at least keep STL on the to-line, or mail him directly as he may not read cfe-dev as closely as others...)
>
> Thanks. I actually subscribed, then disabled mail delivery, since I wasn't planning to monitor cfe-dev for the MSVC bat-signal like I do for Boost. (I was planning to check the web archives for replies, and only later realized that I'd break threading if I didn't have any mails to reply to.)
>
>> The common problem is that standard library headers shipping with the compile *should* have access to the extensions.
>
> Yeah. In VC's STL, we definitely attempt to remain portable except when we absolutely must use extensions (e.g. DLL stuff, type traits compiler hooks), but the CRT, ATL/MFC, windows.h, and other libraries definitely vary in their use of extensions.
>
>> The right approach is for Clang to not set flags when being built by Visual Studio that are flaky or problematic.
>
> A few others that are hopefully not relevant:
>
> * /J is incredibly evil.
> * /RTCc breaks strictly conforming code by design (e.g. casts that truncate). I am barely willing to fix /RTCc problems in the STL when the fixes are trivial, but we don't run our tests with this.
> * /Wp64 is notoriously buggy (it has actually been command-line deprecated for three major versions: VC9-11). It suffers from false positives and false negatives, especially in templated code. The correct thing to do is to compile with a 64-bit-targeting compiler in order to catch 64-bit problems.
>
> [Benjamin Kramer]
>> The /Za flag was added to the build of clang not to encourage writing portable code but because an extension
>> was breaking perfectly valid c++ code for "pre-C++11 move emulation".
>
> I wasn't aware of that (but it doesn't surprise me - in fact I bet it's the Evil Extension).
>
> However, I consider breaking real move semantics to be more severe than breaking simulated move semantics.
>
>> I find the decision to deprecate /Za worrisome because it is a useful feature, but that's your choice
>
> It's actually the compiler team's choice (they have to worry about things like dev/test cost and breaking users; those aren't my costs and I love breaking users) - my preferences are certainly #1 remove extensions outright, #2 fix /Za, #3 remove /Za, #4 command-line deprecate /Za (as a prelude to #3), #5 notify people when we see them using /Za.
>
>> Coverage of building clang with msvc11 will probably decline sharply when it hits the market as setting up a build will require buying a license
>
> I don't actually know anything about this subject (and I won't until I can get VC11 RTM in a VM), but if you care about command-line builds only (as I do), I believe that Magic 8 Ball says Outlook Good.
>
>> A few words to /W4: We experimented with having an automated builder using /W4 in the msvc8-days but it was very noisy and slowed down the build by 2x or so
>
> Compared to /W3, or compared to no (!!!) warnings at all? That is news to me.
>
> STL

We use /W3 by default with quite a few warnings disabled. I just
tested out /W4 with 2012 RC, and while the compile time seems fine, it
generates 157k lines (21MiB) of warnings on LLVM (only x86 target)
alone. Very few of them are useful because they fire in too many
contexts. We can disable them, but then they don't fire at all, even
when they are correct.

As for the /W4 specific extension warnings, I have been unable to find
exactly which numbers they are. We could specifically add these to our
build.

And on a related note, are bug reports about non-standard and
non-extension errors in the Visual C++ Libraries useful? We often
encounter cases with, for example, missing typenames and incorrect
name lookup when compiling with Clang.  We have added support for
emulating MSVC's behavior, but it would be nice to be able to not have
to do this, as it makes writing portable code harder.

- Michael Spencer