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:
Yup, they will segv. I've guarded a few spots with ASM_OPERANDS_LABEL_VEC
before using _LENGTH but there were just more and more crashes so I gave up.
> #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));
I didn't see the latter, but I wouldn't be surprised if there were more.
Marek
