On Wed, 2014-11-26 at 10:41 -0700, Jeff Law wrote:
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):
On 12/02/14 09:20, David Malcolm wrote:
In short, I believe the problem occurs with a *jcc_1 insn that jumps
forwards, but the full details are in the bug.
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
On 12/02/14 09:20, David Malcolm wrote:
I've spent some time trying to track this down, and I've added detailed
notes to the bug.
In short, I believe the problem occurs with a *jcc_1 insn that jumps
forwards, but the full details are in the bug.
My first thought is that something must be
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
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
