This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Assembler Error: orerand out of rage (145 not between -128 and 127) for m32r target
- From: Kazuhiro Inaoka <inaoka dot kazuhiro at renesas dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 25 Jul 2006 12:59:36 +0900
- Subject: Assembler Error: orerand out of rage (145 not between -128 and 127) for m32r target
Hi Nick
We have often gotten the following assembler error with -g option
since m32r-linux-gnu-gcc-4.0 released.
/tmp/cch1oLgA.s: Assembler messages:
/tmp/cch1oLgA.s:2591: Error: operand out of range (145 not between -128 and
127)/tmp/cch1oLgA.s:3358: Error: operand out of range (145 not between -128 and
127)/tmp/cch1oLgA.s:5195: Error: operand out of range (-130 not between -128 and
127)
We have been using DWARF2 since gcc-4.0.
It creates many local label symbols and makes pnop codes for code aligments.
We have no idia to avoid this error on compiling.
So we propose to change the range for using short bransh format code.
Regards,
Kazuhiro Inaoka
EC No. H05-0044
--- m32r.md.org 2006-07-25 11:56:34.430876893 +0900
+++ m32r.md 2006-07-25 11:59:57.270053850 +0900
@@ -1390,15 +1390,15 @@
return instruction;
}"
[(set_attr "type" "branch")
- ; We use 400/800 instead of 512,1024 to account for inaccurate insn
+ ; We use 300/600 instead of 512,1024 to account for inaccurate insn
; lengths and insn alignments that are complex to track.
; It's not important that we be hyper-precise here. It may be more
; important blah blah blah when the chip supports parallel execution
; blah blah blah but until then blah blah blah this is simple and
; suffices.
(set (attr "length") (if_then_else (ltu (plus (minus (match_dup 0) (pc))
- (const_int 400))
- (const_int 800))
+ (const_int 300))
+ (const_int 600))
(const_int 2)
(const_int 4)))])
@@ -1419,15 +1419,15 @@
return instruction;
}"
[(set_attr "type" "branch")
- ; We use 400/800 instead of 512,1024 to account for inaccurate insn
+ ; We use 300/600 instead of 512,1024 to account for inaccurate insn
; lengths and insn alignments that are complex to track.
; It's not important that we be hyper-precise here. It may be more
; important blah blah blah when the chip supports parallel execution
; blah blah blah but until then blah blah blah this is simple and
; suffices.
(set (attr "length") (if_then_else (ltu (plus (minus (match_dup 0) (pc))
- (const_int 400))
- (const_int 800))
+ (const_int 300))
+ (const_int 600))
(const_int 2)
(const_int 4)))])