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 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.
I thought we had code somewhere that made worst case assumptions about
the lengths, to get those arrays initialized with reasonable value
without looking forward. But that may have also been in place prior to
the addition of align_fuzz.
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.
align_fuzz is meant to estimate padding due to alignments. Joern and I
went round and round on that code and I never managed to wrap my head
around it or its correctness. Jim W. might have stepped in at some
point to arbitrate. I may have to pull out my archives and review that
history (IIRC is predates egcs).
Interestingly there was a great discussion around the code in 2009 which
mirrored some of my initial concerns with this code. Ultimately Bernd
recommended removing it, but nobody reviewed/approved the patch.
I think you should ping Joern to chime in here about the proper course
of action to take if we're going to keep this code in GCC. You could
just assign in the BZ to him. FWIW, I can't convince myself
initializing the value to zero is actually safe or not.
jeff
