https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On September 10, 2019 8:11:35 PM GMT+02:00, "wilson at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683 > >--- Comment #16 from Jim Wilson <wilson at gcc dot gnu.org> --- >(In reply to rguent...@suse.de from comment #15) >> I still don't understand. The rtx are not relocated. The only thing >is the >> address of the slot of the regno to rtx map. > >I have a debug session in comment 6 that shows that this address is >changing. >But maybe what you are missing here is how combine changes registers >modes. It >uses a call like this > SUBST_MODE (regno_reg_rtx[REGNO (i2dest)], split_mode); >and this macro is defined as >#define SUBST_MODE(INTO, NEWVAL) do_SUBST_MODE (&(INTO), (NEWVAL)) >so we are saving an address in the regno_reg_rtx array. > >I don't know exactly why it works this way, and I don't care, because I Probably to avoid saving an address of a local variable. The question is why we are in the end recording the address of the reg into the undo buffer... Anyway, fixing it properly likely requires quite some work. >don't >think that fixing this is the right solution for the RISC-V port. I >think the >RISC-V port should stop calling gen_reg_rtx inside splitters. > >The patch where this code appeared suggests that it was a rare hard to >reproduce bug that required this fix. >https://gcc.gnu.org/ml/gcc-patches/2006-01/msg00477.html >Maybe SUBST_MODE was just blindly copied from SUBST_INT, and it was >missed that >it might work without the & in this case. This may also depend on how >exactly >SUBST_MODE is used, but currently it is only used for regs, which are >supposed >to be unique, so dropping the & may work. This may not work if >SUBST_MODE gets >used for otherwise, but currently it isn't.
