On 11/25/14 18:39, David Malcolm wrote:
I suspect this is papering over a real problem, but I've been
applying this workaround locally to keep my valgrind output clean.
gcc/ChangeLog:
PR/64003
* final.c (shorten_branches): Allocate insn_lengths with
XCNEWVEC rather than XNEWVEC; remove subsequent per-element
initialization.
I'd like more information on this one.
My first thought is that something must be creating a new insn after
shorten_branches is complete or an existing insn that was not on the
chain when we called shorten-branches, but got threaded onto the chain
later. Either would be considered bad in various ways, so we'd like to
fix it.
Presumably you're not doing an out-of-range access into insn_lengths?
Right?
Do you have a reasonable testcase for this?
jeff