Adjust Variable Tracking Assignment Length

Question

In a release build I'm getting the following informational warning from GCC 4.4.7.

note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without

Have I exceeded the variable name length supported by variable tracking assignment?
If so, is there a way to adjust the supported size?

Filing

This appears to happen with Clang; but Clang does not produce the helpful message. And it seems to happen more often under GCC and Clang when using the Undefined Behavior Sanitizer. – Yelp

Answer 1

This is just a note from the compiler that the debug info for the particular function will have lower quality, because your code of function is too large/complex so variable tracking reached limit of hash table slots.

The max is large and it can be raised with options (like --param=max-vartrack-size=600000) but you could end up with very slow compilation or the compiler could take very lot of memory to compute the debug info location lists.

So unless you have trouble debugging the code just ignore that warning.

Null

Yeah, the only downside is the file gets compiled twice. FYI, getting this error on a large unit test .cpp. – Filing

"So unless you have trouble debugging the code just ignore that warning..." - How about CI timeouts which cause the build to fail? Since I know one file is a problem, should I just use -fno-var-tracking-assignments? – Yelp

@Yelp CI timeouts guard if something that CI service runs did hang. When build just takes long time then we can adjust the timeout. – Purchasable

The actual default for max-vartrack-size is 10000. So maybe bump it up incrementally from there, --param=max-vartrack-size=200000 might be a good place to start. – Gunar

Answer 2

My warning reads: with -fvar-tracking-assignments, retrying without

if you care about it linking twice, you could set -fno-var-tracking-assignments in the makefile instructions to avoid that retry.

Incursive

Answer 3

[edit:] After experimenting, I recommend the following:

   -param=max-vartrack-size=1500000

Which seems to be surprisingly problem-free, and actually seems to improve my build times. [...end of edit]

The Variable Tracking Assignments feature is used to track use of variables in inlined code. The information is used by debuggers and tools (notably, gdb and Visual Studio Code). If you exceed the cache size, your debugger and tools may not be able to display variable values in inlined code.

[edit: optimizers also use it]

You can increase the size of the variable tracking cache using the following GCC option:

--param=max-vartrack-size=n

The default is 10000, so the following might be a good starting point:

--param=max-vartrack-size=200000

[edit:] Variable Tracking Assignments are also used by optimizers. So maybe better to bump the limit than to indiscriminately disable Variable Tracking.

For some reason, the project I'm currently working on uses a coding style that aggravates this problem. I only get the warnings with RelWithDebInfo builds. Initially, I had a bout a dozen files that had the problem. Debug and release builds are both fine.

-param=max-vartrack-size=400000 has been part of my standard build scripts for some time; but it wasn't enough for this project. In the end I settled on

  -param=max-vartrack-size=1500000

which not only cured the problem, but also improved my build time by ~33%. As far as I can see, there are no problems at all with memory usage. Total memory usage for the build (76 files, 4 concurrent ninja build threads) isn't much more the 1- or 200 megabytes. There's only a modest bump in memory usage during the build. Whatever problem this feature is trying to solve, doesn't actually seem to be a problem, or perhaps it is a problem that's dwarfed by modern IDEs that use 4GB of memory at any given time. (Or modern browsers that use 6GB of memory to read online Linux man pages).

In previous projects I've run into the problem in code that was initialising medium-sized static tables (hundreds-ish entries). In this project, I'm pretty sure the following coding style has something to do with GCC blowing up:

    auto main = CairoFlexGridElement::Create();
    main->Style()
        .FlexAlignItems(CairoAlignment::Start)
        .FlexDirection(CairoFlexDirection::Row)
        .FlexWrap(CairoFlexWrap::Wrap)
        .FlexColumnGap(16)
        .Background(theme->paper)
        .Padding({24, 16, 24, 16}) //<-- maybe this?!
        .VerticalAlignment(CairoAlignment::Stretch)
        .HorizontalAlignment(CairoAlignment::Stretch);

There's something about that coding style that cause problems with variable tracking, even though there's hardly a variable in sight. All the methods are non-template, and not inlined. Could be brace initializers. Or maybe it's GCC 10.4. Hard to say.

But in the end it's nothing that meeelions of cache entries and a couple of hundred megabytes or RAM can't take care of.

Gunar