[Bug target/64003] valgrind complains about get_attr_length_nobnd in insn-attrtab.c from i386.md

["amylaar at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003

--- Comment #13 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #6)
> If I'm reading things right, this loop in shorten_branches populates
> insn_lengths[uid] in order of the NEXT_INSN () iteration:
> 
>   int (*length_fun) (rtx_insn *) = increasing ? insn_min_length :
> insn_default_length;
> 
>   for (insn_current_address = 0, insn = first;
>        insn != 0;
>        insn_current_address += insn_lengths[uid], insn = NEXT_INSN (insn))
>     {
>       uid = INSN_UID (insn);
> 
>       insn_lengths[uid] = 0;
> 
>       /* lots of logic, which can call length_fun, and hence
> insn_min_length.  */
>     }
> 
> and "length_fun" can call into insn_min_length, and hence this calls into
> the get_attr_length_nobnd, which AIUI for this case is accessing lengths of
> other insns before they've been populated: presumably for a jump forwards?

insn_min_length is not supposed to use current insn lengths.
genattrtab does not follow attributes for the purposes of determining
insn current length dependence.
So far we consider it the job of the port to provide
a length attribute that allows the calculation of minimum/maximum instruction
lengths with this limitation in mind.
That means the length attribute in i386.md is broken.
The get_attr_length_nobnd attribute need to be either inlined, or its use
guarded in a clause that appears to be length depepdent and supplies minimum
and maximum values.

AFAICS, the length attribute was broken in r217125
https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00133.html