On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote:
> On Tue, Mar 08, 2022 at 10:25:45AM -0500, Marek Polacek wrote:
> > On Tue, Mar 08, 2022 at 09:14:56AM -0600, Segher Boessenkool wrote:
> > > On Tue, Mar 08, 2022 at 10:08:25AM -0500, Marek Polacek wrote:
> > > > ...I don't see that. In fact copy_rtx does the same thing as
> > > > copy_insn:
> > > >
> > > > case 'V':
> > > > if (XVEC (orig, i) != NULL)
> > > > {
> > > > XVEC (copy, i) = rtvec_alloc (XVECLEN (orig, i));
> > > >
> > > > which will copy a zero-length vector too, right?
> > >
> > > It doesn't. It copies NULL as NULL. That is what that "if" is for.
> >
> > But XVEC (orig, i) is not null, it just has XVECLEN 0.
>
> So where did *that* come from? This isn't correct RTL.
I already said it before:
The zero-length rtvec is originally created in expand_asm_stmt:
rtvec labelvec = rtvec_alloc (nlabels);
where nlabels is 0 but using NULL_RTVEC instead just means crashes everywhere.
> > > You can do similar in copy_insn_1?
> >
> > You mean copy_rtx? It already has the same XVEC (orig, i) != NULL check.
>
> No, I mean do similar in copy_insn_1 as what copy_rtx already
> (correctly) does.
Do similar what? They already do the same thing with XVECs as I've said
twice. If you mean something other than the 'V' case, please be explicit.
> > 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.
>
> You can get rid of the crash, sure. But it is a much better plan to try
> and get rid of the actual problem! (And then add some more checking to
> make sure this doesn't happen in the future.)
Yes, I realize that. That's why I've tried using NULL_RTVEC in expand_asm_stmt
rather than using a zero-length rtvec. It resulted in crashes in, for instance,
jump.cc. So I'm not sure if such a fix is suitable for stage4. I may try
again.
Marek
