On Thu, 2014-09-04 at 22:22 +0200, Jakub Jelinek wrote: > On Thu, Sep 04, 2014 at 04:04:17PM -0400, David Malcolm wrote: > > --- a/gcc/rtl.h > > +++ b/gcc/rtl.h > > @@ -195,6 +195,7 @@ union rtunion > > unsigned int rt_uint; > > const char *rt_str; > > rtx rt_rtx; > > + rtx_insn *rt_insn; > > rtvec rt_rtvec; > > enum machine_mode rt_type; > > addr_diff_vec_flags rt_addr_diff_vec_flags; > > @@ -1208,6 +1209,7 @@ extern void rtl_check_failed_flag (const char *, > > const_rtx, const char *, > > #define XUINT(RTX, N) (RTL_CHECK2 (RTX, N, 'i', 'n').rt_uint) > > #define XSTR(RTX, N) (RTL_CHECK2 (RTX, N, 's', 'S').rt_str) > > #define XEXP(RTX, N) (RTL_CHECK2 (RTX, N, 'e', 'u').rt_rtx) > > Shouldn't XEXP be changed into RTL_CHECK1 (RTX, N, 'e').rt_rtx > then and the accessors of first operand of INSN_LIST and only operand of > LABEL_REF be changed to XINSN too? Of course doesn't have to be done > immediately, can be done as a followup.
I suppose so, but I don't see an easy way of locating such XEXP users beyond building with ENABLE_RTL_CHECKING, and checking on every configuration, and trying to exercise all code paths. Can we consider that a *long-term* followup? Use of XINSN does introduce a hole in the rtx-classes type-safety scheme, in that it's only checked with ENABLE_RTL_CHECKING. I considered it acceptable in the given patch since the SET_NEXT_INSN/SET_PREV_INSN lvalue accessors return an rtx_insn *& and thus will only accept an rtx_insn * as an rvalue - but I'm a bit nervous about its use elsewhere in the code; I'd rather we used rtx_insn_list for homogeneous lists of INSN_LIST nodes, and maybe an rtx_label_ref class for LABEL_REF, and perhaps an rtx_reg_note class for heterogeneous lists of INSN_LIST/EXPR_LIST/INT_LIST nodes for REG_NOTES. > > +#define XINSN(RTX, N) (RTL_CHECK1 (RTX, N, 'u').rt_insn) > > #define XVEC(RTX, N) (RTL_CHECK2 (RTX, N, 'E', 'V').rt_rtvec) > > #define XMODE(RTX, N) (RTL_CHECK1 (RTX, N, 'M').rt_type) > > #define XTREE(RTX, N) (RTL_CHECK1 (RTX, N, 't').rt_tree) > > Jakub
