Re: /mmix/arm-elf/sources/combined/gcc/libgcc2.c:367: RTL flag check: access macro used with unexpected rtx code `sequence' in emit_multi_reg_push, at config/arm/arm.c:7835

[Richard Earnshaw <rearnsha at arm dot com>]

> > /mmix/arm-elf/sources/combined/gcc/libgcc2.c: In function `__muldi3':
> > /mmix/arm-elf/sources/combined/gcc/libgcc2.c:367: RTL flag check: access macro used with unexpected rtx code `sequence' in emit_multi_reg_push, at config/arm/arm.c:7835
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> 
> This is from RTL flag checking, which was added a couple of days ago and
> enabled yesterday.  I added a couple of other new uses, but for this one
> see http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00799.html.
> 
> Janis

Hmm, looking at dwarf2out.c we have:

  /* If RTX_FRAME_RELATED_P is set on a PARALLEL, process each member of
     the PARALLEL independently. The first element is always processed if
     it is a SET. This is for backward compatibility.   Other elements
     are processed only if they are SETs and the RTX_FRAME_RELATED_P
     flag is set in them.  */
  if (GET_CODE (expr) == PARALLEL || GET_CODE (expr) == SEQUENCE)


So this comment seems to be out of sync with the code -- where's the test 
for RTX_FRAME_RELATED_P on the PARALLEL?  If it's now been removed then 
the comment is wrong and needs updating.

The current bit of code that is causing the problem in arm.c is:


  /* For the body of the insn we are going to generate an UNSPEC in
     parallel with several USEs.  This allows the insn to be recognised
     by the push_multi pattern in the arm.md file.  The insn looks
     something like this:

       (parallel [ 
           (set (mem:BLK (pre_dec:BLK (reg:SI sp)))
                (unspec:BLK [(reg:SI r4)] UNSPEC_PUSH_MULT))
           (use (reg:SI 11 fp))
           (use (reg:SI 12 ip))
           (use (reg:SI 14 lr))
           (use (reg:SI 15 pc))
        ])

     For the frame note however, we try to be more explicit and actually
     show each register being stored into the stack frame, plus a (single)
     decrement of the stack pointer.  We do it this way in order to be
     friendly to the stack unwinding code, which only wants to see a single
     stack decrement per instruction.  The RTL we generate for the note 
looks
     something like this:

      (sequence [ 
           (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20)))
           (set (mem:SI (reg:SI sp)) (reg:SI r4))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int 4))) (reg:SI fp))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int 8))) (reg:SI ip))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int 12))) (reg:SI lr))
        ])

      This sequence is used both by the code to support stack unwinding for
      exceptions handlers and the code to generate dwarf2 frame debugging. 
 */
  
  par = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (num_regs));
  dwarf = gen_rtx_SEQUENCE (VOIDmode, rtvec_alloc (num_dwarf_regs + 1));
  RTX_FRAME_RELATED_P (dwarf) = 1;


So are we saying that we shouldn't set RTX_FRAME_RELATED_P on the 
sequence?  If so, can we guarantee that the body of the note holding the 
sequence will be scanned if it is not set?

R.