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 cr
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 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_br
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 X
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