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


Reply via email to