[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Tue Sep 10 18:58:00 GMT 2019


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-bugzilla@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 rguenther@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.


More information about the Gcc-bugs mailing list