This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]