http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #11 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-06 15:40:43 UTC --- (In reply to comment #10) > The insn is actually a millicode call (branch) which needs to be able > to reach stub table. Different variants are generated depending on > pc. I modified the opaque clause a bit as I decided I didn't want to it > to depend on operand 0. Don't see how a negative length can arise. I was actually astonished that these patterns work at all to some extent; the way I recalled it, you have to test for every possible value of your c-function in a cond clause, and then provide that value as a constant, for the length calculation to work. I see now that you get INT_MAX substituted as the maximum length if the value is unknown. If you add anything to that, the value becomes negative. I suppose your only get-out-of-jail card with the current interface, if you can't/won't provide a full cond with constant values, is to let ADJUST_INSN_LENGTH obliterate the MAX_INT, and replace it with something sensible.
