/analyze–Command Line Options

/analyze has a few command line options to control its behavior. However only one of them is actually documented. In this article I share what I’ve figured out about these options.

Update: there are now six options to /analyze that are documented.

Preamble

The enterprise (team development) versions of VS have an extra page in the properties window called Code Analysis, but I don’t generally use it. Instead I just put /analyze and the list of warnings that I want to disable in the Command Line section of the C/C++ page of the properties window. Apparently this use case wasn’t usability tested because it always leads to this warning:

cl : Command line warning D9025: overriding ‘/analyze-‘ with ‘/analyze’

I guess the IDE puts /analyze- on the command line, so when I turn it on with /analyze I am creating a contradictory command line.

Option the first: WX-

The one documented command line option for /analyze is WX-. The VS 2010 documentation for this option says:

Specifying /analyze:WX- means code analysis warnings will not be treated as errors when compiling with /WX.

Simple enough. So, where I used to specify /analyze in the C/C++ Command Line I can now specify /analyze:WX-.

But that doesn’t work.

Apparently /analyze:WX- makes /analyze warnings not be errors, but it doesn’t actually turn on /analyze! Therefore, in the command line options you actually need to go:

/analyze /analyze:WX-

This was sufficiently non-obvious to me that for a long time I thought the option was completely broken. Writing these blog posts always makes me investigate a bit deeper, and so I figured out what was really going on.

Update: /analyze:WX- now (VS 2013) turns on /analyze as well as making /analyze warnings not be errors.

Option the second: stacksize

If you have a function that uses a lot of stack space for local variables (I’ve seen some that use a MB) then /analyze will emit warning C6262, like this:

warning C6262: Function uses ‘40004’ bytes of stack: exceeds /analyze:stacksize’16388′. Consider moving some data to heap

This warning and its documentation are the only mentions of this option. Like the WX- option using this doesn’t actually turn on /analyze, it just configures it. Also note that the syntax shown in the warning is misleading. There are no single quotes around the stack size parameter.

Option the third: only

Wow – a third undocumented option? If there are three I’ll bet there are more.

I can’t even remember where I heard about this one. If you specify /analyze:only (in addition to specifying /analyze) then it tells the compiler to only do code analysis – it tells the compiler to skip code generation. On my limited and guaranteed-not-representative tests this increases /analyze compile speeds by about 30%. If doing code analysis is a separate process from generating code then this can be helpful. Running /analyze this way is still not as fast as running without /analyze, but it’s closer.

Summary

A plausible /analyze command line therefore might look like:

/analyze /analyze:WX- /analyze:stacksize50000 /analyze:only

If you know of more /analyze options, let me know and I’ll document them here.

Useful options should be documented, and documented well. I’ll have more thoughts on some more important documentation in a later post.

Update: there is an interesting side-effect of using the /analyze:only switch. It turns out that some warnings are only caught by the ‘normal’ compile, so compiling with /analyze:only may give fewer warnings. In particular warning C4265, class has virtual functions, but destructor is not virtual, will not be reported if you compile with /analyze:only. Warning C4265 can be quite useful (but is off by default) and it took me a while to figure out why it wasn’t working when I enabled it, until I guessed that /analyze:only was the problem.

About brucedawson

I'm a programmer, working for Google, focusing on optimization and reliability. Nothing's more fun than making code run 10x faster. Unless it's eliminating large numbers of bugs. I also unicycle. And play (ice) hockey. And juggle.
This entry was posted in Code analysis, Code Reliability, Programming, Visual Studio. Bookmark the permalink.

7 Responses to /analyze–Command Line Options

  1. I just noticed the “max_paths” option for /analyze, which looks important, but I haven’t been able to find any differences by cranking up the number. The largest number that I tried was 4,294,967,295 ((2^32) -1), which is ~16 million times larger than the default, but didn’t even have a noticeable effect on compilation times.

    The documentation: https://msdn.microsoft.com/en-us/library/ms173498.aspx

    • brucedawson says:

      If it made no difference to the results or to compilation time then they are probably ignoring the option. You could try on Chromium to see if it makes any changes to the warnings or build times – if it doesn’t affect that huge code base then it is irrelevant. Invoke /analyze on Chromium by doing this before running “python build\gyp_chromium:”
      set GYP_DEFINES=component=shared_library fastbuild=2 win_analyze=1

  2. brucedawson says:

    File a bug on the Python version.
    To count warnings you can use find and wc -l or use the summarizing scripts documented at https://code.google.com/p/chromium/wiki/RetrievingCodeAnalysisWarnings to group them by type and sort by frequency.

  3. brucedawson says:

    Try this (completely untested) CL:

    https://codereview.chromium.org/1175393003/

    You can create a branch and patch this change in to your local repo with this command:

    git cl patch -b analyze_max_paths 1175393003

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s