On May 31, 2011, Alexandre Oliva <aol...@redhat.com> wrote: > On May 30, 2011, Bernd Schmidt <ber...@codesourcery.com> 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. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
