This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
- From: "amylaar at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 06 Nov 2012 15:40:43 +0000
- Subject: [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
- Auto-submitted: auto-generated
- References: <bug-55195-4@http.gcc.gnu.org/bugzilla/>
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.