[cfe-dev] MSVC /Za considered harmful

[Benjamin Kramer]

On 07.06.2012, at 01:22, Stephan T. Lavavej 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 agree, it looks like it's not an issue anymore as /Za was removed from the clang build and everything seems to be fine :)

>> 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.

Compared to a clean /W3 build. But this was years ago and it is likely that there were other factors leading to the slowdown. It produced an enormous wall of text that had to be printed to stderr, logged and sent over the network (it was a buildbot instance). That alone could have caused the slowdown we observed.

- Ben