This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, ira] Invalid assert in reload1.c::finish_spills?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]