[PATCH 08/08] PR/64003 workaround (uninit memory in i386.md)

[David Malcolm]

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): Allocate insn_lengths with
> > 	XCNEWVEC rather than XNEWVEC; remove subsequent per-element
> > 	initialization.
> I'd like more information on this one.

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 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.

I don't think either of these are the case.  I believe it's due to the
size of the jcc_1 insn being affected by the distance to the jump
target, which for a forward jump is a bit of a chicken-and-egg issue,
since that distance is affected by the size of the jcc_1 insn itself.  

It looks like align_fuzz exists in order to cope with this kind of
circular definition, but the issue seems to occur inside align_fuzz
itself.

> Presumably you're not doing an out-of-range access into insn_lengths? 
> Right?
> 
> Do you have a reasonable testcase for this?

I've added a more minimal reproducer to the bug (8 lines); see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003#c7

I see it with latest trunk (r218254) on x86_64.

See my notes in the bug.

Dave