This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

New bootstrap failure on ARM


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]