introduce --param max-vartrack-expr-depth

Alexandre Oliva
Wed Jun 1 22:29:00 GMT 2011

On Jun  1, 2011, Alexandre Oliva <> wrote:

> On May 31, 2011, Alexandre Oliva <> wrote:
>> On May 30, 2011, Bernd Schmidt <> wrote:
>>> On 05/30/2011 12:35 PM, Alexandre Oliva wrote:
>>>> One of my patches for PR 48866 regressed guality/asm-1.c on
>>>> x86_64-linux-gnu because what used to be a single complex debug value
>>>> expression became a chain of debug temps holding simpler expressions,
>>>> and this chain exceeded the default recursion depth in resolving
>>>> location expressions.

>>> What's the worst that can happen if you remove the limit altogether?

>> Exponential behavior comes to mind.

> It's unusual, but debug/pr41264-1.c exhibits it, given INT_MAX for the
> param, even though under such a (lack of) limit bootstrap doesn't go
> slower or faster, after restoring depth 5 for the reverse_op() use.  As
> Jakub pointed out, that one probably shouldn't be affected by the
> parameter, as depth 5 is exactly what we want for the kind of expression
> we're looking for.  With unlimited depth for that one, not even
> libiberty/md5.c compiles successfully, exhausting memory on a box with
> some 40GB of total VM (8+32).

> So I guess I'll stick with what I checked in, but keep a patch handy to
> bump the limit a little bit up and revert to 5 in reverse_op.

Such as this one...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vta-param-vartrack-expr-depth-int-max.patch
Type: text/x-diff
Size: 1086 bytes
Desc: not available
URL: <>
-------------- next part --------------

Alexandre Oliva, freedom fighter
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

More information about the Gcc-patches mailing list