[Bug target/56441] New: [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441 Bug #: 56441 Summary: [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3 Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: gnu...@emblocks.org Already applied patch 43961. Only with -O1 (other optimizations levels are going well). The .LVL137 (cbnz) is giving the error. snippet: strbr4, [r0, #30] .LVL136: .loc 1 2362 0 ldrbr1, [r1, #15]@ zero_extendqisi2 .LVL137: cbnzr1, .L35 .LVL138: .loc 1 2366 0 movr1, #30 b.L6 .LVL139:
[Bug target/56441] [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441
--- Comment #1 from gnugcc at emblocks dot org 2013-02-25 08:31:31 UTC ---
@ ..\..\src\samba\smblib.c:2362
.loc 1 2362 0
@(insn 688 1291 1292 45 (set (reg:SI 1 r1 [orig:698 MEM[(const unsigned char
*)name_10(D) + 15B] ] [698])
@(zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 1 r1 [orig:454 name ]
[454])
@(const_int 15 [0xf])) [0 MEM[(const unsigned char
*)name_10(D) + 15B]+0 S1 A8]))) ..\..\src\samba\smblib.c:2362 735
{thumb2_zero_extendqisi2_v6}
@ (nil))
ldrbr1, [r1, #15]@ zero_extendqisi2@ 688
thumb2_zero_extendqisi2_v6/2[length = 4]
.LVL137:
@ SUCC: 66 [95.5%] 48 [4.5%] (fallthru)
@(jump_insn 690 689 1296 45 (parallel [
@(set (pc)
@(if_then_else (ne (reg:SI 1 r1 [orig:698 MEM[(const unsigned
char *)name_10(D) + 15B] ] [698])
@(const_int 0 [0]))
@(label_ref 721)
@(pc)))
@(clobber (reg:CC 24 cc))
@]) ..\..\src\samba\smblib.c:2362 753 {*thumb2_cbnz}
@ (expr_list:REG_DEAD (reg:SI 1 r1 [orig:698 MEM[(const unsigned char
*)name_10(D) + 15B] ] [698])
@(expr_list:REG_UNUSED (reg:CC 24 cc)
@(expr_list:REG_BR_PROB (const_int 9550 [0x254e])
@(nil
@ -> 721)
cbnzr1, .L35@ 690*thumb2_cbnz/1[length = 2]
.LVL138:
@ BLOCK 48 freq:6 seq:16
@ PRED: 45 [4.5%] (fallthru)
@ ..\..\src\samba\smblib.c:2366
.loc 1 2366 0
@(insn 38 851 1049 48 (set (reg/v:SI 1 r1 [orig:212 j ] [212])
@(const_int 30 [0x1e])) ..\..\src\samba\smblib.c:2366 714
{*thumb2_movsi_insn}
@ (expr_list:REG_EQUAL (const_int 30 [0x1e])
@(nil)))
movr1, #30@ 38*thumb2_movsi_insn/2[length = 4]
@ SUCC: 63 [100.0%]
@(jump_insn 1049 38 1050 48 (set (pc)
@(label_ref 691)) 236 {*arm_jump}
@ (nil)
@ -> 691)
b.L6@ 1049*arm_jump[length = 2]
[Bug target/56441] [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441 --- Comment #3 from gnugcc at emblocks dot org 2013-02-25 11:35:53 UTC --- The "Reporting Bugs" manual isn't taht clear. It says "What we need: the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below)." And below: "What we do not want: Assembly files (*.s) produced by the compiler, or any binary files, such as object files, executables, core files, or precompiled header files" But the issue is according my first quick looks: The computed length (all the lengths from cbnz to label) = 124 and should fit. However b.L6@ 1049*arm_jump[length = 2] This is set at a length of 2 but it assembles always as a b.w (at least in thumb mode) which has a length of 4. If I need to provide other stuff, please let me know. Regards
[Bug target/56441] [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441 --- Comment #4 from gnugcc at emblocks dot org 2013-02-25 11:40:45 UTC --- Created attachment 29534 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29534 This file shows/reproduce the error
[Bug target/56441] [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441
--- Comment #5 from gnugcc at emblocks dot org 2013-02-25 13:14:46 UTC ---
Could it be that in the file arm.md concerning the following snippet:
(define_insn "*arm_jump"
[(set (pc)
(label_ref (match_operand 0 "" "")))]
"TARGET_32BIT"
"*
{
if (arm_ccfsm_state == 1 || arm_ccfsm_state == 2)
{
arm_ccfsm_state += 2;
return \"\";
}
return \"b%?\\t%l0\";
}
"
[(set_attr "predicable" "yes")
(set (attr "length")
(if_then_else
(and (match_test "TARGET_THUMB2")
(and (ge (minus (match_dup 0) (pc)) (const_int -2044))
(le (minus (match_dup 0) (pc)) (const_int 2048
(const_int 2)
(const_int 4)))]
)
the (match_test "TARGET_THUMB2") must be replaced by
(and (not(match_test "TARGET_THUMB2"))
same for
- "*arm_cond_branch"
- "*arm_cond_branch_reversed"
the assembler always uses b.w even if the branch is only 10 bytes away.
Regards
[Bug target/56441] [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441 --- Comment #6 from gnugcc at emblocks dot org 2013-02-25 16:47:51 UTC --- The work-around is working but it is not the correct way. I'm cheating that a branch is always 4 bytes in Thumb2 (which is actually the case with the broken assembler). I can't assemble " b " without getting " b.w " in Thumb 2. So a 2bytes branch isn't possible right now. Binutils version 2.22.0 and 2.23.1.
[Bug target/56441] [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441 --- Comment #7 from gnugcc at emblocks dot org 2013-02-26 09:05:36 UTC --- I was looking completely wrong, the arm_addsi3 is acting wrong. The "add%?\\t%0, %1, %2" for "=l,%0,Py" is set at a length of 2. (first entry in the list) However the "ADD r6,r6, #65" is a thumb2 instruction which is 4 bytes and not 2. An "ADDS r6,r6,#65" will go right because this is a thumb instruction of 2 bytes. Same for the first "SUB" in the same list. So I end up with a miscalculation of 2bytes. Perhaps it's better to make it conservative and always use length of 4. I guess that this isn't the right way but I have put un-predicables in front of the predicable counter parts with the right length of 4.
[Bug target/56441] [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441 --- Comment #10 from gnugcc at emblocks dot org 2013-02-26 17:24:52 UTC --- The ARM branch, sorry I see now that the trunk is different. Arm branch: ;; The r/r/k alternative is required when reloading the address ;; (plus (reg rN) (reg sp)) into (reg rN). In this case reload will ;; put the duplicated register first, and not try the commutative version. (define_insn_and_split "*arm_addsi3" [(set (match_operand:SI 0 "s_register_operand" "=l, r, k,r,r, k, l, r, k,r, k, r") (plus:SI (match_operand:SI 1 "s_register_operand" "%0, rk,k,r,rk,k, 0, rk,k,rk,k, rk") (match_operand:SI 2 "reg_or_int_operand" "Py,rI,rI,k,Pj,Pj,Pv,L, L,PJ,PJ,?n")))] "TARGET_32BIT" "@ add%?\\t%0, %1, %2 add%?\\t%0, %1, %2 add%?\\t%0, %1, %2 add%?\\t%0, %2, %1 addw%?\\t%0, %1, %2 addw%?\\t%0, %1, %2 sub%?\\t%0, %1, #%n2 sub%?\\t%0, %1, #%n2 sub%?\\t%0, %1, #%n2 subw%?\\t%0, %1, #%n2 subw%?\\t%0, %1, #%n2 #" "TARGET_32BIT && GET_CODE (operands[2]) == CONST_INT && !const_ok_for_op (INTVAL (operands[2]), PLUS) && (reload_completed || !arm_eliminable_register (operands[1]))" [(clobber (const_int 0))] " arm_split_constant (PLUS, SImode, curr_insn, INTVAL (operands[2]), operands[0], operands[1], 0); DONE; " [(set_attr "length" "2,4,4,4,4,4,2,4,4,4,4,16") (set_attr "predicable" "yes") (set_attr "arch" "t2,*,*,*,t2,t2,t2,*,*,t2,t2,*")] ) I saw that all the short's are handled in the thumb2.md (thumb2_addsi_short) and the trunk has also one 2 byte length entry in the arm_addsi3. I will check that one. Sorry again!
[Bug target/56441] [ARM Thumb] generated asm code produces "branch out of range" error in gas with -O1 -mcpu=cortex-m3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56441 --- Comment #11 from gnugcc at emblocks dot org 2013-02-26 17:51:16 UTC --- Richard, you can close this one. I'm leaving the ARM-branch and are moving to the head of branch 4.7. Sorry for the inconveniences, I thought that the ARM branch would be the most suitable for ARM but I discovered that that relationship isn't that obvious. At least I learned today a little of the GCC internals. Sorry again. Gerard
