This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, ira] Invalid assert in reload1.c::finish_spills?
- From: Michael Matz <matz at suse dot de>
- To: SenthilKumar dot Selvaraj at microchip dot com
- Cc: gcc-patches at gcc dot gnu dot org, vmakarov at redhat dot com
- Date: Wed, 7 Aug 2019 12:38:38 +0000 (UTC)
- Subject: Re: [Patch, ira] Invalid assert in reload1.c::finish_spills?
- References: <87zhklmcmh.fsf@microchip.com>
Hi,
On Wed, 7 Aug 2019, SenthilKumar.Selvaraj@microchip.com wrote:
> gcc/testsuite/c-c++-common/pr60101.c fails with an ICE for the
> avr target, because of a gcc_assert firing at reload1.c:4233
>
> The assert (in the patch below) looks bogus to me, as it's in
> the if block of
>
> if (! ira_conflicts_p || reg_renumber[i] >= 0)
>
> For this testcase and for the avr target, ira_conflicts_p is
> false because build_conflict_bit_table bailed out early
> (conflict table too big).
> If reg_renumber[i] is now negative, the assert fires and causes
> the ICE.
>
> Getting rid of the assert (patch below) makes the ICE go away,
> not sure if that's the right fix though.
But that obviously can't work, because of the immediately following line,
also quoted in your patch:
> SET_HARD_REG_BIT (pseudo_previous_regs[i], reg_renumber[i]);
If reg_renumber[i] is negative that wreaks havok. So some other logic is
broken. If it's really okay to have reg_renumber be negative here without
IRA conflicts (and I don't know if that's the case), then the assert needs
to become a condition for this statement.
Ciao,
Michael.