On Jan 4, 2012, Jakub Jelinek <ja...@redhat.com> wrote: > Unfortunately from time to time we do generate them, I hope Alex will > look at how to prevent that from happening at var-tracking time, but > still this isn't something we should assert on.
I've spent some time looking into this. I could avoid the huge expression by reducing the default max-vartrack-expr-depth from 12 to 8, and AFAICT this didn't change at all the debug info generated for any of the host parts of GCC, so we could do that. I haven't regtested that, though, for I'm not convinced that's the way to go. FWIW, that wouldn't solve the underlying problem, which is that expressions may get arbitrarily large, and debug info formats may not be able to deal with that. I think cutting them off within the debug info format logic is the best we can do for now. Using dwarf procedures is a longer-term project that, if done in var-tracking where IMHO it belogs, will require some additional interfaces between var-tracking and debug info formats (are procedures supported, what's the expr size limit, what's the size of a certain expr, etc). One shorter-term way to avoid too-big expressions is to change the expr depth computation logic. Currently, if we find something like (op (value) (const_int)) we don't regard it as any deeper than value by itself. Only operations with two or more value operands increase the depth. E.g., in the testcase for this bug, we only increase the depth of the expression for the already-dead variable o at the if_then_else expressions, for everything else (ands, xors, etc) involve constants. I don't think that'd be a positive change overall, though. -- 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