This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
New bootstrap failure on ARM
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Jan Hubicka <jh at suse dot cz>, gcc-bugs at gcc dot gnu dot org
- Cc: Richard dot Earnshaw at arm dot com
- Date: Fri, 07 Dec 2001 14:07:26 +0000
- Subject: New bootstrap failure on ARM
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
Jan,
I know this has been in a couple of weeks, but I was away throughout
November.
The patch:
Wed Nov 14 14:17:05 CET 2001 Jan Hubicka <jh@suse.cz>
* dbxout.c (dbxout_symbol_location): Update call of alter_subreg.
* final.c (walk_alter_subreg): Take pointer; update call of
alter_subreg
.
(final_scan_insn): Update call of alter_subreg.
(cleanup_subreg_operands): Likewise.
(alter_subreg): Rewrite using simplify_subreg.
(output_address, output_operand): Update call of alter_subreg.
* output.h (alter_subreg): Update prototype.
* sdbout.c (sdbout_symbol): Update call of alter_subreg.
* simplify-rtx.c (simplify_subreg): Copy ORIGINAL_REGNO.
* Makefile.in (final.o): Add dependency on expr.h
is causing a bootstrap failure on the ARM when building the Fortran
compiler.
With the RTL template
(define_insn "*arith_shiftsi"
[(set (match_operand:SI 0 "s_register_operand" "=r")
(match_operator:SI 1 "shiftable_operator"
[(match_operator:SI 3 "shift_operator"
[(match_operand:SI 4 "s_register_operand" "r")
(match_operand:SI 5 "reg_or_int_operand" "rI")])
(match_operand:SI 2 "s_register_operand" "r")]))]
"TARGET_ARM"
"%i1%?\\t%0, %2, %4%S3"
[(set_attr "predicable" "yes")
(set_attr "shift" "4")
]
)
And the insn
(insn 74 72 66 (set (reg/f:SI 3 r3 [84])
(plus:SI (mult:SI (subreg:SI (reg/v:DI 4 r4 [69]) 0)
(const_int 8 [0x8]))
(reg/v:SI 1 r1 [66]))) 319 {*arith_shiftsi} (nil)
(nil))
cleanup_subreg_operands ends up calling alter_subreg twice, the first time
when walking the MULT (which matches the "shift_operator" operand) and the
second time when processing operand[4] directly: on the second call
operand[4] is no-longer a subreg and the compiler segfaults. This occurs
because although recog_data.operand_loc[4] has been fixed,
recog_data.operand[4] still contains a subreg (but we then call
alter_subreg with something that isn't a subreg).
It's not immediately obvious to me what the best fix is. Three possible
approaches spring to mind (in rough order of my preference):
1) Test *recog_data.operand_loc[i] for being a subreg rather than
recog_data.operand[i]
2) Make alter_subreg do nothing if it isn't passed a subreg.
3) Make cleanup_subreg_operands ignore match_operator operands.
Do you have an opinion?
R.