On Tue, Mar 08, 2022 at 05:12:43PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote:
> > > But like I said above, even if we didn't copy these XVECLEN 0 rtvecs,
> > > the crash would not go away.
> >
> > An rtvec should never have length 0. Look at gen_rtvec for another
> > example.
>
> That is not true. In case of ASM_OPERANDS, lots of code relies that it
> can use ASM_OPERANDS_{INPUT,LABEL}_LENGTH without checking if
> ASM_OPERANDS_{INPUT,LABEL}_VEC is non-NULL. Those ASM*LENGTH macros are
> defined as XVECLEN which I believe will just segfault if the vec is NULL:
> #define XVECLEN(RTX, N) GET_NUM_ELEM (XVEC (RTX, N))
> #define GET_NUM_ELEM(RTVEC) ((RTVEC)->num_elem)
> #define XVEC(RTX, N) (RTL_CHECK2 (RTX, N, 'E', 'V').rt_rtvec)
> cfgexpand.cc as Marek said will allocate even zero length vectors using
> rtvec_alloc (0):
> rtvec argvec = rtvec_alloc (ninputs);
> rtvec constraintvec = rtvec_alloc (ninputs);
> rtvec labelvec = rtvec_alloc (nlabels);
> or e.g. in
> PATTERN (insn) = gen_rtx_ASM_OPERANDS (VOIDmode, ggc_strdup (""), "", 0,
> rtvec_alloc (0),
> rtvec_alloc (0),
> ASM_OPERANDS_LABEL_VEC (tmp),
> ASM_OPERANDS_SOURCE_LOCATION(tmp));
Wow, what a mess. And this part is completely undocumented even :-(
It seems unintentional (and wrong) to me, but yes we are in stage 4, if
we want to clean this up one way or the other, now is not the time.
In that case: your patch looks good to me Marek.
Segher
