[PATCH, ARM] fix .cfi inconsistency out of builtin_eh_return

[Olivier Hainque <hainque at adacore dot com>]

Hello,

Activating dwarf2 based eh for real on VxWorks6 (patch to come) triggers a
libgcc build failure, where most functions resorting to __builtin_eh_return
fail this check from maybe_record_trace_start in dwarf2cfi.c:

     /* We ought to have the same state incoming to a given trace no
	 matter how we arrive at the trace.  Anything else means we've
	 got some kind of optimization error.  */
     #if CHECKING_P
        if (!cfi_row_equal_p (cur_row, ti->beg_row))
        ...

The inconsistency is introduced by a store inserted in the middle of the insn
stream by arm_set_return_address for __builtin_eh_return, marked FRAME_RELATED
with:

     /* The store needs to be marked as frame related in order to prevent
        DSE from deleting it as dead if it is based on fp.  */
     rtx insn = emit_move_insn (gen_frame_mem (Pmode, addr), source);
     RTX_FRAME_RELATED_P (insn) = 1;
     add_reg_note (insn, REG_CFA_RESTORE, gen_rtx_REG (Pmode, LR_REGNUM));

The FRAME_RELATED ness was setup to fixed DWARF2 unwinding at
the time already, indeed broken by DSE removing the store - see
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01669.html.

The attached patch is a proposal to fix this by setting MEM_VOLATILE_P on
the store destination mem instead of setting RTX_FRAME_RELATED_P on the insn,
which alleviates the .cfi complications and is as effective in preventing
the store removal by DSE, from:

  /* Assuming that there are sets in these insns, we cannot delete
     them.  */
  if ((GET_CODE (PATTERN (insn)) == CLOBBER)
      || volatile_refs_p (PATTERN (insn))
      || (!cfun->can_delete_dead_exceptions && !insn_nothrow_p (insn))
      || (RTX_FRAME_RELATED_P (insn))
      || find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX))
    insn_info->cannot_delete = true;

For testing, I verified that

- an arm-wrs-vxworks build with the extra patch to activate DWARF2
  eh proceeds to completion on mainline,

- the same symptoms were visible and cured on our in-house
  gcc-7 based toolchain, and that

- ACATS are clean for Ada in this configuration after the patch, 
  confirming proper behavior of the DWARF2 exception propagation
  circuitry.

OK to commit ?

Thanks much in advance for your feedback,

With Kind Regards,

Olivier

Attachment: arm-set-return-address.patch
Description: Binary data