* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
@ 2012-11-03 20:45 ` amylaar at gcc dot gnu.org
2012-11-04 2:52 ` dave.anglin at bell dot net
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-03 20:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #1 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-03 20:45:10 UTC ---
Could you attach preprocessed source and the exact options passsed to cc1
(from -v --save-temos compilation) so that I can look at this in a cross
environment?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
2012-11-03 20:45 ` [Bug middle-end/55195] " amylaar at gcc dot gnu.org
@ 2012-11-04 2:52 ` dave.anglin at bell dot net
2012-11-04 16:59 ` amylaar at gcc dot gnu.org
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dave.anglin at bell dot net @ 2012-11-04 2:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #2 from dave.anglin at bell dot net 2012-11-04 02:52:31 UTC ---
On 3-Nov-12, at 4:45 PM, amylaar at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
>
> --- Comment #1 from Jorn Wolfgang Rennecke <amylaar at gcc dot
> gnu.org> 2012-11-03 20:45:10 UTC ---
> Could you attach preprocessed source and the exact options passsed
> to cc1
> (from -v --save-temos compilation) so that I can look at this in a
> cross
> environment?
Unfortunately, -v -save-temps doesn't save the java source from a list
input. So far, I've only seen this
with jc1. I imagine this is because the input is huge.
This is compilation command:
/home/dave/gnu/gcc/objdir/./gcc/jc1 ../../../gcc/libjava/classpath/lib/
gnu/javax/swing/text/html/parser/HTML_401F.class -fuse-divide-
subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-
functions -quiet -dumpbase HTML_401F.class -auxbase-strip gnu/javax/
swing/text/html/parser/.libs/HTML_401F.o -g -O2 -Wno-deprecated -
version -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/home/
dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/classpath/lib/classes -fPIC
-fbootclasspath=./:../../../gcc/libjava/classpath/lib/ -faux-classpath
HTML_401F.zip -MD_ -MT gnu/javax/swing/text/html/parser/HTML_401F.lo -
MF gnu/javax/swing/text/html/p
arser/HTML_401F.deps -o HTML_401F.s
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
2012-11-03 20:45 ` [Bug middle-end/55195] " amylaar at gcc dot gnu.org
2012-11-04 2:52 ` dave.anglin at bell dot net
@ 2012-11-04 16:59 ` amylaar at gcc dot gnu.org
2012-11-04 17:32 ` [Bug target/55195] " amylaar at gcc dot gnu.org
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-04 16:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #3 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-04 16:59:07 UTC ---
I have done a -j2 bootstrap on gcc61, and in fails somewhere else in a similar
fashion. I then transplanted some files to my local (faster) cross
environment.
I've hacked final.c to provide the equivalent of the sh/arc -misize option, and
I see some sizeable chunks of code being estimated with a small size:
.L19464:
; at 11cc
addil LT'.L19517,%r19
ldw RT'.L19517(%r1),%r1
ldw 0(%r1),%r1
bb,>=,n %r1,30,.+16
depi 0,31,2,%r1
ldw 4(%sr0,%r1),%r19
ldw 0(%sr0,%r1),%r1
bl .+8,%r2
addi 8,%r2,%r2
ble 0(%sr4,%r1)
stw %r31,-24(%sp)
.LVL19507:
.L19463:
; at 11d4
addil LT'.L19517,%r19
ldw RT'.L19517(%r1),%r1
ldw 0(%r1),%r1
bb,>=,n %r1,30,.+16
depi 0,31,2,%r1
ldw 4(%sr0,%r1),%r19
ldw 0(%sr0,%r1),%r1
bl .+8,%r2
addi 8,%r2,%r2
ble 0(%sr4,%r1)
stw %r31,-24(%sp)
.LVL19508:
.L19462:
; at 11dc
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (2 preceding siblings ...)
2012-11-04 16:59 ` amylaar at gcc dot gnu.org
@ 2012-11-04 17:32 ` amylaar at gcc dot gnu.org
2012-11-04 17:35 ` amylaar at gcc dot gnu.org
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-04 17:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
Component|middle-end |target
--- Comment #4 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-04 17:31:52 UTC ---
(In reply to comment #3)
In the ccA1Vjgkjx.234r.shorten dump file,
between L19464 and L19463, there is but one call instruction, a basic block
start, a barrier, and some 600 NOTE_INSN_VAR_LOCATION:
(code_label 4141 28778 2472 19464 "" [1 uses])
(note 2472 4141 3318 [bb 311] NOTE_INSN_BASIC_BLOCK)
(call_insn:TI 3318 2472 3319 (parallel [
(call (mem:SI (symbol_ref/v:SI ("@_Jv_ThrowBadArrayIndex") [flags
0x241] <function_decl 0xb73b8700 _Jv_ThrowBadArrayIndex>) [0 S4 A32])
(const_int 16 [0x10]))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (reg:SI 19 %r19))
(use (const_int 0 [0]))
])
/ssd/synopsys/arc_gnu_4.8-r192641/gcc-4.8/libjava/classpath/gnu/java/nio/charset/MacSymbol.java:73
198 {*call_symref_pic_post_reload}
(expr_list:REG_DEAD (reg:SI 26 %r26)
(expr_list:REG_DEAD (reg:SI 19 %r19)
(expr_list:REG_NORETURN (const_int 0 [0])
(nil))))
(expr_list:REG_CC_SETTER (use (reg:SI 26 %r26))
(nil)))
(barrier 3319 3318 28981)
(note 28981 3319 28980 (nil) NOTE_INSN_CALL_ARG_LOCATION)
...
(note 29183 29182 4140 (var_location D.16611 (nil)) NOTE_INSN_VAR_LOCATION)
(code_label 4140 29183 2459 19463 "" [1 uses])
The instruction call_symref_pic_post_reload has the following length
attribute setting:
(set (attr "length") (symbol_ref "pa_attr_length_call (insn, 0)"))
Such a length attribute is not considered variable by shorten_branches.
You need to include a clause that is directly in the attribute, e.g.
(and (match_test "0") (eq (match_dup 0) (pc)))
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (3 preceding siblings ...)
2012-11-04 17:32 ` [Bug target/55195] " amylaar at gcc dot gnu.org
@ 2012-11-04 17:35 ` amylaar at gcc dot gnu.org
2012-11-04 22:23 ` dave.anglin at bell dot net
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-04 17:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #5 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-04 17:34:47 UTC ---
Created attachment 28613
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28613
here is a proof-of-concept patch that allows the offending file to assemble
successfully.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (4 preceding siblings ...)
2012-11-04 17:35 ` amylaar at gcc dot gnu.org
@ 2012-11-04 22:23 ` dave.anglin at bell dot net
2012-11-04 23:50 ` dave.anglin at bell dot net
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dave.anglin at bell dot net @ 2012-11-04 22:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #6 from dave.anglin at bell dot net 2012-11-04 22:23:04 UTC ---
On 4-Nov-12, at 12:31 PM, amylaar at gcc dot gnu.org wrote:
> The instruction call_symref_pic_post_reload has the following length
> attribute setting:
>
> (set (attr "length") (symbol_ref "pa_attr_length_call (insn, 0)"))
>
> Such a length attribute is not considered variable by
> shorten_branches.
>
> You need to include a clause that is directly in the attribute, e.g.
> (and (match_test "0") (eq (match_dup 0) (pc)))
Thanks Jorn for debugging this.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (5 preceding siblings ...)
2012-11-04 22:23 ` dave.anglin at bell dot net
@ 2012-11-04 23:50 ` dave.anglin at bell dot net
2012-11-05 2:32 ` amylaar at gcc dot gnu.org
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dave.anglin at bell dot net @ 2012-11-04 23:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #7 from dave.anglin at bell dot net 2012-11-04 23:50:44 UTC ---
On 4-Nov-12, at 12:31 PM, amylaar at gcc dot gnu.org wrote:
> Such a length attribute is not considered variable by
> shorten_branches.
>
> You need to include a clause that is directly in the attribute, e.g.
> (and (match_test "0") (eq (match_dup 0) (pc)))
In some sense, this seems like a hack which might be optimized by an
attribute processor. What about a way to mark length attributes as
variable?
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (6 preceding siblings ...)
2012-11-04 23:50 ` dave.anglin at bell dot net
@ 2012-11-05 2:32 ` amylaar at gcc dot gnu.org
2012-11-05 16:21 ` [Bug middle-end/55195] " amylaar at gcc dot gnu.org
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-05 2:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #8 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-05 02:32:35 UTC ---
(In reply to comment #7)
> In some sense, this seems like a hack which might be optimized by an
> attribute processor. What about a way to mark length attributes as
> variable?
That would be nice, and pretty straightforward to code, but we seem short of
generator program patches reviewers now.
Note, I don't think there is any valid reason for the attribute processor
to look inside a match_test; if it was something that the generators were
supposed to understand, we should have rtl syntax for it.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (7 preceding siblings ...)
2012-11-05 2:32 ` amylaar at gcc dot gnu.org
@ 2012-11-05 16:21 ` amylaar at gcc dot gnu.org
2012-11-06 12:26 ` dave.anglin at bell dot net
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-05 16:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |middle-end
--- Comment #9 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-05 16:20:44 UTC ---
(In reply to comment #8)
> That would be nice, and pretty straightforward to code, but we seem short of
> generator program patches reviewers now.
I take back that statement about this being straightforward. We need valid
minimum and maximum instruction lengths. The opaque dummy clause automatically
provides a value to be included in these calculations.
If we had a varying_length attribute, I suppose we could make its value the
maximum length, and 0 the minimum length. Maybe we should call the attribute
max_length then. But something would need to be done to weave these values
into the generated insn_ min / default _length functions.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (8 preceding siblings ...)
2012-11-05 16:21 ` [Bug middle-end/55195] " amylaar at gcc dot gnu.org
@ 2012-11-06 12:26 ` dave.anglin at bell dot net
2012-11-06 15:41 ` amylaar at gcc dot gnu.org
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dave.anglin at bell dot net @ 2012-11-06 12:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #10 from dave.anglin at bell dot net 2012-11-06 12:26:06 UTC ---
On 5-Nov-12, at 11:20 AM, amylaar at gcc dot gnu.org wrote:
> I take back that statement about this being straightforward. We
> need valid
> minimum and maximum instruction lengths. The opaque dummy clause
> automatically
> provides a value to be included in these calculations.
This is failing at -O0:
(define_insn ""
[(set (reg:SI 29)
(div:SI (reg:SI 26) (match_operand:SI 0 "div_operand" "")))
(clobber (match_operand:SI 1 "register_operand" "=a"))
(clobber (match_operand:SI 2 "register_operand" "=&r"))
(clobber (reg:SI 26))
(clobber (reg:SI 25))
(clobber (reg:SI 31))]
"!TARGET_64BIT"
"*
return pa_output_div_insn (operands, 0, insn);"
[(set_attr "type" "milli")
(set (attr "length")
(cond [(and (match_test "0") (eq (const_int 0) (pc)))
(const_int 24)]
(symbol_ref "pa_attr_length_millicode_call (insn)")))])
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.
spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/
gcc/ -fno-d
iagnostics-show-caret -O0 -w -c -o 20000427-1.o /home/dave/gnu/gcc/gcc/
gcc/tests
uite/gcc.c-torture/compile/20000427-1.c/home/dave/gnu/gcc/gcc/gcc/
testsuite/gcc.c-torture/compile/20000427-1.c: In func
tion 'ConvertFor3dDriver':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
20000427-1.c:9:1: err
or: negative insn length
(insn 47 46 48 (parallel [
(set (reg:SI 29 %r29)
(div:SI (reg:SI 26 %r26)
(reg:SI 25 %r25)))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 19 %r19 [125]))
(clobber (reg:SI 26 %r26)) (clobber (reg:SI 25
%r25))
(clobber (reg:SI 31 %r31))
]) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
20000427-1.c:8 122 {*pa.md:5433}
(nil))
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/
20000427-1.c:9:1: int
ernal compiler error: in shorten_branches, at final.c:1162
0x537f7b _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
../../gcc/gcc/rtl-error.c:110
0x308df7 shorten_branches(rtx_def*)
../../gcc/gcc/final.c:1162
0x3094e3 rest_of_handle_shorten_branches
../../gcc/gcc/final.c:4368
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (9 preceding siblings ...)
2012-11-06 12:26 ` dave.anglin at bell dot net
@ 2012-11-06 15:41 ` amylaar at gcc dot gnu.org
2012-11-06 17:25 ` amylaar at gcc dot gnu.org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-06 15:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (10 preceding siblings ...)
2012-11-06 15:41 ` amylaar at gcc dot gnu.org
@ 2012-11-06 17:25 ` amylaar at gcc dot gnu.org
2012-11-07 0:39 ` dave.anglin at bell dot net
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-06 17:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #12 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-06 17:25:30 UTC ---
One way to get the maximum right would be to change genattrtab:max_attr_value
too process umax and/or smax, and use that to encapsulate the symbol_ref.
longer term, i think it would be nice if we had rtx codes that not so
much min/max, but assert that a value is in a given range; with gcc_assert
in the generaed function. We could use one to assert a range that is invaiant
during branch shortening, and another one that is variant.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (11 preceding siblings ...)
2012-11-06 17:25 ` amylaar at gcc dot gnu.org
@ 2012-11-07 0:39 ` dave.anglin at bell dot net
2012-11-07 0:54 ` amylaar at gcc dot gnu.org
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: dave.anglin at bell dot net @ 2012-11-07 0:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #13 from dave.anglin at bell dot net 2012-11-07 00:39:01 UTC ---
On 6-Nov-12, at 10:40 AM, amylaar at gcc dot gnu.org wrote:
> 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.
It appears that I need to provide the min length instead of the max
length
in the opaque condition.
Maybe if I just avoid incrementing the length in ADJUST_INSN_LENGTH when
it is MAX_INT, then the error won't occur.
For the call patterns, the number of permutations got out of hand and
impossible
to maintain.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (12 preceding siblings ...)
2012-11-07 0:39 ` dave.anglin at bell dot net
@ 2012-11-07 0:54 ` amylaar at gcc dot gnu.org
2012-11-11 18:09 ` danglin at gcc dot gnu.org
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: amylaar at gcc dot gnu.org @ 2012-11-07 0:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #14 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-07 00:53:48 UTC ---
(In reply to comment #13)
> It appears that I need to provide the min length instead of the max
> length
> in the opaque condition.
It's more like, this is the only thing you can do effectively as long
as you have an unbounded value in the attribute.
And the way the max_attr_length calculation works now, the only bounded
values are selections of constants via if-then-else / cond.
> Maybe if I just avoid incrementing the length in ADJUST_INSN_LENGTH when
> it is MAX_INT, then the error won't occur.
I suppose so, but you'd still have a ridiculous size estimate. And
having one INT_MAX length instruction plus a delay slot insn can still
push you over the INT_MAX edge.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (13 preceding siblings ...)
2012-11-07 0:54 ` amylaar at gcc dot gnu.org
@ 2012-11-11 18:09 ` danglin at gcc dot gnu.org
2012-11-13 0:37 ` [Bug target/55195] " danglin at gcc dot gnu.org
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: danglin at gcc dot gnu.org @ 2012-11-11 18:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
John David Anglin <danglin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-11-11
AssignedTo|unassigned at gcc dot |danglin at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #15 from John David Anglin <danglin at gcc dot gnu.org> 2012-11-11 18:09:24 UTC ---
Created attachment 28657
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28657
Patch
Testing attached patch.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (14 preceding siblings ...)
2012-11-11 18:09 ` danglin at gcc dot gnu.org
@ 2012-11-13 0:37 ` danglin at gcc dot gnu.org
2012-11-13 1:11 ` danglin at gcc dot gnu.org
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: danglin at gcc dot gnu.org @ 2012-11-13 0:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #16 from John David Anglin <danglin at gcc dot gnu.org> 2012-11-13 00:37:01 UTC ---
Author: danglin
Date: Tue Nov 13 00:36:54 2012
New Revision: 193464
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193464
Log:
PR target/55195
* config/pa/pa.md (type): Add sibcall and sh_func_adrs insn types.
(in_branch_delay): Don't allow sibcall or sh_func_adrs insns.
(in_nullified_branch_delay): Likewise.
(in_call_delay): Likewise.
Define delay for sibcall insns. Adjust Z3 and Z4 insn reservations for
new types. Add opaque cond to mark all calls, sibcalls, dyncalls and
the $$sh_func_adrs call as variable. Update type of sibcalls and
$$sh_func_adrs call.
* config/pa/pa.c (pa_adjust_insn_length): Revise to return updated
length instead of adjustment. Handle negative and undefined call
adjustments for insn_default_length. Remove adjustment for millicode
insn with unfilled delay slot.
(pa_output_millicode_call): Update for revised millicode length.
* config/pa/pa.h (ADJUST_INSN_LENGTH): Revise to set LENGTH.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.c
trunk/gcc/config/pa/pa.h
trunk/gcc/config/pa/pa.md
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (15 preceding siblings ...)
2012-11-13 0:37 ` [Bug target/55195] " danglin at gcc dot gnu.org
@ 2012-11-13 1:11 ` danglin at gcc dot gnu.org
2012-12-01 20:36 ` danglin at gcc dot gnu.org
2012-12-06 2:20 ` danglin at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: danglin at gcc dot gnu.org @ 2012-11-13 1:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
John David Anglin <danglin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #17 from John David Anglin <danglin at gcc dot gnu.org> 2012-11-13 01:11:01 UTC ---
Fixed on trunk
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (16 preceding siblings ...)
2012-11-13 1:11 ` danglin at gcc dot gnu.org
@ 2012-12-01 20:36 ` danglin at gcc dot gnu.org
2012-12-06 2:20 ` danglin at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: danglin at gcc dot gnu.org @ 2012-12-01 20:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #18 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-01 20:36:08 UTC ---
Author: danglin
Date: Sat Dec 1 20:36:04 2012
New Revision: 194027
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194027
Log:
Backport from mainline:
2012-11-12 John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
PR target/55195
* config/pa/pa.md (type): Add sibcall and sh_func_adrs insn types.
(in_branch_delay): Don't allow sibcall or sh_func_adrs insns.
(in_nullified_branch_delay): Likewise.
(in_call_delay): Likewise.
Define delay for sibcall insns. Adjust Z3 and Z4 insn reservations for
new types. Add opaque cond to mark all calls, sibcalls, dyncalls and
the $$sh_func_adrs call as variable. Update type of sibcalls and
$$sh_func_adrs call.
* config/pa/pa.c (pa_adjust_insn_length): Revise to return updated
length instead of adjustment. Handle negative and undefined call
adjustments for insn_default_length. Remove adjustment for millicode
insn with unfilled delay slot.
(pa_output_millicode_call): Update for revised millicode length.
* config/pa/pa.h (ADJUST_INSN_LENGTH): Revise to set LENGTH.
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/pa/pa.c
branches/gcc-4_7-branch/gcc/config/pa/pa.h
branches/gcc-4_7-branch/gcc/config/pa/pa.md
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
2012-11-03 17:05 [Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances danglin at gcc dot gnu.org
` (17 preceding siblings ...)
2012-12-01 20:36 ` danglin at gcc dot gnu.org
@ 2012-12-06 2:20 ` danglin at gcc dot gnu.org
18 siblings, 0 replies; 20+ messages in thread
From: danglin at gcc dot gnu.org @ 2012-12-06 2:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
--- Comment #19 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-06 02:19:57 UTC ---
Author: danglin
Date: Thu Dec 6 02:19:48 2012
New Revision: 194238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194238
Log:
Backport for mainline:
2011-11-30 John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
PR middle-end/50283
* config/pa/pa.md (in_branch_delay): Disallow frame related insns.
(in_nullified_branch_delay): Likewise.
(in_call_delay): Likewise.
2012-11-12 John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
PR target/55195
* config/pa/pa.md (type): Add sibcall and sh_func_adrs insn types.
(in_branch_delay): Don't allow sibcall or sh_func_adrs insns.
(in_nullified_branch_delay): Likewise.
(in_call_delay): Likewise.
Define delay for sibcall insns. Adjust Z3 and Z4 insn reservations for
new types. Add opaque cond to mark all calls, sibcalls, dyncalls and
the $$sh_func_adrs call as variable. Update type of sibcalls and
$$sh_func_adrs call.
* config/pa/pa.c (pa_adjust_insn_length): Revise to return updated
length instead of adjustment. Handle negative and undefined call
adjustments for insn_default_length. Remove adjustment for millicode
insn with unfilled delay slot.
(pa_output_millicode_call): Update for revised millicode length.
* config/pa/pa.h (ADJUST_INSN_LENGTH): Revise to set LENGTH.
2012-12-05 John David Anglin <dave.anglin@nrc-cnrc.gc.ca>
* config/pa/pa.md: Use "const_int 0" instead of match_test to simplify
opaque cond in all call insns.
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/pa/pa.c
branches/gcc-4_6-branch/gcc/config/pa/pa.h
branches/gcc-4_6-branch/gcc/config/pa/pa.md
^ permalink raw reply [flat|nested] 20+ messages in thread